Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Feb 24 2021
Feb 24

The advent of Drupal 8 brought about many new features and improvements. One highly anticipated change was the move to a new structured release cycle. The update promised to improve compatibilities between versions, introduce gradual deprecation of old APIs alongside new features, and strongly suggested that the days of performing full-site rebuilds to move between major versions of Drupal were in the past.

Now that Drupal 9 has been released, we’ve had the opportunity to work through the upgrade process from Drupal 8 and found that it is indeed a significantly lower lift than doing re-implementations while moving to Drupal 8. That being said, there are still important considerations to keep in mind when preparing and executing your upgrade to Drupal 9.

Required Tooling
The first step of any project is making sure you have the proper tools to proceed, and Drupal upgrades are no different. Because the first challenge is finding and fixing all of the deprecated code and identifying modules that need updating, you will need a tool to help you. Fortunately, the Upgrade Status module gives you almost everything you need by checking:  

  • Global requirements to ensure our environment is configured correctly and has all of the prerequisites installed to run Drupal 9. 
  • Contributed modules to see if they are Drupal 9 ready, have a compatible upgrade, or have a patch available to make them compatible.
  • Custom code to identify deprecations and required changes.
  • Themes for deprecated Twig syntax.
  • Any installed libraries for deprecation status, required changes to our info.yml files, and other possible compatibility issues.

Upgrade Status can be run with Drush or from within your Drupal site, but it’s not a good idea to run this on production. Instead, install it as a dev requirement and run it locally or on your development or local environment. If your codebase is larger, the checks can take a little bit of time to run, particularly when run locally. You can run against a subset of your site’s modules if necessary and export the results after running the checks.

If your site has a significant amount of custom code, you also want to install Upgrade Rector. This module uses the Rector PHP refactoring library to automatically generate patches to fix the deprecations in your code. While it can’t fix everything, it can significantly speed up the process.

Updating Core
Routine site maintenance should always include installing and testing updates to the latest versions of Drupal Core and installed contributed modules. While Third And Grove’s support process consists of this as part of our regular support contracts, it’s a fact of life that many teams struggle with prioritizing these updates over more critical work to meet actual business goals. If your site is well-maintained, this step will be easy: The Upgrade Check report will be mainly Green, and you are well on your way to being ready for D9.

More commonly, sites will lag on updates, and your reports will show several updates that need to be applied. The first step of the Drupal 9 preparedness project should be to ensure that you are running the latest version of Drupal 8 (8.9.13 at the time of this writing).  Drupal 8.9 is the long-term support version of Drupal 8 and is the ideal starting place for a D9 upgrade. If your site’s code is working on Drupal 8.9 and clean of any deprecations, it should work with Drupal 9 since they share the same public APIs.

The first major stumbling block many upgrades hit is when the site has lagged significantly behind the Drupal update schedule and is currently on a version of Drupal older than 8.8.  This can be problematic because each Drupal feature release introduces different overall requirements and various changes under the hood that can require database updates and other special handling. To address this, we strongly recommend first reviewing the release notes of each minor version (i.e., Drupal 8.4.0, 8.5.0, etc.) and note the changes introduced by each version. Changes include the fact that Drupal now requires PHP 7.3 or greater, the addition of new core modules (such as Workflows, Media Library, and JSON: API), changes to the way path aliases are handled, and the introduction of a new set of Composer packages and a default project template. Make a note of each change that may impact your particular site install and correct any discrepancies that may arise.

Once reviewed, we don’t recommend jumping directly to 8.9 unless you are on a version *prior* to 8.6.1. Generally, you want to perform each minor upgrade individually and test them before moving on to the next version. Still, if there was a bug related to taxonomy updates in the update to 8.6, that is best avoided. Otherwise, use Composer to require and install the latest patch release of a specific version, run any database updates, and test your installation running that version before moving on to the next minor version upgrade.

