Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Oct 24 2020
Oct 24

This month’s SC DUG featured Mauricio Orozco posing questions about getting started as a consultant to long-time members who have all done some work with Drupal as a consultant.

https://www.youtube.com/watch?v=4NG5lgDOFzs

If you would like to join us please check out our upcoming events on Meetup for meeting times, locations, and remote connection information.

We frequently use these presentations to practice new presentations, try out heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.

Oct 09 2020
Oct 09

In this video I show a set of Open Source tools we have created to manage the whole application lifecycle when embedding JS apps inside of Drupal.

You can fork these tools, and with a couple of clicks you will get a demo of progressive decoupling in Drupal in your own site. This works in Drupal 8 and Drupal 9.

It is important to note that this is not only my work. This is a team effort that I collaborated with. Team mates Zequi Vázquez, Ian Whitcomb, and Hunter MacDermut are also the main authors of different parts of the system. I cleaned it up and made it generic so it could be shared as free software.

[embedded content]

Screenshots

Static HTML embed The example widget has a demo page you can show to stakeholders for quick validation. Drupal embed Seamless integration of the JS applications in Drupal, including layout builder.
Oct 07 2020
Oct 07

argument-open-source

Here’s a dirty secret: most businesses are unsatisfied with their website. Research shows that 34% of website owners are unsatisfied with the amount of business their website generates for them. Loudhouse data suggests that 62% of business owners believe a more effective website would increase their sales. And millions of business websites deal with slow load times, inconsistent customer experiences, and problematic UI/UX issues.

There’s a reason that 36% of small businesses STILL don’t have a website. Creating an amazing, design-driven, customer-centric website is challenging. So, what do you do when your website isn’t making the cut? You look towards the source — your Content Management System (CMS). Every year, thousands of private and public entities migrate their website to a new CMS.

But, unfortunately, thousands more don’t. Migration is scary. It’s easier to stay with your current CMS and focus on redesigns or new templates. Here’s the problem: new coats of paint don’t fix broken engines. If you’re thinking about migrating from WordPress or Joomla to Drupal, you’ve probably heard rumors and myths regarding migrations.

Let’s clear those up. Here are 4 myths about migration that need to be squashed.

Myth #1: I’m Going to Lose All My Content/Data

This is, by far, the most common excuse against migrating. You’re worried all of that precious content and data are going to fall off the ship if you switch ports. And, you’re right to worry. It could… if you don’t migrate correctly. But it’s not inevitable. You can prevent data and content loss. In fact, if you lose data or content, we would consider that a failed migration. In other words, successful migrations keep data and content intact by definition.

Here are some handy-dandy steps you can take to ensure that your precious data doesn’t go overboard during your migration:

  • Crawl your site before migration and use the crawl data to check for URL issues. If you check each URL, you should be able to see any missing content (and fix it!)
  • Keep your existing site stable until you’ve fully migrated.
  • When you migrate, check for duplicate content; plenty of site owners run into the opposite of losing content.

Myth #2: I Have to Invest in a Redesign

You’re migrating; you might as well invest in a redesign, right? Sure! You could. But it’s tricky. When you do a redesign and a migration, you’re no longer just matching URL-to-URL and content-to-content, you’re simultaneously rebuilding your website. Don’t get us wrong; there are advantages. It’s a great time to redesign from an SEO perspective (you’re already going to take a small hit during the migration; more on this in the next section), but it also requires significantly more planning, budget, and time.

If you want to do a redesign-migration, we heavily recommend that you touch base with your design company. You want to work through the kinks and create a best-in-class action plan to tackle any issues that may (or may not) pop up. The entire migration will be structured around the redesign, so it’s important to carefully weigh your options.

Myth #3: Goodbye SEO!

From an SEO perspective, migration sounds like a nightmare. You’ve worked diligently to build up your SEO. What happens when you frolic to a new location? Let’s get this out of the way: your SEO will take a temporary hit. But, it shouldn’t last long. In fact, there’s a good chance you’re moving to another platform because it’s better at handling SEO. For example, Drupal has built-in SEO capabilities (e.g., title-based URL nodes, customizable meta tags, etc.) WordPress does not. Obviously, you can get SEO plugins for WordPress that help you build SEO functionalities, but most of those plugins are also available for Drupal — so Drupal gives you a net gain.

Here’s a secret: migration can help your page rank. After the first awkward week (Google has to recrawl your website, recognize that it’s you, and give you back your ranking), migration can help you build a more powerful SEO framework.

Want to migrate without dumping your SEO overboard? Here are some tips:

  • Update your internal links
  • Benchmark your Google Analytics profile and compare it with your analytics post-migration to look for gaps
  • Keep any old domains and redirect your website
  • Check for broken or duplicate content that could tank your SEO
  • Manage your sitemaps
  • Update any PPC campaigns and ad creatives

Myth #4: You Just Have to “Lift-and-Shift”

There are plenty of myths surrounding the difficulty of migration. But there are also a few myths making migration out to be super easy. And, without a doubt, the most prevalent “easy-peasy-lemon-squeezy” migration myth is the ever-coveted “lift-and-shift.” There is no one-size-fits-all strategy for migrating websites. Sometimes, it can be as easy as lifting content off of one website and putting it onto another website. But that’s seldom the case.

Generally, you need to set up test servers, check to see if website elements function correctly on the new platform, test out and utilize new CMS features, and a variety of other tasks before you can simply drop content from one place to another. In other words, lift-and-shift may work when you’re migrating a cloud environment, but it often doesn’t work with CMS migration.

Remember, just because everything worked perfectly in one environment doesn’t mean it will in another one. You may have to fix some website elements and carefully construct your new website ecosystem. At the same time, you’ll probably be playing around with the new features available to you on Drupal — so the “lift-and-shift” is usually more of a “lift-and-test-and-shift.”

Do You Need Help With Your Drupal Migration?

At Mobomo, we help private and public entities migrate to Drupal environments using proven migration strategies and best-in-class support. So, whether you’re looking to establish your website in a more secure, SEO-friendly environment or you’re looking to do a redesign-and-migrate, we can help you migrate pain-free. Are you ready to move to a brighter future?

Contact us. We’ve got your back.

Oct 05 2020
Oct 05

argument-open-source

2020 has been a year full of unexpected surprises and challenges. In March, the coronavirus had reached the United States and had begun spreading quickly causing federal and state governments to take action to ensure public safety, including the development and passing of the Coronavirus Aid, Relief, and Economic Security Act (CARES Act). As the pandemic spread, many more eyes turned to the government to watch how they were navigating this new unmarked territory. 

The Pandemic Response Accountability Committee (PRAC) created PandemicOversight.gov to display the details of the $2.6 trillion coronavirus relief spending provided by the CARES Act. The website allows the public interactive tools for understanding who received coronavirus funding, how much they’ve received, and how the funds are being spent. The website also provides tools for the public to report fraud, waste, abuse, and mismanagement of coronavirus relief funding, as well as helpful information to protect yourself against fraudulent activity. 

Mobomo was brought in to perform the redesign and development of the website, which had initially launched as pandemic.oversight.gov earlier this year. The Mobomo team was able to do a complete overhaul of the legacy platform and re-launch the system in just over five weeks’ time with the new website having been officially launched to the public on September 10th. Since the launch, the website has received thousands of visitors interested in learning more about who, where, and how coronavirus relief funding is being spent. 

“Transparency in government is critical in these uncertain times and the mission of the PRAC strives to provide that public service. I’m very proud of what our team has developed and hope the website helps people see how relief funding is being distributed.” – Brian Lacey, CEO.

Not Your Average Government Website

The Mobomo team redesigned PandemicOversight.gov with the goal of incorporating modern theming and a clean design that many of your traditional government information sites lack, but did so while incorporating 18F and US Web Design Standards best practices.  Mobomo’s User Experience team worked with the PRAC to develop mobile-first, responsive design templates that mesh the innovative branding and theming with the high-fidelity interactive visualizations that are key to communicating coronavirus funding activity. 

Let’s Get Technical

The legacy pandemic.oversight.gov was developed in Drupal 8 and hosted in Amazon Web Services (AWS). For the redesign and re-launch of the site, the Mobomo team decided to rebuild the content management system leveraging the latest version of Drupal 9 and deployed the solution within the Microsoft Azure Websites platform-as-a-service (PaaS) environment. Mobomo developed a number of custom feature integrations with visualization partners Domo and Woolpert, enhanced search indexing for browsing various oversight reports and investigations, and optimized process for users to communicate instances of fraud, waste, and abuse through secure channels. 

In order to meet the tight five-week window for design, development, and deploying the new website – the Mobomo team leveraged containerization and Lando for streamlining local development and hooking into the continuous integration, continuous development (CI/CD) pipeline. Mobomo also worked with the Smartronix Azure Cloud team to architect a zero-downtime deployment procedure to allow seamless promotion of new code the public environment. 

“This is a great team on both sides of the table. For such an expedited delivery schedule, it is critical for all the contract partners and government stakeholders to stay Agile and collaborate effectively to succeed.” – Austin White, VP of Federal Services.

For more information on Mobomo’s work with the Federal Government click here.

About the PRAC

The Pandemic Response Accountability Committee (PRAC) was established by the CARES Act as part of the committee of the Council of the Inspectors General on Integrity and Efficiency (CIGIE). The PRAC has developed a Strategic Plan for the next five years that details how PRAC will serve the public by promoting transparency of funds and by preventing and detecting fraud, waste, abuse, and mismanagement of said funds. The committee will work closely with the Federal Inspectors General to support all affected by the pandemic. 

Our Partners
Pandemic Response and Accountability Committee (PRAC)
Council of the Inspectors General on Integrity and Efficiency (CIGIE)
Smartronix
Domo
Woolpert
Grant Thornton

Sep 30 2020
Sep 30

Our Drupal contributions history

Srijan has been part of the Drupal community for over 12 years. From very early on, we (Srijan) have been contributing to the Drupal project in multiple ways, from sponsoring nearly all DrupalCons since 2013, to regularly contributing code to core and contrib projects.

Many of our people have been mentors for new contributors at DrupalCons and local meetups. For the past 2-3 years, we even had a dedicated open-source community manager within the organization.

 

One of the earliest Drupal.org media case studies, published in 2009

Due to the COVID pandemic, we had a fairly large bench earlier this year. Given this, we decided to create three dedicated contribution teams to leverage this time efficiently and increase our contributions. During the same time, Drupal India Association (DIA) had set out a big-hairy-audacious-goal (BHAG) of putting DIA among the highest contributors globally.

Years of contributions and the above 2 events improved our overall ranking in the Drupal marketplace.

Where we fell short

Highly motivated by the dual goal of putting DIA on the marketplace and improving Srijan's ranking in the marketplace, some of our team members digressed from the objective and started "gathering contribution credits".

Soon we realized that out of the 25 contributors, a few were making mistakes like "assigning/unassigning issues without comments", or "submitting duplicate patches", meanwhile gathering credits intentionally or unintentionally in the process.

We acted immediately, realizing our mistake that we had not conducted a D.O "contributions code of conduct" training — as most of them were first-timer contributors.

We asked some of our seasoned contributors to organize a code of conduct training. These contributors led an internal training session to reiterate the Drupal code of conduct as well as build an internal best practices checklist for contributors at Srijan.


                        A screenshot from the training session

While this session helped in improving the quality of the contributions, we still noticed that a few people were not following all the best practices. Community members were still tagging Srijan and registering their complaints…we acted again.

This time we ‘painstakingly’ made a comprehensive report to identify the key issues and the defaulters.

The following unhealthy practices were identified and each team member was evaluated against these-

  1. Assigning/unassigning without comments
  2. Hopping/hijacking issues - i.e.,not reading the issue history and submitting incomplete patches
  3. Submitting duplicate patches
  4. Incorrect patches, or patches without comments/screenshots

Self-evaluation form filled by each team member, against each issue worked on

This detailed evaluation process took about 2 weeks to complete but helped us address the quality issues. These evaluation sheets will be maintained regularly going forward.

Conclusion

With the above steps, we eventually succeeded in putting a stop to the breach of the ‘code of conduct’ by a few overzealous (or careless) contributors.

We should have done a "code of conduct training" and set up a monitoring system so that we could have avoided these incidents. But that’s the benefit of hindsight.

On behalf of Srijan, I would like to apologize to the Drupal module maintainers and core contributors (including other Srijan contributors) who had to face unnecessary challenges due to some of our nonchalant actions.

Srijan is and will remain among the leading contributors to the Drupal community and a responsible one at that.

The purpose of this post is to address our problem of being tagged on Slack in the Drupal group, rectify them with the right practices, and share this learning experience with others to help them avoid these slip-ups.

I would like to end this post by highlighting some of the positive attention that Srijan’s contribution teams have received during the past few months.

Sep 23 2020
Sep 23

Working in digital design and development, you grow accustomed to the rapid pace of technology. For example: After much anticipation, the latest version of Drupal was released this summer. Just months later, the next major version is in progress.

At July’s all-virtual DrupalCon Global, the open-source digital experience conference, platform founder Dries Buytaert announced Drupal 10 is aiming for a June 2022 release. Assuming those plans hold, Drupal 9 would have the shortest release lifetime of any recent major version.

For IT managers, platform changes generate stress and uncertainty. Considering the time-intensive migration process from Drupal 7 to 8, updating your organization’s website can be costly and complicated. Consequently, despite a longtime absence of new features, Drupal 7 still powers more websites than Drupal 8 and 9 combined. And, as technology marches on, the end of its life as a supported platform is approaching.

Fortunately, whatever version your website is running, Drupal is not running away from you. Drupal’s users and site builders may be accustomed to expending significant resources to update their website platform, but the plan for more frequent major releases alleviates the stress of the typical upgrade. And, for those whose websites are still on Drupal 7, Drupal 10 will continue offering a way forward.

The news that Drupal 10 is coming sooner rather than later might have been unexpected, but you still have no reason to panic just yet. However, your organization shouldn’t stand still, either.

Image via Dri.es

The End for Drupal 7 Is Still Coming, but Future Upgrades Will Be Easier

Considering upgrading to Drupal 8 involves the investment of building a new site and migrating its content, it’s no wonder so many organizations have been slow to update their platform. Drupal 7 is solid and has existed for nearly 10 years. And, fortunately, it’s not reaching its end of life just yet.

At the time of Drupal 9’s release, Drupal 7’s planned end of life was set to arrive late next year. This meant the community would no longer release security advisories or bug fixes for that version of the platform. Affected organizations would need to contact third-party vendors for their support needs. With the COVID-19 pandemic upending businesses and their budgets, the platform’s lifespan has been extended to November 28, 2022.

Drupal’s development team has retained its internal migration system through versions 8 and 9, and it remains part of the plan for the upcoming Drupal 10 as well. And the community continues to maintain and improve the system in an effort to make the transition easier. If your organization is still on Drupal 7 now, you can use the migration system to jump directly to version 9, or version 10 upon its release. Drupal has no plans to eliminate that system until Drupal 7 usage numbers drop significantly.

Once Drupal 10 is ready for release, Drupal 7 will finally reach its end of life. However, paid vendors will still offer support options that will allow your organization to maintain a secure website until you’re ready for an upgrade. But make a plan for that migration sooner rather than later. The longer you wait for this migration, the more new platform features you’ll have to integrate into your rebuilt website.

Initiatives for Drupal 10 Focus on Faster Updates, Third-Party Software

In delivering his opening keynote for DrupalCon Global, Dries Buytaert outlined five strategic goals for the next iteration of the platform. Like the work for Drupal 9 that began within the Drupal 8 platform, development of Drupal 10 has begun under the hood of version 9.

A Drupal 10 Readiness initiative focuses on upgrading third-party components that count as technological dependencies. One crucial component is Symfony, which is the PHP framework Drupal is based upon. Symfony operates on a major release schedule every two years, which requires that Drupal is also updated to stay current. The transition from Symfony 2 to Symfony 3 created challenges for core developers in creating the 8.4 release, which introduced changes that impacted many parts of Drupal’s software.

To avoid a repeat of those difficulties, it was determined that the breaking changes involved in a new Symfony major release warranted a new Drupal major release as well. While Drupal 9 is on Symfony 4, the Drupal team hopes to launch 10 on Symfony 6, which is a considerable technical challenge for the platform’s team of contributors. However, once complete, this initiative will extend the lifespan of Drupal 10 to as long as three or four years.

Other announced initiatives included greater ease of use through more out-of-the-box features, a new front-end theme, creating a decoupled menu component written in JavaScript, and, in accordance with its most requested feature, automated security updates that will make it as easy as possible to upgrade from 9 to 10 when the time comes. For those already on Drupal 9, these are some of the new features to anticipate in versions 9.1 through 9.4.

Less Time Between Drupal Versions Means an Easier Upgrade Path

The shift from Drupal 8 to this summer’s release of Drupal 9 was close to five years in the making. Fortunately for website managers, that update was a far cry from the full migration required from version 7. While there are challenges such as ensuring your custom code is updated to use the most recent APIs, the transition was doable with a good tech team at your side.

Still, the work that update required could generate a little anxiety given how comparatively fast another upgrade will arrive. But the shorter time frame will make the move to Drupal 10 easier for everybody. Less time between updates also translates to less deprecated code, especially if you’re already using version 9. But if you’re not there yet, the time to make a plan is now.

Sep 08 2020
Sep 08

The Drupal Association is running an election to one seat for the board of directors from the community. I asked this questions to all candidates.

I believe that engagement with the Drupal Association is not optional if you want to participate in the Drupal project in any way.

  • The Drupal Association manages drupal.org (ticketing + releases + documentation + API docs + outstanding communications + translations + security coverage). This is not optional for any individual.
  • The Drupal Association manages DrupalCon. This is optional for individuals.
  • The Drupal Association oversees the CWG. This is not optional for individuals.

Maybe some day engagement with the Drupal Association will be optional, but my opinion is that it is not optional today. This is why I think that the Drupal Association cannot act only in its own best interest, but it needs to act on the best interest of the people contributing to the project. That is regardless of their affiliation and/or feelings towards the association.

On that vein I asked all candidates this:

Excuse me if I make no sense in my questions. I am no lawyer either, and the U.S. is not my home country. My questions are framed around legal figures, however I only intend to get a sense of what your values are as a potential director.

