[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