Taking a Bricks site live and combining with existing live site

How To
1

I’ve been developing a new site using Bricks for an existing WP site.

We have a live server (with lots of data: 40k+ posts, 150k+ comments). I’m developing a new front end for it using Bricks on a separate staging server (using an old snapshot of the data). Soon I’m going to need to merge the lovely new Bricks front end with the current, live data/posts.

Has anyone been through this? I’m wondering how to do it with the least amount of pain/lowest amount of downtime / least number of sleepless nights :slight_smile: ?

One thing that’s in my mind, where does Brick store all of its magic? How do I make sure I don’t miss anything? Do I need to think of specific tables to bring across? etc, etc

I’d be grateful for any pointers from the Bricks team and others (@thomas, @timmse, @luistinygod, etc) - It should be of use to many people as they take their developed Bricks site live.

2 Likes
2

Hi, flimflam!

Sorry for the late reply! 40k posts and 150k comments? Holy $h1t :astonished:
This is a lot, and I have to confess that I’ve never worked in those gigantic dimensions, but actually, it doesn’t matter if there are 40 or 40k posts :smiley:

Once you have your staging page ready and everything is working smoothly, all you have to do is switch, so the downtime should be limited. I usually put new pages in their own folder and use a subdomain for the time being.

When the new site is ready, I update the database and replace the subdomain with the final domain, which I then direct to the new folder, and that’s it usually - almost 0 downtimes. Well, of course, you have to recheck everything, but usually, it works out pretty well.

It is essential to make regular backups (especially of the database). Then, if something should go wrong during crucial steps, you can jump back and try again.

Regarding the Bricks magic: actually, you don’t need to pay attention to anything as long as your posts are already Gutenberg posts anyway it should all work smoothly. Of course, it gets more complicated if there are a lot of custom fields and co in the game - but even that shouldn’t be a problem.

Depending on how “clean” your database is, you might want to clean it up with a plugin like WP-Optimize or WP-Sweep.

What I would recommend is something like EWWW Image Optimizer (or another similar plugin) to compress your images and deliver them as webP. With 40k posts, there is undoubtedly a lot together.

Also crucial about images: the image sizes. Choose your image sizes wisely and with care. I usually regenerate my images with the plugin Force Regenerate Thumbnails, which has the great advantage of deleting the old and no longer used image sizes. To be on the safe side, make better before also a database + uploads backup.

I have recently converted an architect’s website to Bricks and noticed that relatively many images were duplicated and triplicated in the media library (because they were uploaded multiple times - for whatever reason). Looking for a plugin that removes these “superfluous” images I came across Media Cleaner, which did an excellent job (Pro version).

Last but not least, I repeat the most crucial point: backups, backups, backups, before and after every critical step. Regular backups will save you sleepless nights :smiley:

Have a nice weekend,
timmse

1 Like
3

Many thanks for taking the time to write up all that detail @timmse - it’s really appreciated.

Those are a great series of tips that go beyond where I was thinking (eg the ones about removing the old thumbnail images - what a great win - I’ve GBs of them I’m sure). Really helpful.

Just so I understand:

When you say, “When the new site is ready, I update the database” - This is taking a copy of the live database and restoring it to the staging/development server?

4

Hi flimflam,

You are welcome. I can’t tell you what the process is with your staging environment, but I’m sure your hoster has documentation for it.

My process is as follows:

I usually create my sites in a local installation, whether it’s an entirely new site or an existing site. For this, I typically use https://localwp.com (alternative: https://kinsta.com/devkinsta).

If it’s an already existing site, I export the posts, custom posts, pages, etc., either directly or using https://www.wpallimport.com if it’s a bit more complex (custom fields, etc.).

Then I prepare my local installation, create or import the Custom Field groups, etc. and import everything one by one using WPAllImport. This way, I make sure the new site is as “clean” as possible. In between, of course, I make backups before each critical step.

When the site is ready, I upload the entire local installation to the server (into a new, empty folder). After that, I update the wp-config and the database (swap the local URL for the actual URL - you can theoretically already do this step locally with a plugin, but I prefer to keep the local one as a test site ). And the last step is to change the domain to the new folder. That’s it in general.

As I said, how that works for you with your staging environment: I have no idea :smiley:
The local environment’s significant advantage is that many things are much faster, be it installing plugins, creating and importing backups (which also works directly from LocalWP).

Greetings,
timmse

5

Another powerhouse post of top tips - Thanks @timmse

I love your idea of importing all the data. Until now I’d been thinking of using WP Migrate DB Pro, but I can see your approach is much better - as you say, you end up with a much clearer install, not just bring over all the old junk from the previous install (Which, as we know, does occur if you install/uninstall plugins that create their own tables).

A question - When you reach the ‘When the site is ready’ stage - Am I right in thinking you export the whole database from your local install to the live server (putting it in its own unique table name) - ready for the switch over? (I think that’s what I’m reading, but just wanted to check)

6

