fluidpages list module UnexpectedValueException on upgraded site 4.5.23 -> 6.0.4 about fluidpages HOT 15 CLOSED

After the wrong comment below, I switched the source link back to 6.0.4 with fluidpages 1.3.0 and still get the same error, so the original issue still stands, but given it works in a new empty database perhaps starting from scratch is still the best path.

edited: I'm a muppet, just one of those days. Forgot to switch the symlink from 6.0.0 (which works) back to 6.0.4) which doesn't.

Original comment below

argghhh... this seems to be a real [heisenbug](http://en.wikipedia.org/wiki/Heisenbug).  

Having just moved around the site directories to test a fresh empty install and database vs the upgraded database and old files it's all now working in the upgraded database.  Can't seem to reproduce it all anymore.  

If it happens again I'll let you know here, but perhaps its time for a new fresh install anyway.
Sorry.

from fluidpages.

"Heisenbug" ;) didn't know that one. Great!

Good to hear the problem is gone.

Cheers
Björn

from fluidpages.

Sorry Björn, I probably confused everything by editing the original incorrect comment rather than adding a new one. I thought it was gone, but I had just forgotten to switch the symlink back to 6.0.4 from 6.0.0.

So I do still get the error with an upgraded database and >6.0.0 with fluidpages installed but as it doesn't occur with an empty fresh installation I figured it must be something from the upgrade. So I guess the workaround is to start fresh, but perhaps it is still a bug that may affect more people as upgrades from 4.5 LTS to 6.x and the popularity of fluidpages increases.

I've still got the test install if you can let me know of any further troubleshooting steps I can perform?

from fluidpages.

Don't know really. Is there a straight upgrade path from 4.5 to 6.0 at all? I remember having trouble upgrading from 4.5 to 4.7 leaving out 4.6 but that was not Fluid related. Maybe @NamelessCoder has a hint.

from fluidpages.

I'm assuming there will be an upgrade path from one LTS to another (6.2?) when it comes out. But I bet you're right, I did just go direct from 4.5 to 6.0. I'll try an upgrade through each minor version and see what happens.

Thanks.

from fluidpages.

Hi guys,

It should be possible to go directly from 4.5 to 6.0 but on most sites where I've done this (have also done 4.4 -> 6.0 and 4.2 to 6.0) I had to upgrade all extensions (including flux, fluidpages et al), run the upgrade wizard multiple times and always (stress always) paying attention to DB updates - and keep a backup of localconf.php since the rewriting feature does not seem 100% safe - it failed for me in around a quarter of all upgrades, leaving a blank config file.

Apart from this, you should be able to upgrade from any 4.x to 6.0. In my experience it almost entirely depends on the extensions being used. It helps to be very patient, constantly clearing typo3temp and manually clearing cache tables because damn, there are quite a few ways for bad caches to linger around during an upgrade!

from fluidpages.

I've still got the test install if you can let me know of any further troubleshooting steps I can perform?

I'm very interested in seeing a (full but huge) stack dump of the UnexpectedValueException, recommend saving as .html file or print PDF - it would definitely help if we could trace this back to a specific file or class or even better, a specific argument value which could stem from an existing configuration that's no longer valid.

Will it display the stack dump for that exception if you set "displayErrors=1" in install tool...?

from fluidpages.

displayErrors=2 at the moment. Any other exceptions I've had came through the debughandler but this particular error (line 55 in typo3/mod.php) seems to be hard coded, and not much info is included in the error.

Would we need a debugger to step through the functions in that case, or is there a snippet of code that might be able to output something? This install is pretty old, and has had many extensions over the years so wouldn't be surprised at all if there's something crufty in the database causing problems.

I'm just running through the minor version upgrade scenario with a fresh copy, but after that I'm game to try getting some sort of debugging set up with phpstorm. Been meaning to learn more php and I guess this is as good a time as any!

from fluidpages.

I can confirm pixelplumber's findings:
The error doesn't occur if fluidpages is not installed and also not in TYPO3 version 6.0.0
Additionaly it depends on the existence of a content element on the page (tt_content). Without any content the page loads in list view.

When I move the page into a page wich has a working root template in its rootline the error also doesn't occur.
I observed the issue in two different TYPO3 instances. But both where updated from an earlier version though.

Since the mentioned source file mod.php doesn't differ between 6.0.0 and 6.0.4 the error must be connected with either the call of
$temp_M = (string) \TYPO3\CMS\Core\Utility\GeneralUtility::_GET('M');
or one of the two methods used there to determine the $isDispatched variable.
Since there is a value $TBE_MODULES[_dispatcher][0]=TYPO3\CMS\Extbase\Core\BootstrapInterface
I guess for a failing call $dispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Extbase\Object\ObjectManager')->get($dispatcherClassName);

Also there is a difference in the request between failing and successful call: The failing request contains an unnecessary ampersand:
http://typo3.stable/typo3/mod.php?M=web_list&id=52&
and gets redirected to
http://typo3.stable/typo3/mod.php?id=52&redirected=1 which fails in mod.php.

The successful doesn't:
http://typo3.stable/typo3/mod.php?M=web_list&id=1

Kind regards
Dirk

from fluidpages.

I've just done the 4.5, 4.6, 4.7, 6.0,x upgrade and do get the same error. I originally thought it showed up on page doktypes (and it didn't show up on sysfolders or shortcuts) but as Dirk mentioned, this seems to be more to do with tt_content within, as an empty page works but a sysfolder with content elements inside doesn't work.

Also like Dirk, I have the redirected=1 showing up in firebug for the failed pages.

Cheers,
Mark.

from fluidpages.

IMHO closing this bug was quite optimistic ...

from fluidpages.

IMHO closing this bug was quite optimistic ...

Well, it was quite optimistic to call it a Heisenbug ;)

from fluidpages.

Looks like Dirk pin-pointed the cause: the redirection is done in a way which can strip off URL arguments which are expected to exist (among others, the "M" parameter).

Correcting the redirect should solve the problem. Björn, if you've got the time it would be a question of reading current GET vars and reusing them, with the "redirect" argument added. If you don't have time I should have some tonight.

Cheers,
Claus

from fluidpages.

Well, it was quite optimistic to call it a Heisenbug ;)

hehe, well it was a heisenbug to me (non-programmer) at least. Thanks for your help guys. Happy to test it whenever its fixed.

Cheers.
Mark.

from fluidpages.

Closing; the missing argument issue is most surely fixed by the two referenced commits. Thanks Dirk for painting the target :)

from fluidpages.