Migrator script for Joomla 1.6

[Matias Aguirre]

Hi all,

I see in the Joomla Development Status that is planned to include a
migrator script into the Joomla 1.6 core.

What is the plan of this? Make a migrator script as component or
external script?

I think that i can help with this, so if any have some info or ideas
please tell me.

Take care

[Hannes Papenberg]

Hi Matias,
thanks for your offer. At this moment, its not really decided how to do
this. I would prefer that people would not have to delete all their
files, install 1.6 and then migrate data over from 1.5. My dream for the
update process from 1.5 to 1.6 would be an updater-component. That
component would ship with all the files from 1.6 and after installation,
you just select it from the component menu and it starts the update
process. So it has to move around a lot of files, delete the obsolete
ones and do table updates. This will trigger the max_execution limit, so
this has to happen with a bunch of ajax requests and several page loads.
But thats just me dreaming. ;-)

If you have good ideas for a migration path, write them down and present
them to the list here and you can start work on this. :-)

Hannes

Matias Aguirre schrieb:

[Matias Aguirre]

Hannes,

The component will include 3rd party extensions or only contents,
categories, modules and stories images?

-Matias

[Hannes Papenberg]

I would say that the component should only care for Joomla. Upgrading
their extensions to something compatible for 1.6 is the third party
developers job. Since we are not going to a completely new encoding
scheme like from 1.0 to 1.5, we don't need to export the complete
database, install a new Joomla 1.6 and then import the old database.
"Just" replacing the changed files and applying the necessary changes to
the database would be enough. But that would only be the case when we
really go the way of an installable update component.

Hannes

Matias Aguirre schrieb:

[Mike Hamanaka]

Hi J1.6

Hannes, You mentioned that the extension upgrade to 1.6 is the 3rd
party developers job.

Obviously the community thrives on added functionality.

Could all people here offer transparency on any available
documentation on j1.6 extension update manager that Sam is involvled
with.

I feel that the easy accessiblility of this information could motivate
extension devs and the extension community to have greater
organization in regards to the delivery of communication for ext
upgrades both major and minor.

Just the usual subscription the the 3rd party dev's RSS feed is not
good enough anymore.

Mike Hamanaka
Website Production
Vertualize.com

On Aug 31, 2009, at 12:50 PM, Hannes Papenberg

[Matias Aguirre]

Its possible to make an API to help 3rd party devs to migrate to
J1.6 ?
Just some class that helps in the installation/upgrade process.

My idea is to do a component that allows users to set ftp access and
database access and then allows to retrieve the files and data from
the old site

What do you think?

On Aug 31, 6:16 pm, Mike Hamanaka <haman...@gmail.com> wrote:
> Hi J1.6
>
> Hannes, You mentioned that the extension upgrade to 1.6 is the 3rd  
> party developers job.
>
> Obviously the community thrives on added functionality.
>
> Could all people here offer transparency on any available  
> documentation on j1.6 extension update manager that Sam is involvled  
> with.
>
> I feel that the easy accessiblility of this information could motivate  
> extension devs and the extension community to have greater  
> organization in regards to the delivery of communication for ext  
> upgrades both major and minor.
>
> Just the usual subscription the the 3rd party dev's RSS feed is not  
> good enough anymore.
>
> Mike Hamanaka
> Website Production
> Vertualize.com
>
> On Aug 31, 2009, at 12:50 PM, Hannes Papenberg  
>

[Hannes Papenberg]

