[TYPO3-english] [Rant, long] Update 4.5.35 -> 6.2.x

Axel Joensson a.joensson at web.de
Thu Oct 2 19:11:17 CEST 2014


Hi there.

I have started working with TYPO3 more than 10 years ago with some 3.x
version, though I never had the time to do this full time. So,
experienced, yes, but probably not a professional, just one of those to
whom T3 is quite a challenge. I am presently taking care of a
multi-language site that is up for almost ten years, too, and is (still)
running under 4.5.35 at a very good specialized hoster, whose name
starts with "W" ;o).

In August, I started preparing to upgrade to 6.2.4 LTS by cloning the
installation into a subdomain and updating that clone. I encountered
some problems with extensions, most of which initially I could not
directly update (autotemplateparser, CoolURI, Static Info Tables,
sourceoptimization, sr_languagemenu), but I overcame, if though I
finally dropped sr_languagemenu and replaced it by some lines in TS
setup, because I did not even understand how to configure the
new ext version any longer. But my TS now does that job just like I want
it. I updated the other extensions after arriving at 6.2.4. The single
problem seemed to be that in the updated frontend everything was running
quite slow, even after updating to 6.2.5.

Nevertheless, trying to exchange the old 4.5.35 version for the update
broke everything. It was impossible to make CoolURI (1.0.37) update its
link cache, even uninstalling and reinstalling it didn't help. First the
frontend, and finally the backend, too, were broken. I even tried some
voodoo like deleting temp files, but in the end both the 4.5.35 and
6.2.5 versions were BE/FE-dead, valid log-in to BE or install tool was
declined, so finally, for the first time since I am working with TYPO3,
I had to use a backup to bring up again a productive site, after it was
completely offline for maybe two hours in the middle of the night.

As I am not lazy and adrenalin can reduce your need for sleep (and I had
a lot of adrenalin circulating after having shot my first productive
site!) I went on. Of course I had not backed up the clone before trying
to shift it to productive state, my fault, which I regret. I wanted to
save some time. Now I had to clone everything again, set it up in a
subdomain, trying to update the extensions. This time, none of them I
managed to update, but frequently got error messages like this (not only
for CoolURI, like in this case, but similarly for other exts):

> ERROR: Query could not be parsed: "SQL engine parse ERROR: No table
found!: near "`link_cache` ( `id` int(10) unsigned NOT NULL
au"". Query: "CREATE TABLE `link_cache` ( `id` int(10) unsigned NOT
NULL auto_increment, `params` blob, `url` char(255), `tstamp` TIMESTAMP
default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, `crdatetime`
datetime default NULL, `sticky` tinyint(1) unsigned default 0, PRIMARY
KEY (`id`), KEY `url` (`url`(64)), KEY `params` (`params`(64)) ) ENGINE
= MyISAM; " 

Well, I deactivated all problematic extensions, updated to 6.2.5,
declined some of the tables (those related to CoolURI and Static Info
Tables) to be marked for deletion. While assets should be migrated
during the update procedure by the upgrade wizard, some assets were
reported to be missing (PDFs, vcf-files, images), just as it had already
been during the first update attempt. Probably this happens with
obsolete assets which before were deleted, however not from *within* the
backend's filelist module, but by FTP. Obviously TYPO3 never forgets and
never forgives. So, I ftp'ed "dummy" copies for these files to the
server, and the errors disappeared when I sent the wizard looping
through there time by time.

Finally, no more errors appeared, except for the index.php, which my
hoster for security wants to be a file, not a symlink. So that field
remains yellow, but no red alarms, no problems, or so I thought.

Then I looked at the frontend, which at first had seemed fine. Now I
noticed almost all images were missing: fileadmin/_migrated/pics was
empty, not a single file arrived in there. I renamed them appropriately,
appending a "_04" or "_08" or whatever name the wizard complained to
lack) and copied them into _migrated/pics. Now they were back in FE, but
that was also when I discovered that almost all images were double, at
least all of those referenced directly as content elements, but not
those being referenced e.g. from within HTML content elements by a
"hardcoded link" to fileadmin. About a total of 300 pages in five
languages. Two or more images per page. All of them double referenced.
That must have happened when the upgrade wizard needed several runs to
"migrate" images into the FAL, which never arrived.

As this newly upgraded installation -- which I arrived at around eight
o'clock in the morning after not having slept at all -- runs much faster
than the first attempt did, I decided to delete the double references on
all of the 300 pages manually (isn't that sick? But the alternative
would have been to start yet another attempt of upgrading ...), and to
be honest: I was grumbling about the people who, some years ago, decided
to have TYPO3 make internal copies of assets, changing their original
names by appending some number and storing them elsewhere for asset
management. That is everything else, but "user friendly". I remember
that I was suspicious about such a way of messing with and multiplying
assets without explicit admin consent from the very first moment I
discovered this behavior somewhen in version 4.x. But there is a
tradition in TYPO3 of doing silly things to users without asking: It was
the same when each and every extension came with abundant CSS styles of
its own, and one first had to disinfect an installation by dropping lots
and lots of unwanted styles by TS setup (that part in my setup is not
much less than 100 lines), even before being able to start to define the
own layout. And now DAM is exchanged for FAL, and I am cleaning the
mess.

If I try to get such senseless hours paid by a client, I will be left
with double images, but no more client. So, I will have to see if this
second attempt (or maybe a third one?) will finally be successful.

But honestly: I am no longer sure if I will ever again recommend
somebody to use TYPO3. Features get introduced and kicked out again for
allegedly "advanced" new versions, before I even made use of them.
Instead of becoming more transparent, everything seems to get more
complicated from version to version. What for? 6.2 LTS will be running
for the coming two years and I don't think that I want to face any other
TYPO3 upgrade. Updating or upgrading is probably the most difficult
thing to do with TYPO3, and many extensions every single time defend
against starting their service after updates. Still, this one was too
nasty, really, regardless of how this (... no, I don't want to swear ...
argh!) upgrade will go on. Still tired.

Regards.


More information about the TYPO3-english mailing list