Part 4 – What about plugins and themes?
In this series so far we have explored why we decided to migrate Coconut Tickets from WordPress to Laravel, the strategy we decided on and the areas of technical migration. Unfortunately those steps were not enough to migrate the whole of the event ticketing platform to Laravel. This post rounds up the remaining subjects and explains what we did about them.
Two subjects not yet covered are two of the main reasons why WordPress has been such a success: third party themes and plugins. Replacements needed to be found for the following:
- WFX WordPress theme
- Yoast SEO plugin
- MailGun plugin
- WordFence plugin
- MailChimp plugin
- WP Bakery page builder
- Ticketing API using the SLIM framework
The WFX theme was used very lightly by Coconut Tickets. It did not rely on any specific WFX functionality that could not be found in another WordPress theme. Also, many of the WordPress pages had been developed as custom pages in WordPress with their own partial templates for headers and footers. These existing pages, headers and footers were migrated to Laravel blades without much difficulty. A hierarchy of blades was put together so that most pages only needed to fill in the content section, and they would inherit the header, footer and any sidebar.
Yoast SEO is excellent on WordPress. With very little effort each public page had its own meta data for SEO and an XML sitemap was built by it automatically. We didn’t find an equivalent for Laravel and so committed to manually adding meta data to the page blades. The sitemap is more tricky because we want to exclude pages behind the subscription wall which includes some dynamic URLs, we don’t have an automated solution for that yet.
The MailGun plugin simply isn’t needed because MailGun support is included in Laravel as standard. This was good news because MailGun has become essential to us in making sure transactional ticket emails really get delivered.
WordFence has helped us fend off many hacking attempts on our WordPress site. Laravel has good security as standard and in 5.7 it also automatically throttles down failed login attempts. So no replacement of WordFence was deemed necessary but it did make us extra cautious about possible PHP/SQL injection attacks.
We did have some public pages that were built with WP Bakery page builder. These pages were built by outside contractors, and they worked well for more than 2 years. To migrate these pages we copied the HTML structure from the rendered page and then wrote our own CSS to get the new pages formatted correctly. The page builder’s automatically generated CSS was as messy as spaghetti and would have cost us a few more days to understand, so it was better to start again while trying to match the look of the old pages.
Our event tickets can be scanned by an Android application that talks to WordPress through the REST API. Originally this used the official WordPress REST API but it was so slow and memory hungry that we had long ago switched to using the SLIM framework for our scanning app connectivity. I’m sure that Laravel could be efficient enough to replace our use of SLIM but we couldn’t use Laravel because it doesn’t support the exact same URL syntax for REST routes as WordPress and SLIM (when you have multiple parameters with “=” signs in the URL). So the simplest solution was to continue to use the SLIM framework with the revised Coconut Tickets database on Laravel. Of course long term we would want to remove the complexity of having two frameworks but that would require changing the API of the Android application too.
In the last part of this series we will bring all this together and consider the migration itself and what happened.
Find out more about Coconut Tickets