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

[Luis E. Suarez]

Axel, the problem is that TYPO3 is like a  woman that is always pregnant 
but never delivers.  It is a looong way far from mature systems like 
Wordpress (to mention just one) that year after year improve without 
nightmares.  I personally use TYPO3 (since version 3.x) as a "challenge 
hobby" not for commercial purposes. As such I'll be very happy to give a 
try upgrading 6.2 to 6.3 including a bunch of always beta extensions.

Be happy.

On 02/10/2014 18:11, a.joensson at web.de (Axel Joensson) wrote:
> 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.
>

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com