While it hasn’t launched yet, I am on the home stretch of a project with numerous technical challenges and a combination of requirements making it a significant endeavor. To what do I speak? Converting an outdated Drupal to WordPress website — maintaining not only all content in three languages but also the visual site design as close as possible.
While I cannot share client name or website URL for confidentiality reasons at this time, the reasons for pursuing a parallel conversion are solidly based economically and in improving overall performance. This client also has numerous WordPress websites with this solitary Drupal 7 site being the outlier. This migration will centralize technical investments for greater content management ease. The client also abhors the Drupal admin which is far less friendly than WordPress. I firmly believe they regret venturing into the Drupal platform as it was wholly inappropriate for their needs.
There is also a small WordPress blog integrated into the Drupal site and menu system. However, it was not set up correctly by the other developer, and despite their experience with WordPress content management, it has been difficult to create properly performing and formatted posts. It was as if there was a basic lack of understanding about category taxonomy. Adding to the problems, this blog was built with a defunct custom theme (and not even a child theme) that cannot be updated.
The existing website is built in Drupal 7 although Drupal 8 was released at the time of construction. Unfortunately, Drupal 7 sites must remain on PHP 5.6 and upgrading to PHP 7 is incompatible with the platform (but it would have been fine for Drupal 8). As there is resistance to changing hosting, the Drupal 7 site on a GoDaddy shared account prevents other co-hosted WordPress sites from upgrading to PHP 7+. This inhibits site speed and security on those sites in a hosting environment that doesn’t allow multiple PHP versions in a single account.
Further, unlike WordPress, upgrading Drupal to a new version is not a simple task. Moving this site to Drupal 8 was quoted at a very high cost by the developer who has been “maintaining” this site for the past 18 months. They were not the original developers. The client has never been happy with the site performance or various inconsistencies. However, they liked the visual design created by the original web designer, and for this specific site, maintaining the consistency for brand and marketing purposes is quite critical. Therefore, I had a mandate to keep the visual design as similar as possible in a WordPress conversion.
There is no functionally in the existing Drupal site that cannot be replicated in WordPress,
Necessary requirements for the new WordPress site.
Drupal is quite a beast as CMS platforms go. Fortunately, with a set of premium plugin tools, I have managed to conquer the beast and pull in most of the content to a new WordPress development site on the same server. These are the tools I have used:
Because I needed to import authors, taxonomy and a lot more, I bought the premium version of the above plugin along with a lot of its add-ons to include Location and Internationalization.
The site uses WPML and a ton of its modules to include those for Gravity Forms and MailChimp. I also installed WP All Import, WPML All Import, and the entire suite of Toolset plugins.
I handled the small, separate WordPress blog in typical fashion by exporting and importing.
It is essential to start the Drupal conversion with a clean WordPress install, but a database that has no pre-existing content when running the FG Drupal to WordPress system. Because of how modular Drupal is in its construct, much of the material appeared in broken bits and pieces, but it didn’t take too much to get things consolidated since I had the live Drupal site and WordPress blog for reference.
Charged with replicating the visual design, I learned that many graphic elements did not convert over. Fortunately, since the WordPress development site is living on the same host as the Drupal site, I was able to dig around in folders and gain access to a lot of the theme resources as well as some of the very customized CSS elements. For example, the Drupal site used a different arrow element for the slider system used, and I managed to set a customized style in Revolution Slider so navigation design would remain the same.
Once I managed to get the English, default version of the site to actually visually resemble its Drupal model, it was surprisingly quite a smooth process to incorporate the translations to two other foreign languages. In fact, with WPML, the behavior and language management is much improved over that presently in place on the Drupal site. There were several missing translations on the Drupal site that are now just awaiting some verification for accuracy.
As far as theme, I elected to use the UDesign theme by Andon (ThemeForest). The client has this theme on a few other WordPress websites, and I its one of my favorites as it is versatile—providing a flexible, responsive platform. Because I know it so well, I can replicate a visual design provided to me by a graphic designer or a project such as this. I can create nearly any type of visual design that is distinctive and not cookie cutter when combined with CSS. Of course, I am using a child theme and while the site is not quite finished because we’re integrating some additional features (Gravity Forms inputs will automatically populate their CRM via Zapier) and a new Chat module, the heavy lifting is complete.
Once the Drupal to WordPress project completes and the site launches, the Drupal site and existing WordPress blog will be archived. The hosting account PHP version will be upgraded to 7.1 for the icing on the cake.
I look forward to sharing the project results with you soon to include some before | after images.