Is there a definitive way to upgrade Magento while keeping all order data, sales data, ect?
After setting up a staging environment and ensuring all extensions, ect. are working properly there will inevitably be orders placed, orders processed, ect. Is there a proper way to sync the data with the production installation?
An alternative way I've read about is to set up a staging area and essentially practice the upgrade while taking notes on all the fixes that need to be completed. Then put the site into maintenance mode and do the upgrade on in the production environment. Is this a viable solution?
Any insight is appreciated.
Dane
With most magento updates you just need to ensure that you are pointing to the same database in your local.xml file. Magento will run all updates needed on that database to get it up to speed automatically. Yay!
However. Back up that database before the update runs. If you have any issues, you want to make sure you have a clean version.
The update often uses a lot of memory if you have many items/orders. So make sure your .htaccess file (which might have been overwritten by the update) still has a good amount of memory allocated.
Related
I am using the free plan for a personal project, so can't afford to move to a better (paid) one. Unfortunately, my database filled and stupid me did a reset, thinking it will delete only the rows, leaving the structure intact. But it deleted everything, so now I have to rebuild it.
Before I start, I'd like to know if there is a way to empty old records/rows from the database. If I could manage to do this automatically (ideally there are some heroku settings that can do this, something I've missed), so I won't reach the 10000 monthly limit, it will be great.
There are no safeguards built into the platform to delete rows on your behalf. You will need to do it manually or teach one of your applications to do it programmatically.
I'm curious how other people have approached this. Our group has been given the directive of implementing an internal website utilizing Joomla. We've set up a dev server for the person who is responsible for maintaining the site, and a production server. We're using IIS and the current version of Joomla.
I can sync the two with Akeeba Backup Core and Kickstart, but it seems an "All-or-Nothing" choice. It works, but if she's doing work on, for example, the look and feel of the site, but just wants to sync content, that doesn't appear to be doable.
I feel that someone out there must have tackled this goal before, but web searches seem to turn up people running dev/prod on the same server but in different subdirectories, or ignore the "all-or-nothing"ness of the issue, going for the "Do all at once" approach, which doesn't seem practical. Content changes frequently, but not-so the look/feel.
We've been doing this for several years now. We use a dev server and a prod server. When we make content changes on dev, we use phpMyAdmin to copy the content table from the dev db to the prod db. In some respects, it's still an all-or-nothing approach, because we have to copy the entire content table at once. This means you can't have some pages still in development when you do the copy. In other respects, it still a piecemeal approach, because we can copy individual tables such as modules, menus, etc. But again, it's ALL modules at once, ALL menus at once, etc. There is a way in phpMyAdmin to copy an individual page or item from a table in dev and put it in the corresponding table in prod, but it's a little cumbersome. It works, though.
As for design elements (images, css, template changes, etc.) we do the same thing, but the copying is done manually by ftp from one server to the other. Obviously this is the same method for things like pdf files on dev that need moved to prod.
In summary, this method has worked fairly well for us for a long time. But it's limitation is that you must realize you're copying an entire table at once.
The positive of all of this is that when we have pages that are in development, I have leverage over the content people to hurry and finish their work because one unfinished page can hold up the entire site!
This workflow dilemma has come up a few times for me.
You mention changes to look and feel, and that is simpler really, if it is just template changes. It is quite simpler to pull down an Akeeba Backup of the live server, kickstart it onto a local server, work on the template files, and then upload the updated template files to the live server.
That said, if it is more than CSS and HTML tweaks to existing files, it can be a more involved process.
Personally I've not found a silver bullet for this sort of thing, but with some forethought and planning it is not too bad.
I have developed 9 multiple websites/stores in one magento installation. On DEV server it is ready and working good. Now my client wants to launch first 3 websites in next month, then after we will make some modifications in other websites based on feedback from first 3 websites. Then launch other websites one by one.
One thing which I am worried about is how we make modification and further development. Because magento files and db is one installation, if we launch first three which means we are launching whole system, and if we make DEV work in live site that is not good because if anything breaks etc. LIVE sites will go down.
What is the best and logical procedure in magento to launch multiple stores one by one. What approach we can follow for such situations.
Please help, thanks!
To my eyes, the fact that you have 9 different websites/stores running off the install is of minor importance. You will encounter the same issues that any dev / live Magento set-up will encounter. At the point the site launches you will need to create a second copy of your database / code for use as a development environment. With regards to the code, I would hope that you are using some kind of VCS such as Git or SVN, if you aren't you should seriously consider it.
The database is the slightly trickier side of things. It is also going to be the issue exacerbated by the fact you have 9 different websites, since you will have a lot of different configurations. There will likely be 3 different types of configuration changes to be made.
1.) A setting that needs changing for the live websites.
2.) A setting that needs changing for a future website to be launched.
3.) A setting that needs changing in order to make your development site work.
The 3rd type is the easiest to deal with. You can simply change them in the database and forget about them. These will include things like setting the base_url values in core_config_data.
The 2nd type should ideally be made with migrations rather than through the UI. If you are using Source Control these migrations would be kept in a branch that will get merged into your master branch at the point you wish to launch the website they effect (at the point the code is merged, you may have to do some tinkering with the version numbers based on how you deal with type 1.
The 1st type can be handled in one of two ways, a migration is a favourable option as it means all installs of you code dev / staging / live can be kept in sync. If needs be, simply ensuring you update your dev database at the same time as the live one, would suffice.
Some of the things you need to change won't necessarily be the easiest things to achieve through migrations, but doing so should prevent any errors from arising whereby you forget to update a single value on one of your servers.
So, we had the hosting service set up a dev site with the intentions to then upgrade our live site once that was done. After a ton of back and forth the hosting service bailed on us, and we're left with an updated dev site and not much of a clue on how to update the live site.
While I'm not asking for a foolproof way of updating the live site, I do need something that won't impact sales by being down....or something that won't be a problem to roll back on in case there's issues.
any guidance / tutorials would be a big help. when I set up our original site we weren't live yet, so I could grind away without losing $$$. That's not the case now.
Thanks!
There are two things that happen for upgrades: new functionality from the updated / additional files themselves, and database upgrades which are triggered by each module's version.
Above all, it may be advisable to find a freelancer or shop with a good Magento track record and experience in 1.3 to >= 1.4 upgrades. They should be able to set you up for the clearest upgrade path moving forward. That said, here's a procedure:
Backup database and filesystem.
Perhaps, make another backup.
Create your own dev environment from this backup: install files, duplicate database, change the db settings in app/etc/local.xml. You likely will need only to change the base_url settings in the core_config_data table: SELECT * FROM core_config_data WHERE path LIKE %base_url).
Check the big core files: Diff your app/code/core/, js/, lib/* files with a known-good copy of the 1.3.2.4 or 1.3.3 (there is no 1.3.4) - check Mage::getVersion(). Any changes will need to be accounted for. And slap whoever changed them :-)
Once you've verified that you have a healthy core / fixed your core, you are ready to test the upgrade. Simply copy the files from 1.5.1 over.
Make sure that you have set a substantial timeout if you have lots of orders.
If you have issues with this upgrade, you may opt to step through versions. Particularly, you can go from 1.3.2.4 to 1.4.0.0 to 1.4.2.0 to 1.5.1.0. At the very least, this might help you spot where along the upgrade sequence things are going to pot.
Also, you will need to fix your templates. Between 1.3 and 1.4 Magento implemented a base design package and default theme; other themes should build from this. You'll almost certainly need to merge your changes from your layout templates (under template/page/; 1column.phtml, etc.).
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.