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

[Sinisa Mitrovic]

Hello,

I must say that I like TYPO3 a lot, and for me it is far better than 
other CMS i had to use (Joomla, Drupal, Wordpress). Each CMS have its 
own advantages and disadvantages.
A few weeks ago I had to upgrade company Drupal website from version 7.x 
to 7.y and it was really hard and time consuming because of old modules 
used on system. But system itself is easy to upgrade, just like Typo3 
and any other system.
Yes there are difference between DAM and FAL, but you have extensions to 
migrate that. Also there is a lot of documentation how to upgrade from 
4.x to 6.2.x LTS, it is not an easy process, but you gain a lot with 
upgrade.
And final, I had a lot of problems with TYPO3, but a lot of people 
helped me on this list, and a lot of times I did not need to ask, just 
to read documentation.

Best regards,
Sinisa Mitrovic

On 10/2/2014 7:11 PM, 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.
> _______________________________________________
> TYPO3-english mailing list
> TYPO3-english at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
>