Update Contributed Modules
By this point, you have used Upgrade Status to generate a list of modules your site uses and their readiness for Drupal 9. This is a straightforward process for most common modules: The module will have a version ready that is compatible with both Drupal 8 and 9, and you will update it as usual (after reviewing the release notes — see the next section). There are three cases where this can become less straightforward:
No Update Available, But There Is A Patch
Some module maintainers may not have released a version of the module with the required Drupal 9 changes yet, but Upgrade Status tells you that a patch is available for the module. One tricky aspect of this is that if some of the required changes are to the module’s composer.json file, they cannot be patched using Composer. This is due to the way it checks dependencies — a classic chicken and egg problem. While in general, it is not recommended to add contributed modules to your codebase, you can pull the modules that require patching into your project, remove them as composer dependencies, and then follow the [process of applying that patch to your codebase with Composer](https://groups.drupal.org/node/518975).  If you have to take this approach, you should continue monitoring the project and adding it back to your composer.json when the module is D9-ready.

Module Has No Patches Available
Because of the Drupal 9 Project Readiness Bot, most modules should have at least one patch available to bring the module up to speed from a compatibility standpoint. However, if you are using a module that does not, there’s still hope. With the information that Upgrade Status gives you about specific deprecations and the patches generated by Upgrade Rector, you can patch the module yourself, making it ready for other users.  

When you build these patches, we recommend following the standard Drupal module contribution guidelines and working on the module against the dev version outside your site’s codebase. Once the patch is built, you can contribute it back to the community via the project’s issue queue, then follow the process outlined above for a module that has a patch available.

Update Is A Major Version Change
We have seen one tricky situation arise with some contrib modules: modules that have a version that supports Drupal 9, but the version is also a major release with breaking API changes. This is rare but worth noting, especially if the module is one that your custom code depends on in some way. Big API changes in a module behind the scenes may significantly impact your site and require that you refactor your code to account for them. 

Updating Custom Code
Your custom code can be the most significant source of potential changes to your codebase in preparing your site for Drupal 9, especially for long-running projects that started in the early days of Drupal 8. The API changes and deprecations in D9 are well-known and documented. Still, it’s never surprising to find that routine maintenance has taken a back seat to implement new functionality to handle new business requirements.  

Fortunately, the tools for upgrading Drupal also handle custom code, pointing out where the deprecations are, what changes need to be made, and sometimes even making the change itself using Upgrade Rector. Rector can’t fix every deprecation, but it can automatically make quick work of many of the items, freeing up developer time to tackle more difficult changes. This is also an opportunity for possible efficiency, as many custom module updates could be happening in parallel to the contributed module work.

Testing Your Upgrade
Once the code is all in place and all database updates have been run, it’s time to test your site for potential regressions. Most issues and edge cases can be caught when performing the upgrades themselves, which is one reason we suggest performing the module upgrade steps one-at-a-time. If you update one module at a time (or in small groups of modules of similar/shared functionality), obvious regressions and unexpected behavior can be caught early, reviewed, and fixed. If you have enough hands, fixing problematic code can be handled by one developer while another developer continues updating and testing other modules.

A smart strategy for getting ahead of these issues is to review the release notes for the modules you are updating before beginning the process. Most module maintainers will give guidance on any additional upgrade steps or considerations you should take before upgrading, saving you time and headaches later on in the process.

Once your upgrades are complete, you will want to perform a series of checks of your site's overall functionality to ensure you aren’t running into edge cases that your unique combination of code is surfacing. It’s crucial to check all editorial and administrative functions as well — the site may appear to be operating normally. Still, some unseen interaction could be wreaking havoc with your editors’ ability to update content.  Behavioral and visual regression testing can help accelerate this process. Still, sites with complex interactions and administrative needs should be tested in concert with the actual people who use these sites daily — they are often the people best equipped to detect if something is amiss.

In The End
As we said at the outset, the underlying architecture changes to Drupal 8 brought with them a promise for easier future updates and the ability for our sites to continue to grow and evolve through many major versions of Drupal. Every functioning Drupal site relies on modules from the wider Drupal community for essential functionality. This adds another layer of complexity and dependency on the maintainers of those modules. The community as a whole has been good about maintaining modules to the D9 standard, but it’s not unusual for a site to depend on a module that lags.  

Another critical factor in the upgrade conversation is whether your site has been maintained and kept up to date already. Many site owners struggle to keep their sites' code current, but sacrificing these regular updates makes sites vulnerable to security issues and makes the Drupal 9 upgrade process significantly more difficult. That being said, a well-maintained Drupal 8 site can deliver on the promise of easy upgrades to Drupal 9 and beyond.

Jan 19 2021
Jan 19

We set up an internal ask me anything session with Nat, the Drupal core maintainer that works at TAG that we sponsor to contribute to Drupal core every day and let our engineering team ask him anything they wanted. We got into some very deep topics and had learned some things that quite surprised us. Below is a transcript of the most interesting bits of the conversation. 

Read on for insights into Drupal 8 and 9!

How do you decide what to work on?

I start my day, and really spend all my time, on the Ready and Tested By the Community (RTBC) queue on Drupal.org. Typically there are always 40-100 issues waiting to be committed. I think it’s been empty just once in the past five years. Some of the issues are small and some of them are huge 200k patches. So really at 9 AM I get on the queue and work the issues, kicking some back for additional refinements and committing some to core.

At the end of the day, there might be more in the queue than when I started. It’s a bit Sisyphean.

In addition, I believe it’s crucial as a Core Maintainer to do client work because you need that perspective from using Drupal in the wild for real client uses. I think that informs our work on core better. I spend roughly half of my time doing client work for these reasons. So it does happen that something that annoys me on a client ticket I will look at improving it in core.

I’m also jointly responsible with xjm for the release schedule. This means keeping an eye on issues that we’re hoping to get done for the next minor release, as well as identifying blockers (and sometimes unblocking) for Drupal 10, which means trying to plan a year or three ahead. This could be features, critical bugs, or dependencies like Symfony.

Is working on Core really just like an issue queue for a contributed module, just bigger?

Essentially. There are always core initiatives happening, some of which have their own teams and funding, so function more like a contributed project within a project. But, at the end of the day, all of that work ends up as an issue in the queue that I work on. Every change in core needs to be worked on by at least three different people (the patch or merge request author, a reviewer, and a committer), so there is no directly committing code for core maintainers, it’s always a collaborative process whether you have commit access or not.

How do you handle strategic long term concerns, when things could go in two different philosophic directions, and conflict?

We don’t have an official guidance document or anything; we really just try to hash things out. There are long-running ones. Often with these big decisions we make a meta issue and hash it out there, and at some point, consensus starts to push it in one direction or the other.

Events versus hooks is a good example of a major issue that as yet has not been resolved. In Drupal 8 we added a Symfony events system because it was needed by core functions like routing. We then started adding events in Drupal Core that contributed modules could take advantage of. We also kept the hook system in place, in parallel.

Some people want to deprecate hooks entirely and use only events. Others, like me, prefer to modernize the hook system and drop the event system entirely. We don’t yet have a consensus on this issue, but I’m confident at one point we will. Until then we’re stuck with both, but while this might be an annoyance sometimes, it’s not really broken.

When there are important bug fixes that are also blocked on architectural changes things can become a bit more urgent, although this doesn’t always mean they’re resolved faster. Having said that, it’s rare that architectural disagreements are what holds an issue up for very long. What tends to take most of the time is ensuring that changes in one system don’t break another and that people are able to move from old APIs to new ones smoothly - more like city planning than architecture.

What are the shortcomings of turning ideas in the issue queue into Drupal functionality?

It’s better than it used to be. In Drupal 6 and 7, it was challenging because the release cycle was 3-4 years and no new features could go into Drupal 6 or 7 after their first stable release. So if new functionality didn’t make it into Drupal 7, that was often kicked back or punted to Drupal 8.

With our six-month release cycle, we now have a clear, quick process to get new functionality into the next release of Drupal or set it on a clear path for a future release, no more than a year away usually. With experimental modules, it’s also a lot easier to introduce things in stages, while keeping the overall system working

We have a lot of technical debt in core so there have been some occasions where two groups of people will work on different issues, not knowing the other issue exists, and not knowing that these two issues are actually duplicates. Work can get wasted, buried in those unknown duplicates.

There is a new initiative called Bug Smash that is trying to address this, cleaning out old issues and cleaning up the past. It’s been a great success so far to reduce technical debt in Drupal, but it’s still resolved hundreds of issues in a backlog of thousands.

Getting more people involved in core is great, but it’s required to add more structure to how issues progress. I think this speeds up throughput overall since it’s easier to see at what stage any particular issue is at, what’s left to be done, what should be tackled in a follow-up or parallel issue etc., but at the cost of additional steps for each individual issue compared to core development say ten years ago.

What are your favorite things to come out of Drupal 8 & 9?

The two major ones for me are the Entity System and the caching layer.

The Entity System changes in Drupal 8 compared to 7 have been great. It actually is a coherent system now. We added automated Entity schema updates late in Drupal 8, which introduced upgrade path bugs at the time but made the system much more powerful. It feels solid and complete now.

Cache tags and context, the new caching layers in Drupal 8, was one of the first things I worked on in core. Lots of people implement the system wrong, I notice this in client work, but when you implement it right you have a really powerful, granular caching system at your disposal that works with edge caching layers.

What is the right way to use cache tags?

When you add stuff to the cache system you have a cache ID (like an Entity ID). A unique identifier for the thing that you are caching. The context, when you are rendering, is not the identifier for the thing, but things that come from the request, like the current user, or time zone, etc. So even if you’re rendering the same content teaser, contextual links may or may not show up depending on permissions, or the author name may or may not link to their user profile depending on whether you’re allowed to access it. The combination of cache ID and cache context affects which actual cache object the render API will retrieve when building a page.

Cache tags are stored with the cache items. So a list of ten nodes might have cache tags for each node in the list, as well as the authors of each node and any media items. When a node is updated, we invalidate its cache tags, and the next time that list of nodes is rendered, the tags are checked and it’ll be a cache miss. The list of nodes has to be rerendered, the node we updated has to be rerendered, but the other nine nodes in the list will usually be retrieved from the cache because they don’t have that cache tag.

The combination of cache contexts and cache tags means you’re showing the right thing to the right people at the right time.

Where people tend to get it wrong are areas like access checks. For example, if I’m implementing an access check depending on the author of a node, someone could come along, edit the node, and change the author, and my access check is still based on the old author. These bugs can be hard to track down because by the time a developer goes to look at the information being displayed, the cache may have been invalidated for some other reason.  By using RefinableCacheableDependencyInterface :addCacheableDependency($node);, when the node is updated, the access result cache will be invalidated too via cache tags.

Another area that people get wrong, or rather often don’t know exists, is placeholdering. So if you have something that is per user, ideally you want to placeholder that and we have a Placeholder API in the render system. If you have 200,000 users on a site, you don’t want to cache your entire site header 200,000 times - you want to cache as much as possible once, and their username separately, even though it’s rendered as part of the header. You can take advantage of the placeholdering API almost for free - it just requires using a #lazy_builder callback in a render array for the content that is per-user, instead of putting everything in there directly, then the render API will figure out that this is content which needs placholdering almost by itself.

Dec 09 2020
Dec 09

How often does one quick fix to a problem stay as only one? More often than not, a domino effect takes place and the flood gates open. Suddenly, you’re stuck in a never-ending cycle of applying band-aids to a problem that has no quit. Enter strategy. Where instead of being in a constant state of panic, you’re in the most powerful position to navigate a pandemic you didn’t see coming.

Presently, companies don’t want to fall behind the rapidly-changing pace of the current landscape. They’re reactive versus proactive approach of cutting corners seems to be the option as of late — or always — but now it’s more noticeable to consumers. A stalled credit card transaction or a broken tab can lose a potential customer’s attention span to your competitor in seconds. The world is online and remote, and competition is fierce, so wanting to go from A to C while bypassing B could be the kiss of death. We can use Band-Aids and pay for quick-fix remedies all day long, but doing the due diligence now to avoid those additional fixes later will establish your site as credible. It can put you in the powerful position of increased traffic and conversions.

Ever heard the term, “ You have to spend money to make money?” This is the 2021 path mindset needed to secure your company’s reputation and legacy going forward. It’s not going to get any easier from here, it’s time to embrace the necessary steps.

If the world has gone remote, so has whatever field your business is in. Retail is one industry where companies must maintain a powerful website that functions flawlessly, but so do institutions, museums, events, conferences, grocery stores, restaurants, etc.

“Online shopping has been a boon for some retailers during the Covid-19 crisis. It has been a lifeline for others. But for nearly all companies, it’s brought a slew of new challenges.” - CNBC.

So what’s the answer to secure your spot among the greats while avoiding the Band-Aid technique?

Allot time to figure out what your site needs.
Pen and paper it out from the customer’s perspective. What is it that your site needs to provide them with a flawless experience? Is it a seamless shopping cart structure? Better navigational flow? A transformational experience? Better speed? Or is it all of the above? Write them down.

If you’re not an expert in the field, seek out those who are.
A good CEO knows their strengths and weaknesses. Hence, building a supportive team with specific and valuable skill sets makes all the difference. If you’re that CEO who thinks he/she can manage the totality of their business, then something significant is falling through the cracks, and your company may not reach its full potential.

Change up your budget.
In the past, marketing budgets were primarily driven by traditional mediums. Even then, some chose to only stick by word of mouth, and occasionally, that’s all that it took to survive. Some companies and some individuals can still skate by using the word of mouth method, but the percentage is tiny, and even then, a website for information or contact is necessary 9.5 times out of 10. So if the local dog walker needs a one-page parallax, what does that mean for your e-commerce site or your institution or your mom-and-pop grocery store that just started a delivery service? The budget has been divided and not only between marketing and digital. It’s now three buckets; marketing, digital, and site. It’s 2020 COVID, soon to be 2021 COVID. It’s survival of the fittest site.

Even e-commerce sites that are already well-oiled machines are continually looking to better their infrastructure to accommodate increased traffic flow. If you want to compete, you have to structure like you are. King Arthur Flour had no idea a pandemic would hit, but their timing was impeccable. The company went through a massive site revamp a year before, and now it’s easier to manage and can withstand an influx in online traffic. King Arthur has now solidified itself as the top baking site and has become the baking sensation of 2020—their products are flying off the shelves!

If you’re waiting for the perfect time to handle a revamp, you’ll never get it done. Dive into the process now, because 2021 is not going to make it any easier.

Your company keeping a competitive edge is a non-negotiable.

Nov 09 2020
Nov 09

So you have the excellent opportunity to build a global digital platform for a terrific brand, to activate a new brand digitally, to elevate the digital game of your organization, to build a platform that will be used for years to come. Well, with great opportunities come great opportunities to screw up.

Using our experience over the years building a variety of global platforms for clients, we have developed a rigorous process for ensuring project success on launch day and for years onward. Our process involves program execution built on seven key pillars. The pillars are a mix of process must-dos, technology must-haves, and systems that must be implemented.

Let’s take a look at our seven pillars.

Pillar #1: Editorial Extensibility

Global web platforms involve global marketing teams. And ensuring that your global platform allows for an intuitive and empowering editing experience for your marketing team is vital. But that’s table steaks.

To be effective, a global platform must strike the right balance between defining thoughtful editorial guardrails and flexibility, giving disparate marketing teams the tools they need to effortlessly self-serve.

The key to success with this pillar is understanding that a grand bargain must be struck between the developer experience -- how easy and pleasant it is for an engineer to make updates to your global platform -- and the marketer experience (how easy it is to manage the site from the CMS interface). A lack of appreciation that a bargain must be struck that there must be compromises made on both sides of the web team is a recipe for disaster.

Be sure to fully flesh out the marketing team’s expectations and needs, reflect on these teams’ realistic capacity to focus on digital, and consider your goals around developer velocity.

Pillar #2: Discovery

A leave-no-stone-unturned discovery phase is critical to success.

We shouldn't have to write this, but it is far more common than you would expect to find organizations approaching their global platform build in a reactive manner and starving the investment in time needed for proper discovery.

Discovery uncovers technical integrations, key considerations around cloud hosting strategy, global compliance needs (like GDPR, LGPD, CCPA, etc.), security requirements, functionality requirements, and downstream needs from stakeholders. Discovery is how you create accurate timelines, phases, and budgets. But most importantly, the discovery sets you up for success to deal with the surprises that will inevitably come later in the project.

That’s right; the purpose of discovery isn’t to stop problems from happening in your project. So long as humans are involved, large projects will always include large issues. The reason discovery is so vital is that it clears the board of all of the avoidable problems, freeing up the resources of your attention to deal with those significant, later problems you don’t know about today, but that will occur.

Pillar #3: Open Framework

When you sit down to build a global digital platform for a brand, there are things you know; there are things you know you don’t know, and, most terrifyingly, there are things you don’t remember that you don’t know. Those are the unknown unknowns, and they should keep any program manager up at night. Unknown unknowns. Hic Sunt Dracones indeed.

This platform is going to have a lifespan of many years, perhaps even a decade. With such a long-term time horizon, it is impossible to predict the initiatives you will have to support, the technology you have to deploy, the brand evolution you will have to empower, and the integrations you will have to achieve. You must ensure your platform is flexible enough to manage those uncertainties.

This is best achieved with open APIs and an open digital experience framework.

Pillar #4: Site Industrialization

World-spanning organizations need and have a diverse digital footprint. This means that most global platforms need an efficient way to roll out new microsites and market sites to support new business initiatives and corporate acquisitions. A thoughtful site industrialization strategy is crucial.

Organizations must consider how functionality (read: code) will be shared between the various sites, the level of effort involved to spin up a new site, the tooling in place to provide rapid deployments, rigorous change control, how to address various compliance needs in different markets, the guardrails in place for market editorial teams, and a long term support strategy to control costs.

Pillar #5: Analytics & Insights

You get what you measure. That classic wisdom is as true in digital as it was in the analog era. But data aren’t insights, and only insights help you improve metrics because insights power the strategy and inform discussions that improve the quality of decisions that marketing teams make.

A global platform must have an intelligent website analytic and tag management strategy to collect the data needed to derive insights. But more importantly, you must industrialize turning that data into actionable insights.

You must do this if you want to reap the benefits of a genuinely agile marketing strategy.

Pillar #6: Program Management

Success requires exceptional project leadership.

Global platforms involve extensive scope, integrations, competing interests, schedules full of dependencies, large teams, multiple stakeholders, and many organizations internal and external to the brand. Every project will have October surprises every damn month.

Effective on the ground project management is obvious but will only have a tactical perspective. Strategic project leadership is needed to balance the overall mission, and effective program managers bring just that.

Pillar #7:  Governance

While this appears as a thread in several pillars, it’s essential to call out separately that governance at all digital experience levels must be thoughtfully curated.

You must align the interests of a disparate organization — involving many cultures, lines of business, teams, regulatory environments, and divisions — with a strong governance foundation to achieve consistency in compliance, brand tone, content strategy, and editorial workflow.

Wrapping Up

Building a global platform may seem like a daunting task, but like so much in life, breaking down a significant effort into smaller pieces makes it far more achievable. Use these pillars to focus your attention, organize your team, and, well, to put it rather crudely, choose the right hills to die on.

Oct 22 2020
Oct 22

Third and Grove was recognized in the 2020 Acquia Engage Award program, winning an award for Leader of the Pack - Technology, for work with CloudHealth by VMware.

After VMware acquired it, the CloudHealth team needed to redesign their digital experience to align with VMware’s broader product portfolio and optimize for B2B lead generation efforts. In the first phase of the effort, we focused on redesigning the site’s blog. The blog had substantial content, but the goal was to leverage that content better to increase engagement. After the blog redesign went live, the team turned to redesign the main marketing site.

There were four challenges. The first challenge was that the existing site was on an old installation of Drupal 7 and did not take advantage of all of the tremendous editorial experience functionality available in Drupal 8 and 9. The site also lacked product extensibility. Precisely, the navigation and information architecture needed to be updated to support the growing business and product lines and support future product announcements. The final challenge was to update the UX and make it more elegant, properly reflect CloudHealth’s cutting edge technology, and help improve lead generation.

We formed a single team composed of the CloudHealth marketing team and our implementation team to design and build, from the ground up, a brand new, engaging, and elegant visitor experience. Together we implemented an agile approach, working in sprints, from ideation to execution to launch.

Check out the case study.

More About Acquia Engage 2020 Awards

More than 100 submissions were received from Acquia customers and partners. Nominations noted for functionality, integration, performance, and UX comprised the final rounds, where an outside panel of experts select winning projects.

Acquia Engage Award winners were announced at the Acquia Engage Conference, virtually, on October 21st, 2020.

Oct 22 2020
Oct 22

Third and Grove was recognized in the 2020 Acquia Engage Award program, receiving an award for Leader of the Pack - Financial Services, for work with The Carlyle Group.

The Carlyle website was overdue for a visual and functional refresh. It needed to reflect the business’s position as a leader in the investment space and showcase its new, forward-thinking digital brand positioning. Goals for the new website included a flexible content system that would allow Carlyle to control its content and put content first, as well as expand its original content strategy to show current and potential investors what makes Carlyle unique.

The Carlyle Group had a very ambitious timeline for this renovation. And as one of the top-five private equity firms globally, there was no margin for error and no pixels could be misplaced. The bar was as high as bars can be raised.

Working closely with the Carlyle team and Sub Rosa, the creative agency behind the design, the TAG project team led an aggressive schedule, keeping all three teams closely aligned throughout the ideation, implementation, testing, refinement, and seamless launch.

Check out the case study.

More About Acquia Engage 2020 Awards

More than 100 submissions were received from Acquia customers and partners. Nominations noted for functionality, integration, performance, and UX comprised the final rounds, where an outside panel of experts select winning projects.

Acquia Engage Award winners were announced at the Acquia Engage Conference, virtually, on October 21st, 2020.  

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