First of all I am asking the question here because I did not get an answer in the wordpress forum.
I have a working blog based on wordpress 3.8, which is a pretty old version.
I would like to start everything from scratch and to use the existing DB with all the data (which is very very big, 300+ thousands of tables, it is multisite).
I am afraid to upgrade it because I suspect that the core files were modified in the past (before me).
I would like to install the most recent version of wordpress and make sure everything is compatible and working. What is the best method to do so?
I can install the most recent version and connect it to a clone of the old db instance. Can it break something?
I can install a clean version 3.8 and perform an upgrade. Is it a smart thing to do?
Other methods?
Step 1: backup your database.
Step 2: backup your code base.
Step 3: In a non-production installation, upgrade the WordPress installation. This will trigger a database upgrade as WP needs.
At this point, you have a backup of the old data, you have a versioned copy of the data, and you have a copy of the code that may have been modified, as well as a version that is "current / correct". You are in a position of strength to test functionality, ensure nothing has been lost, etc.
If everything looks good, you could then upgrade the production installation (keeping a copy of backups of both the database and the code base).
Lastly, if I were in your shoes, I would visit the Release Archive and download the specific version you are currently on (3.8.?), then run a comparison between the known good / unaltered files and the files that you have in place. In this way, you can prove whether core files had been altered, and you can see the alterations. This would provide you with the information you might need to re-implement those "features" that were incorrectly implemented in the core code.
Related
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.
We(small group) have a SocialEngine based project and we made lots and lots of changes in 4.6.0 version including core modules, now we struggle to update to 4.8.0 which is a pain in the ass so question:
Which logic to implement in new version of social engine where will be stored our modified code that will help for future update?
We are trying using Decorator Pattern, creating another folder(modules2) for example there creating clones of modules and using only modified files(which is currently unsuccessfully).
You can to compare your files with the latest upgrade package files with Softwares like WinMerge and copy new changes in SocialEngine core to your modified files. Don't forget the database queries in application/MODULE_NAME/settings/my-upgrade sql file of each module. It's gonna take time but I don't think there's any easier solutions.
See, thats where git or subversion comes handy , you exactly know where the code is changed .
I'm updating an existing wordpress site making significant modifications the the theme and site structure, as well as making updates to plugins which in turn store their data into mysql database.
As far as I'm aware there are 2 (3?) possible strategies here:
'Dump-and-load' MySQL database from DEV to LIVE and replace wp-content folder with latest updates.
Import changes via WP-importer and replace wp-content folder with latest updates.
Make database changes manually via WP admin interface and replace wp-content folder with latest updates (this is useful only for minor changes).
While I am developing in my own separate environment this is for an existing website which is currently live and will continue to receive updates from the public such as comments and entries into contact forms, hence I expect the database to be different now from when I release my changes.
Given this the options above provide the following problems.
1. DUMP AND LOAD
The 'dump-and-load' strategy seems to be out of the question as my data is being updated behind the scenes (this would have been my preferred approach as this is easily rolled back).
Result: requires synchronising databases post release to get latest updates, TOO COMPLICATED.
2. USE THE IMPORTER
Using the WP-Importer plugin page and post IDs will get updated, screwing up styling that relies on the post IDs to get activated. This in turn creates a CSS nightmare that I wish to avoid, having to go though the CSS after release to update the new page/post IDs with the ones the database created.
Result: Too finicky, not very professional approach leading to long and complex release process.
3. UPDATE DATABASE MANUALLY
This option is great for small changes but when for more complex releases the list of steps to follow on the PROD interface becomes long and hard to follow, making it easy to make mistakes.
Result: Too easy to screw up, only a last resort.
IS THERE A STANDARD WORDPRESS RELEASE STRATEGY FOR EXISTING WEBSITES?
So basically, my question is: What release process do other wordpress developers follow when UPDATING an existing website? Is there an option that I have not listed below that minimizes hassle and reduces time and complexity during release?
I've set up source control for the site using GIT and I am used to automating things via ANT or similar release script, this may be overkill for the current project but would be ideal to at least know of a simple way to update a wordpress site and minimize the chances of screwing it up.
Thanks!
I don't think this is particular to WordPress, it's a similar situation to any custom site. I personally favor replaying the SQL changes on production that were made on dev. The tricky part is that you have to know what SQL changes were made. For example a certain plugin may make some schema changes when you install it - you need to know what they were. You can do that by creating an export of your DB as SQL before installing a plugin, then take another export after and do a diff on the files.
Since you say you're making the modifications then I might assume you know what SQL changes you are going to make? Just make sure all changes you make to the DB are in the form of SQL script files and not just editing using the GUI (you can use the GUI to help write the queries, but save the actual SQL). After all of your changes are done you should have a bunch of SQL scripts that you ran during your development process - you can re-run them in order without encountering errors.
Then when it's time to push to production, create a staging version of production (that is take a fairly current DB backup of production). Run your update scripts on that and test that everything is ok. If it is, then you can run on production.
definitely make a backup of production before running any changes on it!
The guy behind WordFence was working on a deployment plugin called
Deploymint.
There's a new one called WP Stack.
Metal Toad Media discussed using Capistrano, but that Capistrano isn't specific to WP.
CrowdFavorite launched a service called
RAMP.
Needless to say, you have some other options. If you're making db changes manually make sure you're working with the serialized data effectively. I recommend using Search and Replace DB. WordPress also had a great little trick for changing the site url entirely from the wp-config file.
I assume you have everything running in a test environment. I would then:
Create a new database in your live environment.
Preload it with all content and configurations for the new site.
In your test environment, configure your config.php to point to the new database.
Upload all files to the live server. Upload your config.php last.
This will minimize downtime.
Sometimes we have to alter Wordpress plugins slightly to fit our needs. If an update comes up I would like to still be able to update the plugin and merge it with our changes. What is the best to structure my code so this process is not a catastrophe? We are using SVN to store our wordpress plugins. And we are using tortoiseSVN as our SVN client.
Specifically, I altered qa-lite to take out voting options. A newer version of qa-lite came out and I want the new features that it has. Other than downloading the new version and combing through to make the changes by hand, is there, specifically, a better way to do it?
The only things that comes to mind right now is to consider public release of the plugin as head and your modified version as a branch. So, you'd keep them separated and perform a merge from head to branch in order to get new features. Manually.
Or create a patch from the diff between head and your changes. Then use the patch over the new public version.
I'm looking to upgrade a themed/custom Magento from 1.3.x to Magento 1.9 Enterprise. So far, after multiple attempts at upgrading, I have failed.
After the first upgrade, I uploaded the new Magento in a clean environment, copied the database to a dev database. Using this, the upgrade occurred with two errors: It appears Magento upgrades only support 1.4+ currently, and previous mysql upgrade scripts were not included. After the "install" of the upgrade, I couldn't access wither the admin, or the frontend, and there was no errors to tell me what gives.
Scrapping that idea, I tried a clean install: It worked fine. Then I tried importing all the products from a CSV export. Worked OK, but custom attributes such as images, sizes, etc. didn't transfer over. I have over 900 product, and entering everything manual would be a pain, and unfeasible. Scrapping that idea.
Now I'm at various upgrade configurations, upgrading from Magento 1.3. I'm going to try and upgrade 1.3 to 1.4, and then 1.4 to Enterprise, but has anyone performed such an upgrade successfully before and might be able to provide hints?
Thanks,
Bryon
Byron, I feel your pain. I struggled with an upgrade from 1.3 to 1.4 a month ago.
Try the technique mentioned here: http://www.webshopapps.com/blog/2010/02/upgrading-magento-to-version-1-4-keeping-it-simple/ In the end it worked for me.
The thing that is sort of counter intuitive is the deletion of the database. I kept trying to skip that step, and that's what stymied me for a while. You have to delete the database and reload the data (it does something to the key constraints). In the end I was able to upgrade to 1.4 without manually moving anything.
You should go the route 1.3 to 1.4 , 1.4 to enterprise and switch to default skin while doing so. Skin/templates needs special attention later as the dom is quite different. Merging 1.3 templates to enterprise dom will take ~ 2-4 days experienced slicer who knows how to use diff tools
my usual workflow for this is:
add all three magento versions to git and tag by version , use your own magento installation as base and ignore your template folders and local/community extensions that are not installed by default
on your web directory , checkout your base version
git pull 1.4 to your installation and visit the website to get the upgrades
git pull enterprise to your installation and visit the website to get the upgrades
doing it in such order you also get rid of removed files that magento has removed from each version and you also get all changes and new files.
Magento Enterprise Edition Upgrade Procedure for 1.9 to 1.9.1
Generally all Magento upgrades work by running the updated code with the old database. The differences will be detected and incorporated automatically on the next page request. Magento keeps track of every module's version number for this reason. This is not advised with this upgrade if you have custom code.
Disclaimer – if you have a lot of customization, the upgrade will break the system; it is best to do this on a new (temporary) site, compare, bug fix, then test, then cross browser test.
Your general approach:
Close production server Backup all
DBs and Magento installation Turn
off all your custom extensions and
themes
Delete from HDD: core Magento modules, their layouts, all standard themes and cache.
Get 1.9.1 EE, copy it into a fresh DB installation, then place custom code over the top.
File compare between OTB 1.9.0 and 1.9.1. Pay special attention to a list of core controllers which have been overridden and compare the difference between these controller in version 1.9.0. and 1.9.1.
Here is a list of known problematical issues which will cause rework in our custom code:
1) Google Analytics (does not work in
1.9.0 and to fix it, many changes are required to our custom code)
2) Flat
Category
3) Searching by Attribute –
(xml fix)
4) iFrame problem in CMS
pages
5) Missing admin custom tabs
(compare before and after)
6) Home
page enterprise_home has to be
renamed! (this is an example of a
hidden pitfall undocumented and
represents a warning to you to factor
in time for such problems)
7) Check Mage/Community for new modules which
override modules which we need.
8) Anything which extends the customer
entity should be rigorously tested.
9) JavaScript – be careful - the
actual js templates may be the same,
but the blocks and modules which call
them may have subtle changes!
10) Custom Product Imports – do a test
product import on 1.9.1 using dataflow
method and see
what db fields are needed then add them into the procededural code for your custom code.
Check release notes documentation and update for your theme, whether it supports EE 1.9. Turn it on if it supports, otherwise you'll need another theme.
Check release notes documentation and updates for all your custom extensions - whether they support 1.9.1 Turn them on - one by one.
You will have problems upgrading all core DB data if it's made automatically, check which fields are missing/changed and add them.
Cross Browser testing - problems with your custom theme, and you'll need to check your custom extensions and upgrade their template files, skin css and DB data to fit 1.9.1.
Testing is the biggest task, walk through the application, notice errors and warnings, fix them.