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

[Jan Bednarik]

Hi,

I'd say that with 4.5 the woman has delivered and now it's pregnant 
again with 6.2 :)

I have a bunch of websites running 4.5, which I cannot imagine upgrading 
to 6.2. The customers would never pay for it, as the cost would be too high.

BTW, Axel's complaints about CoolUri were resolved, I helped him fix the 
issues he had.

Jan

Dne 3. 10. 2014 11:35, Luis E. Suarez napsal(a):
> 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
>