[TYPO3-mvc] Concept of dynamic USER_INT switch maybe has to be refactored?

Franz Koch typo3.RemoveForMessage at elements-net.de
Wed Apr 7 15:04:18 CEST 2010


Hi again,

I just stumbled over another issue with the current USER/USER_INT 
situation. Problem are mixed GET/POST vars and TYPO3s way of handling them.

Let's say you have a page with a contact form on it and the form should 
not be cached in order to get the validation stuff work correctly. So 
you configure your extbase controller/action in ext_localconf.php to be 
USER_INT. Now extbase is adding a TS-condition that'll be triggered as 
soon the controller/action pair matches. So far so good.

But in case of forms they never will get triggered due to the way TYPO3 
is handling mixed GET/POST-parameters in t3lib_div::_GP (I think it was 
_GP - it's been more then a year since I digged for the cause of this 
for the first time). It'll completely ignore the GET vars as soon as one 
POST var is given. So you're form might trigger a certain 
controller/action via the URL (GET) but send it's values via POST and 
TYPO3 will never ever match the TS condition as long as you also don't 
send the controller and action names via POST (which is currently not 
the case by default). So please keep that in mind if you start building 
sensible forms with extbase/fluid. I at least got quite some issues on a 
live website because of this.

A temporary solution could be to explicitly check for GET parameters in 
the conditions (which is possible, but was undocumented to the time I 
stumbled over this issue - not sure if it still is). But this might 
again rise some issues in other cases (thinking about AJAX requests via 
POST).
-- 
kind regards,
Franz Koch


More information about the TYPO3-project-typo3v4mvc mailing list