I think I phrased this wrong and I feel confusion coming up. What are
the changes between 1.5 and 1.6? We have some added tables and we have
some changed tables in the database and we have some files that have
been deleted and others that have been added and a sh*tload that has
been changed. Now in the upgrade process for Joomla, we need to execute
those ALTER statements in manner safe for the data and in a way that
does not crash the host because of max_execution_time limitations. We
also need to replace, add and delete all those files. I expect that you
need at least 5 page calls alone to adjust the database without running
into such a max_execution_time limit. It might be several times as many
page calls for the files, unless you do it by hand of course. In any
case, this is a major problem for Joomla, because its so big. The
typical extension out there however is relatively small compared to the
complete Joomla package and wont need such a sophisticated system to be
updated. In fact, they can just use the update mechanism already built
into Joomla at this right moment. (Although at the moment I don't know
if any queries are executed during such an update, but thats a minor
thing to code for a third party developer)

What I meant with third party developers being responsible for their own
upgrade is, that there is no real migration necessary for extensions,
except that they have to update their code in some places to work with
the changed API of 1.6.

Hannes

Mike Hamanaka schrieb:

[Hannes Papenberg]

You don't need an old site and a new site. We are not talking about a
migration like from 1.0 to 1.5 where we basically tore everything down
and build it from scratch. We are talking about changing stuff in the
live site. There also is no need for an API for third party devs, since
they just have to pack up their installation and install it with the
update option over the installed version.

Hannes

Matias Aguirre schrieb:

[Matias Aguirre]

Forget the files for now. Let's focus on data from the database.

Never mind that there were changes in the database, which we have to
ensure is that the old data in Joomla 1.5 can easily be transferred
from a fresh install of Joomla 1.6. That is correct?

So what we need is to transfer the data and put them into the new
structure of Joomla 1.6 to work properly.

With respect to the API, this would be only one class to help devs to
migrate their own data (from the old Joomla 1.5 site) easily. This
would be work if the migration component is configured correctly.

Sorry if my comments cause confusion, what happens is that my English
is not entirely correct.

-Matias

[Matias Aguirre]

OK, I understand but I have some doubts.

How would this update? installing an upgrade directly to the Joomla
1.6 from Joomla 1.5?

[Airton Torres]

If I understood correctly what Hannes said, the upgrade from 1.5 to 1.6
cannot be made the same way as we will do it, for example, from 1.5.14 to
1.5.15, by only copying the new files over the old ones. Not only the files
will change but also the structure of the tables, and some files will be
deleted. Those things don't happen in a regular upgrade.

Nevertheles, it won't be necessary a migration script like we had from 1.0
to 1.5. No need for a new 1.6 site to migrate the old 1.5 site's database.

We will need a script that will take care of the changes in the tables and
also of deleting the files that will need to be deleted.

As for the 3PDs, they can offer their components packed with the "upgrade"
method in the xml file and also provide scripts in the install process to
take care of the changes in the tables structures.

An active upgrade script would be the best option (for J not 3PDs). This
script would be installed as a component in the 1.5 site and then, when
started, would take care of the database changes, of deleting the unecessary
files and also of fetching the new files directly from Joomla 1.6 repository
and placing them in their due places.

The limting factor in such a script, as Hannes said, are the
max_execution_time limitations and the size such a script would have to
handle all that stuff.

I'm sure someone will come up with a nice idea for that script that will
make everybody's life easier.

Airton

[Matias Aguirre]

To sort the max_execution_time we can to create a patch package (zip)
that the component will download from the joomla repository, extract
it and replace the files. Then we need to have a list with the files
to delete and run the databases changes.

The download could be done using AJAX with some progress bar.

Do you think that the extracting method will cause a timeout?

-Matias

[Sam Moffatt]

The hope is eventually we'll get the JED automatically building the
XML files required for the update. Extension wise there isn't much
that is changed, if you have an extension that updates now, it'll
still work. There is support for using a class instead however the
legacy com_install/com_uninstall functions are still there.

XML Update Samples: http://jsitepoint.com/update/update.xml (follow
the referenced uris)
Sample component:
http://joomlacode.org/svn/joomla/testing/trunk/installer_samples/components/com_alpha/

All that is really being added is support to have a slightly improved
UI for updates integrated into a single point.

Sam Moffatt
http://pasamio.id.au