Multiple plugin with random banner on same page: Safari shows same banner

[swisschocolate-zz]

If there are multiple plugins showing randomly one banner of a pool of banners, Safari shows on all plugin places the same banner. This is because the URL in the js for fetching the banners are identical and Safari is "optimizing" this by doing only one request (under the mikstaken assumption the content will be the same). Solution: add the uniqueid to the fetching url in Resources/Private/Templates/Banner/Show.html like this: banners.push(['banners-{uniqueid}', '{url -> f:format.raw()}&{uniqueid}']) @derhansen : Would be nice to adapt this in the template ☺️

[derhansen]

Thanks for your report. I trief to adapt the template as suggested, but this does not work, since adding a various parameter to the URL will result in a 404 error when the TYPO3 cHash check is active (what is highly recommended).

I also tried to add a random variable to the generated URL, but this leads to deadlocks with the TYPO3 cache.

An exception occurred while executing 'DELETE tags2, cache1 FROM cache_rootline_tags AS tags1 JOIN cache_rootline_tags AS tags2 ON tags1.identifier = tags2.identifier JOIN cache_rootline AS cache1 ON tags1.identifier = cache1.identifier WHERE tags1.tag IN ('pageId_34')': Deadlock found when trying to get lock; try restarting transaction

Also replacing the jQuery.get request with a cache aware solution as shown below (and by including _ in $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters']) results in the described behavior with the TYPO3 deadlock

    $.ajax({
        url: url,
        cache: false,
        success: function (data) {
            postscribe('#' + position, data);
        }
    });

I was successful to add a setTimeout to the AJAX request with a min of 100-150ms, but I have the feeling that this is only a bad workaround and that the main issue with the DB deadlock should be resolved in either TYPO3 or doctrine (no idea where the problem is located)

[swisschocolate-zz]

Thanx for investigate this. Too bad it doesn't work with CHash check. I probably have to find another approach. Generally the goal is to spread a bunch of banners randomly between other site content. Maybe best would be to get all banners with one fetch and then distribute them by moving around the DOM. Perhaps this would be even a performance advantage.

[derhansen]

Yes, maybe this would be a better approach with just one request, but it would also require a bigger (and breaking) refactoring of the extension, since then the Extbase action has to:

• fetch all banner plugins on the current page
• parse the flexform for each plugin
• process the query in the repository for each plugin
• collect and output the combined result as HTML

And also the async banner placement needs to be refactored, since combined result must be split and distributed to each banner position individually.

[derhansen]

Well, I the problem with the deadlock seem to occur randomly with the current version of the extension. So maybe it is really better to fetch all banner code in just one request. Since this will be a breaking change, I consider to only implement this feature for the next major version, which will support TYPO3 11 only.