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 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 have a WordPress Multisite that I use for several projects while they're in development - and then migrate a single install when I'm moving to a new server / domain.
The problem I'm running into, is that I have 3 sites within this multisite install (of 6+ sites total) that I need migrate to a different server, but am not sure how to only export only the parts of the database that are needed for these 3 sites (with wp id's of 6, 7 and 8).
I've been using this guide - which is slightly problematic since I only need THREE of the sites databases exported, but still need (at least some) of the multisite tables exported as well.
Any one know of any links to guide me in the right direction? Thanks!
I would suggest exporting all of the context via something like All-in-on-migration (you'll need the premium version for multisite) (documentation is POOR) and then exporting it all as the most up to date version, then removing what you don't need.
Partial migrations are a pain. I've not managed to do one that's not very messy. It's a problem I am trying to solve right now. Hence coming across this post.
I'm trying to create a web application to manage multiple websites. I'm still not sure what platform to built upon this kind of app, Node.js or Laravel (PHP). I want the application to be scalable to millions of users with an average of 2 sites each.
Would you recommend SQLLite3, JSON or MYSQL for storing all individual site's data in separate files or a single database with all individual site's data?
How can I prevent users from hacking into each others site?
mainSite >
Common
Site1/config.json, content/posts/, layout/
Site2/config.json, content/products/, layout/
Site3/config.json, content/pages/, layout/
I'm still not final on the above structure. Please help me with getting started with this app.
For scalable system you should use some system that will allow you easy redistribute resourses, so in this case i think node.js is better one, you could find many services that shares resourses for node.js
Big plans. Lots of work. My advise start small.
Setup one website with laravel and see how far you get.
You will get one website with multiple pages.
Laravel is easy, scales, has tons of extensions and a living, vivid community.
You have the choice to clone the website and set the same thing up under a different domain or just a subdomain.
I'm developing a component which has the below structure. This system is developed under Multi-Tenant concept.
www.a.com, www.b.com, www.c.com are web sites which are in different domains but they run the same system. Each website have their own template and web pages in their local database. That's doable.
The system which is ran on these three sites are independent from the mentioned above(templates etc). www.a.com, www.b.com, www.c.com have a one large database where all the system data is maintained. Since the system is developed according to MVC what I want to do is have a single model(multiple models) where all the logic is contained. So if I make a single change in the model it affects the 3 sites.
According to my research, model should be maintained in the cloud. How can I implement such a requirement with MVC(Given I'm using Joomla as my CMS, MySQL as DBs) ? How can I have a single model for all the 3 sites ?
You can put more than one domain on the very same joomla installation without any changes, just add a plugin that's called virtualdomains which will allow you (for free) to choose template and - thus - menus, extensions and available pages for each domain;
Maintenance-wise this will be easy since all is in one box; but the users will see three sites with different content, layout and urls.
Just a couple of warnings:
1) make sure no scripts or css or other local resources are invoked with the url (http://www.a.com/template/xxx/js/jquery.autocomplete.js) vs /template/xxx/js/jquery.autocomplete.js, the first will work badly with cache.
2) handle any intricacies such as same-url on different domains with .htaccess; use a sh404 or similar component to manage the SEF urls.
This model looks quite complicated to me.
It depends what the main goal of this? Its just fetching all articles/users together? But why?
If you are dealing with problem of running one project on multiple Joomla installations I can advise you to put them on single Joomla and than using Virtual Domains (http://extensions.joomla.org/extensions/core-enhancements/multiple-sites/7557) for "copying" the website on other domains. Then you will one database for all your project.
One downside of this is that its mainly suitable for the projects with same component and article structure. Meaning for example local news divided by regions under different domains etc.
For the reference: the solution is really working fast on Joomla 2.5 latest update.