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.
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’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?
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.
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?
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)
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.
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.
I had recently moved a Bricks to site from a staging domain to production, and ran into an issue where all background images weren’t loading at all in the various containers (but all other content seemed fine). I use a platform called Cloudron so my usual routine was a simple domain name change for the app which updates the URLs along with it, but I usually still need to go and use Better Find & Replace plugin to update the other URLs.
In my case, for some reason Better Find & Replace wasn’t finding them all this time (first time I’ve had that issue), and I had to go in and manually edit the database to update the URLs in all places. The WP CLI actually has a good find & replace functionality I wasn’t aware of before, so just used that I believe.
Once I did that, it was all good again. I could tell it was a URL thing because the background images were somehow still pointing to the old staging domain even while the site resided on the prod URL.
Not sure if that’s related in your case but figured I’d share my most recent experience.
It was all very exciting when I found that Theme Switcha was broadly worked as promised - Ticking the ’ Apply switched theme to Admin Area’ option makes the Bricks menu appear, so you can import templates, etc.
Finally I thought, a fix for this months of trouble I had trying to get site I’ve developed on the Dev server in Bricks to work!
The major issue is that when I click ‘Edit with Bricks’ on the templates, Bricks doesn’t load, but instead the message “Invalid post type” is shown, so I’m not able to make any edits, or change conditions for showing templates.
Sadly back to the drawing board.
I really want Bricks to work, but f*** me, this really isn’t making it easy.
Separate Dev version
Going from the Dev server and trying to apply the Dev templates has exposed quite a few more issues. For example, the Bricks header template calls the menus defines on the server, but even if you have menus with the same name, they don’t appear as they have a different internal (Wordpress) reference number on each server.
I dont think you will find this ability in any page builder to be fair.
I think you need something more along the lines of versioning. Just had a quick google and this came up, but defo worth investigating this train of thought.