The Drupal Association (DrupalCon Inc.) currently declares itself as a 501(c)(3) (as per 2018's tax filing). According to the IRS website:

A section 501(c)(3) organization must not be organized or operated for the benefit of private interests, such as the creator or the creator's family, shareholders of the organization, other designated individuals, or persons controlled directly or indirectly by such private interests. No part of the net earnings of a section 501(c)(3) organization may inure to the benefit of any private shareholder or individual. A private shareholder or individual is a person having a personal and private interest in the activities of the organization.

(emphasis of my own)

I sense a lot of effort in promoting business using Drupal in what the Drupal association does (my perception might be wrong). From my limited understanding, this is typical from 501(c)(6) organizations (Business leagues, Chambers of commerce, Boards of trade, ...). For context, the Linux Foundation declares itself as 501(c)(6) (as per 2018's tax filing).

My questions are:

  1. Do you feel the current Drupal Association is living to the 501(c)(3) spirit? (I am not asking about the legality, but the spirit).
  2. Should a voting arise: do you lean towards promoting the project itself and stay as a 501(c)(3)? or do you think that promoting business with Drupal is the best course of action and, therefore, the Drupal Association should become a 501(c)(6)?

My questions are geared towards: how will you position yourself in the balance between promoting the common good vs. fostering healthy business using Drupal? But I would love to get specific answers to the two questions above.

Aug 04 2020
Aug 04

Drupal allows the creation of multivalue fields. Wouldn’t it be useful to have a way to enter all the values for that field as comma separated values? I wrote a module for that.

This video shows the how to configure a textfield to accept comma separated values that are interpreted as multiple values for the field. Learn more at Comma Separated String Widget.

[embedded content]

Usage

Step 1

Configure your text field to use the new widget. Screenshot of the configuration

Step 2

Profit. Screenshot of the widget

Photo by Brook Anderson on Unsplash

Jul 19 2020
Jul 19

Many enterprises use Drupal for the flexibility it offers. This comes at a cost, every Drupal site is very different from each other. Patterns emerge that are not reused or standarized across different projects.

This video proposes a code structure and workflow when working around entities with Typed Entity. This has helped me in the past to achieve more maintainability and modularity in my Drupal projects.

[embedded content]

Photo by Neven Krcmarek on Unsplash

Jun 05 2020
Jun 05

In anticipation o' th' June 3rd launch o' Drupal 9, I spent the weekend a week previous to the launch dustin' off th' tha Drrupal module I'm most famous fer: th' Pirate module! What does it do, exactly? Like th' WP extension, th' Pirate module changes yer site's content t' pirate-speak on September 19th, International Talk Like a Pirate Day. I took th' tagline ("Ah, Squiddy! I got nothin' against ye. I just heard thar were bein' gold in yer belly. Ha ha har, ha ha ha har!"), which I buried in th' configuration, from a non-pirate, sea captain Horatio McCallister. (Spoiler alert: The ornery cuss's not even a real sea Cap'n.) It adds a text filter (previously known as an input format) t' whatever field ye specify, an' on September 19th, that field's content is changed into vari'us pirate-like sayin's, interspersed with yarr! an' avast! Durin' Drupal's semantic versioning transition, versions 8.x-1.1 forward be intended t' be fully compatible with tha Drrupal 9.

The module started out as an internal ticket at Bryght in 2005. Boris Mann came across th' Talk Like a Pirate plugin fer WordPress, an' since both tha Drrupal an' WordPress be written in PHP, he wanted it ported o'er. I took th' ticket, 45 minutes before a colleague saw it an', almost 15 years later, it serves as th' project I use t' keep up with tha Drrupal internals. Thanks t' a patch from Snehal Brahmbhatt, later confirmed by a robot, I am able t' legitimately claim that th' module has full tha Drrupal 9 compatibility. (Unlike th' move from tha Drrupal 7 t' 8, Drupal 9 is an update, not a rebuild.) It has had an official release fer all versions o' tha Drrupal since 4.6.

Over th' weekend o' updatin' th' module fer D9, I caught wind o' DrupalSpoons, an' without fullin' realizin' th' implications, I applied t' have the Pirate module mirrored there. (Moshe was excited!) After readin' the DrupalSpoons announcement, I understood it t' be an experiment in usin' GitLab as th' issue queue an' repository platform more directly than th' tha Drrupal core an' contributed modules projects, which uses GitLab as an underlying provider for their official repositories. As long as code an' issues be synced betwixt th' two, I dern't have a problem pushin' an' respondin' in both spaces.

I'm lookin' forward t' September 19th this year an' years t' come. Yarr!

Jun 02 2020
Jun 02

End of life (EOL) software is a very real problem. Whether your business is using ecommerce and customer relationship management systems across multiple platforms or relying on basic scheduling and accounting software, you will at some point reach a technological expiry date.

Acro Media has developed a 6 step action plan for handling software end of life. View it here >>

When a system reaches end of life, the creator/owner of the software/technology no longer delivers support services for the product. That can include technical support, hardware or software upgrades, bug fixes, security patches, or feature development. In short, the system gets abandoned by its owner. 

Software becoming obsolete can cause all sorts of problems. Here are a few of the  risks to your business in running EOL software:

1. Compromised security

If you hold people's information and data, you are responsible and liable for it.

End of life technology receives no security updates. No bug fixes. No patches. No monitoring. Your technology is dead in the eyes of the creator. That means your security is completely compromised, not only for the platform that is EOL, but also potentially for any others that connect to it.

At minimum, your system can be accessed and your content or records edited, stolen, or deleted. If you have any user data, financial data, or sensitive information, you could have a major problem. The monetary and reputational cost could kill your business.

A survey of 2,600 CIOs across the U.S. found that the number one concern was keeping systems and information secure. By being proactive and not letting your systems reach their end of life, your company is better positioned to ensure that your data, and your customer’s information remains secure.

2. Lack of reliability

If you were a taxi driver, would you willingly drive an old car that is no longer maintained and has sporadic issues? Of course not. That’s because your livelihood relies on the economics of your vehicle. 

But that is what you are doing if you continue with EOL software. Old software is less reliable and more prone to failure. 

Maintaining EOL software is complex and expensive, and integrations into other systems require even more time-consuming and expensive workarounds. 

Regular updates, bug fixes and support in general goes away at EOL, which makes system maintenance much more difficult. Instead of spending your resources on new tools or building better customer experiences, you are stuck paying top dollar for fixes and updates no longer covered by the software creator.

Which brings us to our final point...

3. Higher operational costs

EOL software costs more, whether it’s through lost/stolen data, updating and maintaining with third parties, legal liabilities, or lost revenue from downtime or issues. 

The sticker price on a new system can sometimes seem large and prohibitive from a business point of view. But, consider the consequences of a security breach, or a major bug. The peace of mind  that comes with having a fully secure and supported system that won’t arbitrarily go offline is worth its weight in gold.

Another benefit from moving away from EOL software is the opportunity to review your company's entire technology stack/architecture. If you have software moving towards EOL, it's essential to look at not only replacing the single system, but also assessing your whole technology landscape for opportunities to make larger improvements.

Conclusion

Ultimately, EOL technology is costly to your business in multiple ways. Most technology providers give lots of notice when one of their products is going to be unsupported. That gives you time to assess your options and determine the path you should take. 

To help you assess your options download our 6 step action plan for handling software end of life.

Download the End of Life Playbook (PDF)

Editor’s Note: This article was originally published on June 2, 2020 and has been updated for freshness, accuracy and comprehensiveness.
May 26 2020
May 26

Many costs are associated with developing a new ecommerce site or migrating from an antiquated setup to an upgraded version. And unless you work in the thick of ecommerce development every day, you likely don't know what questions to ask to ensure you’re getting the full picture.

This article explains what your typical expenses will look like and makes a few suggestions about how to approach budgeting for this undertaking.

Open Source vs. SaaS: A Comparison of Costs

You need to decide whether you will go with open source or a Software-as-a-Service (SaaS) platform to power your site. The cost of doing business is very different with each model.

An open source ecommerce framework has the expenses front-loaded. You pay for development time and configuration costs, and then the final product is yours to own and manage—license-free. 

A SaaS approach is quicker to get live and has lower costs up front. But then you pay an annual license fee and give a percentage of your revenue to the platform with each transaction made. 

Start by doing some easy math. Calculate three percent of your average annual sales. With an SaaS approach, if you sell $50 million online each year, you'll pay $1.5 million in revenue share (on top of licensing fees). If that is an acceptable cost of doing business and allows you to “set it and forget it," then SaaS is likely the right way to go for you.

But if you're a business that needs or wants more control of the front- and back-end experiences, you can use that three percent as a starting point to decide how to shape and invest in your online architecture. With open source software, you’d invest this money up front in year one. In years two and beyond, expenses taper down to about 15 percent of this initial investment annually to keep operational. 

Complete this exercise in relation to your own revenue and figure out what your working budget would be to get started. If three percent leaves you with peanuts, I’d suggest searching out a DIY platform-first ecommerce tool and seeking the help of an independent contractor to start generating revenue online. Your year-one investment may look closer to 50 percent of your annual online revenue to get where you need to be. 

Try to avoid thinking of this as an expense. Instead, think of how much money you’re going to spend to get a return on investment. How long will it take you to earn that ROI? Are these expectations realistic?

How to Budget for an Open Source eCommerce Architecture

Moving from an existing platform (typically SaaS or home-brew) over to a fully open source, headless ecommerce architecture setup incurs costs like:

Planning

Planning is the backbone of a successful ecommerce development project. If you don’t spend the time and money to work out that foundational blueprint, you will get a half-assed outcome that will likely cost more than you were initially promised.

On average, the planning processes for building a substantial ecommerce site for businesses that generate $50 million or more in revenue take 10 weeks of work and cost about $50,000. 

Planning is the absolute MUST-DO on your list. If you skip it, you may save $50,000, but your project will spend it on the other end trying to figure out who meant what because you flew cheap and blind. 

Ask if your proposed agency completes the following activities in their planning phase: 

  • Visualization / live prototyping 
  • Conversion planning, persona development, user journeys 
  • API integration planning, platform and integration reviews and selections 
  • ERP / product mapping 
  • Server and dev ops planning, security, performance and scalability planning

If you’re being pitched the above list, and you can see working past examples of blueprints such as these, then you’re spending your money wisely and you have a shot at getting this project right the first time. 

TIP: This plan should be detailed enough that you can either take it and build out your new site in its entirety with your on-staff tech team, or take it to ANY agency and have a crystal-clear spec for execution. 

Planning is not conceptual. It is a fully operational blueprint that the engineers have stamped and approved. This is a one time cost and the most essential ingredient in your budget. 

If you can only afford to get through planning in year one, make it a priority and wait for the next round of capital expenditure funding to implement it.  

Creative Design

Designing a new eComm site is the fun part. This phase of the project should be done after planning is fully signed off on. That’s because planning allows ideas to flow and evolve. And changes in functionality dictate front-end experiences. 

Your design phase will vary in price depending on what you want to see mocked up versus just built by the team without your input. Set aside $25,000 to $45,000 to make sure your creative phase reflects the quality of your business accurately. This is a one-time cost.

Here are a few tips to ensure that you’re spending your money wisely:

  • Beware of agencies that propose mockups for 30 pages within your new ecommerce site. This is a waste, a cash grab, and a sign of an inexperienced development team.  
  • Limit mockups to the home page, catalog landing page, product details page, and a general content page. However, if you have some funky options in your cart and/or checkout process, design them, too. 
  • Don’t bother fully mocking up creative designs for responsive options. If you’re dead set on seeing the mobile experience, start with the homepage on phone only and evaluate from there. 
  • Don’t waste time or money creating full mockups for each page. You can always add more designs as you go, if needed, or designers can provide elements to improve designs on single pages.
  • Complete and approve the home page design fully first before moving onto any “internal” templates. You don’t want rework across multiple designs. 
  • Use a web design agency, not a design agency. There are specifics for designing to web standards that don’t apply to companies that deal in logos, brands, and print work.

Sprinting / Development

Your project team should work with you to break your planning into stories, block these stories into epics, and group these epics into sprints. You’ll then have an idea of how many sprints you’ll need to get live.

Typical costs for sprinting range from $20,000 to $60,000 a month for the lifetime of the build cycle, which is usually six to 12 months. After this investment, you have a feature-rich ecommerce setup to push live. (Remember: These expenses are front-loaded. After this one-time cost, you own the site and don’t have to pay licensing fees or share your revenue).

Sprinting costs depend on velocity. That is, how many bodies can we afford to put on this development until the sprints are done? If you have $20,000 a month to spend for six months, you’ll get through $120,000 worth of programming or about 600 hours (give or take per agency).

That’s a decent amount of programming time for a version one go-live. You can alter the velocity, or speed with which you move, by altering your spend. After you get to that first launch, you may have the option to taper down resourcing (i.e., output) and slow spending over the following months.

Additional Features or Ongoing Support

Your site is not a static business channel. You’ll need to budget for continued rollout of new ideas, features, integrations, and changes. We often work with companies to train an in-house developer and take the agency expense out. With an open architecture and open source ecommerce setup, the ongoing costs are fully in your control.

Plan out your monthly spend over 12 months to figure out what’s realistic to your ROI, and if you should start right away or take a break.

TIP: Budget for  at least a year of ongoing expenses at whatever rate you deem suitable if you want to get a little consulting, training, advice, or coding from some experts. Just be sure to align your expectations of output with your willingness to spend.

Third-Party Expenses

Look past your site to see the full picture. What else does it need or plug into that has an annual contract? Account for these costs, too. A few typical additional expenses include:

  • Hosting
  • Server maintenance, security, updates and monitoring
  • Accounting software
  • ERP software / PIM 
  • CRM software
  • 3PL software (shipping, warehousing, labeling)
  • Programmers on staff
  • CSRs on staff 
  • Training and documentation

Conclusion

Your website is not an expense; it's a revenue channel that needs to be flexible and well architected. A substantial investment will be needed to compete online, so make sure you understand the costs involved. 

If you don’t know where to start, chat with a consultant to see if your math lines up with your goals, and then take this information to your internal team. You have options, and they should be clearly laid out for you up front, not presented to you with an invoice when you’re well into development with an agency’s team. 

Inform yourself on the process, not on the programming, and you’ll be in a better position to evaluate the best path forward.  

Click to contact one of our ecommerce consultants

May 19 2020
May 19

How amazing does it feel when you walk into a coffee shop and the barista greets you by name and asks if you’d like the usual? Or when you meet someone you haven’t seen in a long time and they ask about some obscure and specific hobby you once mentioned you had?

These personalized experiences give you the warm and fuzzies. You typically come away from those interactions a fan of the place or person. Heck, if someone were to criticize them, you’d speak up that that's not your experience. And you wouldn’t hesitate to recommend that place or person to others.

At an event a few years ago, I noticed someone who seemed a little hesitant. I introduced myself and invited them to join me at my table, and we chatted a little. We never spoke much after that. But on multiple occasions over the past few years, that person has given me a glowing reference when I came up in conversation. 

Personalization makes us feel valued and understood. And that's how you want your customers to feel. Because if they do, they will buy more and advocate for your brand.

Personalized Marketing Options to Consider

Broadly speaking, there are two ways to do web personalization: with real-time data or historical data.

Real-time data involves using location data to serve up a specific site, content, or offer. Here are a few examples:

  • Using device type or operating system to either manage how content is displayed or make assumptions on product needs
  • Using traffic source to tailor content (i.e., looking at when and what the user came from)
  • Basing promotions on products or services that have proven popular with others

Historical data goes deeper. This involves presenting personalized content, products, or offers based on users' previous interactions. You could look at factors like:

  • The number of orders they made
  • Their average order size
  • The total amount they spent
  • The products they looked at
  • The carts they abandoned
  • The time that has elapsed since their last transaction and/or visit

The options are as vast as the data you have collected. But through segmentation and rules, you can greatly increase the user's odds of converting.

Why You Need to Tread Carefully

Many consumers are becoming increasingly concerned about privacy and data management. You need to ensure that the personalization you supply is helping them in making a conversion decision and not simply showing them how much you know about them.

For instance, your barista asking if you fancy trying the new mocha latte (because they knew you had recently bought one from another brand) is much less creepy than being greeted with, "I heard you’re now into chocolate, so try this new mocha latte." The difference is small, but crucial.

Choose the Right Tools

With the overwhelming array of personalization options, it's important to work with an experienced team that can help guide you. At Acro, we love Drupal, and it can do many entry personalization functions within its platform (much more than most content management systems).

However, if you need to get very sophisticated, then you need a third-party platform. We love Acquia Lift. For features, usability and support, it is unparalleled. If you would like a personalized introduction to Acquia, hit me up and I’ll set you up, personally. 

The Bottom Line

Global research and advisory firm Gartner stated that the three key takeaways on personalization are:

  1. Consumers want to receive personalized help as they navigate the buying journey.
  2. Focusing solely on personalized recognition is potentially detrimental to a company’s commercial objectives.
  3. When it comes to help, consumers prioritize information, a simpler purchase process and saving time.1

Peronalization isn’t the ultimate goal. It’s another tool to achieve whatever your actual goal is, whether that be increased sales, increased order value, increased frequency or brand loyalty. Once you define what your goals are, you can explore if personalization will give the required ROI.

If you would like to have a conversation about your business goals and see if personalization is an appropriate tool for you, give me a call. And if not, if we ever meet out and about, you’re always welcome to sit at my table.

Click to contact one of our ecommerce consultants

1 - Source: Gartner, "Maximize the Impact of Personalization,” April 2019

May 12 2020
May 12

Many people researching Drupal Commerce 2.x for Drupal 8 (or the upcoming Drupal 9) are likely wanting to either remove the extra ecommerce shopping carts or allow checkout for multiple carts. This blog post will explain why we have multiple carts—and why being able to checkout with multiple carts is challenging, but possible.

Why you can have more than one Drupal Commerce cart

First, let’s demonstrate what Commerce 2.x can do out of the box for a single user and is often considered a bug. 

  1. Go to Acro Media’s demo store.
  2. Start out as anonymous and register as a user.
    1. Register here.
    2. Check your email/spam and click a link.
    3. Set your password because you’ll need to log back in shortly.
      Note: Acro doesn’t use your email address used on the account sign up on this site to contact you for marketing purposes. You can opt into marketing materials by clicking the large red help question mark on the right.
  3. Once registered, add something to your cart, and log out.
  4. Add something to your cart and log in.
  5. Go to /cart.

Shopping-cart

If you are seeing two carts, then you have discovered, like many others, that Drupal Commerce 2.x shows multiple carts by design. Drupal Commerce 1.x created multiple carts like this as well, but would only show one cart at a time. In 1.x, you could follow the five steps outlined above, then checkout and your original cart would display.

Why? Because the system will not delete carts. We’re using a simple anonymous session to create two carts in a potentially common edge case.

The pros and cons of multiple carts

Pro Con
  • Customers never lose a cart, even if their use of the site means they have more than one.
  • You could have multiple sellers, enabling a marketplace feature to be built on top of the existing functionality
  • You could enable different checkout workflows (one for digital services, one for recurring services, and another for physical items that require shipping).
  • You could end up with a confusing user experience by making your customers check out multiple times.
  • Payment and fulfillment must be handled separately for different items or different vendors.
  • More than one cart presents a significant visual challenge for designers. In the cart dropdown, for example, how do you should more than one cart? On the cart page, for another example, how do you handle more than one checkout button?

Turning off multiple carts in Drupal Commerce 2.x

There are two relatively simple Drupal modules you can use to show a single cart to a user:

Commerce Combine Carts—If this module is turned on, the multi-cart demo above would not produce two carts.

Commerce Cart Advanced—This module packs a lot of features into it for the crowd of users who want management tools around their multiple cart experience, but it also includes the feature to display only one cart at a time. It was created and is maintained by Acro Media’s senior developer known as krystalcode (Dimitris Bozelos).

Checking out multiple carts, Etsy/Amazon style

The holy grail of marketplace commerce is multi-store and single-checkout. The idea is that you could have a site that features multiple stores and customers could check out once from more than one store. 

According to the original author and former maintainer of Drupal Commerce 2.x, bojanz, you can do this by coding a form that acts like a checkout flow-form, but changes more than one order simultaneously.

However, you also have to consider a number of other issues: 

  • Fulfillment—If the stores are selling physical products, how will these orders appear to the customer and to customer service for each store? Likely, each store would want to only see the products for which they are responsible.
  • Order management—Even Amazon does some weird things with orders for its customers. Often, orders are split up for seemingly no reason, changing order totals and making order management challenging for customers and for customer service.
  • Payment—If you, as the site owner, plan to pay stores from your own bank account, you’ll want to set up a single, site-wide payment gateway and manage disbursement payments to your store owners. If not, then you’ll require each store to have its own payment gateway credentials or some other even more complex setup.
  • Taxes—Assuming you have good solutions for all of the above, taxes will still likely make it very hard to move forward. Tax law is hard in the best of times, and depending on how you take payment, tax rules would need to be created and maintained per store. Solutions like Avalara AvaTax only work per store and can be overly expensive for small retailers.

The bottom line

Basically, you have a few contrib options if you want to manage carts for your customers. But if you want that elusive multi-vendor, single checkout, you’ll have to plan well according to your business needs. Regardless, the flexibility of Drupal’s ecommerce cart functionality is capable of creating the best ecommerce shopping carts out there, you just need to know how to do it.

May 08 2020
May 08

I have recorded a video tutorial highlighting some of the features of a module I created for Drupal recently. This is the Entity Reference Preview Drupal module.

When you preview the latest version of an entity (ex: a node) you only preview that entity. That means that referenced entities in that page are rendered with the published version, not the latest. This module addresses that.

When prompted, many people ask: Wait! that is not the default behavior already?

Have you ever wanted to preview a listing from a view (or a block, or a layout builder page, …) with the latest version of the embedded entities? This module allows you to do that.

[embedded content]
Mar 29 2020
Mar 29

I have recorded a video tutorial highlighting some of the features of a module I created for Drupal a while ago. This is the Warmer Drupal module.

Cache warming may not be a critical piece for sites with a lot of traffic, because traffic organically warms caches. However, it is critical for these sites to deploy with warm caches after a release that cleared all caches. This will prevent overloading the server or even cache stampedes.

[embedded content]
Mar 02 2020
Mar 02

As of Drupal 8.7, the Media and Media Library modules can be enabled and used out-of-box. Below, you'll find a quick tutorial on enabling and using these features.

out-of-box before media and media library

In the past there were two different ways to add an image to a page.

  1. An image could be added via a field, with the developer given control over its size and placement:
     

    Image field before media library
  2. An image could be added via the WYSIWYG editor, with the editor given some control over its size and placement:
     

    Image field upload choices screen

A very straightforward process, but these images could not be reused, as they were not part of a reusable media library.

reusing uploaded media Before Drupal 8.7

Overcoming image placement limitations in prior versions of Drupal required the use of several modules, a lot of configuration, and time. Sites could be set up to reference a media library that allowed editors to select and reuse images that had previously been uploaded, which we explained here.

This was a great time to be alive.

What is available with Media Library

Enabling the Media and Media Library modules extends a site's image functionality. First, ensure that the Media and Media Library core modules are enabled. 

Enable media library in drupal

A media entity reference field must be used with the Media Library. It will not work with a regular image field out-of-box.

Image field on manage display page

On the Manage form display page, select "Media library" widget. 

Media library widget on manage display page

On the "Node Add" and "Node Edit" forms, you’ll see the below difference between a regular image field and a field connected to the media library.

Media library field on node edit

Click on “Add media” and you’ll see a popup with the ability to add a new image to the library or to select an image that is already in the library.

Media field grid

With a simple configuration of the field, if multiple media types are allowed in the field, you’ll see vertical tabs for each media type.

Media grid with multiple media types

WYSIWYG configuration

The WYSIWYG editor requires a few steps when configuring the media library for a specific text format. First, a new icon will appear with a musical note overlapping the image icon. This should be added to the active toolbar and the regular image icon should be moved to the available buttons.

wysiwyg toolbar configuration

Under “Enabled filters,” enable “Embed media."  Under the filter settings, vertical tab settings can be chosen for media types and view modes. Once that configuration is saved, you’ll see on a WYSIWYG editor that you have the same popup dialog for adding a new image to the media library, or selecting an already-uploaded image.

wysiwyg media configuration

Once you are on a "Node Add or "Node Edit" page with a WYSIWYG element, you’ll see the media button (image icon plus musical note).

Media button on wysiwyg editor

Clicking on the media button brings up the same, familiar popup that we saw earlier from the image field:

media library grid

This article is an update to a previous explainer from last year. 

Feb 11 2020
Feb 11

1) Built-in support for multi-language sites and admin portals

Let's jump right in! For business owners, ecommerce eliminates many restrictions of traditional business practices. One opportunity is the ability to sell your product to overseas consumers, expanding your possible market to contain, well virtually, the whole world. Of course, one of the barriers to entry into certain markets may be the language.

Imagine this: You are a Brazilian business owner who just invented chewing gum that never loses its flavour. Obviously, the demand for this product is worldwide. The only problem is that you do not feel comfortable writing the script for your new online product page in English or any language other than Portuguese for that matter. In a perfect world, the ideal solution might be to hire translators for every language of each country that you want to sell this amazing gum in. However, the costs of such an endeavour are enough to make even those with even the deepest of pockets think twice.

In my opinion, the next best and completely viable option is to choose to develop your chewing gum site using Drupal then make use of the many multilingual modules to automatically translate your content (just Google “Drupal automatic translate” for a list of options). The advantage of these Drupal translation modules is that, first, it can appear as an option at the top of the page and is therefore easily accessible to the customer. Second, additional modules can allow you to automatically show the users local language based on their browser’s set language. Third, you can choose which blocks of text you want to translate and which you do not; so let us say for aesthetic reasons or brand awareness you do not want a certain block of the site to be translated, you simply do not enable the translation for that block in the admin portal. Additionally, while your site frontend is being translated for your visitors, as an admin you can maintain Portuguese as the primary language to run your backend admin portal.

Read the full Gartner reportSpeaking from my own experience, I shop online for bicycle components quite often. The problem is many of the unique manufacturers I am looking to buy from are based out of Italy and Germany. Google translate can do an adequate job of helping you navigate the site, but when it comes to the finer details like product specifications or return policies I quickly find myself out of my depth. The great thing about using Drupal Translate is that you can manually enter the translation for each language of every block on your website. So for example, instead of paying for a full site translation in each language, you could hire professionals to translate the important areas like the fine print and leave the less critical areas up to Drupal.

2) Features on features

