Project

General

Profile

Actions

Bug #43944

closed

$TSFE->tmpl->setup sometimes not completely present in tslib_fe->sendFormmail()

Added by Christoph Dörfel almost 12 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2012-12-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.4
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

The issue presents itself as follows:
Hook into tslib_fe->sendFormmail() with $TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['sendFormmail-PreProcClass'].
Sometimes when checking for plugin configuration, $TSFE->tmpl->setup['plugin.']['tx_someplugin'] is not available because something went wrong with the caching (I have no idea what causes this).
We are using wt_spamshield and a custom captcha extension. Both are checking for their plugin configuration ("enable = 1") and obviously fail because there's only a basic setup present. This generated a massive amount of SPAM mails being sent over one of our standard mailforms.
Because we're already xclassing tslib_fe and extending sendFormmail() through our custom captcha extension, the quick fix was to write the following at the beginning of the function (~Line 2543):

function sendFormmail()    {
    global $TSFE;

    $formmail = t3lib_div::makeInstance('t3lib_formmail');
    $EMAIL_VARS = t3lib_div::_POST();

        ## if no plugin config is present, something has gone wrong
    if (empty($TSFE->tmpl->setup['pugin.'])) {
        $TSFE->forceTemplateParsing = 1;
        $TSFE->getConfigArray();
    }

Of course, if no plugins were installed, then $TSFE->getConfigArray(); would be called in vain - but the downside of not having any plugin configuration is far worse than some additional time spent parsing the setup again (even if it came from cache).
This fix is easy to implement, although it doesn't fix the issue of why the correct setup wasn't available in the first place.

Actions #1

Updated by Tobias Liebig almost 12 years ago

  • Complexity deleted (easy)

I guess tmpl->setup is not available if the page is cached and no uncached ContentElement/Object (e.g. USER_INT) needs to be rendered. Can you confirm that?
Forcing to parse the TypoScript every time, even if the page is fully cached might become a performance issue.

Actions #2

Updated by Tobias Liebig almost 12 years ago

  • Status changed from New to Needs Feedback
Actions #3

Updated by Christoph Dörfel almost 12 years ago

Tobias Liebig wrote:

I guess tmpl->setup is not available if the page is cached and no uncached ContentElement/Object (e.g. USER_INT) needs to be rendered. Can you confirm that?
Forcing to parse the TypoScript every time, even if the page is fully cached might become a performance issue.

Confirmed.
SPAM was sent through the "Jump to page" which is cached and only contains a text element.
If mailform POST data is present (e.g. sendFormmail() is called), shouldn't that always be handled as uncached? Since this doesn't happen too often (only when a mailform is submitted), I personally see no problem in that...

Actions #4

Updated by Alexander Opitz over 11 years ago

Hi,

this issue is very old, does it still exists with newer versions of TYPO3 CMS (4.5 or 6.1)?

Actions #5

Updated by Alexander Opitz about 11 years ago

  • Status changed from Needs Feedback to Closed
  • Is Regression set to No

No feedback for over 90 days.

If you think, that this is the wrong decision, then please write to the mailinglist typo3.teams.bugs with issue number and an explanation.

Actions

Also available in: Atom PDF