Case Study: WP Development on a Live Website and Existing Site Builder

The Current Situation

The client is running on a live WordPress website built with a site builder — in this case using the WP Bakery Visual Composer site builder plugin — alongside multiple webpages.

The site builder contains the following blocks:

• Text blocks
• Media gallery
• WP custom navigation menu
• Imagery

As the website is also live, with new site builder content being updated daily, and new images added to the media library as well, it is paramount to use the plugin WP Migrate DB Pro to aid in this, as the tables mentioned later below are regularly modified.

The Ideal Outcome

With the current situation put in place, the following ideal outcomes are required upon the website launch:

• Retain the SEO and base link structure and internal linking across the new website
• Allow the client to easily customise the new theme layout, to add text and edit the imagery
• Allow the client to easily add new image galleries
• Allow the client to easily add new testimonials using a custom post type

Implementation

The following have been implemented to make sure that the ideal outcomes are reached:

During New Website Development

• Daily routine of pulling the latest tables, namely:

  • posts
  • postmeta
  • term_relationships
  • term_taxonomy
  • termmeta
  • terms
  • usermeta
  • users
  • options

• Take the approach of avoiding modifying these tables during website development. If need be then modify (add, edit, delete) these tables on the live website making sure that content is not visible unless needed.

• Use page-*.php to re-build templates of new layout agnostic of site builder plugin, whilst being able to pull latest post data using the plugin WP Migrate DB Pro.

• Create theme shortcodes to aid in layout structure

• Create a staging website for 2 reasons:

  • Client to view staging website for amendments
  • As a live backup for your team to view the new website for the launch period

Pre-Launch Routine

• After theme development, re-enable the_content() to prepare application of the site builder content, and move all theme shortcodes into the site builder during launch period
• Set up a maintenance mode that will display the client’s main call-to-actions (CTAs)

Launch Routine

• Inform the client of the time period of the launch routine
• Enable maintenance mode, making sure there is a 503 response with a Retry-After header (please see this Yoast article here for more info)
• Modify all pages’ site builder layouts to match that of the new website
• Plug in new posts, e.g. the custom post type Testimonials for the testimonial section.
• Test all contact forms, and their conversion tracking codes

Recommendations

The set up was built under a tight time constraint, therefore a more well-defined setup could not be applied, of adding Advanced Custom Fields’ (ACF) Local JSON syncing, custom post type exporting onto the live website (and hiding the post type temporarily), and test-driven development TDD set up across the webpages.

It is best to always keep in good communication with the client and let them understand how the syncing of content impacts the development time. This is mainly due to the site builder data within the database tables posts and postmeta. However, if the content is to be managed through Gutenberg then this will no longer be a challenging point.

As usual during a live website’s new website development, it is not necessary to update plugins as this will have an impact on the development time. It is better to leave them not updated unless they have been updated on the live website.

It is good to understand if the live website’s plugins store their data in the posts and postmeta database, so that database syncing is kept organised.