Okay, Drupal is not exactly an episode of Pimp My Ride, but it can pretty much do anything you can dream of. If, for some reason, you want to design a site that sources all of the types of chicken wings sold in restaurants across your city. Then create a catalogue that breaks down the various chicken wings by texture, flavour, price, size, messiness, etc. Now you want to integrate a system that uses logic and intelligence to recommend the best beer your company sells to accompany any wing selection made. This is all possible with Drupal.

The cost to develop such a unique site with these custom modules on Drupal would not be cheap. However, the point remains that a feature such as the one mentioned above is quite crazy, but completely possible. If there is functionality that you need, it can be built on Drupal. The other big takeaway is that once you have paid for the development of the module you are now the owner and do not have to worry about any ongoing licensing costs. For reasons like these, it is my opinion that Drupal is the best CMS for such robust and custom site requirements.

3) Security

Of course, nothing can ever be fully secure especially without regular upkeep, but Drupal does a few things differently that should help you sleep better at night. Unlike the many popular SaaS platforms, Drupal is open source and non-proprietary. This means that you are the owner of your data and you are the one who decides how it is managed, meaning you can fine tune every aspect of your Drupal site from the site itself to your hosting environment. If you have a security team or security-focused partner that you work with, Drupal provides the flexibility they need to keep your data safe.

The official Drupal Security Team is also thoroughly on top of the security of the core Drupal software’s code and helps module developers keep their modules secure. This team frequently releases security patches that address any vulnerabilities that come up. In addition to the official Drupal team, the large Drupal community of developers donate their time to develop and monitor Drupal’s code. Drupal and all of it’s modules are built using a core set of coding standards, so the many thousands of developers working with Drupal’s code ensures security issues are found and addressed quickly.

Lastly, one of the features of Drupal that is best known is its ability to integrate into third-party applications. As such, Drupal is also capable of easily integrating into other security systems and platforms on the market. You’re not restricted to Drupal alone.

4) Open source community

In my mind, there are two main reasons that the open-source nature of Drupal and the community that surrounds it are such an advantage.

First, because of the large community of developers and its open-sourced nature, there are countless plug-and-play ready modules available free of licensing fees just waiting to be added to your website. This means, in addition, you are the owner of your own code and data. Furthermore, you never have to worry about losing development support for your website. There will always be another Drupal agency out there waiting to pick up the pieces if something were to go wrong.

Second, because there is such a large community of developers behind the expansion of Drupal, you have a veritable fusion of diverse ideas and designs. Instead of a single organization pushing code in a certain direction, you can find incredibly creative and unique libraries of code. This means a deeper pool of free talent to pull from. Even with the creative minds driving the development of Drupal, there is still consistency in the underlying code. This enables easier upkeep of the code itself and allows a lower barrier of entry when onboarding new developers. The advantage to the end-user is that, when compared to a fully custom build, using Drupal means that should your partner agency ever go out of business or the relationship deteriorates, you will have other experts in Drupal to turn to.

5) Future-proof

I keep bringing this up, but it really enables so many possibilities; because Drupal is so open to API integrations, you can design Drupal to work as a modular middleware behind the scenes. This means as you acquire new technology and software, it really is as simple as plugging it in and configuring an API hook.

Furthermore, as long as Drupal is paired with the right server, it can handle endless amounts of traffic and scale from small business to enterprise. This is a reason why Drupal is such a popular CMS of choice for medium-sized to enterprise-level organizations.

Finally, Drupal as a CMS is kind of like Play-Doh. You can build out your frontend experience for the market you are presently targeting using Drupal’s built-in theming layer or by using one of the many other frontend frameworks. Drupal’s APIs allow it to run headless, so it can hold your backend data but you’re not tied down to any specific way of building your frontend. Ten years down the road, though, you may have a completely different set of needs for your frontend framework. No problem, you can rest assured that Drupal won't get in your way.

Are you considering options for your digital experience platform?

Choosing the right DXP now is important to your business now and in the future. Protect your tech investment by assessing the trade-offs of buy or build deployment options and how they relate to your digital experience goals and business outcomes. This Gartner report has been made available to our readers for a limited time and will help you get started. Check it out.

Click to access the Gartner report today

Jan 28 2020
Jan 28

Due to the nature of B2B sales, one of my roles is cold outreach. Most of the time my first method of outreach garners no replies. However, every so often I will receive a prompt email message or reply over the phone. It usually goes something along the lines of: “We already have a web development agency.” or “We are not interested.” I often wish I was at a sit-down meeting when these situations arise. This is because I simply cannot describe the multi-faceted solutions Drupal can provide, far and above a typical web development agency. “You should absolutely stay with them” is my typical response to prospects that have an agency they are happy with. I say this because there is so much more that Drupal, as a business solution, can provide without even interacting with the frontend of their website. What we often promote with Drupal is its capability to create a more complete digital experience platform (DXP), not just a website.

What Gartner has to say about the DXP

In a 2019 report, Gartner has this analysis about DXPs:

“Driven by digital transformation efforts, organizations are moving beyond the traditional audience engagement resources of websites and mobile apps. There is a growing acceptance of the idea of digital experience platforms as vital to these efforts. DXPs provide a scalable foundation for creating, optimizing, integrating, delivering and managing a range of digital experiences for different audiences, both internal and external.1”

So let me unpack that a little bit in my own words. Essentially, your website and mobile apps are still very much at the forefront of digital marketing. Moving forward, though, more organizations have and will continue to create a more cohesive, single platform (DXP) in order to cater to all stakeholders of the company. This not only includes said organizations’ customers but also their teams and employees, allowing for a more comprehensive snapshot of the company from the outside and inside. In the same report, Gartner estimates that:

“Through 2021, 85% of the effort and cost involved in a digital experience platform (DXP) program will be spent on integrations with internal and external systems, including the DXP’s own, built-in capabilities.1”

In my opinion, this assumption by Gartner indicates that organizations are already well aware of the advantages a DXP can provide. 

Don't wreck digital engagement with bad deployment decisions Use Drupal and Drupal Commerce for your digital experience platform >

An imaginary business case for a DXP

Imagine you started a business selling gadgets. Your gadgets were better for target market X because they were less complicated than the gadgets that were available on the market at the time. So first off, you rented a storefront and sold the gadgets in your store, but you also realized you could scale your business by selling the same gadgets online. So in addition to your point of sale system (POS), you now had to adopt an appropriate ecommerce platform and build a website to sell the gadgets online.

Now that you were selling gadgets online you also had to have a shipping channel and a returns channel for replacing defective gadgets. As demand for your product began to grow you needed more gadgets on hand at any given time. The obvious solution was a warehouse, but you also needed a product information management (PIM) system to keep on top of your inventory and distribution channels.

As your product created a name for itself you opened a few more gadget stores and to satisfy demand across the globe you began selling your product through Amazon. With increased demand came competition, so in response, you invested in marketing software to stay on top of the industry trends. You began to diversify in order to make your business more resilient to market volatility. The diversification led to custom gadgets in addition to a gadget service and repair business.

In order to keep track of what your customers had purchased and to identify opportunities for cross-selling and up-selling, you invested in a customer relationship management (CRM) system. Finally, just under a year ago you invested in a new enterprise resource planning (ERP) system. This way all of your new departments had the information they needed to operate efficiently.

So we are now in the present day. Like many other businesses that grew at a rapid pace, you find yourself in a situation where all of your technology has become siloed. In this analogy, your data and information all exist, but it is locked away in separate silos. Each silo represents a piece of software, a distribution channel, a legacy POS system, or that missing Amazon integration that can only be accessed from one place. You can run a business this way, and many organizations do just that, without realizing that there is actually a more efficient way to do things. This is where the DXP comes into play. What you would prefer rather than individual silos would be a horizontal technology architecture with open lines of communication between everything. This, as one could imagine, can save a tremendous amount of time and manual workflows, eliminating what we call swivel-chair processes. Simply stated it is a more efficient way of doing business. The problem is many business owners and decision makers may not even realize this is happening because they live in their own silos and no one has pointed it out to them.

How does Drupal come into play?

Drupal is a content management system (CMS), but at the same time, Drupal can do so much more than a traditional CMS. Through API integrations, also known as API hooks, Drupal has the ability to be used as middleware. As middleware, Drupal can act as a modular engine that connects all the data from the aforementioned gadget business’ technology. Data can flow forwards and backward between the various pieces of technology and even integrate into legacy systems like the POS in the gadget example. Furthermore, the modular nature of Drupal middleware essentially future proofs your business allowing for business scalability.

Drupal as middleware example

To give an analogy, you can think of Drupal middleware as a computer with unlimited USB ports. The computer acts as the brain passing information back and forth between systems and the USB ports are the API hooks. USB ports are non-proprietary and you can, therefore, unplug cables you no longer need and replace them with new cables. You can also add or remove cables as necessary and the computer keeps on functioning as long as you configure the drivers. So as you outgrow software systems or you decide to replace that legacy POS, no problem because you can just plug in the new software, install the drivers, and you are back up and running again.

Connecting it all together

How to patch digital gaps in a growing business Find out how Drupal can improve customer experiences and streamline backend operations.So to return to my statement at the beginning of this blog post, the reason I wish I could sit down with those who respond so quickly to my first cold outreach is that I do not want to be typecast as just another web development agency. In actual fact, because our expertise lies in Drupal we are far better positioned to provide solutions that lay beyond the scope of the traditional idea of a website. Sure we can develop an incredibly robust frontend experience and, likewise, a flexible scalable ecommerce engine. But, we can also use Drupal as middleware that allows for seamless flow of information between systems.

If you've read this and would like to have a quick chat, let us know! We're happy to help. I also mentioned a Gartner report from 2019 that is a great introduction for anyone trying to nail down their digital experience platform.

While this report is no longer available, we invite you to reach out to us at any time to discuss how connecting your systems through middleware can improve your business operations and income. 

1 - Gartner, "Don’t Wreck Digital Engagement With Bad Deployment Decisions for Your Digital Experience Platform,” 31 July 2019, Gene Phifer.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Jan 23 2020
Jan 23

In the Drupal support world, working on Drupal 7 sites is a necessity. But switching between Drupal 7 and Drupal 8 development can be jarring, if only for the coding style.

Fortunately, I’ve got a solution that makes working in Drupal 7 more like working in Drupal 8. Use this three-part approach to have fun with Drupal 7 development:

  • Apply Xautoload to keep your PHP skills fresh, modern, and compatible with all frameworks and make your code more reusable and maintainable between projects. 
  • Use the Drupal Libraries API to use third-party libraries. 
  • Use the Composer template to push the boundaries of your programming design patterns. 

Applying Xautoload

Xautoload is simply a module that enables PSR-0/4 autoloading. Using Xautoload is as simple as downloading and enabling it. You can then start using use and namespace statements to write object-oriented programming (OOP) code.

For example:

xautoload.info

name = Xautoload Example
description = Example of using Xautoload to build a page
core = 7.x package = Midcamp Fun

dependencies[] = xautoload:xautoload

xautoload_example.module

