Joomla 1.5 will reach the end of its life in a short term and many site are being upgrade to a 1.7 or 2.5 version. We are trying to figure out how we can upgrade our sites. Unfortunately the developers of Joomla, who are doing a great job, haven't kept backwards compatibility high on their requirementslist.
We know there are many resources describing how to migrate a Joomla site to version X from version 1.5. But in our company we have about 120 Joomla sites. With all the migration steps that have to be done to the templates, custom written code and the third party modules we use this would be a hell of a job to migrate. So we are looking into methods and techniques that would make our (upgrade) job easier.
I can't imagine we are the only one with this problem so I am looking for more information on migrating these sites on a large scale. We can't be the only one who are struggling with this.
To give some detail, for upgrading of the minor versions we used the Vendor branches technique which worked awesome. In short, in our SVN repository we have a folder containing the current Joomla release. In the same repository we have a folder containing our own Joomla version with some custom code adjustments. Every project is based on that custom version. With the use of version branching we could easily update all our projects to the latest Joomla version.
For the major upgrade this technique won't be suitable. For instance we expect that some projects won't be upgraded to the new Joomla version for compability issues.
A way to solve this for the 2.5 branch could be to create two new folders with the 2.5 release of Joomla and our own customized 2.5 version. Each migrated project then would be branched of the 2.5 customized version. The migration process would be tedious and for sure be a manual drill.
We are afraid that we have to do this for every major release of Joomla so this won't be a real solution.
A solution we are thinking of is using phar and composer to create the project. If we succesfully can create a joomla phar as library and put custom development in an other phar, upgrading should be as simple as replacing the phar. Third party modules should be put into a phar archive also for easy updating. If modules don't support this, we are going to phar it ourself.
Of course we know that Joomla has a new, integrated update mechanism. We are looking into this mechanism but doubt we can use it since we have some custom patches to core code or module functionality.
To summarize this post, we have two challenges we'd love to get some feedback of.
How would you sggest upgrading 120+ sites to the latest release of Joomla
How do you manage Joomla updates if you have a large number of Joomla sites to maintain
The bad news is that there is no automated upgrade path from Joomla 1.5 to 2.5, as the changes are so drastic that they are almost like night and day. The template changes are such that you may have to rewrite them from scratch. Do not forget that 2.5 does a number of things differently too so you may also face a learning curve.
My suggestion would be to have a tiered migration plan and only migrate the sites that you need to or can justify the costs of the migration as the components, modules and plugins you use.
When doing so you need to watch the release schedule which provides a Long Term Release every 18 months each of which will most probably break backward compatibility from the previous versions, so you will end up with sites at 1.5, 2.5, 3.x etc
I believe that phar can be used in order to distribute a new upgraded version - but it will not help you in the upgrade process itself.
My (painful) experience with a migration from 1.5 to 1.7 taught me that not only the code changes were dramatic but also the DB changes (structure!), ACL implementation etc etc. The template will probably be the least of your problems.
My question back to you is, why do you want to upgrade ALL the websites ? if a specific website needs tools/plugins that are available only on higher versions of Joomla then I guess it's a good enough reason. But to upgrade all the websites will be, like you anticipate, a project from hell...
Related
I'm working on a magento Enterprise edition store and I want to migrate it to Community Edition.
I'm new to magento, please help me with some steps that I can follow to migrate EE to CE.
Could you please provide some ideas?
In my mind there are two different approaches.
You can start fresh with a new community install and bring over your code and design modifications and then your data.
Or you can try to downgrade your installation by "upgrading" to the latest version of community.
The way to go would depend on what modifications or customizations are in place
Not all data can be moved as some of the tables and fields are not in community edition.
Steps suggested:
1. Install fresh magento community version.
2. Copy theme folder from ent site and paste in communiyt site.this will probably break at places and you will have to fill.
3. Magento has data import export system so use that to import products.
4. Similarly apply import export for customer(You might have to go with some 3rd party code for this).
5. Apply configuration via admin.
I am not sure whether you want to move order data too.This part is going to be complex.
See https://magento.stackexchange.com/questions/6706/how-to-migrate-from-enterprise-edition-to-community-edition
Yanted has written a fabulous guide to this - some of the EE features in >= 1.13 actually make upgrades a little more painful than the below writeup would lead you to believe. As Marius points out in the comments that all passwords will have to be reset as encryption methods are handled differently between EE/CE.
See the blog for more details.
http://blog.yanted.com/2014/02/21/downgrading-magento-enterprise-to-community/
Original post:
Migrating is actually very easy - point your CE codebase at your production database. There's little more to it than that (see below for some folder removal information).
If you're using a well-built EE-compatible theme it should be backward compatible.
Here are some little-known EE features you'll need to watch out for when downgrading to Community:
No access to Customer Attributes from Admin Panel
Customer segments will go away
Catalog events, private sales, Invitations etc. will go away
CMS hierarchies are not supported in CE
Banners are not supported in CE
RMA - people always seem to forget about RMA (information will be resident in db)
Admin Logging information will be inaccessible (still resident in db)
If you have a large portion of your CMS built in EE I recommend you take a very thorough and methodical approach and make sure that your new CE theme (or backwardly-compatible EE theme) support the data that is still resident.
I also suggest not dropping any tables from the db prefixed with enterprise - as well as not removing any enterprise folders from your 3rd party themes. These are not considered as part of the EE install and you should take them along with you when you leave. You will need to remove the files and folders from the following locations:
app/code/core/Enterprise
app/design/frontend/enterprise
app/design/adminhtml/default/default/layout/enterprise
app/design/adminhtml/default/default/template/enterprise
skin/adminhtml/default/enterprise
skin/frontend/enterprise
app/etc/modules/Enterprise_*.xml
js/enterprise
LICENSE_EE.txt
LICENSE_EE.html
And of course, you need to consider the real biggie: Full Page Cache. I highly recommend that you find a decent 3rd party Full Page cache.
Best of luck!
Just I have one doubt that why one component or module is compatiable with one version of Joomla(Ex-> Joomla 2.5) but the same component or module is not compatiable with another version of Joomla(Ex-> Joomla 3.0).
If I want to make it compatiable with another versions also then what changes I need to do
The problem with compatibility is Joomla! is a delicate one.
The Joomla! platform / API is evolving all the time (especially between LTS releases like 1.5 and 2.5), so classes / functions are changed or deprecated and later removed. New things are added and so on.
For developers is possible to maintaing a component under different versions (I am not saying it's easy), but they need to know what has changed in the API.
Also constructs like (in pseudocode)
if (Joomla! version == 1.5) then do this else do that.
are used to make sure some parts of the code are used only in a specific version.
To better understand what is going on have a look at:
Potential backward compatibility issues in Joomla 3.0
You you easily see:
Renamed classes
Removed classes
etc.
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.
I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7
I tried the Audio module at http://www.drupal.org/project/audio but I'm looking for alternatives if better ones exist.
My problem with the Audio module is that the current release (and the past 5 releases) seem to have all been released as unsable.
The second problem is that the player itself that plays the audio is not showing when I display the node. I thought it was a theme problem, but when reverting back to Garland, the player is still invisible.
Any solutions or alternatives?
It's hard to say much about a module from it's release names. Some module developers don't like to release stable releases, as they then are saying, this module is bug free. They don't have the same commitment if user's should have issues, as the module is a unstable version. There have been talks about making a guideline/codex for module development and when modules should be regarded as stable releases.
Anyways in your example, if you look at the usage of the project, you'll find that July 4th had 2,958 sites using the 6.x branch of the module. that's a fairly high number, so you shouldn't worry too much about the module being all that unstable.
Your problem with the player, could be a theming / settings issue. If you want help with that, you should write a more specific question about that, including what you've tried/done etc.