The Joys and Trials of Website Adoptions

Author:
Art Williams
Art WilliamsPrincipal / Chief Information Officer
The Joys and Trials of Website Adoptions

It’s not uncommon for the maintenance of a website to change from one agency or freelancer to another. At Texas Creative, we affectionately refer to these as “adopted” websites. And while we have no intention of pushing this analogy too far, adopting the work of someone else into your family is both a treasure and a challenge.

Whether you are the agency tasked with maintaining a website you did not develop, or the client/owner of a site asking someone new to help you with maintenance, we will highlight some of the considerations and challenges of this endeavor, specifically with regard to Drupal, Wordpress and ExpressionEngine content management systems. As a San Antonio web design company, we have experience maintaining all three of these CMSs. 

General Considerations

The stark reality of web design and web development is that the continuum of skill levels and approaches to the job are so varying that you can never assume anything about the site. We’ve found sites in such a wide variety of states that our first step is to gain access to the backend of the CMS and the file system to evaluate the site. In some situations, the evaluation has to wait until after migration, but it is preferred that it occurs first.

Depending on the results of this evaluation, an adopted site might need weeks of work to bring it up to standards before any new features can be implemented, or it could be ready to go. More likely, it’s somewhere between these two extremes.  One part of the evaluation that you should never forget to perform, is the security scan.  It is more common than you'd think finding a site that's been hacked and the owner and previous maintainer doesn't even know.

In our experience, the specific content management system chosen to build the site comes with its own special hurdles that should be considered.

Adopting Drupal

When the adopted site is Drupal, you can be fairly confident that the original developer had a reasonable level of technical expertise. The difficulties usually arise from the varying approaches that developers take with Drupal. Some developers rely heavily on layout systems like Panels or Display Suite, while others prefer custom coded templates. In recent years it’s more common to see the Paragraphs module used extensively. All of these systems add their own complexity. The challenge of maintaining a site built in a system differing from the new agencies preferences can be great. The more Drupal-specific experience that the agency has, the more likely that they are familiar with all or a majority of these approaches. As the agency, you will have to determine how much (if any) of the systems should be refactored in the site. Our opinion is that refactoring should only occur if the existing approach is holding back the ability for the client’s needs to be met. Otherwise, learn the new/different system and maintain the consistency of the project.

Adopting Wordpress

Wordpress has a different issue altogether. It is the most commonly found open-source CMS and does not require much technical expertise to install and get running. So, while you can find sites that are engineered as well as any Drupal site, it is more common to find sites that were built by simply installing lots of plugins without an understanding of how they affect each other.

Only the most basic Wordpress blog or brochure site, built on a commercial (not custom) template can get away with not needing ANY kind of custom code. So, an inexperienced developer who needs to build something that doesn’t come out-of-the-box will have to install a plugin. This in itself isn’t wrong, but it is an opportunity for things to go very wrong in the build. Coupled with the fractured plugin marketplace it’s common to see plugins that are overreaching.  

We recently migrated a Wordpress site that looked great on the surface but was using a plugin that completely took over the built-in page editor and replaced it with something that was 10 times more complex, under the promise of being more flexible. We found it too complex for the client to use and too heavy-handed for our liking. However, it was so comprehensive in how it took over the site that disabling it would have broken the site. We developed workarounds to improve the maintainability until we had the opportunity to replace the functionality. It’s clear in this case that the previous agency used this plugin so that they didn’t have to write any code themselves.

Adopting ExpressionEngine

Due to the license fee charged by EllisLab, the creators of ExpressionEngine, we’ve found it to be the most unique experience of the 3 CMSs. Additionally, some of the best 3rd-party add-on modules also have license fees. We’ve also found that previous developers were less likely to update older versions of the software. In many of these cases, the version of EE that we find is months/years beyond the End-Of-Life (EOL) and therefore is no longer receiving security updates. We assume that it’s because of the license fee. Another reason may be that EE can require quite a bit of custom code to be written for advanced functionality. If an agency has invested in those custom modules for a specific version, they may be hesitant to re-invest in porting that code to the new version until absolutely necessary. EE is not upgradable across major versions, either, so the site has to be rebuilt in order to bring it current.

To be transparent, we at Texas Creative do not build any new sites in ExpressionEngine, but we have experience with maintaining ExpressionEngine CMS, which is built on the PHP programing language just like Drupal and Wordpress. 

We will “adopt” EE sites when the client is intending to rebuild/redesign and just needs us to maintain it while the new site is in development.

Conclusion

As you can see, the challenges and concerns of an adopted site are many. It’s important that both parties enter the arrangement with open eyes. Without a thorough evaluation as early as possible, the results of the migration and maintenance can vary wildly from what might be expected. And even in the best situation, there will always be hiccups with these sites. We always try to give them our best, and it helps our success rate that we have a team of very experienced developers.