We need to recreate our site from scratch. When I mean from scratch I mean we want to keep the same content (pages, articles, URLs and tons of media) and move it to a new WordPress installation with a different theme.
A brief background to try to understand what the underlying problem is. The current site (the one to be copied and transferred) is HUGE. It has more than 1500 pages and 3000 articles. It is currently running on an old version of WordPress and an outdated theme. We are deliberately not updating WordPress, theme and PHP so as not to risk crashing and being left without a site (this has already happened in the past with another installation).
What we have done is to create (on the same hosting) a new, updated installation of WordPress (on another directory). This will be the new and definitive one. Then – when all is said and done – we should use the name of the first installation (but this will be another issue to deal with at the end). We decided to operate in this way because we want everything to be done as safely as possible.
Some details:
Objective: SITE 1 -> SITE 2
SITE 1: Installation: domain.org/directory1 WordPress 5.2 PHP 7.1.33
Theme: Awaken
SITE 2: Installation: domain.org/directory2 WordPress 5.7.1 PHP
7.1.33 Theme: Divi Builder
At the moment, we have already installed the new theme in directory2 and created the home page that will host all the pages and articles from the old site. We are not interested in keeping the plugins. Our aim is for the new installation to be as “clean” as possible, without the risk of dragging around old problems.
What do you think is the correct way to proceed? Again, the most important thing is that the links are not changed (so that the URLs will still work once the change has been made; I mean: domain.org/directory1/perma/link/article-written-in-the past = domain.org/directory2/perma/link/article-written-in-the past
Could the export/import tool do this job? How should I proceed to make sure that I don’t affect the performance of the new site? Is it possible to carry out a test with a few pages to see if this can be done?
Thank you all!
The first step is to create a backup of the existing site. You can do this manually, you need all of the site files plus the database.
However, Duplicator is a great plugin that will create a backup package that includes everything for you. One thing to be aware of is the size of your site may cause issues for the plugin do to server load, but its the easiest method. There are other plugins as well to help with migration.
Once you have everything you can copy it to a new domaon like dev.website.com. The installer from Duplicator will help with the url updates, but its pretty easy to adjust in the config file and database options table. If you use relative urls most things wont be an issue, but a simple find and replace in the database will easy update any absolute urls.
Once you have made all your changes in dev you just reverse the process by writing over the live site and your set. This is safe beacuse you have a backup of the live site from step one in case you need to revert to the current state.
I have extensive modifications to carry out on a prestashop 1.6 site.
I have created a local copy, and am tracking filesystem changes in git.
However a lot of changes in prestashop are stored in the database, specifically in my case:
Installing and configuring a new module
Uninstalling a module
Adding shop categories and changing the hierarchy
Changing module positions
and generally modifying what modules appear in what hooks.
During the dev process, the live site has received numerous new orders, customers, subscribers etc, so the databases are out of sync.
I have solved similar problems in other frameworks by dumping and importing specific tables in the db, or using the frameworks built in migrations functionality, but i cannot find any advise specifically for prestashop.
How is this handled?
Considering that the dev site has probably undergone more diverse changes than the live one, i wonder if it would be easier to copy the new orders etc over to the dev site then overwrite the whole thing?
I don't think that it is possible to achieve this in PrestaShop. You must have immense knowledge of PrestaShop DB (i.e. have knowledge of each and every table and columns in it) to merge the databases.
It is never recommended to do that either.
I suggest you do the syncing manually as it is a very risky task and you might lose all the data in your live store, which will be even more painful.
For modules the information is stored in all tables which start with modules.
Module config values are stored in configuration and configuration_lang. Make sure you also copy custom module tables of course.
Shop categories information is in all tables which start with category.
Module hooks information is in all tables which start with hook.
However as Raghubendra Singh said in his answer this is very risky task, if you really really want to do it, I suggest you create another local copy of currently live site and first try the process between two local copies and make sure everything works correctly.
I can tell you my experience on updating the Prestashop and using it everyday.
For the everyday work (fix bug or add feature) I do the changes in DB directly in phpmyadmin. I test everything in a mirror isntallation, copy the changes to the prod site and apply the mysql changes.
We only lauched 2-3 new major versions of the site (once every 2 years, more or less) and wait for a stable version of Prestashop, even 1.7 now has a few major bugs (Translations was one of them, not sure it's 100% fixed in 1.7.1).
The last one, that went quite well, we altered the theme to our needs, applied a bunch of new features for our customers, etc... When was time to launch I just analysed the difference in the relevant tables, and copied the data from the old db to the new one, with the added fields and changed defaults, etc... using ssh access as they were both on the same server.
Btw, the old tables we need were related to address, carrier, cart, category, customer, delivery, feature, group, image (but not image_type), manufacturer, orders, product, range, specific_price, stock_available, supplier, tax, tax_rule, wishlist, zone, country, state, employee, profile, and others used by our modules. Others like modules, configuration, hooks, etc, didn't matter because it was a complete new theme.
I always thought on doing something that could synchronize the db of the dev version and live one. But still haven't done due to the fact that we don't do that many major changes, and the minor ones, we try to keep the changes in a file until we apply it (not the most professional, I know). And sometimes, on these major version changes there could be new ways of Prestashop doing things. THe last i remember was the access slug in the 1.6.something, that was not in the 1.5, and after everything done, I could login to back office, but other workers couldn't, because it had changed how access was controlled, and since I was superadmin, I was not affected by it. Another thing in the of not doing it right now, it that Prestashop is starting to use Symfony, and I think will try to use it even more in the future, impacting how things are going to be done in the future. So a solution now could not work in the future.
We could also use the upgrade features in modules. Never tried it, but it could be used to apply upgrades to the DB and others automatically. Looks promising, but don't know if it works with a push or if only on module upgrade. One of these days i'm going to test this.
This is not a response with a solution, but I'm interested in one, and in working on one if there isn't any. It would be interesting to do a push, and not having to change things in db "by hand".
I have recently discovered the multisite functionality of the wordpress core. really exciting! After digging around some more, I noticed that the database simply replicates 9 tables each time we create a new subdomain; but keeps them all in the same database.
The project I am in the planning stages for has a high amount of data information to be stored. The information that would be stored would be proprietary for each company that uses the site.
My question is this. How would I go about getting the entire database to replicate vs getting just a few tables to replicate? Basically, I am looking to create exact copies of the site over and over and over, but each site would have its own database. eventually, each copy of the site would be created once a customer has paid to use the service.
I have seen shardb and hyperdb, but they actually just add databases to store tables from multiple subdomains (at least thats how i interpretted it) to increase site speed.
Im not concerned about site speed as much as I am security and redundency.
Any ideas?
One of the features of MultiSite is that all the WP instances use a single WP installation, and a single database, just with different tables.
In answer to your question, a plugin you could use for this is Multi DB https://premium.wpmudev.org/project/multi-db/. Although this plugin is no longer officially supported by them anymore, it's still compatible with WP 4.5.3 according to the site.
As for redundancy, you could run 2 linux VM's for hosting the databases, one a primary, one a failover
If you've heard of EduBlogs (Like Wordpress.com, but for education), they host about 3 million blogs using Multisite. The guys behind it are WPMUDev (Linked to above) but here they have a thorough article for Multisite for a large number of sites and the potential Database issues you may encounter: https://premium.wpmudev.org/blog/ultimate-guide-multisite/
I am moving 11 sites that are currently in a Multisite configuration in an internal network, and would like to migrate them to WP Engine as single individual sites.
I would like to use phpmyadmin to export the data site by site. I am using HeidiSQL to connect to the database and exporting as sql. I will need to manipulate the data, turning it from a multisite to a single install.
What specifically should I be modifying?
-removing site id (i.e. wp_17 to wp_)
-what else?
I would test the plugins first before I do the migration, I know 11 sites will take too much time.
although keep in mind that 99% of the popular plugins has been tested to a newer vision of WP.
Don't forget to change the Wp_config from multi-sites to individual.
I am maintaining a magento shop and its sort of messy now with age. Also want to implement a fresh design. Current version is 1.7.0.2. I am thinking of making a fresh install and build a new theme to leave behind all the mess (many programmers have worked on it). I came across this blog - http://www.2hatslogic.com/blog/importing-data-to-new-version-install-of-magento-cleanup-easy . If it works as said in the article, that would be exactly what I want. Do you think its possible as in the blog article?
I know that the DB changes with the newer versions for the imported DB tables might not be carried over since the core_resource table have updated version number for each modules, but if I copy this table as well, then Magneto should update all tables with the set up SQL and it should all be fine I assume?
Thanks in advance!
Aneesh