Rebuild vs Upgrade - need pointers, advice

Question

I know that I don't know what I don't know about Wordpress. :-)

I've been deploying large Joomla websites for over 10 years. My team has done simple Wordpress sites but nothing super customized.

I need some general pointers/direction in dealing with a Wordpress website rebuild.

Details: A good tourism client of ours has two largeish, popular, and customized Wordpress sites that need to be upgraded or rebuilt. It's first iteration using WP was in 2011. The developer built it using the WPEngine solution. Then in 2015 a different developer company did a reskin, which kept the original code. We took over the hosting, support and maintenance in 2016 which included decoupling it from WPEngine.

All in all, the current website performs well. 80% of the delivered content gets cached via Cloudflare which is really important considering it’s the busiest site on my server during the summer. However, the current sites do not support PHP7 even though the WP codebase and plugins are up-to-date.

I have over the past year, convinced the client that we need to rebuild their WP websites to include fresh code, look, and promotional strategy. The other significant new features I am proposing is using Multisites and Responsive design. Content assets such as images, will have to be redone to accommodate a new “big image” design.

Existing template concerns: 1. Not responsive. 2. Remnants of the WPEngine can be found in the file system. 3. Key layout elements are hardcoded such as copyright and contact info in the footer where the client can’t change. 4. I don’t fully know and understand the strategy the developer used for the first version which still rules these websites. 5. I’m unsure of which installed plugins are actually being used and which plugins are legacy and should be uninstalled.

The existing template has 11 cpts. There are 16 ACF custom field groups with 36 total custom fields.

Questions:

Given my description... Do you think a “from the ground up” rebuild is needed? By that I mean, new everything and migrate over the content. OR do you think it would be better to clone the site and develop a new template?

How would Multisites play into this rebuild or upgrade?

Thanks for any advice or insight.

Answer 1

having done a few rebuilds myself I have seen my share of horror situations because some devs make a mess of it :) It's hard to advise you what the best way is without examining the code/setup/problems and without knowing what budget is available.

1. Can be fixed in the template if you have someone who knows what they're doing.
2. What remnants ? Just files or also database things ?
3. Stuff like this can be made dynamic inside an existing template.
4. Then better find out or redo it 'properly' and the way you understand it.
5. Any bit of decent developer should be able to assess this on a local environment with a bit of debugging.

I'm a fan of rebuilds because you can do everything they way you want to have it and don't have to worry about legacy code and so, but I think you would need to get someone to assess the code to give you a well founded answer.

Answer 2

My past experience with WP sites: when it's a large install (10+ plugins, over 500 posts/pages/CPTs), if you check the theme and plugins and find they're tightly coupled (as you mention with WPE code) it's generally worth rebuilding from the ground up. As you said it's hard to tell which plugins are actually being used.

You could either copy everything onto a staging site, deactivate plugins, and run a variety of test cases across the site until you can ascertain what's actually in use, then "clean up" what's already there... or truly rebuild. Normally, I would recommend rebuilding hands down, since technology has changed a lot in 7 years and so have coding best practices. But your timing is interesting, in that WordPress 5.0 is scheduled to come out sometime this year, and with it comes a completely new editor called Gutenberg. Because it will be a major change, I think you'd be better off with another approach I've taken on this kind of thing: rebuild, but rebuild it the way it already is, with a plan to rebuild again within a year after you've learned more about the ins and outs of the site's functionality.

First, test the site and find out its capabilities and map out use cases. Also carefully, painstakingly map out all of the URLs, because you want to avoid changing those if at all possible at this stage. Then start with a brand-new-from-scratch WP install and slowly work your way up to the use cases. Start with the theme - either find a free theme on .org that is somewhat visually similar to what they have already, and go the child theme route; or custom code a new theme. Since your WP theming skills sound minimal, I would suggest the child theme route as it will teach you a lot about how themes work. Then you can create the CPTs (or not, if there isn't a real reason for them to be CPTs). Granular permissions are often the reason related things get shoved into CPTs, but if permissions aren't a reason, you may be able to just use Pages for a bunch of the CPTs.

Once you've rebuilt the site to look visually similar to the old version, it's time to work on plugins. You may be able to ditch ACF depending on theme and functionality requirements - that's a very case-by-case basis. Stick to Core functionality wherever possible, and try out a few plugins to see which mix works best together and still gives all the functionality that was there before.

It will probably take you a couple of months to really go through and map all this out, then rebuild it. By the time you have it all ready to go, you can have the client/stakeholders test and make sure you didn't miss anything, and go live with that version. From there, follow up to see how Gutenberg is progressing and use the knowledge of themes and plugins you've gained to rebuild the site one more time.

As far as MultiSite, it's really meant for groups of highly related websites. Unless there's some major reason these should go together, it's usually best to keep separate sites... separate. That way if, for example, one site gets hacked, you don't have to restore the entire MultiSite and have both sites go down at once while you plug the security holes. Also, unless you get into a very fancy hosting setup, MultiSite will store both sites' date in a single database, which can lead to performance bottlenecks. It's usually faster to run two separate databases - even if they're on the same server - than to merge everything into a MultiSite.