All third party components need to be reinstalled and their content migrated manually. There is a facility to migrate the core content using com_migrator.
#Fm 2005 patch 5.0.3 upgrade
There is no upgrade route planned but only a data migration. Regarding the planned tranisiton from Joomla! 1.0.x to 1.5. I have found no problems on several versions of php including 5.1.2.Ĭan you please provide a dump of your environment. (There is a library of functions, iconv() being one of them). The phpinfo() is reporting setting of the iconv environment settings and not necessarily checking if the function exists. I suspect something in your operating environment. This is the first instance of a false report of iconv function existing or not. What about my installed modules like CB, Joomla Explorer, Joom!Fish, Helpdesk, and others? Will I have to reinstall these modules/components/mambots? If you do not reccomend the migration wizard than what should I do? Should I duplicate my 1.0.9 database and use it for 1.5 selecting the "backup" option? Yep, I checked phpinfo and it is indeed enabled. Joomla looks the most promising of any cms I have found so far! If you edited the php.ini to enable iconv, please don't forget to restart apache for it to take effect. You can aslo check phpinfo() output in the php tab. In the main page you should see if inconv is loaded or not.
#Fm 2005 patch 5.0.3 install
I suggest to install without migration and in the administrator, go to tools -> system info. I checked on php 5.1.2 and it worked fine for me. At that time the foreign key issue will be reevaluated with an eye on future development of MyISAM table engine. In any case there will be no major changes in db schema before Joomla! 2.0.
Most shared hosts do not enable creation of innoDB tables which do support foreign keys. MyISAM tables do not currently support foreign keys or referential integrity. Joomla 1.5 is to be compatible as far back as MySQL 3.23 which means versions that will not even parse the foreign key statement (implemented only in version 3.2.44). Today you have to guess to where some fields refer - as torkil experienced in reverse engineering the schema in the post mentioned earlier. Adding foreign keys constraints to the current 1.5 schema would be the first step on the way to getting referential integrity, and also making it possible for us that use ER diagramming tools to reverse engineer the schema ensuring correct couplings between tables. All tables that have compositional dependencies to/from other tables should specify those in the form of a foreign key. I imagine it would make the job of the migration tool harder, but nonetheless it would be its responsibility.Ģ) What I mean with foreign keys - current schema doesn't specify foreign keys, this is _bad_ practice. So if the team for instance introduced cleaner naming convetions for field names, table names, SQL queries, etc, as argued in the post, the migration tool would be responsible handling those differences. Since the team already has decided for a migration path between 1.0 and 1.5, changes in the schema of the 1.5 installation would be the job of the migration tool to handle. I'm not sure that I'm following you on the foreign key issue. This applies to data and to string field definitions. There is also another reason to migrate data (irrespective to db schema) and that is the encoding conversion that is required. There is no practical way to patch an existing site to the new code.
#Fm 2005 patch 5.0.3 code
The changes that argue against an upgrade path are the code base and it's structure. The only thing that almost has almost no changes is the database schemal Besides two field renames, there are a few additions which usually don't affect upgrade or migration. The developer team have been claiming all along that they weren't going to change the database schema because of compatibility issues with previous versions - now you're saying that there is no way outside migration - so the question really is why you don't do schema upgrades as well since 1.5 is so significantly changed? Add foreign keys to all the tables at least, so one can reverse engineer it properly, this won't change the schema at all. The core data migration does reconstruct menu items for core elements and also keeps core module records with configuration settings. Extensions need to be installed and configured as if the site is new. The concept is to build a new site and to migrate data from the old site. This is the reason that we are providing a migration path. Joomla 1.5 is so significantly changed from 1.0 that there is no 'upgrade' path.
0 kommentar(er)