Correct, I export my local database and then import it into a new, empty database on the live server. Then I adjust the wp-config with the latest database login credentials and replace the local URLs ( e.g., https://bricks.local » https://bricks.com).

I usually do this with this script. Alternatively, you can do this already in the local WordPress installation with a plugin like Better Search Replace.

Best regards,
timmse

1 Like
7

Thanks for clarifying @timmse

I’m a big lover of BSR - paid for all the way baby!

1 Like
8

Just had a thought - Does Bricks stores any setting/config in wp_posts @timmse ?

9

Hi flimflam,

afaik all bricks data is stored in wp_options or wp_postmeta.

Best regards,
timmse

1 Like
10

I’ve found some entries in wp_options (below) - Is that all in that table? If not, how can I ID them?

Re wp_postmeta - I can’t ID any in there yet (I’ve got 750k+ (!) entries in that table). Possible to get help finding them ?

It’d be great if the devs could chip in on this to give the definitive answer on where Bricks data in stores in tables too please

11

Yes folks I’ve now found out that’s where the majority of the Brick data is stored. If you want to find yours you’re going to need to look into wp_postmeta table.

I ran the following SQL to find mine

SELECT * FROM wp_postmeta WHERE meta_key LIKE "\_bricks%" ORDER BY post_id ASC

(A quick translation - show me all the rows where the meta_key field starts with _bricks)

I had 790 entries in there.

Hope it helps someone else

1 Like
12

I’ve been spending ages digging into the database tables and thinking further on this. All of the tips I’ve been given before are great @timmse - I now realise what’s missing is the details of how to merge the current live data with the Bricks templates and page designs.

I’m going to try to quickly reframe this:

  • ServerA has all of the data (as described in posts above)
  • ServerB has an old copy of the data (so I had something to design the new look site from), but importantly, the new Bricks design and layout.
  • I want the data from ServerA running with the new Bricks design I’ve developed on ServerB. The question is how?

We now know Bricks stores its page designs in multiple rows in wp_postmeta (see above) and some setup in wp_options.

If I migrate the data from ServerA to ServerB, the Bricks design of templates and pages (on ServerB, stored in wp_postmeta and wp_options) will be wiped out by the wp_postmeta and wp_options tables coming over from ServerA, won’t they?

The Bricks rows will be wiped out even if I export/import won’t it?

So the question I’d love the answer to @timmse is - How do I migrate the data from ServerA to ServerB, to have the latest data AND keep the Bricks designs?

Should I export the Bricks-related records in wp_postmeta and wp_options on ServerB before bringing in the ServerA data over, the re-import the Bricks-related records in wp_postmeta and wp_options?

Oh my , this is sending me around the bend! :sweat_smile:

13

Hi flimflam,

This is a tough challenge, which is difficult to answer.

It could be problematic if the IDs of the pages and posts are identical when you move them from A to B. Accordingly, the posts and pages with identical IDs would be overwritten.

I would probably try it (maybe not directly with all data, but with selected pages) and see what happens.

The proof of the pudding is in the eating :smiley:

14

Hi @timmse - I’m back on this project again.

It’s now at a crunch time - this has to be delivered.

It hasn’t been solvable by the collective brains here - and I haven’t been able to subsequently find a way - to move an existing WP-templated site to Bricks without the serious risk of losing data, or taking it offline .

As they say, “We are where we are.” This site must be delivered.

In desperation, the only way I can think of getting this new Bricks site delivered is by taking the site offline and importing the Bricks templates that have been pre-developed on the Staging server. What do you think @timmse?

15

You can also take another approach. Clone the existing site to a staging site on the same server. Upload your bricks changes to this staging site. Verify everything is working. Update URLs via Better Search Replace to Live Site URL. Remap the folder for the live site from old folder to this staging site folder (you can do that depending on the control panel or may be just move all the files from staging to old site folder)

1 Like
16

Thanks for the pitch @omega.

One of the issues is that the Live site is quite active, with comments and posts being added regularly, so the staging server would get out of date quite quickly.

Part of this would also be the concerns of Bricks writing to the Staging copy of wp_postmeta and the Live site having new data added to its copy of wp_postmeta - both using the same postIDs, so remerging would not possible.

17

In that case a scheduled downtime will be required.

18

Sad isn’t it.

It does seem amazing that this hasn’t been tackled.

It means only totally new sites can be created with Bricks (Elementor has the same issue).

Same problem with developing updates on Staging servers of current Bricks sites - you can only do it on the live server - as you know, best not done.

It’s really limiting the potential use of the product to fresh creations - so short term.

With Big-Brains like @luistinygod and @thomas behind Bricks, I’d have thought (hoped) they’d have come up with a solution.

1 Like
19

If you have a woocommerce with products and stock and you want to implement a custom field?

Wpvivid has an option to work in staging with the same bbdd, but I don’t know how it would behave to changes to an existing page / post or changes in the woocommerce product structure.

20

Could you use a plugin like Theme Switcha to install and apply all of the Bricks templates for admin users only, then switch themes when you’re ready?

1 Like