<?php use Drupal\xautoload_example\SimpleObject; function xautoload_example_menu() { $items['xautoload_example'] = array( 'page callback' => 'xautoload_example_page_render', 'access callback' => TRUE, ); return $items; } function xautoload_example_page_render() { $obj = new SimpleObject(); return $obj->render(); } useDrupal\xautoload_example\SimpleObject;functionxautoload_example_menu(){  $items['xautoload_example']=array(    'page callback'=>'xautoload_example_page_render',    'access callback'=>TRUE,  return$items;functionxautoload_example_page_render(){  $obj=newSimpleObject();  return$obj->render();

src/SimpleObject.php

<?php namespace Drupal\xautoload_example; class SimpleObject { public function render() { return array( '#markup' => "<p>Hello World</p>", ); } } namespaceDrupal\xautoload_example;classSimpleObject{  publicfunctionrender(){    returnarray(      '#markup'=>"<p>Hello World</p>",    );

Enabling and running this code causes the URL /xautoload_example to spit out “Hello World”. 

You’re now ready to add in your own OOP!

Using Third-Party Libraries

Natively, Drupal 7 has a hard time autoloading third-party library files. But there are contributed modules (like Guzzle) out there that wrap third-party libraries. These modules wrap object-oriented libraries to provide a functional interface. Now that you have Xautoload in your repertoire, you can use its functionality to autoload libraries as well.

I’m going to show you how to use the Drupal Libraries API module with Xautoload to load a third-party library. You can find examples of all the different ways you can add a library in xautoload.api.php. I’ll demonstrate an easy example by using the php-loremipsum library:

1. Download your library and store it in sites/all/libraries. I named the folder php-loremipsum. 

2. Add a function implementing hook_libraries_info to your module by pulling in the namespace from Composer. This way, you don’t need to set up all the namespace rules that the library might contain.

function xautoload_example_libraries_info() { return array( 'php-loremipsum' => array( 'name' => 'PHP Lorem Ipsum', 'xautoload' => function ($adapter) { $adapter->composerJson('composer.json'); } ) ); } functionxautoload_example_libraries_info(){  returnarray(    'php-loremipsum'=>array(      'name'=>'PHP Lorem Ipsum',      'xautoload'=>function($adapter){        $adapter->composerJson('composer.json');      }

3. Change the page render function to use the php-loremipsum library to build content.

use joshtronic\LoremIpsum; function xautoload_example_page_render() { $library = libraries_load('php-loremipsum'); if ($library['loaded'] === FALSE) { throw new \Exception("php-loremipsum didn't load!"); } $lipsum = new LoremIpsum(); return array( '#markup' => $lipsum->paragraph('p'), ); } usejoshtronic\LoremIpsum;functionxautoload_example_page_render(){  $library=libraries_load('php-loremipsum');  if($library['loaded']===FALSE){    thrownew\Exception("php-loremipsum didn't load!");  $lipsum=newLoremIpsum();  returnarray(    '#markup'=>$lipsum->paragraph('p'),

Note that I needed  to tell the Libraries API to load the library, but I then have access to all the namespaces within the library. Keep in mind that the dependencies of some libraries are immense. You’ll very likely need to use Composer from within the library and commit it when you first start out. In such cases, you might need to make sure to include the Composer autoload.php file.

Another tip:  Abstract your libraries_load() functionality out in such a way that if the class you want already exists, you don’t call libraries_load() again. Doing so removes libraries as a hard dependency from your module and enables you to use Composer to load the library later on with no more work on your part. For example:

function xautoload_example_load_library() { if (!class_exists('\joshtronic\LoremIpsum', TRUE)) { if (!module_exists('libraries')) { throw new \Exception('Include php-loremipsum via composer or enable libraries.'); } $library = libraries_load('php-loremipsum'); if ($library['loaded'] === FALSE) { throw new \Exception("php-loremipsum didn't load!"); } } } functionxautoload_example_load_library(){  if(!class_exists('\joshtronic\LoremIpsum',TRUE)){    if(!module_exists('libraries')){      thrownew\Exception('Include php-loremipsum via composer or enable libraries.');    $library=libraries_load('php-loremipsum');    if($library['loaded']===FALSE){      thrownew\Exception("php-loremipsum didn't load!");

And with that, you’ve conquered the challenge of using third-party libraries!

Setting up a New Site with Composer

Speaking of Composer, you can use it to simplify the setup of a new Drupal 7 site. Just follow the instructions in the Readme for the Composer Template for Drupal Project. From the command line, run the following:

composer create-project drupal-composer/drupal-project:7.x-dev <YOUR SITE DIRECTORY> --no-interaction

This code gives you a basic site with a source repository (a repo that doesn’t commit contributed modules and libraries) to push up to your Git provider. (Note that migrating an existing site to Composer involves a few additional considerations and steps, so I won’t get into that now.)

If you’re generating a Pantheon site, check out the Pantheon-specific Drupal 7 Composer project. But wait: The instructions there advise you to use Terminus to create your site, and that approach attempts to do everything for you—including setting up the actual site. Instead, you can simply use composer create-project  to test your site in something like Lando. Make sure to run composer install if you copy down a repo.

From there, you need to enable the Composer Autoload module , which is automatically required in the composer.json you pulled in earlier. Then, add all your modules to the require portion of the file or use composer require drupal/module_name just as you would in Drupal 8.

You now have full access to all the  Packagist libraries and can use them in your modules. To use the previous example, you could remove php-loremipsum from sites/all/libraries, and instead run composer require joshtronic/php-loremipsum. The code would then run the same as before.

Have fun!

From here on out, it’s up to your imagination. Code and implement with ease, using OOP design patterns and reusable code. You just might find that this new world of possibilities for integrating new technologies with your existing Drupal 7 sites increases your productivity as well.

Jan 14 2020
Jan 14

Content management systems (CMSs) are the engine that drive content creation on the web today. They form the foundation that we build on for publishing and sharing information, creating digital experiences and conducting online retail. WordPress and Drupal are staples in the CMS world and they have both been around a long time. WordPress is known for its intuitive and easy-to-use interface. Drupal is known for its flexibility and complexity. While both have their strengths and weaknesses, the usability gap between WordPress and Drupal is changing. This article will show you the current state of Drupal’s admin user experience in a side-by-side comparison with WordPress, the most widely used CMS. If you’re familiar with one CMS but not the other, this comparison is also a good introduction to the other.

TL;DR: The primary goal of this article is to dispel the perception that Drupal is widely different and harder for administrators to use than WordPress. If you don’t care about the background behind this perception, just skip down to the direct comparison.

WordPress is easy, Drupal is hard… why does this perception exist

But first, a little background. The dominant CMS in terms of number of sites running on it is WordPress. It’s estimated to power about 62% of all websites that use a CMS, meaning multiple millions of websites are using it. Why is WordPress so popular? WordPress started as a blogging engine with a focus on being easy-to-use. This proved to be incredibly important because it meant that nearly anyone could get a WordPress site up and running fast and be able to use it with little-to-no training. The idea caught fire with both individuals and local businesses who just wanted a simple, low-cost website that others could find online. Web developers and agencies also finally had a framework that allowed their clients to make simple content edits within an admin environment that was friendly. Of course, WordPress today can be used for much more than a simple website, but it is still ideal for simple websites. Another key takeaway here is this perception of WordPress as being easy-to-use. This reputation holds true just as much today as it ever did in the past.

This article isn’t actually meant to praise and promote WordPress. Instead, much of this article will focus on another popular CMS, Drupal. Drupal is a fantastic CMS and is incredibly powerful when used correctly. In many web development circles, Drupal is the go-to solution for providing a robust solution for today’s CMS driven website development. It’s thriving both in usage and as a community of enthusiasts, but while WordPress sits in #1 spot with 62% of the market share, Drupal holds steady at #3 with about 3%. It still means there are many hundreds of thousands of websites powered by Drupal, but the number of websites using it pales in comparison to WordPress.

Why isn’t Drupal more popular? Well, anyone who knows Drupal (and even many who don’t) will tell you that Drupal is best suited for large websites with high traffic and complex requirements. Universities, government, nonprofits and online retailers are a sample of who uses Drupal. Drupal out-of-the-box isn’t as ready to use as WordPress, so it’s unlikely a suitable fit for simple websites. For individuals, configuring Drupal is a steep learning curve. For local web agencies, it takes more time to setup which means they must charge more. These reasons alone largely take Drupal out of the running for many websites, so for Drupal it’s more about use case than mass adoption.

With that said, Drupal’s ability to be configured and developed on literally means it can handle nearly any situation required of it, whether that means selling products for enterprise businesses or being the integration layer between multiple platforms. While this inherent flexibility is great for software developers, Drupal’s perception of complexity combined with a historically underwhelming admin experience has cemented a reputation that Drupal is unintuitive and difficult to use for the end user, the people who will be using it every day. While in my opinion this isn’t true of today’s Drupal, like WordPress it’s reputation precedes it. In Drupal’s case, however, this reputation isn’t as flattering and it’s something that our sales and outreach teams battle with often.

For Drupal, it’s time for change

Like WordPress, Drupal is open source software. It’s free to use and anyone has full access to the underlying code to modify and build upon. Both platforms have a core team for advancing key initiatives and a massive community of individuals and organizations that support the initiatives while also adding additional functionality through plugins (WordPress lingo) or modules (Drupal lingo).

While usability has always been important to WordPress (since it started as a blogging platform), Drupal was historically more focused on being open and flexible. It’s user experience has continuously improved with each version release, but late in 2018 marked the beginning of a big push towards modernizing the Drupal admin user interface (UI). Drupal is really amazing software and it’s time that the admin experience catches up.

Introducing Claro, Drupal’s new admin UI

Drupal 8 Claro admin theme
Claro interface design mockup courtesy of Drupal.org

Claro is the new admin theme being built as part of the Admin UI Modernization initiative. It’s included with every Drupal 8 site, new and old, and can be enabled right now if you so choose. Just be aware that it is currently considered “experimental” while progress continues to be made. It’s not yet in its finished state, but you can view the development roadmap here to see what is still left to do.

Side-by-side: WordPress & Drupal Admin UI Comparison

On to the comparison!

For WordPress, I’m using version 5.3.2 (released Dec. 18, 2019) which comes with its own Twenty Twenty default theme and content.

For Drupal, I’m using version 8.8.1 (also released Dec. 19, 2019. How about that!) and the new, but experimental, Claro admin theme. If you’re looking at this at a later date, some aspects may be different (for the better!) as development of the theme continues. I’ve also installed Drupal using the official Umami demo install profile so that I have a theme and some content to work with.

In each of the 10 comparison categories below, I’ll give my opinion on which CMS has the edge out-of-the-box and why I think this. I’ve used both platforms and do have some bias towards Drupal, but I’ll do my best to keep that in check.

Category quicklinks
  1. Admin toolbar
  2. Login dashboard
  3. Managing media
  4. Creating pages
  5. Editing pages
  6. Managing widgets and blocks
  7. Managing menus
  8. Managing users, roles and permissions
  9. Site status report
  10. Plugins and modules
  11. WordPress & Drupal comparison summary

1. Admin toolbar

The admin toolbar is always present on the page of both WordPress and Drupal.

WordPress

WordPress admin toolbar

In WordPress, a single toolbar is used as a jump-off point for common admin pages, but you can also start the content creation process and access your account profile and information.

Drupal

Drupal 8 admin toolbar

Drupal has a similar admin toolbar except you have access to everything including creating new content. Every admin page that your user role has permission to view is available through this menu. While it’s more to look at initially, experienced users enjoy fewer clicks to get where they want to go.

Edge: Drupal

While the learning curve to know where everything is might be a bit steeper, experienced Drupal users enjoy being able to access everything in one familiar way. With that said, new users may find this larger menu intimidating.

2. Login dashboard

After logging in, the login dashboard is the first page you see. WordPress and Drupal both take a different approach to their login dashboard.

WordPress

WordPress login dashboard

WordPress has a robust dashboard right out of the gate. This dashboard takes admins away from the site frontend and into an interface that only they can see. The left side has a larger menu for accessing the rest of the admin interface. The main content area mix of useful information about your site and information specific to WordPress as a whole, such as training resources and upcoming WordPress events. The panes on this page can be toggled on and off and plugins can add new panes.

Drupal

Drupal 8 login dashboard

This is the first area where Drupal takes a different approach. Instead of a robust dashboard, you don’t actually get much of anything. The admin toolbar already gives you access to the entire site, so Drupal keeps you on the website frontend and instead shows you your “user page”. This page is entirely customizable although you will most likely need third-party or IT support to do so. It’s an open canvas to do with as you like. For ecommerce, you might show a customer their information, recently viewed products and their last order placed. For content creators, you might show a custom dashboard with quick links to their common tasks. What you do here is entirely up to you.

Edge: WordPress

Although it’s not entirely useful, WordPress actually has a dashboard which is a nice touch for new users. Drupal's clean slate offers a lot of exciting potential for admins and visitors alike, but any potential must first be realized before this page is useful.

3. Managing media

Images, videos, documents and more are uploaded and organized within a media manager. Both WordPress and Drupal offer a convenient content editor plugin which makes selecting and adding media into content easy.

WordPress

WordPress media manager

WordPress really defined the way media can be managed within a CMS. Their interface for managing media contains a handy drag-to-upload feature and each piece of media is shown in a grid format by default. Media can be filtered by date, type and name.

Drupal

Drupal 8 media manager

Drupal admittedly isn’t as clean as WordPress in this interface yet but it’s functionality is essentially the same and solid for most users. The visual interface will improve as the development of Claro progresses. By default, Drupal displays media in a list, but you can toggle between list and grid. There are also similar filtering options. Like all other aspects of Drupal, advanced users can customize media types beyond what you see here and entirely new media types can be created. This advanced functionality is unique to Drupal and isn’t as easily done in WordPress.

Edge: WordPress

WordPress does a great job of making media easy to manage. Drupal will continue to see improvements in the near future, but right now it still feels clunky.

4. Creating pages

Creating new pages, such as general content pages and blog posts, is a common interaction that most admin users will need to do.

WordPress

WordPress new page Gutenberg editor

As of version 5.0, WordPress includes their much anticipated Gutenberg editor experience. This editing format is sleek, modern, and very intuitive. You start with a title and then continue piecing together chunks of content by selecting various types of “blocks” to build the page with. Blocks are a single, reusable type of content such as a heading or paragraph of text, an image or gallery, a list, a quote, etc. Custom blocks can be created and plugins may also add additional blocks that content creators can use. Along the right side of the page is a settings pane. This pane provides various page specific settings and customizations such as page visibility, featured image, an option to allow comments, etc. Additional settings for the currently selected content block also appears here.

Drupal

Drupal 8 new page creation

Out-of-the-box, creating a new piece of content looks like the screenshot above. Content in Drupal could potentially be something wildly different than just a basic page, so Drupal defaults to a standard “field based” editing interface where the different fields that are configured to make up the content are laid out on the page. All editors need to do is fill in the blanks. Field types can be text (with an optional WYSIWYG editor), and image, a file upload, a date, and anything else you can imagine. This again is where Drupal’s flexibility is both an advantage and a curse. The advantage is that a type of content can be anything you can imagine, but the downside is that someone has to configure that content type first. The field based editing experience is provided by default to ensure the editing experience is consistent across different content types.

Here’s the important thing to know about Drupal. Drupal doesn’t like to make assumptions as to what your editing experience should be. As an example, a used car dealership, a national newspaper, and an online retailer will all have entirely different content editing requirements. Drupal doesn’t want to get in your way and it doesn’t try to. What it does do is give you a solid foundation to create YOUR ideal editing experience. This might not be ideal for organizations and businesses with simple website requirements, but for those with complex workflows and unique requirements, Drupal is ideal.

One last important note to make on this topic is that Drupal does also have a Gutenberg editing experience, it just doesn’t come packaged with Drupal out-of-the-box. This module and other editing interface modules and initiatives can be installed in Drupal to make the default editing experience more capable and modular.

Edge: WordPress

When based solely on out-of-the-box functionality, WordPress pre-packaged Gutenberg editing experience is modern and intuitive for new and experienced users. However, it’s important to note that Drupal modules exist that greatly improve Drupal’s default experience. You can even add the same Gutenberg experience.

5. Editing pages

Once a page has been created, sometimes you still need to go back and edit it once in a while. This is a different experience from creating new content, so let’s now look at how it works with each CMS.

WordPress

WordPress editing existing pages

Pretty standard, as a logged in administrator you have access to editing content by viewing the page on the website frontend and using one of the various “edit” buttons. You’re then brought to the same Gutenberg interface that you see when creating content.

Drupal

Drupal 8 edit existing pages

I would say Drupal has the upper hand for editing existing content. Similar to WordPress, as a logged in administrator you have access to page edit links when viewing the content which brings you back to the same interface as when the content was created. However, in Drupal you also have additional links to view content revisions as well as the view and edit page translations for multi-language sites.

Drupal 8 inline page editor

The current version of Drupal, Drupal 8, also includes an additional edit icon that contains a new “quick edit” option. Depending on the content, the quick edit allows on-page inline editing (shown above) instead of taking you to a separate page! This makes simple edits quick and easy. Furthermore, the edit icon also appears when administrators hover over menus and other configurable page elements too, giving you a quick way to access their configuration.

Edge: Drupal

While WordPress has the edge when creating new content, Drupal’s on-page inline editing feature makes editing existing content quick and easy by keeping content editors on the website frontend.

6. Managing widgets and blocks

Widgets (WordPress lingo) and blocks (Drupal lingo) are two words for essentially the same thing. While not limited to these locations, the header, footer and often left and right columns beside the main content area contain defined regions where certain elements can be placed. I’m talking about slogans, menus, a search bar, your copyright, recent posts, social feeds, etc. WordPress and Drupal have similar but different ways to manage these elements.

WordPress

WordPress widgets page

WordPress includes a backend and frontend methods for editing page widgets, both of which are quite basic and lack a lot of real capability.

The backend method (shown above) is accessed through the backend Appearance menu. This page gives you a nice list of available widgets on the left side and another list of active widgets within the available regions on the right. A simple drag and drop interface lets you move elements around and opening each widget allows for basic configuration.

WordPress widgets live editor

The frontend method is through a "Live Preview" mode (shown above) where a version of the site theme is presented and widgets are managed through the left column. Settings for existing widgets can also be quickly opened by clicking its blue edit icon, as you can see in the image above.

Out-of-the-box, it’s difficult to understand exactly where a widget will appear throughout the site because you don’t have the ability to see or control which pages accept the widget. Some third-party plugins are available to give you this functionality, but they must be added. New widgets are also a bit more difficult to add as they must be created by a developer or added though a plugin.

Drupal

Drupal 8 block layout page

Like WordPress, Drupal has the ability to manage blocks from both the backend and frontend of the website, although Drupal handles both situations better.

The backend method (shown above) is accessed through the admin toolbar’s Structure menu. Here you can view all available regions and the blocks contained within each. Regions are a big part of Drupal theme creation, so you will often see 10+ available regions to choose from. If you’re not sure of your themes regions, the “Demonstrate block regions” link above the list of regions will give you a preview. Each region has a “Place block” button for adding new pre-configured blocks. Existing blocks can be moved dragged between regions and each block can be configured independently. Block configuration in Drupal is very robust, including but not limited to control over what pages the block is visible on and what account roles can view it. Like content, blocks can be translated and even have revisions.

Custom blocks can also be created by more advanced Drupal users in a similar way that new media and content types are created. In the screenshot above there is a link to the “Custom block library,” which is where new blocks can be created. Like WordPress, modules can also be installed which will add new blocks.

Drupal 8 frontend block quickmenu

Drupal’s frontend method for managing blocks takes on the same familiar editing experience that we discussed for editing content. When logged in and viewing the website frontend, navigating to a page and hovering your cursor over an element will reveal an edit icon if that element is a configurable block. Options for the block are then given. The block in the screenshot above contains a menu, so we see options to configure the block and edit the menu. In this case, clicking one of these options will take you to the backend page for performing these actions. If the block contained text, we would also be given an option to edit the text directly on the page, just like we can with content.

Edge: Drupal

Simply put, Drupal’s block management is robust yet not too difficult. Being able to manage existing blocks directly from the website frontend is both user friendly and familiar given that existing pages can also be managed in the same way.

7. Managing menus

Menus connect the pages within a website. Commonly you’ll find a primary navigation and some sort of footer menu, but menus are used in many other places as well.

WordPress

WordPress menu management

The menu system in WordPress is a bit strange at first, but overall it’s pretty simple. You create a menu (or select an existing one using the menu selection dropdown), then add links by selecting pages, categories, or by creating custom links (add menu items in image above), then use a drag and drop interface for moving and nesting the menu items (menu structure in image above). Each menu item within the menu structure can be opened for a bit of customization.

The menu settings area controls where the menu is displayed within predefined template locations. Just check the box and the menu will appear once saved. Any menu created here can also be assigned to region as a widget or through the template live preview screen.

One odd thing I’ve found with WordPress is that, when editing a page, you’re not able to add it into a menu. I’m sure there are plugins that allow this, but out-of-the-box you have to add the page through the menu system or check a setting within the menu that all new pages get added… but then you might have to remove some.

Drupal

Drupal 8 menu management

Drupal’s approach to menus is what I would consider more standard. You navigate the “menus” page which lists all of the menus that have been created, then you create a new menu or edit an existing menu. The screenshot above is what you see when editing a menu. Here you manage this menu’s links by either adding a new one or manipulating the existing ones. When adding a new link you can easily search for content that the link will link to or specify a custom link.

Pages can also be added to a menu when the page is being created or edited. Within the page settings, all you do is select the menu and specify a link title.

Like WordPress, once you create a menu you can then add it into a region of the site as a block. However, within the menu itself you don’t have the ability to put the menu anywhere.

Edge: Drupal

A more standard approach makes managing menus clearer and more user friendly. Also being able to choose if a page should be included in a menu while creating the page is a nice feature. That said, I appreciate being able to manage a menu in its entirety on a single page like you do in WordPress.

8. Managing users, roles and permissions

Managing users is common for both controlling who can edit the website and who can login for other reasons, such as non-admin accounts for an online store or community.

WordPress

WordPress user management

WordPress has six predefined user roles: Super Admin, Administrator, Editor, Author, Contributor, and Subscriber. Each has varying degrees of what they can do, but it’s pretty clear for the most part and goes back to when WordPress was mainly a blogging platform. Users can be created and managed through a “users” page (shown above), which is laid out in a straightforward manner displaying

But WordPress has some major drawbacks here. First, WordPress doesn’t have any frontend user self-management, meaning users can’t view or edit their own profiles. Second, the predefined roles and their associated permissions don’t work for everyone and actually complicate user management when you don’t need it. Third, there is nowhere to really manage role permissions in a granular way. These drawbacks can be fixed through custom development and/or various plugins, but many consider this to be a general weak point of WordPress.

Drupal

Drupal 8 user management

User management is another area where Drupal shines. In contrast to WordPress, Drupal only starts with three default roles: Anonymous, Authenticated and Administrator. Anonymous is a user who is not logged in, authenticated is a user who has an account but isn’t someone who typically isn’t managing content and site configuration, and administrator is a user with full site and admin access. These three roles are minimal, clear and cover all of the basic needs of most sites. If and when another role with different permissions are created, this is easy to do right out-of-the-box.

The image above shows Drupal’s version of the current list of users. It follows a similar look and style to the rest of the admin pages, giving administrators a place to add and manage user accounts, including assigning users to specific roles. Anonymous and authenticated users can also create or manage their own account through the website frontend (although this functionality can be turned off if desired).

Drupal 8 user permissions page

Drupal’s strength in user management comes in the form of roles and permissions. When a role is created, a column of permission checkboxes for the role is added to the Permissions page (shown above). Almost every piece of functionality within Drupal has an associated permission. Simply checking the boxes determines what each role can and can’t do. It’s powerful and easy.

Edge: Drupal

A simple yet powerful user management system combined with frontend self-service functionality gives Drupal a clear edge over WordPress.

9. Site status report

Both WordPress and Drupal include a site status page that gives you information about the website and server configuration as well as an overall health report that outlines any issues. These automated health checks help keep your CMS up-to-date and secure.

WordPress

WordPress site health page

The “Site health” page (shown above) gives you an overall health status and list of any issues. This status page is clean and each item can be expanded for more information, but there is no visual urgency that makes the “2 critical issues” stand out. In my opinion, critical issues should be resolved and so highlighting these issues in some way is a necessary UX improvement.

An info tab at the top of the page can be opened which gives more information about your installation of WordPress, the server, the PHP version, and the database.

Drupal

Drupal 8 status report page

Drupal contains both site information and site health in one “Status report” page (shown above). Like WordPress, this page gives you everything you need to know at a glance about your Drupal installation and the other components that make it run. Here we can also clearly see what errors and warnings have been found and some information on how they can be resolved.

Edge: Drupal

While both WordPress and Drupal have similar pages that show similar information, Drupal’s status report does a better job at laying out the information and visually capturing the severity of any issues.

10. Plugins and modules

Plugins (WordPress lingo) and modules (Drupal lingo) extend core CMS functionality and add new features. Extensions are usually created by third-party developers and released to the platform communities for anyone else to use. Whether it’s to increase performance, enhance SEO capabilities or create an online store, extensions are a powerful way to improve and adapt the CMS platform.

WordPress

WordPress plugins page

Visiting the “Plugins” page (shown above) is a quick way to see what additional plugins are currently packaged with your WordPress installation and can be activated if desired. Plugins shown here all provide some sort of new functionality or feature that is not part of the core WordPress software.

WordPress plugin search page

When you need new functionality, WordPress provides an excellent and convenient plugin library browser (shown above) accessible within the website backend. Here you can search for, view, and install plugins easily with the click of a button.

Drupal

Drupal 8 extend page

Drupal’s module list is where you can see all current extensions, activated or not, for your Drupal installation. The big difference here between WordPress and Drupal is that for Drupal you are able to see all modules installed, even those that are part of the core software. Modules are also nicely grouped which nicely organizes the large list.

Installing new modules isn’t nearly as easy in Drupal. Unlike WordPress, Drupal doesn’t include a module library browser within the backend interface. Instead, users must search for modules within a web browser and manually install them. Finding modules can be difficult if you’re not familiar with the process.

Edge: WordPress

While both platforms have a massive library of extensions, WordPress offers users a much friendlier and intuitive way of finding and installing extensions that users of any skill level can appreciate. This may or may not be an issue for you if you have a capable IT team or development partner, but for small teams WordPress has the clear edge.

WordPress & Drupal comparison summary

I hope after going through this comparison you now have a good understanding of the differences and similarities between WordPress and Drupal. As you can see, both platforms out-of-the-box have different strengths and weaknesses, but it’s important to know that all of the weaknesses can be overcome through platform extensions and experience. In extreme cases, both platforms support custom development to overcome unique problems.

For convenience, here is a quick summary showing which CMS has the edge in the 10 categories compared. However, I would recommend that you go back and read the edge summary for each category, if you haven’t done so already.

Comparison category WordPress Drupal Admin toolbar   ✓ Login dashboard ✓   Managing media ✓   Creating pages ✓   Editing pages   ✓ Managing widgets and blocks   ✓ Managing menus   ✓ Managing users, roles and permissions   ✓ Site status report   ✓ Plugins and modules ✓  

A final word of advice

In my opinion, you shouldn’t be turned off from one platform or the other simply because you’ve heard that one is better or easier to use. Both platforms are mature and constantly improving, user experience is top of mind, and usability gaps have become less of an issue in recent years.

My advice, select the platform you use based on your requirements. WordPress is a great authoring tool and is good for small and medium sized organizations. Drupal is fantastic for medium and large sized organizations or anyone who has complex workflows, products, and/or a need to integrate with other platforms. That’s a pretty general summary, but if you’re considering either of these platforms, first know what your requirements of the platform are and then start talking to the experts for each.

Acro Media is an ecommerce consultation and development agency who can help you in this regard. We specialize in open source ecommerce and a large part of our work is based around Drupal. Drupal typically works better for our clients but we know WordPress, too. If you’re researching your requirements or evaluating your options, hit us up for a quick chat, we would love to help. Otherwise, check out some of these related resources.

Contact Acro Media Today!

Related resources

Dec 15 2019
Dec 15

I have t' say, I were bein' skeptical about dark mode in our current operatin' systems, but since wirin' it up t' switch t' it automatically after sunset, I’m a believer. I know some scallywags always operate their in dark mode, an' that's not fer me. I prefer th' light on me screen t' match th' light o' th' day. It's especially nice t' have me iPhone in dark mode at concerts, so I can avoid bein' "that lubber" who blinds th' person behind me,

Websites now respect th' system settin' o' dark mode, an' e'er since Jeff Geerling updated his site's theme to support dark mode, I had on me list t' do th' same.

It turns out that the Responsive Blog Drupal theme, a very nice theme that does what it says on th' tin, has a switch fer turnin' on th' dark mode version o' it. I'm glad I realized that most o' th' work had been done fer me, an' I've submitted a patch to the project for review.

The last frontier o' dark mode based on system settin' is third-party JavaScript widgets. None o' th' 3 widgets on me blog, t' me knowledge, have th' ability t' switch automatically.

Dec 09 2019
Dec 09

With Drupal 9 set to be released later next year, upgrading to Drupal 8 may seem like a lost cause. However, beyond the fact that Drupal 8 is superior to its predecessors, it will also make the inevitable upgrade to Drupal 9, and future releases, much easier. 

Acquia puts it best in this eBook, where they cover common hangups that may prevent migration to Drupal 8 and the numerous reasons to push past them.

The Benefits of Drupal 8

To put it plainly, Drupal 8 is better. Upon its release, the upgrade shifted the way Drupal operates and has only improved through subsequent patches and iterations, most recently with the release of Drupal 8.8.0

Some new features of Drupal 8 that surpass those of Drupal 7 include improved page building tools and content authoring, multilingual support, and the inclusion of JSON:API as part of Drupal core. We discussed some of these additions in a previous blog post

Remaining on Drupal 7 means hanging on to a less capable CMS. Drupal 8 is simply more secure with better features.

What Does Any of This Have to Do With Drupal 9?

With an anticipated release date of June 3, 2020, Drupal 9 will see the CMS pivot to an iterative release model, moving away from the incremental releases that have made upgrading necessary in the past. That means that migrating to Drupal 8 is the last major migration Drupal sites will have to undertake. As Acquia points out, one might think “Why can’t I just wait to upgrade to Drupal 9?” 

While migration from Drupal 7 or Drupal 8 to Drupal 9 would be essentially the same process, Drupal 7 goes out of support in November 2021. As that deadline approaches, upgrading will only become an increasingly pressing necessity. By migrating to Drupal 8 now, you avoid the complications that come with a hurried migration and can take on the process incrementally. 

So why wait? 

To get started with Drupal migration, be sure to check out our Drupal Development Services, and come back to our blog for more updates and other business insights. 
 

Dec 02 2019
Dec 02
A Step-by-step guide to integrating your BigCommerce store with the Drupal CMS


The BigCommerce for Drupal module, created by Acro Media in partnership with BigCommerce, was released early this year and brings together two different platforms – BigCommerce, the open SaaS ecommerce platform, and Drupal, the open source content management system. The result provides a wonderful new way for retailers to implement an innovative and content rich headless ecommerce strategy. If you use one and would like to have the capabilities of the other, the BigCommerce for Drupal module is the bridge you need. With this module, you can use Drupal as the powerful front-end CMS with BigCommerce as the easy-to-use and scalable ecommerce backend.

This post is a step-by-step guide for people who want to know how to install the BigCommerce for Drupal module and get started with both platforms. If you just want to know more about the BigCommerce and Drupal together as ecommerce solution, check out this post instead.

How this module works

Here’s a quick overview of how this all works. The BigCommerce for Drupal module integrates BigCommerce and Drupal together, but each platform is still used for different tasks.

In BigCommerce, you configure products, categories, shipping, taxes and everything else for the ecommerce side of your site. BigCommerce is also where you go to manage orders as they come in.

Drupal is then used for the website frontend and theming. Product and category information from BigCommerce are synced to Drupal, importing them as Drupal Commerce products so that they can be displayed and used like any other Drupal-based content. Any non-commerce content is also managed within Drupal. When a customer goes to checkout, a BigCommerce checkout pane is embedded in the Drupal site to securely process payment and save customer and order information.

Setup BigCommerce and Drupal

On to the guide! Follow these steps and you’ll have your BigCommerce and Drupal store configured in no time!

Prerequisites

This guide already assumes that you have the following ready.

  1. A BigCommerce account and store created
    You will need to create a BigCommerce account with at least one product, shipping method and payment method configured in your BigCommerce store. Do this here, not in Drupal.

    NOTE: BigCommerce currently offers a 14-day trial period, so any one can go and create and configure a store easily for free. For this demo, I signed up for that and created some random products to use for testing.

  2. A working Drupal 8 site
    You should have a Drupal 8 site with the Commerce module enabled and a default store added (via Commerce > Configuration > Store > Stores). You don’t need to do any other setup here yet or enable any of the other Commerce modules like checkout or payment. BigCommerce is going to handle all of this for you.
  3. An SSL certificate for your Drupal site
    Your Drupal website needs to have an SSL certificate active for the BigCommerce checkout form to render. This is required because it ensures security for your customers at checkout, so make sure you install one.

BigCommerce for Drupal setup guide

With the prerequisites done, here’s what you need to do to the the BigCommerce for Drupal connection made.

Step 1: Create a BigCommerce API account

  1. Go to your BigCommerce store admin page and navigate to Advanced Settings > API Accounts.
  2. Click on “Create API Account” button and select “Create V3/V2 API Token”.

    BigCommerce Store API Accounts page
    Fig: BigCommerce Store API Accounts page

  3. Provide a name (i.e. Product Sync) and select the scope for each features (i.e. if you don’t want the ability for the Drupal admin to modify product information, you can set the scope for “Products” as “read-only”).

    API configuration in BigCommerce
    Fig: API configuration in BigCommerce

  4. Click “Save” to save your changes. Once saved, you will see a summary and a prompt to download a file. Download it and keep it safe. Once you create an API account, you can’t modify the keys (but you can always make a new one).

    BigCommerce API Credentials dialog box
    Fig: BigCommerce API Credentials dialog box

Step 2: Download and configure the BigCommerce for Drupal module

  1. Get and install the BigCommerce for Drupal module.TIP: This module requires a bunch of other modules to work. To get the BigCommerce for Drupal module and all of its dependencies at the same time it’s recommended to use Composer instead of manually downloading it. Running the following command within your Composer based Drupal project will get everything you need.
    composer require drupal/bigcommerce
    
  2. In Drupal, navigate to module configuration page at Commerce > Configuration > BigCommerce > BigCommerce Settings.
    1. Fill in the API Path, Client ID, Secret Key, and Access Token that you received when creating the BigCommerce API.
    2. Hit “Save”. If everything is correct, you will see a message saying “Connected Successfully”.

      BigCommerce Configuration page in Drupal
      Fig: BigCommerce Configuration page in Drupal site

  3. Next we configure the Channel Settings. This will create a storefront url for you in BigCommerce which will match the one that is generated on the Drupal side.
    1. Select “Add new channel” from the select channel list.
    2. Provide a channel name.
    3. Click the “Create new BigCommerce channel” button. You will then see a Site ID and Site URL on the setting page.

      BigCommerce configuration page in Drupal - Channel settings
      Fig: BigCommerce configuration page in Drupal

  4. Now in the same Channel Settings area, click on the “Update BigCommerce Site URL” button. This lets you confirm that the url generated is actually sent to the BigCommerce, otherwise the checkout form will not be loaded on your Drupal site.

    You can also confirm the channel connection in from within the BigCommerce admin dashboard by visiting the Channel Manager admin page.

    Channel Manager storefront confirmation in BigCommerce
    Fig: Channel Manager storefront confirmation in BigCommerce

Step 3 : Sync products, variations and taxonomies from BigCommerce

  1. In Drupal, navigate to the product synchronization page at at Commerce > Configuration > BigCommerce > BigCommerce Product Synchronization.
  2. Click the “Sync Products from BigCommerce” button and ta-da, all the products, variations, and categories will be synced to your Drupal site in an instant.

    Alternately, you can also synchronize via the following Drush command. Advanced Drupal users can use this command on cron to do automatic syncing.

    drush migrate:import --group bigcommerce
    
    Product Synchronization page
    Fig: Product Synchronization page

    BC4D-Setup_Syncing-from-BigCommerce-in-progress-1
    Fig: Syncing from BigCommerce in progress

    NOTE: If you run into errors when syncing products, it probably because you don’t have a store added in the Drupal Commerce module yet. Add one at Commerce > Configuration > Store > Stores.

    TIP: Any time you make changes to the products in BigCommerce, visit this page or use the Drush command to synchronize the changes. Before syncing, you’ll also see a message telling you that updates are available.

  3. Confirm the products have synced by visiting the Product page for Drupal Commerce at Commerce > Products. A list of all of the products brought in from BigCommerce will appear here.

Step 4 : See the BigCommerce checkout in action

  1. Now that everything is set up, go to a product page, and it to your cart and proceed to checkout.

    If everything was done correctly, you will be able to see the BigCommerce checkout form embedded in to your Drupal site! Hurray! All of the shipping methods, payment methods, tax calculations, and other BigCommerce store configurations will be seen in the embedded form here.

    If you don’t see the checkout form make sure that your channels settings are correct and that you have an SSL certificate installed.

    Drupal’s checkout page with embedded BigCommerce checkout form
    Fig: Drupal’s checkout page with embedded BigCommerce checkout form

    Drupal’s checkout page after order complete
    Fig: Drupal’s checkout page after order complete

  2. Once an order has been placed, the order information will be stored in Drupal (at Commerce > Orders) and will also be sent to BigCommerce (at Orders > View).

    BigCommerce backend View Orders page
    Fig: BigCommerce backend View Orders page

Additional notes

The BigCommerce for Drupal module is ready for production and available for all to use. When writing this guide, there were some additional notes that I wanted to share.

  • At this time, product management should always be handled within BigCommerce and then synced to Drupal. Currently there is no option to bring back a product if you delete it in the Drupal side, so be careful.
  • A development roadmap for the module can be found here. It outlines future features and plans.
  • If you use the module and find any bugs or want specific features, please add them to the module issue queue here.

Acro Media is a BigCommerce Elite Partner

Acro Media is the development team partnered with BigCommerce that made the BigCommerce for Drupal module a reality. We have many, many years of ecommerce consulting and development experience available to support your team too. If you’re interested in exploring Drupal, BigCommerce or both for your online store, we’d love to talk.

View our BigCommerce for Drupal services

Nov 05 2019
Nov 05

Shawn McCabe, Acro Media’s CTO, recently made waves when he proclaimed through our blog that Ubercart is dead. We received both praise and criticism from the Drupal community for saying it, but the truth of the matter is that Ubercart, once the primary module businesses relied on for adding ecommerce functionality into the Drupal CMS, has yet to have a stable Drupal 8 release (even though Drupal 8 was released 4 years ago in November, 2015). It’s currently stuck in “alpha” and overall usage has been steadily declining for years. Read the initial post for more information.

We put out that post as an attempt to inform businesses that are currently using Ubercart that they should be planning their migration to something else ASAP, before Drupal 7 reaches end-of-life. Our suggestion for these businesses is to move to the Drupal Commerce module for Drupal 8. Drupal Commerce is the successor to Ubercart and was founded by one of the Ubercart creators. It’s the natural choice for these businesses and overall it’s a much better platform in every way.

Of course, when you tell a business that they need to replatform because their ecommerce software is “dying,” that’s not an easy thing for business owners to hear. Many flat-out ignore it to be honest, but those who understand the warning want to know more about how it will affect their business. From the reaction we received to the initial post, we understood that more needed to be said. Businesses using Ubercart now have questions that need to be answered. Because of this, we held an “Ubercart is Dead Roundtable” webinar-style discussion where we put Shawn in the spotlight to answer the questions that have come in. The goal of this discussion was to be both informative and demystifying, a general discussion instead of a sales pitch.

So without further ado, here is the roundtable recap video. A list of timestamped discussion topics are shown below the video. If you have any other questions not mentioned here, send us a message. We would be happy to answer any questions you may have.

Watch the roundtable

Host: Jace Anderson
Specialist: Shawn McCabe, CTO

00:00 - Introduction
00:45 - Who is Shawn McCabe
01:55 - Why do you [Shawn] think Ubercart is Dead?
03:07 - Why is Drupal Commerce the next platform of choice?
04:02 - Why should I move off of Ubercart when our business is currently operating fine?
05:58 - Is there a performance difference between Ubercart and Drupal Commerce?
08:06 - Is it possible to move off of Ubercart but stay on Drupal 7?
09:29 - How do we know Drupal Commerce won’t see the same fate as Ubercart?
11:00 - Is there a big difference in the features from Ubercart to Drupal Commerce? Is Drupal Commerce more robust?
13:35 - Is there a big learning curve for the backend administrators when using Drupal Commerce?
15:21 - How big of an undertaking is the migration from Ubercart to Drupal Commerce? Can an IT team of 5 complete it?
16:44 - What website components add to the complexity of a migration?
18:00 - Would a migration interrupt my business? Will it affect the customer experience?
18:54 - How would a migration impact my internal operations?
20:25 - How do we know Drupal Commerce won’t see the same fate as Ubercart (second part)?
21:26 - Currently we use multi-currency. Does Drupal commerce support this too?
22:41 - We use MailChimp for abandoned cart recovery. Can it still be used with Drupal Commerce?
23:10 - Are there other alternatives to Drupal Commerce? Is it the only option to continue using Drupal?
24:04 - How does Drupal Commerce perform on mobile?
25:02 - From your blog post, there looks to be companies using Ubercart on Drupal 8. What would prompt this?
25:57 - Can Drupal Commerce be used for custom customer experiences?
27:20 - Based on my research, Drupal Commerce is defined as having a difficult user interface. How can we ensure our team will be able to manage the backend?
28:28 - Can I manage my orders from my mobile device?
29:19 - What does Drupal Commerce offer for legacy software integration?
30:51 - What are the key specifications in a migration that attribute to an increased cost when doing a migration?
32:31 - Is my data migrated automatically? Can I also move order history, receipts and customer data?
33:40 - For a migration, where does one find support?
34:52 - What process is involved in managing coupons and promotions?
37:01 - How does bundling differ from Ubercart to Drupal Commerce?
38:00 - Does Drupal Commerce have subscription payment functionality?
40:05 - Is Drupal Commerce catalog taxonomy based?
41:10 - Shawn’s final words to those still on Ubercart who are not planning their move away from it yet.

Click to contact one of our ecommerce consultants

Nov 04 2019
Nov 04
A proactive approach for cleaner Drupal coding


So you are stuck in the cruft, struggling to create some semblance of sanity within a sea of code-rot. Code standards sound like a great idea for your project, but perhaps automated enforcement tools look like more of a pain than they're worth. This post is intended for Drupal developers using PhpStorm who need fast, flexible, standards enforcement tools.

Maintaining a stringent standard for your codebase is a battle. On one hand, your code is cleaner, more unified, and easier to maintain. On the other hand, these little formatting rules cause frustration and time loss - especially if a tiny slip causes you to waste a full pipeline cycle just to pass an automated standards check. As they say, the best defence is a strong offence, and the tools proposed here will help you find and fix standards violations before they reach a pipeline.

Drupal recommends a tool called PHP Code Sniffer, aka phpcs, to scan your files for Drupal Code Standards violations. Thankfully, it also comes with a companion tool called PHP Code Beautifier and Fixer, aka phpcbf, which fixes the small, tedious violations for you.

The goal of this post is to get phpcs and phpcbf under your fingertips and into your habits. Only once you have hotkeys set-up to run these tools while coding will they become useful — instead of just annoying.

The steps are as follows:

  1. Install and set-up phpcs
  2. Create a custom combination of rulesets
  3. Integrate with PhpStorm for hotkeys and syntax highlighting

1. Install and set-up phpcs

It may seem straightforward to install phpcs globally via Composer or apt, or to simply require it in your current composer project. However, a global install is not easy to customize and share. Instead, I recommend using a standalone repo that is specifically for your code standards tools. When your standards stand alone, they are easier to edit, share with teammates, and transfer to new work environments.

Here’s a simple repo to get you started:
https://github.com/nilswloewen/drupal_code_standards

  1. If you currently have phpcs or phpcbf installed globally, uninstall them before proceeding.
  2. Quick install with example repo:
    git clone [email protected]:nilswloewen/drupal_code_standards.git
    cd drupal_code_standards
    composer install
  3. Once composer has installed phpcs for you, add it to your global path with:

    export PATH=$PATH:~/PATH/TO/drupal_code_standards/vendor/bin
    NOTE: Adjust accordingly for your shell and OS of choice.
  4. Next, you must tell phpcs which rulesets you have installed use.

    The optional tool phpcodesniffer-composer-installer will automatically detect rulesets in your composer package and set your phpcs & phpcbf installed_paths for you. This is part of the example repo and the next step should have been done for you during "composer install".

    However, to set installed paths to rulesets manually run:

    phpcs --config-set installed_paths vendor/drupal/coder/coder_sniffer,vendor/phpcompatibility/php-compatibility/PHPCompatibility
    

    Then confirm that phpcs knows about the rulesets within the installed paths with:

    phpcs -i

    You should see this list that confirms your rulesets:

    The installed coding standards are ... PHPCompatibility, Drupal and DrupalPractice
    

    You may need to set installed paths for phpcbf as well using the same process.

2. Create a custom combination of rulesets

Out of the box, phpcs can only run one standard at a time. This is a problem when working with Drupal because we have 2 standards to follow. For this post I have added a third standard, PHPCompatibility, which is helpful when upgrading php versions on legacy projects.

  1. To combine standards we first create a custom ruleset that references multiple rulesets. Note that this is already included in the example repo as phpcs-custom-standards.xml.
    <?xml version="1.0"?>
    <ruleset name="Custom code standards">
    <rule ref="Drupal"/>
    <rule ref="DrupalPractice"/>
    <rule ref="PHPCompatibility"/>
    </ruleset>
  2. Then set this standard as your default. Use an absolute path to ensure your standard will be found no matter what context phpcs is called from.
    phpcs --config-set default_standard ~/PATH/TO/drupal_code_standards/phpcs-custom-standard.xml
    
    See the example standard for a few other helpful settings.

3. Integrate with PhpStorm for hotkeys and syntax highlighting

There are two levels of integration with PhpStorm: Passive and Active.

Passive

Passive code analysis with PhpStorm Inspections will give you syntax highlighting and hover-over explanations of the file you are currently working on.

PhpStorm passive integration

This is quite helpful when dealing with one file at a time, but when you need to get an entire directory to pass standards, you need a way to hunt for violations.

Active

Active analysis when you use phpcs to scan many files at once. You can do this through the terminal with a command like:

phpcs ~/module # Scans all applicable files in dir.
phpcs ~/module/example.php # Scans only a specific file.

However, it’s a pain to open a terminal window, navigate to the file you are working on, and then type a command. You’ll probably forget or neglect to check your work because of these extra steps involved. A better way to run phpcs is to set-up hotkeys within PhpStorm to scan your files instantly.

Configure PhpStorm inspections

  1. Register phpcs and phpcbf as PHP Quality Tools.

    Settings | Languages and Frameworks | PHP | Quality Tools | Code Sniffer

    PhpStorm PHP Quality Tools settings
  2. Enable the inspection.

    Settings | Editor | Inspection | PHP | Quality Tools

    PhpStorm PHP Inspections settings

  • Set the extension list to match what Drupal standard sets: source
    php,module,inc,install,test,profile,theme,css,info,txt,md,yml
    
  • DO NOT set the "Installed standard paths", as this overrides what you have previously set in the command line.
  • The refresh list button on "Coding Standard" should mimic what "phpcs -i" shows. Choose "Custom" Coding Standard and then click the ellipses to choose the path to your custom standards file (i.e. phpcs-custom-standards.xml).
  • Click OK and your inspections should be working!

Configure hotkeys

  1. Register phpcs and phpcbf as external tools.

    Settings | Tools | External Tools

    PhpStorm External Tools settings

    The "$FilePath" argument runs the tool against the file you are currently working on, or against a selected folder when in project view.
  2. Double check that this step works by running the tool from the main menu.

    Tools | External Tools | phpcs

    Running phpcs external tool

  3. This is the special sauce. Configure a keyboard shortcut for your new tools.

    Settings | Keymap | External Tools

    PhpStorm Keymap settings

  4. Right click on the external tool you just registered and add a keyboard shortcut. "Ctrl+Alt+Shift+Comma" was simply a combination that was not used anywhere else in my setup.

Bringing it all together

Now you can actively use phpcs and phpcbf while you code! I frequently use the phpcbf hotkey while writing new code to do the tedious stuff for me, such as creating doc blocks and pushing whitespace around. Here's an example:

Use phpcbf in PhpStorm with a hotkey

With phpcs and phpcbf now under your fingertips you are set to be much more assertive in your application of code standards!

Taking it to the next level

If you are using Gitlab for CI/CD, which I hope you are, another great strategy for enforcing standards is to create a pre-deployment job that scans your custom code for violations. This will keep your team (and you) in check by stopping standards violations from being auto-deployed.

After a few super annoying pipeline failures for minor syntax errors, you will want this next level of enforcement — git pre-commit hooks. I highly recommend using grumphp to manage this for you.

Best of luck keeping your code readable and up to snuff!

End-to-end Drupal services

As a full service Drupal agency, Acro Media has significant expertise in digital commerce architecture, ecommerce design, customer experience, software development and hosting architecture. If you’re looking for a Drupal agency dedicated to code and project quality, check us out. We would love the opportunity to talk.

View Our Drupal Commerce Services

Oct 28 2019
Oct 28

Drupal Commerce 2, like Drupal 8, was a big change from previous versions. The code base is much different and it’s quite a learning curve when moving from Drupal 7 to the more complex approaches in Drupal 8. However, this is good. The new versions are modern and all around better. I’ve had a number of revelations while working with Drupal Commerce 2 and Drupal 8 that made me smile. In this post, I’ll explore one revelation I had while working with Drupal Commerce 2’s checkout handling and how it’s forward-thinking development has paved the way (and encourages all new checkout panes to follow suit) for headless ecommerce using Drupal.

Drupal Commerce 2 checkout is not a form… say what!?

Generally, when you think of checkout, you think of it as a sequence of events and one big final submission. This is further driven home by the idea that you can, and should, be able to go back and edit your checkout choices before the final submission. In Drupal Commerce 2, going back and forth between checkout steps is supported, but there is no final submission handler that saves everything.

Wait, what? That’s right, there’s no need to save all the data on the checkout form once checkout is completed. You see, all checkout panes (a step in the checkout process) have a submission event that gets called when it's time to save the data. So if you’re going to save data in a checkout pane, you gotta do it after your customer has moved forward in the checkout process but before your customer is ready to commit to the checkout pane’s final value state (complete checkout). Submission is perceived to be at the end of checkout, not before.

On the surface that might make sense, in fact, this workflow being so obvious might even blind you to the implications. Since each pane is basically handling its own submission workflow, you can’t allow your form state to persist choices and not make a decision until the end. You’re probably, like me, thinking that saving data and reacting to data is the same thing. But this assumption is old, out of date, incompatible with best practices, and in checkout for Commerce 2, causes design problems.

Click to discover your ideal architecture with our analysis.

Explanation through an example: A checkout newsletter subscription

A common want is to include a little checkbox underneath a contact information email field where new or returning customers can opt-in to a newsletter. Sure, that’s no big deal, right?

Our customer expects that things in checkout aren’t real until they complete checkout (i.e. nothing is saved until they actually place the order). On the other hand, Drupal Commerce 2 expects all panes to save their data after a “continue to next-step” button gets clicked, submitting that pane.

Here’s how the checkbox would be made using our current form submission logic:

  1. Create a CheckoutPaneBase object that collects data through a checkbox
  2. On the pane form submission, subscribe the customer to your newsletter

Do you see the problem? If we react on pane submission (our only choice in our current way of thinking), we’ll subscribe the customer to our newsletter well before they are done with checkout. In fact, each time they see the first page of checkout and proceed to the second, they will be subscribed to our newsletter. Not only is this not what the customer would expect, but subscribing them multiple times is totally unnecessary and would likely cause problems. Subscribing the customer on pane form submission is the wrong approach.

This is where things get really trippy – and awesome and beautiful and wonderfully clever and great. You see, Drupal 8, which Commerce 2 is built around, has been designed to not require forms, form states and value persistence in order to trigger important actions. This is a whole new way of thinking and maybe the most important to our discussion. Previous to this, most Drupal 7 developers would have assumed that all forms require user-facing interfaces that would be submitted, but that is a pretty brutal assumption and has plagued a lot of Drupal installations over the years. If that was still the case, then form submissions are something that headless implementations of Drupal would never really trigger. There must be a better way.

Headless decoupling breeds better code using events

If checkout was a single form with a final submission handler that submitted payment, subscribed users to newsletters, saved addresses to profiles, and did all the things you would expect all at once, then all the code that manages these things would have to react to a single form submission.

However, if we use Drupal's built in event system instead, we suddenly have much greater degree of control. But before we get into that, let’s first take a quick look at what events are and where they come from.

Drupal 8 made a big shift towards being object oriented by adopting Symfony within its framework. Symphony provides a number of components useful in modern object oriented programming, one of which is events. Events in Drupal 8 give developers a new way to extend and modify how interactions with core and other modules work. If you’re already familiar with Drupal 7, events are basically meant to replace hooks. Drupal 8’s event system documentation helps us to understand the basic concepts and components making up the event system.

  • Event Subscribers - Sometimes called "Listeners", are callable methods or functions that react to an event being propagated throughout the Event Registry.
  • Event Registry - Where event subscribers are collected and sorted.
  • Event Dispatcher - The mechanism in which an event is triggered, or "dispatched" throughout the system.
  • Event Context - Many events require specific set of data that is important to the subscribers to an event. This can be as simple as a value passed to the Event Subscriber, or as complex as a specially created class that contains the relevant data.

Source: Drupal.org documentation, Subscribe to and dispatch events (link)

Getting back to our checkout scenario, if you use the events system and your checkout completion is simply a state transition from Draft to Completed, then other modules could subscribe to that transition event, take the saved data from the different pane submissions, and do whatever they want with it.

Do you see the beauty here? By forcing checkout panes to submit before the final submission, we (module builders, implementers, etc.) have a baked-in reason to store checkout decisions on the order so that order events can access them separately, giving us the ability to create orders with checkout decisions saved that can skip checkout completely and still have the events trigger the needed actions. This is quite powerful and opens up a whole new world of possibilities. Of course, since this is an implicit design choice, it’s up to the author of the module or code to see the reasons and embrace them.

Entity + event-based instead of form-based

So to complete our newsletter subscription pane example using our new knowledge of events instead of form submissions, here’s what we would do:

  1. Create a CheckoutPaneBase object that collects data through a checkbox and saves it to the order (either through a field value or the ->setData typed data interface.
  2. Save this value on pane submission but don’t act on the value (i.e. don’t subscribe the user)
  3. Create an event subscriber and use the transition event you want to use as a trigger. Completing checkout makes the most sense.
  4. Treat the order value as a "request subscription to newsletter." Then, when the event fires and the event subscriber runs, it can look for the saved value and set the user to subscribed or not after it returns. This allows us to handle someone going through an event twice for some reason, like for multiple orders, etc.

Your customer gets subscribed to your newsletter when they, and you, expect them to. No forms needed. ISN’T THAT AMAZING!

Thanks to the many authors of Drupal Commerce 2, including Bojan Živanović and Matt Glaman, that implemented this design choice years ago, many modules and implementations are simply technically better and likely ready for headless implementations now that headless is all-the-rage.

And best of all, from a developer standpoint, this also means the bulk of your most critical automated tests that interact with your code doesn’t have to access the checkout form. They simply have to have orders that get transitioned. This makes writing tests, which equates to better code, simpler.

Your Drupal Commerce experts

As a full service Drupal agency, Acro Media has significant expertise in digital commerce architecture, ecommerce consulting and design, customer experience, Drupal development and hosting architecture. We would love the opportunity to work with you.

View Our Drupal Commerce Services

Oct 02 2019
Oct 02

With its open source software and proven technology, Drupal is the first choice for many business owners when it comes to deciding a framework for their digital commerce business. After all, it’s a great CMS and ecommerce can be added to it through custom-built development (although custom might not be best, more on that later).

So, how about your business? Are you using Drupal and have an integrated or custom ecommerce component? Or, maybe you’re still deciding on which way to go to add ecommerce functionality? If so, let’s talk about the features that you probably wish to have in your website:

  • Are you looking for limitless product presentation and customization options?
  • Do you have plans to set up multichannel marketing and automation for your website?
  • Are you planning to integrate third party systems or run custom social media campaigns?
  • Do you need the flexibility to scale your website with endless options?

If you replied “yes” to any of the above questions, I would say custom-built ecommerce probably isn’t your best option. Nor do I think you need a pre-packaged SaaS solution, either. Before I suggest what you might want to do, let’s first look specifically at why custom ecommerce can present its own difficult challenges you definitely want to avoid.

5 challenges of a custom ecommerce system

Depending upon the complexity of requirements, it can take anywhere from months to years to set up a proper ecommerce site, no joke. Let’s say you’ve decided on building custom ecommerce functionality into your Drupal site. You’ve hired a developer, or maybe an agency or an internal team, to build it and have been able to get the ecommerce functionality that your business needed to get started. Great!

Now, after a year or so, you start thinking of scaling it by adding more features and functionality. This is where you may start running into challenges. Let me outline some of the more critical challenges you may face.

1. Handcuffed to an internal development team or outside agency

This can be a touchy subject but is probably the biggest liability for a company using custom development, so let’s start here. Ideally you’d still want to use that original development team who has all the knowledge of how your ecommerce component was made. But what if you can’t get the same developers or what if you have a falling-out with the agency who built it? Imagine how difficult it might be to onboard new developers when you yourself don’t know the code. Without a predefined standard or framework, how your ecommerce was built is anyone's guess. Significant cost will be added just to get any new developers up-to-speed.

2. Slow to implement new features and/or functionality

If you’re constantly feeling like you are reacting to the market rather than being a proactive innovator, this can be a direct cause of custom development. Simply put, everything you add to your website needs to be built and nothing is ready-made that you can just plug in. There is no time saving options that you can take advantage of to speed things up.

3. Inability to integrate with desired third party platforms

Integrations are one of the biggest benefits of an open source platform so it can be a real problem if you’re not able to integrate quickly and effectively.

Consider the cost that you have to bear when you are introducing something as simple as a new payment system or a new tax rule. Something that should be easy might take far too much time than it’s worth because you don’t have access to an underlying framework that was made specifically to make building these integrations faster.

Or maybe a robust new marketing tool comes in to the market and if you want to take advantage of it by integrating it with your ecommerce site. Let peace be upon you… this larger integration could be a monumental task. Every integration you require means more custom development, more cost, and lengthy timelines to completion.

4. Sacrificing the front-end customer experience

Custom development is built by developers first and so the actual look and presentation is often sacrificed for functionality. This isn’t meant to be a knock on developers, but the simple truth of the matter is that building code and building layout and design are two entirely different specialties. It’s very rare that you find someone with both skill sets. Without good UX and design, your customers will not get the front-end experience they expect which could impact your business performance.

If the makeup of your team includes designers and frontend developers, great! This would alleviate presentation issues, but these extra specialists will add additional expense to your custom build.

5. Unable to take advantage of the community

If all you have is custom functionality, you could be spending a lot of time and money developing features and/or integrations that potentially already would have existed if you had gone a different route. If you think about it, one of the great things about Drupal in general is all of the community-made modules that you have access to for extending your site’s functionality. While you’ll still be able to use them with your Drupal site, the custom ecommerce side of things doesn’t have that benefit. Everything you need must be built and probably only your team of developers can do it.

If not custom development, then what?

So what do you choose when custom development is a hassle and I’ve already mentioned that I’m not pushing you towards a SaaS solution. Well, my suggestion is that you should consider using the Drupal-native ecommerce module, Drupal Commerce. I mean, why marry off your Drupal site with someone else when we have fully compatible Drupal Commerce with us. It has been a proven ecommerce framework since 2011 (view usage stats) and lets you build a secure, scalable, SEO and mobile friendly ecommerce site in whatever way your business needs! It’s framework has been made for extending. It’s documented and has a large community centered around it (which Acro Media is a part of). Maybe you’ve heard negative rumblings about it in the past, and if so, I think you should look again.

Here’s how I justify my view, or rather, how Drupal Commerce can help you fulfill your ecommerce requirements.

Top 7 reasons why you should use Drupal Commerce

Below are the top 7 reasons why you should be selecting Drupal Commerce over any custom or off-the-shelf hosted solutions out there.

1. Commerce and content will easily get along

When we use Drupal Commerce with Drupal, it will let you manage your content strategy right within your ecommerce platform. You can easily manage complex relationship between products and other contents in the site. The CMS part will let you create custom landing pages to attract the attention of users while flexibility in the ecommerce part will make it easier for a site owner to manage new products and its workflow.

2. Requires less development effort

When you need a content site as well as an ecommerce site, With out-of-the-box modules and pre-configured distributions, a Drupal Commerce store can be easily setup without much hassle. Plus, when custom development is required, Drupal’s strict code standards ensure that any competent Drupal developer can easily jump-in and understand what’s going on. You’re not stuck with just a single developer or agency to manage your project. You have the freedom to shop around.

3. Highly customizable and scalable

Unlike most SaaS systems, Drupal and Drupal Commerce can be customized according to the business’s needs. Even though Drupal and Drupal Commerce are architected to be extended limitlessly, all the extensions follow a general standard. This makes sure that when the next person with knowledge in Drupal Commerce comes along, either from a development or administrator standpoint, this person can handle the software easily. New features or integrations can be performed faster which takes the system scalable to the next level.

From a performance perspective, Drupal and Drupal Commerce are more than capable of scaling to meet the needs of small business all the way to enterprise. Need proof, we’ve tested their performance and you can see the results here.

4. Integration with external systems

This is the core strength of Drupal. Drupal modules have been built so that they can interact with one another easily. If you need to connect your ecommerce to payment gateways, marketplaces, CRMs, analytics tools, SEO tools, shipping providers, the list goes on, they can be done as quickly as within a few hours (integration depending, of course). Drupal takes an API first approach which is what you want for integrations now and in the future.

5. Free and open source

Unlike proprietary ecommerce systems, Drupal Commerce is open source and there is no licensing cost or usage limits. Unlike other open source solutions, there are no paid modules within the Drupal community. You have access to it all and can extend and customize it in whatever you like. By saving money on the software, you can instead invest that money in your Drupal based platform and your own business needs.

6. Community support

Drupal has an immensely large community with thousands of active users helping to build and maintain the core software and its extensions. The features you require for your site could be already created by someone else and available on Drupal.org, waiting for you to take advantage of. Various IRC channels, blogs, forums, agencies, etc. will help you in case you are blocked or need advice on almost anything related to Drupal.

7. Solid future version support

With the release of Drupal 8, we are quite clear on how migrations to the next version will happen. If your site is already using Drupal 8, then you don’t have to worry about Drupal 8 being unsupported by community because you will easily be able to migrate your site to Drupal 9 (and future versions) when the time comes.

It doesn’t mean that your Drupal 7 site will be isolated either. The stable Migrate module in Drupal 8 will make a migration of your Drupal 7 site to Drupal 8 easier than ever before, saving time and money when adopting the newer version.

Demo Drupal Commerce today! View our demo site.View a Drupal Commerce demo

To help show you what a Drupal Commerce ecommerce solution looks like, check out our fully functional Drupal Commerce demo site, Urban Hipster.

Here you can click around and “buy” products just like you would using any real ecommerce site. You will see content pages, a best-practice product catalog, a variety of product types, and more. This feature rich demo was made to give you an idea of what your Drupal Commerce site could do, but of course this is just one example. The possibilities are endless.

Plan your move to Drupal Commerce

Leave custom development and integrated ecommerce frameworks behind by starting your move to Drupal Commerce today. Acro Media is an ecommerce consulting and development company that specializes in open source and Drupal Commerce. Take a look at our Drupal Commerce solutions today and let us know if you have any questions. We’d love to help you understand if Drupal Commerce is a good fit for your business.

Sep 19 2019
Sep 19

Ubercart, once the go-to commerce option for Drupal and the precursor to Drupal Commerce, is slowly fading away. Its usage has been declining for years and a stable Drupal 8 release will never happen. Even one of the original creators has moved on to support a new Drupal ecommerce solution instead of continuing on with Ubercart. In you’re running an ecommerce site that uses Ubercart, this post is for you. Our goal is to show you why you should consider moving off of Ubercart now instead of waiting until it finally reaches end of life.

UPDATE: Click here for an Ubarcart is Dead roundtable discussion. The roundtabe discussion is a follow up to this article in the form of a webinar-style question and answer recorded video session with Shawn McCabe.

The decline of Ubercart today

As mentioned in the introduction. Ubercart usage has been declining for years. The Drupal 7 version of the module is where it saw most of its success with usage peaking in 2014/2015, but usage has been continuously dropping since then. The following graph is a snapshot of Ubercart’s usage history as recorded on Drupal.org.

Ubercart usage history
Ubercart usage history (source)

Ryan Szrama, one of the original creators of Ubercart, moved away from it and started the Commerce module for Drupal as a replacement. Since then, the majority of the ecommerce community around Drupal has also moved along with him making Drupal Commerce the new go-to option for ecommerce built on Drupal. Not only does Commerce now have more installs for both Drupal 7 and Drupal 8, but it is also a much more active development community.

Usage-statistics-for-Drupal-Commerce-1
Commerce usage history (source)

Ubercart and Drupal 8

The Ubercart module has never moved over to a proper Drupal 8 release. Development is stuck in alpha and without a new release in over 3 years, there is never going to be a stable Drupal 8 release.

What “alpha” means

In software development, alpha is a term given to a software release that is still very much in development and not ready for production. Here’s the description of alpha from Drupal.org.

alpha: Most reported errors are resolved, but there may still be serious outstanding known issues, including security issues. Project is not thoroughly tested, so there may also be many unknown bugs. There is a README.txt/README.md that documents the project and its API (if any). The API and DB schema may be unstable, but all changes to these are reported in the release notes, and hook_update_N is implemented to preserve data through schema changes, but no other upgrade/update path. Not suitable for production sites. Target audience is developers who wants to participate in testing, debugging and development of the project.

In contrast, the Drupal Commerce module has had many full production-ready releases for Drupal 8 and follows a release schedule for bug fixes and new features. The group behind Drupal Commerce is actively developing the core software and the wider community is also active in supporting the project.

Ubercart and Drupal 7

What Ubercart development still happens focuses on maintenance of the Drupal 7 version only. The catch here is that Drupal 7 reaches end of life November 2021, which will likely spell the effective end of Ubercart as well. If you’re using Ubercart and Drupal 7 together and you want new features and active development, that realistically ended years ago when the majority of the contributor community moved away from the project.

Here’s a couple snapshots of the commit history for both the core Ubercart module and the core Drupal Commerce module. A commit is a term given to code changes that have been added to the module. Commits are typically code improvements, new features, bug fixes and security updates that have been written, tested and approved for release.

ubercart-commit-historyUbercart commit history

drupal-commerce-commit-history
Commerce commit history

When looking at the graphs above, it’s important to know that it’s common to see number of commits trailing off over time. This is because the majority of the core software is built early on and so fewer commits are made over time as development of the core ramps down. What is important to see is that development of Drupal Commerce over Ubercart is still continuing, meaning new features and code improvements are being actively made to the core Commerce software but not to Ubercart.

Another point to note about these graphs is that when commits are ramping down to the core software, development efforts are likely being moved to community built extensions. This data isn’t reflected in the graphs above. The community built extensions is the ecosystem of new add-ons and features that aren’t found in the core software. In the case of Ubercart, this community development is very small and limited whereas for Drupal Commerce community is very active and engaged.

Where to go from Ubercart?

You’ve probably guessed this already, but the clear path moving away from Ubercart is to Drupal Commerce. Commerce is the Ubercart replacement and it’s capable of so much more. It’s also Drupal 8 ready and will provide a painless transition to Drupal 9, when that happens.

Commerce improvements over Ubercart

The following is a list of improvements Commerce for Drupal 8 has over Ubercart:

Drupal 8 improvements over Drupal 7 include:

  • Robust caching and performance for authenticate or unique users, very important for any ecommerce site
  • Drupal’s new rolling release schedule, no more large updates between versions makes updates easier
  • Modern object oriented design, which makes testing, extension and use of 3rd party libraries easier. Commerce follows all of the architectural improvements for Drupal 8 and has, in some cases, lead the way by innovating first.

Commerce improvements over Ubercart include:

  • More secure payment architecture. Commerce encourages the lowest level of PCI risk possible and enforces good practices with it’s payment API, compared to Ubercart’s primarily DIY payment model.
  • Proper variation based product model with unique SKUs for each variation
  • Robust and accurate promotions, discounts and pricing adjustments. If you’ve struggled with pricing accuracy in Ubercart you’ll understand.
  • Multi-store and multi-currency support is robust and built in.
  • And the list goes on…

Why move now instead of later?

While you could wait until Drupal 7 end of life to move your ecommerce site off of Ubercart and onto Drupal Commerce, this is not something we would ever recommend. The truth of the matter is that by waiting until the very end, you’re taking on a lot of unnecessary risk for both your business and your customers. You don’t want to be in a position where you’re scrambling to make-it-happen quickly when suddenly you’re not getting any more security updates to both Drupal 7 AND Ubercart. That is a worse-case scenario and you would be wise to avoid it.

Right now is an ideal time for you to consider making the switch. Both Drupal 8 and Commerce have been used in the wild now for years and the software is very stable. Most likely all of the features and functionality that you currently use has already been ported over to the new versions. The tools that help migrate Drupal 7 and Ubercart over to Drupal 8 and Commerce have been created to assist with the move. Really, from a technical standpoint there’s no reason to not make the move now.

Of course, it can’t be denied that completing a migration to the latest and greatest does take time and effort to do, and there will be a cost involved. All the more reason to start the process now. Right now you have the time to find the help you need and to properly budget and plan how your migration will be executed. Right now it’s not a hassle, it’s an opportunity to make your business better for both you and your customers while at the same time correcting any of the little things that bother you about your site now.

Acro Media has been helping ecommerce owners and operators with consultation and development for well over 10 years. We’re intimate with both Ubercart and Drupal Commerce, and we even staff some of the talented people who built Commerce and the migration tools everyone uses to make the move. If you want to learn more about how your migration would happen, we would love to talk. Click the link below to get started.

Read the full Gartner report

Aug 13 2019
Aug 13

Back in April, BigCommerce, in partnership with Acro Media, announced the release of the BigCommerce for Drupal module. This module effectively bridges the gap between the BigCommerce SaaS ecommerce platform and the Drupal open source content management system. It allows Drupal to be used as the frontend customer experience engine for a headless BigCommerce ecommerce store.

For BigCommerce, this integration provides a new and exciting way to utilize their platform for creating innovative, content-rich commerce experiences that were not possible via BigCommerce alone.

For Drupal, this integration extends the options its users and site-builders have for adding ecommerce functionality into a Drupal site. The flexibility of Drupal combined with the stability and ease-of-use of BigCommerce opens up new possibilities for Drupal that didn’t previously exist.

Since the announcement, BigCommerce and Acro Media have continued to educate and promote this exciting new headless commerce option. A new post on the BigCommerce blog published last week title Leverage Headless Commerce To Transform Your User Experience with Drupal Ecommerce (link below) is a recent addition to this information campaign. The BigCommerce teams are experts in what they do and Acro Media is an expert in open source integrations and Drupal. They asked if we could provide an introduction for their readers to really explain what Drupal is and where it fits in to the headless commerce mix. This, of course, was an opportunity not to be missed and so our teams buckled down together once again to provide readers with the best information possible.

So without further explanation, click the link below to learn how you can leverage headless commerce to transform your user experience with Drupal.

Read the full post on the BigCommerce blog

Additional resources:

May 28 2019
May 28

This is the second post in a two part series focused on specific platforms for experience-led ecommerce. The first post focused on Drupal, an open-source CMS, as an excellent option for creating content-rich customer experiences when combined with an ecommerce component of your choice. This post will focus on BigCommerce, an increasingly popular open SaaS ecommerce platform, and how its strengths in ecommerce can be complemented by an integration with Drupal.

A quick introduction

Like the last post, here’s a quick introduction to the main concepts and software discussed.

SaaS

Whether it’s accounting, marketing, ecommerce, etc., SaaS (software as a service) platforms are a great option for many businesses. With this service model, businesses simply sign up and pay a monthly fee to use the platform. This is an attractive option because the cost is generally quite reasonable and the onus is on the service provider, not the business, to host the service and keep it up and running. For a business, it’s hands-off and requires little to no IT staff to manage.

Open SaaS

Open SaaS is still a relatively new term and has a couple different meanings. For this post, I’m using open SaaS to describe a SaaS services that is also open for integration and innovation through APIs and webhooks. This means that a business can use the SaaS service as-is, but it’s not restricted by it. This will become more clear the further you read through this post.

BigCommerce

BigCommerce is gaining popularity as a SaaS ecommerce platform. As a service, BigCommerce provides everything a business needs to quickly create an online store and start selling products. It has a wide variety of customizable themes available, supports custom themes, and has an extension library to add additional functionality to the base platform. While this is all quite normal for SaaS ecommerce, what makes BigCommerce an exciting platform is it’s commitment to being open via APIs and webhooks. This allows BigCommerce to be used as a headless backend store management area with the front-end of your choice, opening up a world of possibilities for creating customer experiences not previously possible with other popular SaaS ecommerce solutions.

SaaS at different stages of growth

Ecommerce businesses can grow quickly. Being set up for scalability to handle this growth is extremely important early on to eliminate headaches later on. This is the main reason why all of us at Acro Media are always talking about the importance of utilizing the right commerce architecture. The right architecture will enable a business to scale effectively without bottlenecking operations with swivel-chair processes. BigCommerce is uniquely capable of handling this growth, from startup all the way up to enterprise powerhouse.

Click to discover your ideal architecture with our analysis.

SaaS for startup and small businesses

For many small ecommerce businesses, SaaS ecommerce platforms like BigCommerce provide a quick and cost-effective solution to get to market. These businesses typically have a low IT budget and are just looking for solutions that are easy to implement and use. In many cases, SaaS checks these boxes and is the perfect starting point. This is why platforms like BigCommerce, Shopify and SquareSpace have become so popular. We call this scenario commerce-led because the ecommerce platform used dictates what other software and integration are also used in combination.

SaaS for medium, large and enterprise businesses

While SaaS is typically great for startups and small businesses, established businesses are an entirely different situation. They’re now looking at technology as an enabler for reaching the next level. They see personalization and the customer’s experience as an area where they can differentiate themselves from their competitors. These businesses are now hitting the limitations and restrictions of their SaaS ecommerce platform due to the fact that SaaS is typically built for the most common use cases and is therefore rigid in allowing these businesses to add the unique functionality and the integrations that they need. As technological requirements for a business changes, the software used must change too. These businesses are now looking at investing in stable technology that increases efficiencies, automates time consuming tasks, and gives them the edge in defining their customer journey. This may mean moving away from a commerce-led architecture and into experience-led. Often, ecommerce replatforming is part of this move.

BigCommerce is different

So, where does BigCommerce and Drupal fit into the mix. As I mentioned earlier, BigCommerce as a SaaS service is an ideal ecommerce platform for startup and small business. Not only does it give these businesses the ecommerce tools and stability needed to easily conduct business online, but it’s uniquely capable of growing with these businesses further, all the way through to enterprise.

How? Through BigCommerce’s open APIs and webhooks, BigCommerce can be run headless as a robust and secure enterprise-level ecommerce backend that compliments the incredible content experience capabilities of Drupal as the frontend. This means that these businesses can start with a SaaS solution that works great and then replace the frontend with Drupal if and when it makes sense to do so. They integrate directly together, creating a SaaS & open source hybrid ready to disrupt the insanely expensive enterprise ecommerce space, finally giving companies a capable and cost-effective alternative solution that is built for growth, scalability and integration.

Why Drupal?

If you haven’t read the first post in this series, I’d recommend you take a moment to do that. It discusses the strengths of Drupal for experience-led ecommerce complete with some examples. In short, customer experience is seen as a major competitive advantage in established ecommerce and Drupal is able to provide that experience while also being able to integrate with the ecommerce component of your choice. One choices being BigCommerce.

How it works

Acro Media teamed up with BigCommerce to create the BigCommerce for Drupal integration, so we are very in-tune with the strengths of both platforms. Here’s a high-level breakdown of how the integration works.

  1. Set up a BigCommerce store
    The business signs up for an account with BigCommerce and adds products, payment gateways and shipping options as it normally would. The BigCommerce backend is used for all of the ecommerce functionality, so the store configuration happens here.

    As mentioned earlier, existing BigCommerce store’s don’t need to create a new store for this integration with Drupal to work. Drupal just replaces the frontend, so the integration can happen at the beginning or anytime in the future.

  2. Connect BigCommerce and Drupal
    Drupal is then installed separately and the BigCommerce for Drupal module is added along with any dependencies. The module’s settings page within Drupal is where the BigCommerce store is connected and products get synced. This brings the products into Drupal as content.
  3. Complete the Drupal website frontend
    The rest of the website is then built within Drupal like any normal Drupal website. This involves setting up additional content types, configuring the display of this content and imported products, and finally theming the site.

That’s it! Drupal is where the content lives and what customers interact with. Operational staff who manage the store and fulfill orders do so within BigCommerce. When customers decide to purchase products, they do so through an embedded BigCommerce secure checkout.

And there you have it, the best of both worlds!

Further information

Interested in learning how your business can leverage the strengths of BigCommerce and Drupal together?

Discover BigCommerce for Drupal

Or check out these related resources.

May 21 2019
May 21

This is the first of a two part series (UPDATE: part two here) discussing a couple of different platforms that we at Acro Media endorse for our clients. First up, I’ll talk about Drupal, a popular open-source content management system, and how it’s excellent content capabilities can be extended using an ecommerce component of your choice. For companies that require experience-led commerce architecture solutions, Drupal as an integration friendly content engine is an ideal open source choice.

A quick introduction

People who follow our blog will already know about open source technology and Drupal because we talked about them a lot. For those of you who don’t know, here’s a quick introduction.

Open Source

Wikipedia sums up open source software well.

Open-source software is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose. Open-source software may be developed in a collaborative public manner. Open-source software is a prominent example of open collaboration.

Open-source software development can bring in diverse perspectives beyond those of a single company. A 2008 report by the Standish Group stated that adoption of open-source software models have resulted in savings of about $60 billion (£48 billion) per year for consumers.

While that describes open source software as a whole, there are many advantages of open source specifically for content creation and ecommerce. No licensing fees brings the total cost of ownership down, businesses are fully in control of their data, and integrations with virtually any other system can be created. If you like, you can read more about the advantages of open source for ecommerce via this ebook.

Drupal

Drupal is a leading open source content management system that is known for being extremely customizable and ideal for creating rich content experiences. In a CMS world dominated by WordPress, Drupal is often overlooked because of its complexity and somewhat steep learning curve. Don’t let that stop you from considering it, however, as this complexity is actually one of Drupal’s greatest strengths and the learning curve is continuously improving through admin-focused UX initiatives.

The platform can literally be made to do anything and it shines when very specialized or unique functionality is required. It has a rich ecosystem of extensions and is very developer friendly, boasting a massive development community ensuring that businesses using Drupal always have support.

On top of this, Drupal has various strategic initiatives that will keep it modern and relevant now and into the future. One of the initiatives is for the platform to be fully API-first, meaning that a primary focus of Drupal is to be integration friendly. Developers can integrate Drupal with any other software that has an API available.

Drupal for experience-led commerce

Drupal is suited for any of the three main architectures (discover your ideal architecture here), but experience-led commerce is where it’s most capable. Experience-led is for businesses who keep the customer experience top of mind. These businesses want more than to just sell products, they want to also tell their story and foster a community around their brand and their customers. They want their customer experiences to be personalized and content rich. It’s these experiences that set them apart from their competitors, and they want the freedom to innovate in whatever way is best for their business.

Click to discover your ideal architecture with our analysis.More often than not, SaaS ecommerce platforms alone just don’t cut it here. This is simply because they’re built for ecommerce, not as an engine for other content. Although there are a lot of benefits to SaaS for ecommerce, businesses using SaaS must conform to the limitations set by the platform and its extensions. Robust content is just not typically possible. Sure, a business may be able to maintain a blog through their SaaS ecommerce platform, but that’s about it.

Drupal, on the other hand, is a content engine first. It was built for content, whatever that content may be. If you can dream it, Drupal can do. On top of this, Drupal, being integration friendly through its API-first initiative, allows businesses the freedom to integrate any compatible SaaS or open source ecommerce platform. At this point, a complete content & commerce solution has been created and the only limitation is your imagination and available resources to implement it. Implementation can be done in-house with an internal IT team or outsourced to one of the many service providers within the Drupal marketplace, Acro Media being one of them.

Let’s look at three widely different examples of Drupal based experience-led commerce.

TELUS Mobility

Website: www.telus.com

TELUS Mobility is one of Canada’s largest telecommunications companies. Imagine the missed opportunities when a customer’s online billing isn’t connected to your latest promotions and customer service can’t quickly or easily get this information in front of them. This was a problem that they faced and business restrictions, one being that they need to own all of their code and data, required that they look outside of the SaaS marketplace for a solution. Drupal, combined with a Drupal-native Drupal Commerce extension, was the solution that they needed. The open source code base of both Drupal and the Commerce extension meant that TELUS Mobility had the control and ownership that they needed. The result was huge, many important customers and customer service UX improvements were made which enabled TELUS Mobility to outperform their competitors.

You can read the full TELUS Mobility case study here.

Bug Out Bag Builder

Website: www.bugoutbagbuilder.com

Bug Out Bag Builder (BOBB) is a content-rich resource centered around preparedness. They generate a lot of different types of content and needed a way to do it that is easy and reusable. They also had a very unique commerce element that needed to tie in seamlessly. Here’s how we did it.

First is the content aspect. BOBB is full of content! They maintain an active blog, continuously write lengthy product reviews and provide their readers with various guides and tutorials. They’re a one-stop-shop for anything preparedness and have a ton of information to share. As you can see, a simple blog wouldn’t be sufficient enough for this business. They needed a way to create various types of content that can be shared and reused in multiple places. The Drupal CMS was easily able to accommodate. All of the content has a specific home within the site, but each article is categorized and searchable. Content can be featured on the homepage with the click of a button. Various blocks throughout the site show visitors the most recent content. Reviews can be attached to products within their online custom bug out bag builder application (more on this below). All of this is great, but what makes Drupal a fantastic content engine is that if BOBB ever needs to use this content in another way, all of the saved data can be reused and repurposed without needing to recreate the content. Just a little configuration and theming work would need to be done.

Second is the commerce aspect. BOBB is not a standard ecommerce store. At their core, they’re actually an Amazon Associate. They’ve developed a trust with their readers by providing fair and honest reviews of preparedness products that are listed on the Amazon marketplace. If a reader then goes and buys the product, BOBB gets a cut since they helped make the sale.

That’s all pretty normal, but what makes BOBB unique is that they also have a web-based Custom Bag Builder application. This tool has a number of pre-built “BOBB recommended” bag configurations for certain situations. Customers can select these bags (or start from scratch), view/add/remove any of the products, and finally complete the purchase. Since BOBB doesn’t need the full capabilities of ecommerce, it didn’t make sense for them to be paying monthly licensing fees. Drupal Commerce was selected for this purpose. It’s used as a catalog for holding the product information and creating a cart. Then, an integration between Drupal Commerce and Amazon transfers the cart information to Amazon where the customer ultimately goes through checkout. Amazon then handles all of the fulfillment and BOBB gets the commission.

BikeHike Adventures

Website: www.bikehike.com

BikeHike Adventures was founded as a way of bringing like-minded adventurers together through the unique style of world travel that they promote – activity, culture and experience. They provide curated travel packages that customers enquire about through the BikeHike Adventure website. Travel is all about experience and they needed to share this experience through their website. They also needed more than just a standard article page to do it since there is a ton of information to share about each package. Furthermore, they wanted to give customers a way to reserve a trip for pre-selected dates or through a custom trip planner. Again, Drupal was a perfect fit.

When you visit the site, you’re immediately thrown into the world of active travel through a rich video banner followed by a series of travel packages, a travel blog and more. There is a lot of exciting locations and vibrant imagery throughout.

Clicking into a package, you’re again hit with spectacular photography and all of the information you would need to make a decision. You can read about the trip, view the itinerary and locations marked on a map, learn about what’s included and where you’ll be staying, read interesting and useful facts about the country and location, see a breakdown of day-to-day activities, read previous traveler review, and more. When a customer is ready to book, they can submit an enquiry which is then handed off to the BikeHike Adventures travel agents.

A commerce component isn’t actually being used in this site, but it’s just a great example of content and customer experience that is used to facilitate a booking with a travel agent. If BikeHike Adventures wanted to in the future, they are free to integrate the booking and payment platforms of their choice to automate some, if not all, of that aspect of this process. By utilizing the open source Drupal CMS, this is an option that they can exercise at any point in time.

Who is Drupal best suited for?

Drupal could be used for any business, but it’s typically best suited for ecommerce businesses:

  • Who want to differentiate their brand through personalized shopping experiences
  • Who want to showcase products outside of a standard product page
  • Who want the power to develop a content-rich experience AND have an industry standard checkout process
  • Who want to sell across multiple channels and third-party marketplaces
  • Who need to develop and execute cohesive and synchronized marketing campaigns across multiple channels
  • Who want the freedom to integrate and connect their CMS and commerce platform with other components within their overall architecture
  • Who want to limit platform fees and instead invest in their own commerce infrastructure

In closing, there’s a reason why the ecommerce market is open to open source more than ever. Businesses are increasingly seeing that open source provides a quality foundation for which to build and integrate the solutions they need for today's new-age ecommerce. Customer experience is now seen as a competitive advantage and there are a handful of options that can provide this experience, Drupal being one of them. If you’re looking experience-led ecommerce solutions, consider Drupal. It might just be what you need.

UPDATE: Read part 2 of this series - BigCommerce & Drupal for Growing Ecommerce Businesses

Additional resources

If you liked this article, check out these related resources.

Click to discover your ideal architecture with our analysis.

Apr 08 2019
Apr 08
Acro Media teams up with BigCommerce


Acro Media has teamed up with BigCommerce, a leading SaaS ecommerce platform, to create the BigCommerce for Drupal module, a headless commerce module integrating both platforms together.

What does this mean? It means that companies can now utilize the quick-to-market and feature-rich backend benefits of BigCommerce SaaS while enjoying the content-rich and extensible frontend experience of Drupal, the open-source CMS. It’s a melding of systems that results in a best-of-both-worlds solution for today's digital experience driven ecommerce needs.

Discover BigCommerce for Drupal

Read the full press release below.

April 8, 2019 11:00 am EDT

BigCommerce for Drupal Brings Customized Shopping Experiences to Drupal Community

SEATTLE – April 8, 2019 – BigCommerce, the leading SaaS ecommerce platform for fast-growing and established brands, today announced BigCommerce for Drupal, a headless commerce module built specifically for the open-source content management system (CMS), at DrupalCon Seattle. Developed in partnership with Acro Media, a world-renowned digital commerce agency, BigCommerce for Drupal gives brands the ability to embed flexible, enterprise-level ecommerce functionality into revolutionary customer experiences created within Drupal’s highly-extensible and secure CMS.

Available now in the Drupal module library, BigCommerce for Drupal facilitates an agile headless commerce architecture for merchants by decoupling Drupal’s powerful front-end CMS and BigCommerce’s scalable commerce engine. Knitted together by fast, open-source APIs, the module allows the two platforms to operate simultaneously and more efficiently within a single interface. Additionally, BigCommerce for Drupal is built directly into Drupal Commerce, making it compatible with the many existing themes and modules available within Drupal Commerce.

“Shopping experiences should not be limited by any single content management or ecommerce platform’s native capabilities, and BigCommerce for Drupal embodies that philosophy. We want pioneering brands to continue driving retail innovation forward and help redefine how customers buy products, whether it be through augmented reality, social selling or any disruptive technology that lies ahead,” said Russell Klein, chief development officer at BigCommerce. “Furthermore, announcing BigCommerce’s headless implementation at DrupalCon, an event that brings together one of the strongest and most engaged online communities, signals the value we place on open-source technology that can be made better through collaboration.”

Key features of BigCommerce for Drupal include:

  • Drupal Commerce Core: BigCommerce for Drupal is built atop the Drupal Commerce module, developed in part by Acro Media, tapping into years of iterative improvements and enhancements.
  • Data Sync: With BigCommerce for Drupal, retailers can synchronize product and metadata directly from BigCommerce into Drupal, and then augment and manage data directly within the Drupal CMS.
  • Cached Commerce: The connected BigCommerce store will sync at merchant-determined intervals, saving a cached version of the catalog inside Drupal rather than pinging BigCommerce APIs for information.

“As two open, API-driven platforms, there is a natural alignment between BigCommerce and Drupal, and this module bridges the gap to unify their respective functionalities into one intuitive interface,” said Shae Inglis, chief executive officer at Acro Media. “The future of ecommerce is open architecture, and headless integrations lets even enterprise-level brands be nimble and capitalize on the explosion of new, innovative consumer touchpoints.”

To learn more about BigCommerce for Drupal visit www.bigcommerce.com/drupal. To download the BigCommerce for Drupal Module visit www.drupal.org/project/bigcommerce. DrupalCon attendees can also get more information by visiting the Acro Media booth (#802).

Is BigCommerce and Drupal right for you?

Quickly find out using Acro Media's Ideal Commerce Architecture Analysis.

Complete Your Ideal Architecture Analysis

Mar 13 2019
Mar 13

Note: This post refers to Drupal 8, but is very applicable to Drupal 7 sites as well

Most Drupal developers are experienced building sitewide search with Search API and Views. But it’s easy to learn and harder to master. These are the most common mistakes I see made when doing this task:

Not reviewing Analytics

Before you start, make sure you have access to analytics if relevant. You want to get an idea of how much sitewide search is being used and what the top searches are. On many sites, sitewide search usage is extremely low and you may need to explain this statistic to stakeholders asking for any time-consuming search features (and yourself before you start going down rabbit holes of refinements).

Take a look for yourself at how the sitewide search is currently performing for the top keywords users are giving it. Do the relevant pages come up first? You’ll take this into account when configuring boosts.

Using Solr for small sites

Drupal 8 Search API comes with database search included. Search API DB has come a long way over the years and is likely to have the features you need for smaller sites. Using a Solr backend is going to add complexity that may not be worth it for the amount of value your sitewide search is giving. Remember, if you use a Solr backend you have to have Solr running on all environments used in the project and you’ll have to reindex when you sync databases.

Not configuring all environments for working Solr

Which takes us to this one. If you do use Solr (or another server-side index) you need to also make sure your team has Solr running on their local environments and has an index for the site. 

Your settings.php needs to be configured to connect to the right index on each environment. We use Probo for review sandboxes so we need to configure our Probo builds to use the right search index and to index it on build.

Missing fields in index or wrong type

Always included the ‘Rendered HTML’ field in your search index rather than trying to capture every text field on all your content types and then having to come back to add more every time you add a field. Include the title field as well, but don’t forget to use ‘Fulltext’ as its field type. Only ‘Fulltext’ text fields are searchable by word.

Not configuring boosts

In your Processor settings, use Type-specific boosting and Tag-boosting via HTML filter. Tag boosting is straightforward: boost headers. For type-specific boosting you’re not necessarily just boosting the most important content types, but also thinking about what’s in the index and what people are likely looking for. Go back to your analytics for this. 

For example, when someone searches for a person’s name, are they likely wanting the top result to be the bio and contact info, a news posting mentioning that person, or a white paper authored by the person? So, even if staff bios are not the most important content on the site, perhaps they will need to be boosted high in search, where they are very relevant.

Not ordering by relevance

Whoops. This is a very common and devastating mistake. All your boost work be damned if you forget this. The View you make for search results needs to order results by Relevance: Descending.

Using AJAX

Don’t use the setting to ‘Use AJAX’ on your search results View. Doing so would mean that search results don’t have unique URLs, which is bad for user experience and analytics. It’s all about the URLs not about the whizzbang.

Not customizing the query string

Any time you configure a View with an exposed filter, take the extra second to customize the query string it is going to use. ‘search’ is a better query string than ‘search_api_fulltext’ for the search filter. URLs are part of your user interface.

No empty text

Similarly, when you add an exposed filter to a search you should also almost always be adding empty text. “No results match your search” is usually appropriate.

Facets that don’t speak to the audience

Facets can be useful for large search indexes and certain types of sites. But too many or too complex facets just create confusion. ‘Content-type’ is a very common facet, but if you use it, make sure you only include in its options the names of content types that are likely to make sense to visitors. For example, I don’t expect my visitors to understand the technical distinction between a ‘page’ and a ‘landing page’ so I don’t include facet links for these.

A screen shot of facets in DrupalYou can exclude confusing facet options 

Making search results page a node

I tell my team to make just about every page a visitor sees a node. This simplifies things for both editors and developers. It also ensures every page is in the search index: If you make key landing pages like ‘Events Calendar’ as Views pages or as custom routes these key pages will not be found in your search results. 

One important exception is the Search Results page itself. You don’t want your search results page in the search index: this can actually make an infinite loop when you search. Let this one be a Views page, not a Views block you embed into a node.

Important page content not in the ‘content’

Speaking of blocks and nodes, the way you architect your site will determine how well your search works. If you build your pages by placing blocks via core Block Layout, these blocks are not part of the page ‘content’ that gets indexed in the ‘Rendered HTML.’ Anything you want to be searchable needs to be part of the content. 

You can embed blocks in node templates with Twig Tweak, or you can reference blocks as part of the content (I use Paragraphs and Block Field.)

Not focusing on accessibility

The most accessible way to handle facets is to use ‘List of Links’ widget. You can also add some visually hidden help text just above your facet links. A common mistake is to hide the ‘Search’ label on the form. Instead of display: none, use the ‘visually-hidden’ class.

Feb 19 2019
Feb 19
Performance and scale for all levels of digital commerce


Drupal Commerce is a fantastic open source ecommerce platform, but there is a common misconception that it is lacking when it comes to performance and scalability. This is not true! Drupal Commerce is extremely fast and is more than capable of scaling from small business all the way to enterprise level ecommerce. We have proof and it’s right here for you to view.

Download the Drupal 8 Commerce Performance Benchmarks Report (PDF)

About the report

Shawn McCabe, Acro Media’s CTO, put Drupal Commerce to the test to see how it performed on a number of different AWS configurations, ranging from single server setups all the way up to multi-server configurations.

He ran simulated traffic through Drupal Commerce, mimicking actual traffic as close as possible, testing concurrent users, site speed, transactions per second, and a number of other useful technical metrics.

The smallest server configuration tested was capable of handling 130 concurrent users flawlessly, with a throughput of 13.59 transactions per second. On the other hand, the largest configuration could handle 52,000 concurrent users with a throughput of 1,305.85 transactions per second.

The report goes further and includes how the tests were set up, their limitations and methodology, all of the server configurations details and, of course, the test results. This testing puts the performance and scalability question to rest, backed by hard data that anyone can reproduce. Drupal Commerce is a viable option for ecommerce that businesses of any size can use and grow with in the future.

Feb 06 2019
Feb 06

Mass.gov dev team releases open source project

Moshe Weitzman

The Mass.gov development team is proud to release a new open source project, Drupal Test Traits (DTT). DTT enables you to run PHPUnit tests against your Drupal web site, without wiping your database after each test class. That is, you test with your usual content-filled database, not an empty one. We hope lots of Drupal sites will use DTT and contribute back their improvements. Thanks to PreviousNext and Phase2 for being early adopters.

Mass.gov is a large, content-centric site. Most of our tests click around and assert that content is laid out properly, the corresponding icons are showing, etc. In order to best verify this, we need the Mass.gov database; testing on an empty site won’t suffice. The traditional tool for testing a site using an existing database is Behat. So we used Behat for over a year and found it getting more and more awkward. Behat is great for facilitating conversations between business managers and developers. Those are useful conversations, but many organizations are like ours — we don’t write product specs in Gherkin. In fact, we don’t do anything in Gherkin beside Behat.

Meanwhile, the test framework inside Drupal core improved a lot in the last couple of years (mea culpa). Before Drupal Test Traits, this framework was impossible to use without wiping the site’s database after each test. DTT lets you keep your database and still test using the features of Drupal’s BrowserTestBase and friends. See DrupalTrait::setUp() for details (the bootstrap is inspired by Drush, a different open source project that I maintain).

Zakim Bridge at Night, North End Boston. Photo by David Fox.
  • Our test cases extend ExistingSiteBase, a convenience class from DTT that imports all the test traits. We will eventually create our own base class and import the traits there.
  • Notice calls to $this->createNode(). This convenience method wraps Drupal’s method of the same name. DTT deletes each created node during tearDown().
  • Note how we call Vocabulary::load(). This is an important point — the full Drupal and Mink APIs are available during a test. The abstraction of Behat is happily removed. Writing test classes more resembles writing module code.
  • Typically, one does not run tests against a live web site. Tests can fail and leave sites in a “dirty” state so it’s helpful to occasionally refresh to a pristine database.

If you have questions or comments about DTT, please comment below or submit issues/PRs in our repository.

More from Moshe: Our modern development environment at Mass.gov

Interested in a career in civic tech? Find job openings at Digital Services.
Follow us on Twitter | Collaborate with us on GitHub | Visit our site

Feb 05 2019
Feb 05
How do you start contributing to Drupal without code?nstagram iconouTube icon

<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1114119085333160&amp;ev=PageView&amp;nosc...">

<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=247202&amp;fmt=gif">

Outlets for contributing to Drupal beyond code, whilst abundant, are not always evident to those having interest to do so. I want to help people become better acquainted with ways to get involved and how to start their contribution journey. Be they completely new to Drupal or simply yet to find an outlet.

At DrupalCamp London 2019 I will be speaking about non-code contributions and invite you to share your experiences and ideas. Open my eyes to the many ways individuals can create impact with their time, without knowing code at all.

Your participation will ensure attendees discover a multitude of ways to get involved well beyond my experiences alone. In doing so you are embodying the principle of contributing without code.

Therefore I have set up a Google Form to collect suggestions from the community. Please complete it with as many ideas as you have and I look forward to reading your suggestions!

 

Share your ideas

Feb 01 2019
Feb 01

Just imagine it: Drupal 8's robust features as a CMS, the flexible e-commerce functionality of the Drupal Commerce ecosystem and a JavaScript framework for the front-end! All in the same native mobile app! You can easily achieve this “combo” — a reliable content repository & a JS-based front-end providing a fantastic shopping cart experience — if you just... decouple Drupal Commerce.

For why should you trade Drupal's battle-tested content authoring and administration tools for a more interactive user experience? 

And why should you give up on your goal to deliver richer cart experiences just because Drupal 8 can't rival the JavaScript in terms of advanced native mobile app functionality?
 

  • push notifications
  • complex shopping options
  • enabling users to manage their own delivery times and places
  • ... to configure various aspects of their orders and so on
     

Just leverage a decoupled Drupal Commerce strategy in your shopping app project and you can have both:
 

  • Drupal as your secure content service 
  • the front-end framework of your choice “in charge” with the user experience 
     

In this respect, these are the most useful Drupal tools at hand for implementing an API-based headless architecture:
 

1. Headless Commerce Comes Down to...

… separating your commerce stack (back-end content handling area, data store etc.) from the user interface.

Or the “head”, if you wish.

The presentation layer would “retrieve” content from the back-end content storage area and is the one fully “responsible” with delivering fantastic user experience.

This way, you're free to choose your own front-end tools.

Now, why would you consider choosing a decoupled architecture for your e-commerce solution? The benefits are quite obvious and not at all negligible:
 

  • higher flexibility and scalability (that JS frameworks are “famous” for)
  • freedom to customize your app to your liking (for every platform or/and device)
  • richer, more interactive shopping experiences 
     

2. Decoupled Drupal Commerce... Out of the Box? The Commerce Demo 

Narrowing our focus down to... Drupal, to Drupal Commerce, more specifically, the question's still there:

“How do I decouple Drupal Commerce?”

Considering that:
 

  • there are specific challenges that such a decoupled front-end architecture poses
  • Drupal solutions like Forms API and Views won't fit your specific (probably quite complex) design implementation requirements
     

Luckily, the Commerce Guys team has already faced and solved these challenges.

First of all, they've put together the Commerce Demo project, a store providing default content to be “injected” into Drupal.

Secondly, their attempt at integrating a design meant to support advanced functionality, for richer shopping cart experiences, resulted in 2 new modules:
 

  • Commerce Cart API
  • Commerce Cart Flyout
     

More about them, here below...
 

3. Useful Modules to Decouple Drupal Commerce 

Here's a collection of the most... relevant modules that you could use in your headless Drupal Commerce project:
 

3.1. The Commerce Cart API Module

It's no less than a handy Drupal tool that enables you to custom build your shopping cart widget. 
 

3.2. The Cart Flayout Module

The go-to module when you need to ajaxify the “Add to cart” form in your shopping app.

Basically, what it does is:

Provide a sidebar that “flies out” once the user clicks the “Add to cart” button or the cart block.

If I were to dive into details a bit, I'd add that the flyout enables users to:
 

  • view the products in their shopping carts
  • remove all the items there
  • update the quantity of a specific item
     

Should I add also that Cart Layout comes with no less than 9 different Twig templates, for various parts of the module? By leveraging Drupal's library management feature you can easily override these JS segments of the module.

And not only that you get to customize it to suit your needs entirely, but:
 

  • it comes with a well structured JS logic
  • it's built on top of Backbone
     

… which translates into an efficient models-views separation.
 

3.3. Commerce 2

Use Drupal Commerce 2 as the core structure of your e-commerce project.

Being an ecosystem of Drupal 8 modules and “spoiling” you with unmatched extensibility via its APIs, Drupal Commerce empowers you to implement all kinds of headless commerce scenarios.

It enables you to use Drupal as your content/data (user and order-related info) repository and to easily serve this content to your mobile app. To your end-users.
 

3.4. The Commerce Recurring Framework Module

Some of its handy charging & billing features include:
 

  • configurable billing cycles
  • configurable retries in case of payment declines
  • both prepaid and postpaid billing systems
     

3.5 The JSON API & JSON API Extras Modules   

Need to decouple Drupal Commerce, to enable a full REST API in JSON format? 

It's as easy as... enabling a module (or 2 at most): the JSON API module.

What it does is:
 

Expose the API so you can vizualize the data in JSON format.

And Drupal's built and perfectly adapted to support JSON API, which turns it into the go-to option when you need a back-end content repository for your headless shopping app.

In addition to this module, feel free to enable JSON API Extras, as well. It comes particularly handy if you need to customize the generated API. 

It allows you to:
 

  • override the name of your resources
  • change their path...
     

You'll then have a specific place in your app's user interface where you can visualize your content paths.

Once you have your data in JSON format, safely stored in your back-end content creation & moderation Drupal area, you're free to... serve it to your mobile shopping app!
 

The END!

And these are some of the already tested tools and techniques to decouple Drupal Commerce so that you can deliver richer, more interactive cart experiences.

Have you tried other modules/methods? Writing custom JavaScript code... maybe?

Feb 01 2019
Feb 01

In this article we will see how to update data models in Drupal 8, how to make the difference between model updating and content updating, how to create default content, and finally, the procedure to adopt for successful deployments to avoid surprises in a continuous integration/delivery Drupal cycle.

Before we start, I would encourage you to read the documentation of the hook hook_update_N() and to take into account all the possible impacts before writing an update.

Updating the database (executing hook updates and/or importing the configuration) is a very problematic task during a Drupal 8 deployment process, because the updating actions order of structure and data is not well defined in Drupal, and can pose several problems if not completely controlled.

It is important to differentiate between a contributed module to be published on drupal.org aimed at a wide audience, and a custom Drupal project (a set of Drupal contrib/custom modules) designed to provide a bespoke solution in response to a client’s needs. In a contributed module it is rare to have a real need to create instances of configuration/content entities, on the other hand deploying a custom Drupal project makes updating data models more complicated. In the following sections we will list all possible types of updates in Drupal 8.

The Field module allows us to add fields to bundles, we must make difference between the data structure that will be stored in the field (the static schema() method) and all the settings of the field and its storage that will be stored as a configuration. All the dependencies related to the configuration of the field are stored in the field_config configuration entity and all the dependencies related to the storage of the field are stored in the field_storage_config configuration entity. Base fields are stored by default in the entity’s base table.  

Configurable fields are the fields that can be added via the UI and attached to a bundle, which can be exported and deployed. Base fields are not managed by the field_storage_config configuration entities and field_config.

To update the entity definition or its components definitions (field defintions for example if the entity is fieldable) we can implement hook_update_N(). In this hook don’t use the APIs that require a full Drupal bootstrap (e.g. database with CRUD actions, services, …), to do this type of update safely we can use the methods proposed by the contract EntityDefinitionUpdateManagerInterface (e.g. updating the entity keys, updating a basic field definition common to all bundles, …)

To be able to update existing data entities or data fields in the case of a fieldable entity following a modification of a definition we can implement hook_post_update_NAME(). In this hook you can use all the APIs you need to update your entities.

To update the schema of a simple, complex configuration (a configuration entity) or a schema defined in a hook_schema() hook, we can implement hook_update_N().

In a custom Drupal project we are often led to create custom content types or bundles of custom entities (something we do not normally do in a contributed module, and we rarely do it in an installation profile), a site building action allows us to create this type of elements which will be exported afterwards in yml files and then deployed in production using Drupal configuration manager.

A bundle definition is a configuration entity that defines the global schema, we can implement hook_update_N() to update the model in this case as I mentioned earlier. Bundles are instances that persist as a Drupal configuration and follow the same schema. To update the bundles, updated configurations must be exported using the configuration manager to be able to import them into production later. Several problems can arise:

  • If we add a field to a bundle, and want to create content during the deployment for this field, using the current workflow (drush updatedb -> drush config-import) this action is not trivial, and the hook hook_post_update_NAME() can’t be used since it’s executed before the configuration import.
  • The same problem can arise if we want to update fields of bundles that have existing data, the hook hook_post_update_NAME() which is designed to update the existing contents or entities will run before the configuration is imported. What is the solution for this problem? (We will look at a solution for this problem later in this article.)

Now the question is: How to import default content in a custom Drupal project?

Importing default content for a site is an action which is not well documented in Drupal, in a profile installation often this import is done in the hook_install() hook because always the data content have not a complex structure with levels of nested references, in some cases we can use the default content module. Overall in a module we can’t create content in a hook_install() hook, simply because when installing a module the integrity of the configuration is still not imported.

In a recent project i used the drush php-script command to execute import scripts after the (drush updatedb -> drush config-import) but this command is not always available during deployment process. The first idea that comes to mind is to subscribe to the event that is triggered after the import of the configurations to be able to create the contents that will be available for the site editors, but the use of an event is not a nice developer experience hence the introduction of a new hook hook_post_config_import_NAME() that will run once after the database updates and configuration import. Another hook hook_pre_config_import_NAME() has also been introduced to fix performance issues.

A workflow that works for me

To achieve a successful Drupal deployment in continuous integration/delivery cycles using Drush, the most generic workflow that I’ve found at the moment while waiting for a deployment API in core is as follows :

  1. drush updatedb
    • hook_update_N() : To update the definition of an entity and its components
    • hook_post_update_N() : To update entities when you made an entity definition modification (entity keys, base fields, …)
  2. hook_pre_config_import_NAME() : CRUD operations (e.g. creating terms that will be taken as default values when importing configuration in the next step)
  3. drush config-import : Importing the configuration (e.g. new bundle field, creation of a new bundle, image styles, image crops, …)
  4. hook_post_config_import_NAME(): CRUD operations (e.g. creating contents, updating existing contents, …)

This approach works well for us, and I hope it will be useful for you. If you’ve got any suggestions for improvements, please let me know via the comments.

Jan 30 2019
Jan 30

Drupal Camp London is a 3-day event celebrating the users, designers, developers and advocates of Drupal and its community! Attracting 500 people from across Europe, after Drupalcon, it’s one of the biggest events in the Drupal Calendar.

CxO day, on Friday 1st March, is dedicated to businesses using Drupal, encouraging them to lead development and innovation of the Drupal platform.

The weekend (2nd & 3rd March) then packs in over 40 sessions covering seminars, Birds of a feather talks, Sprints and much more. Over the weekend there are also 3 Keynotes addressing the biggest upcoming changes to the technical platform, its place in the market, and the wider Drupal community.

 

Drupal camp 2018 Ryan SzramaRyan Szrama delivering a session at Drupal Camp 2018, Photo Cred: @pdjohnson

 

Our Weekend Sessions

Our Drupal Director, Paul Johnson, will be focussing on contributions to Drupal, but not as you know them. The session will be diving into a whole host of ways to contribute to Drupal that don’t require code. From content writing to photography, this session includes something for everyone and is guaranteed to spark some inspiration for new Drupal community initiatives.

 

Our UX specialist, James Genchi, will also be speaking at Drupal Camp London about UX and accessibility. With a background in development and a passion for user experience, James’ understanding of accessibility within design and development is vast. Following a substantial redesign for the University of West London, James will be sharing the unique design considerations he applied to achieve global accessibility within the website. In particular, he will be highlighting how accessible design is not just for people with a permanent disability, but also for those with a temporary and situational disability.

Be sure to follow us on twitter  so you don't miss either of these sessions!

Why should you attend Drupal Camp? 

[embedded content]

 

Exchange knowledge

Discover the latest in UX, design, development, business and more. There’s no limit to the types of topics that could come up...as long as they relate to Drupal that is!

Network

From C-Level and Site managers to developers and designers, over 500 people attended last year. Meet the best and brightest in the industry at talks and breakouts.

Recruit and be recruited

A wide variety of business and developers attend Drupal Camp, make the most of it by creating connections to further your own career or grow your agency team.

Reasons for attending the weekend eventImg Cred: Drupal Camp

 

 

We hope to see you there! Grab your ticket while you still can on the Drupal Camp website.

Tickets 

And be sure to follow us on your social platform of choice to find out when our sessions are!

 

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web