Resource icon

Standard Library by Xon 1.24.11

No permission to download
Overview Updates (91) Reviews (5) History Discussion
Most of those don't load additional javascript in all cases, so for some users the link-post links would break
 
I recently had a client having bots requesting a huge number of misc/style links due to all the unique _xfRedirect attribute in the URL. With the link-post.js backport this isn't actually required to have the front-end behave sanely for actual users.
 
Xon said:
I recently had a client having bots requesting a huge number of misc/style links due to all the unique _xfRedirect attribute in the URL. With the link-post.js backport this isn't actually required to have the front-end behave sanely for actual users.
Click to expand...

Does this fix the same issue as discussed in this topic?
K

Future fix Post in thread 'Google tries to crawl links from style variation chooser menu'

A less invasive option:

style_variation_macros

Code: 
<xf:macro name="variation_menu_item"
    arg-routeType="public"
    arg-route="{{ link('misc/style-variation') }}"
    arg-variation="!"
    arg-icon="fa-adjust"
    arg-label=""
    arg-selectedVariation="{$xf.visitor.style_variation}"
    arg-live="{{ false }}"
    arg-redirect="{{ null }}">

    <xf:set var="$tag" value="{{ $live ? 'span' : 'a' }}" />

    <{$tag} class="menu-linkRow {{ $variation === $selectedVariation ? 'is-selected' : '' }}"
        {{ !$live ? 'href="' . link_type($routeType, $route, null, {...
  • Like
 
Hi Xon,

I think I may have found a small issue in SV\StandardLib\Helper::getEntityStructure().

Currently the method looks like this:

PHP: 
$class = \XF::stringToClass($entityName, '%s\Entity%s');

try
{
if (@!class_exists($class))
{
return null;
}

return \XF::em()->getEntityStructure($entityName);

}
catch (\Throwable $e)
{
return null;
}

The problem is that XF::stringToClass() itself can throw an InvalidArgumentException if the supplied string does not match the expected formatter.

Because this call is outside the try block, the exception escapes before the intended error handling can run.

In my case, SignupAbuseBlocking iterates over all registered entity content type fields:

PHP: 
foreach ($app->getContentTypeField('entity') AS $contentType => $entityName)
{
$structure = Helper::getEntityStructure($entityName);

if ($structure === null)
{
    continue;
}

...
}

One of my installed add-ons (PainBaker's PostAsUser) registers:

Code: 
content_type: pb_pau_original_poster
field_name: entity
field_value: PB\PostAsUser\OriginalPoster

Whether this registration is intentional or not is beside the point. The important part is that Helper::getEntityStructure() already appears to be designed to ignore unsupported or invalid registrations and simply return null:

PHP: 
// detect invalid content type+entity configuration

However, because XF::stringToClass() is executed before entering the try block, it throws:

Code: 
InvalidArgumentException:
Class PB\PostAsUser\OriginalPoster does not match formatter pattern %s\Entity%s

As a result, the entire Spam Options page fails instead of simply skipping that content type.

Wouldn't it make sense to move the stringToClass() call into the existing try block?

PHP: 
try
{
$class = \XF::stringToClass($entityName, '%s\Entity%s');

if (@!class_exists($class))
{
    return null;
}

return \XF::em()->getEntityStructure($entityName);
}
catch (\Throwable $e)
{
return null;
}

This would preserve the current behaviour of returning null for unsupported registrations while also handling InvalidArgumentException from stringToClass().

If the entity registration from the other add-on is considered invalid, that's perfectly fine—it can simply be ignored. The important point is that enumerating content types in the ACP should not fail because of a single unsupported registration.

Thanks!
 
That will be fixed for the next version, I'm working on some final testing and should be released in a day or 3
 
Hi Xon,

I have encountered an issue related to cookie handling in XenForo 2.3.10 that appears to be caused by your "Standard Library" add‑on (versions 1.24 and later).

When the cookie consent is set to the "extended" mode and a user clicks the "Accept all cookies" button, the resulting URL becomes:
/misc/cookies?update=1&accept=1
but the expected URL should contain a security hash parameter, for example:
/misc/cookies?update=1&accept=1&t=1785656915%2Cb9720ad24b3779ffd44c4ee9b328cd92
The hash is missing, which breaks the consent process – after clicking the button, the user is redirected to a "Redirect" page with a "Proceed" button, and after clicking that they are taken to the homepage, but the consent is not properly recorded.
Снимок экрана 2026-08-02 224844.webpСнимок экрана 2026-08-02 225208.webp
To reproduce the issue, do the following:
  1. Enable the "extended" cookie consent mode. The problem occurs only in this display mode.
  2. Force an update of the privacy policy or terms agreement using these links:
    /admin.php?force-agreement/privacy-policy
    /admin.php?force-agreement/terms
  3. Visit as a guest. Click the "Accept all cookies" button in the cookie notice.
Actual result:
The button URL lacks the hash parameter, and the consent process does not complete correctly (you get an intermediate page where consent is not finalised and requires clicking a button that sends you to the homepage). This should not happen.
  • With version 1.23.9 (and earlier), everything works fine.
  • With versions 1.24.0 and above, the problem appears immediately.
I have already tried the workaround of enabling debug mode and resetting the "privacy-policy" and "terms" fields to 0 via admin.php?options/groups/debug/ – this did not resolve the issue.

Apparently, there was an official bug regarding the handling of policy and terms agreements in these settings, and it was fixed in XF 2.2.9, but your add‑on seems to trigger this bug again.

I kindly ask you to review this and take appropriate action. Of course, I could switch to the "simple" display mode and the problem would disappear, but that is not a solution.

Could you please check how your library affects the generation of the cookie consent URL (specifically the hash parameter)? It seems that something in the library (starting from version 1.24) modifies or removes the hash, possibly due to a change in the way requests or URLs are processed.

Please note that such a page (/misc/cookies?update=1&accept=1) does not officially exist in XenForo, and these operations simply cannot be performed by the core software. This means that only your add‑on creates these conditions – for what reason, I do not understand.
1785701914761.webp

As I see, you have already addressed the cookie-related issue, but you seem to have overlooked the link to the mandatory policy and consent refresh in XF, as I pointed out earlier.
X

Post in thread 'Standard Library by Xon'

Xon updated Standard Library by Xon with a new update entry:

1.24.3 - Bugfix update

  • Fix advanced cookie concent form didn't work as expected when redirecting from GET to POST links
  • Fix possible javascript error in link-post.js on XF2.2
Click to expand...

Read the rest of this update entry...
  • Like

I checked every version from 1.24 onward, and each one has a hash processing error. If I disable the plugin, everything works fine. If I install 1.23.9, everything also works fine. Of course, if you don't force the policy and consent update, then there are no issues with versions 1.24 and above. However, the fact that it breaks the official XF tool is not good.

On version 1.24.4, the issue persists.
 
Last edited:
Because of all these issues that are being discussed, I'm using version 1.23.9. I assume there's no problem with that (in terms of security, bugs, etc.).
 
@Sado Yasashii Using ChatGPT (or similar) to generate a plausible but very wrong explanation is actively harmful to communicating what errors or issues you are experiencing.

XF2.3 has always redirected after accepting/rejecting the cookies, and my changes are to remove the token out of the GET link and then use javascript to push the token to php. There is a php side change to add the interstate page.

If a interstate page is being shown, this can happen if the user is disabling javascript or if http referrer policy are set to no-referrer. They will experience the same issues with XF2.4 as it is planning the same changes.

:edit: By default; XF2.3 doesn't actually white list the advanced cookie consent form if you force a terms/privacy policy update, it just silently breaks. It offers functionality to white list those routes but that isn't populated by default or during any XF upgrade

Mike S said:
Because of all these issues that are being discussed, I'm using version 1.23.9. I assume there's no problem with that (in terms of security, bugs, etc.).
Click to expand...
Please actually test it on an XF2.3 site. While there where some early issues they have been resolved.
 
Last edited:
Xon said:
Using ChatGPT (or similar) to generate a plausible but very wrong explanation is actively harmful to communicating what errors or issues you are experiencing.
Click to expand...
I won't hide the fact that I skipped the text for translation through DeepSeek to make it clearer to you, but it seems that the explanation may have misled you in some way.

However, the error itself is real. I understand that the hash disappears after updating the privacy policy and consent in the XF console, and it doesn't appear in the extended cookies form because you have changed the processing of the GET link, which uses JS from the browser instead of the URL. Thus, after updating the policy/consent, I encountered the issue mentioned above. However, I am unsure of what to do in this situation. Can you provide guidance on how to proceed?
 
After testing with XF2.3.12 & XF2.3.10; updating the privacy policy and accepting the cookie consent works fine together. That is accepting cookie consent works even on the accept privacy policy update screen.

The interstate landing page is expected if the accept/reject cookie consent form is opened via a GET http action (ie new tab) or the javascript is blocked. This is intended behavior, and XF2.4 will implement the same functionality.
 
Xon updated Standard Library by Xon with a new update entry:

1.24.5 - Maintenance & Bugfix update

  • Fix unexpected recursion causing a stack overflow when add-on cache data is rebuilt
  • Harden post-link.js to avoid infinite redirect due to a WAF security check redirecting back to the same page (aka cloudflare security checks)
  • Update choices.js
    • More reliably trigger iOS virtual keyboard in all cases
    • Fix arrow-key navigation did not start from the selected choice when no choice is currently highlighted
  • Harden...
Click to expand...

Read the rest of this update entry...
 
Getting an enormous amount of errors after installing this version:

Code: 
Template error: [E_USER_WARNING] Function is_toggle_set is unknown

Stack trace

#0 [internal function]: XF\Template\Templater->handleTemplateError(512, '[E_USER_WARNING...', '/home/nginx/dom...', 1215)
#1 src/XF/Template/Templater.php(1215): trigger_error('Function is_tog...', 512)
#2 internal_data/code_cache/templates/l2/s28/public/svESE_macros.php(39): XF\Template\Templater->func('is_toggle_set', Array, false)
#3 src/XF/Template/Templater.php(933): XF\Template\Templater->{closure:internal_data/code_cache/templates/l2/s28/public/svESE_macros.php:12}(Object(DigitalPoint\Cloudflare\XF\Template\Templater), Array, NULL)
#4 internal_data/code_cache/templates/l2/s28/public/svElasticSearchEssentials_widget_similar_threads.php(7): XF\Template\Templater->callMacro('svESE_macros', 'similar_threads', Array, Array)
#5 src/XF/Template/Templater.php(1818): XF\Template\Templater->{closure:internal_data/code_cache/templates/l2/s28/public/svElasticSearchEssentials_widget_similar_threads.php:4}(Object(DigitalPoint\Cloudflare\XF\Template\Templater), Array, NULL)
#6 src/addons/MaZ/AUN/XF/Template/Templater.php(39): XF\Template\Templater->renderTemplate('svElasticSearch...', Array, true, NULL)
#7 src/XF/Widget/WidgetRenderer.php(62): MaZ\AUN\XF\Template\Templater->renderTemplate('public:svElasti...', Array)
#8 src/XF/Widget/WidgetRenderer.php(67): XF\Widget\WidgetRenderer->render()
#9 src/XF/Template/Templater.php(2164): XF\Widget\WidgetRenderer->__toString()
#10 internal_data/code_cache/templates/l2/s28/public/thread_view.php(1166): XF\Template\Templater->widgetPosition('sv_thread_view_...', Array)
#11 src/XF/Template/Templater.php(1818): XF\Template\Templater->{closure:internal_data/code_cache/templates/l2/s28/public/thread_view.php:639}(Object(DigitalPoint\Cloudflare\XF\Template\Templater), Array, Object(XF\Template\ExtensionSet))
#12 src/addons/MaZ/AUN/XF/Template/Templater.php(39): XF\Template\Templater->renderTemplate('thread_view', Array, true, NULL)
#13 src/XF/Template/Template.php(24): MaZ\AUN\XF\Template\Templater->renderTemplate('public:thread_v...', Array)
#14 src/XF/Mvc/Renderer/Html.php(50): XF\Template\Template->render()
#15 src/XF/Mvc/Dispatcher.php(473): XF\Mvc\Renderer\Html->renderView('XF:Thread\\View', 'public:thread_v...', Array)
#16 src/XF/Mvc/Dispatcher.php(455): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Html), Object(XF\Mvc\Reply\View))
#17 src/XF/Mvc/Dispatcher.php(414): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Html), Object(XF\Mvc\Reply\View))
#18 src/XF/Mvc/Dispatcher.php(66): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'html')
#19 src/XF/App.php(2830): XF\Mvc\Dispatcher->run()
#20 src/XF.php(850): XF\App->run()
#21 index.php(23): XF::runApp('XF\\Pub\\App')
#22 {main}

Request state

array(4) {
  ["url"] => string(23) "/threads/carbon.174389/"
  ["referrer"] => bool(false)
  ["_GET"] => array(1) {
    ["/threads/carbon_174389/"] => string(0) ""
  }
  ["_POST"] => array(0) {
  }
}

Code: 
ErrorException: [E_WARNING] Undefined array key "addon"
src/addons/SV/StandardLib/XF/Template/Templater.php:53
Generated by: Unknown account
Aug 3, 2026 at 5:25 PM

Stack trace

#0 src/addons/SV/StandardLib/XF/Template/Templater.php(53): XF::handlePhpError(2, '[E_WARNING] Und...', '/home/nginx/dom...', 53)
#1 src/addons/XenAddons/Showcase/Listener/ControllerPostDispatch.php(37): SV\StandardLib\XF\Template\Templater->includeJs(Array)
#2 src/XF/Extension.php(54): XenAddons\Showcase\Listener\ControllerPostDispatch::listen(Object(XF\Pub\Controller\IndexController), 'Index', Object(XF\Mvc\ParameterBag), Object(XF\Mvc\Reply\Reroute))
#3 src/XF/App.php(3372): XF\Extension->fire('controller_post...', Array, 'XF\\Pub\\Controll...')
#4 src/XF/Mvc/Controller.php(390): XF\App->fire('controller_post...', Array, 'XF\\Pub\\Controll...')
#5 src/XF/Mvc/Dispatcher.php(397): XF\Mvc\Controller->postDispatch('Index', Object(XF\Mvc\ParameterBag), Object(XF\Mvc\Reply\Reroute))
#6 src/XF/Mvc/Dispatcher.php(266): XF\Mvc\Dispatcher->dispatchClass('XF:Index', 'Index', Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\IndexController), NULL)
#7 src/XF/Mvc/Dispatcher.php(121): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XF\Pub\Controller\IndexController), NULL)
#8 src/XF/Mvc/Dispatcher.php(63): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#9 src/XF/App.php(2830): XF\Mvc\Dispatcher->run()
#10 src/XF.php(850): XF\App->run()
#11 index.php(23): XF::runApp('XF\\Pub\\App')
#12 {main}

Request state

array(4) {
  ["url"] => string(1) "/"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}
 
Since updating to version 1.24.5, I've been getting the following message in the log.

Code: 
Server-Fehlerprotokoll

    ErrorException: [E_WARNING] Undefined array key "src" src/addons/SV/StandardLib/XF/Template/Templater.php:54

    Generiert von: Unbekanntes Benutzerkonto 03. Aug. 2026 um 20:05

Stack-Trace

#0 src/addons/SV/StandardLib/XF/Template/Templater.php(54): XF::handlePhpError(2, '[E_WARNING] Und...', '/var/www/vhosts...', 54)
#1 src/addons/SV/LazyImageLoader/Helper.php(100): SV\StandardLib\XF\Template\Templater->includeJs(Array)
#2 src/addons/SV/LazyImageLoader/XF/BbCode/Renderer/Html.php(87): SV\LazyImageLoader\Helper->enqueueJs()
#3 src/XF/BbCode/Renderer/Html.php(785): SV\LazyImageLoader\XF\BbCode\Renderer\Html->getRenderedImg('http://s14.dire...', 'http://s14.dire...', Array)
#4 src/addons/SV/LazyImageLoader/XF/BbCode/Renderer/Html.php(55): XF\BbCode\Renderer\Html->renderTagImage(Array, NULL, Array, Array)
#5 src/XF/BbCode/Renderer/Html.php(357): SV\LazyImageLoader\XF\BbCode\Renderer\Html->renderTagImage(Array, NULL, Array, Array, Object(SV\LazyImageLoader\XF\BbCode\Renderer\Html))
#6 src/XF/BbCode/Traverser.php(63): XF\BbCode\Renderer\Html->renderTag(Array, Array)
#7 src/XF/BbCode/Renderer/Html.php(1500): XF\BbCode\Traverser->renderSubTree(Array, Array)
#8 src/addons/SV/ThreadSEO/XF/BbCode/Renderer/Html.php(219): XF\BbCode\Renderer\Html->renderTagUrl(Array, 'http://www.dire...', Array, Array)
#9 src/XF/BbCode/Renderer/Html.php(357): SV\ThreadSEO\XF\BbCode\Renderer\Html->renderTagUrl(Array, 'http://www.dire...', Array, Array, Object(SV\LazyImageLoader\XF\BbCode\Renderer\Html))
#10 src/XF/BbCode/Traverser.php(63): XF\BbCode\Renderer\Html->renderTag(Array, Array)
#11 src/XF/BbCode/Renderer/Html.php(500): XF\BbCode\Traverser->renderSubTree(Array, Array)
#12 src/XF/BbCode/Renderer/Html.php(357): XF\BbCode\Renderer\Html->renderTagAlign(Array, NULL, Array, Array, Object(SV\LazyImageLoader\XF\BbCode\Renderer\Html))
#13 src/XF/BbCode/Traverser.php(63): XF\BbCode\Renderer\Html->renderTag(Array, Array)
#14 src/XF/BbCode/Traverser.php(39): XF\BbCode\Traverser->renderSubTree(Array, Array)
#15 src/addons/SV/ThreadSEO/XF/BbCode/Renderer/Html.php(50): XF\BbCode\Traverser->renderAst(Array, Object(SV\ThreadSEO\XF\BbCode\RuleSet), Array)
#16 src/XF/BbCode/Traverser.php(22): SV\ThreadSEO\XF\BbCode\Renderer\Html->renderAst(Array, Object(SV\ThreadSEO\XF\BbCode\RuleSet), Array)
#17 src/XF/Pub/View/FeedHelper.php(135): XF\BbCode\Traverser->render('[CENTER]
[B]And...', Object(XF\BbCode\Parser), Object(SV\ThreadSEO\XF\BbCode\RuleSet), Array)
#18 src/XF/Pub/View/Forum/Rss.php(72): XF\Pub\View\FeedHelper::setupEntryForThread(Object(Laminas\Feed\Writer\Entry), Object(SV\SearchImprovements\XF\Entity\ThreadCollab))
#19 src/XF/Pub/View/Forum/Rss.php(31): XF\Pub\View\Forum\Rss->createEntry(Object(Laminas\Feed\Writer\Feed), Object(SV\SearchImprovements\XF\Entity\ThreadCollab), 'last_post_date')
#20 src/addons/SV/ThreadSEO/XF/Pub/View/Forum/Rss.php(16): XF\Pub\View\Forum\Rss->renderRss()
#21 src/XF/Mvc/Renderer/AbstractRenderer.php(92): SV\ThreadSEO\XF\Pub\View\Forum\Rss->renderRss()
#22 src/XF/Mvc/Renderer/Xml.php(72): XF\Mvc\Renderer\AbstractRenderer->renderViewObject('XF:Forum\\Rss', '', Array)
#23 src/XF/Mvc/Dispatcher.php(473): XF\Mvc\Renderer\Xml->renderView('XF:Forum\\Rss', '', Array)
#24 src/XF/Mvc/Dispatcher.php(455): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Rss), Object(XF\Mvc\Reply\View))
#25 src/XF/Mvc/Dispatcher.php(414): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Rss), Object(XF\Mvc\Reply\View))
#26 src/XF/Mvc/Dispatcher.php(66): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'rss')
#27 src/XF/App.php(2830): XF\Mvc\Dispatcher->run()
#28 src/XF.php(850): XF\App->run()
#29 index.php(23): XF::runApp('XF\\Pub\\App')
#30 {main}

Status der Anfrage

array(4) {
  ["url"] => string(41) "/bereich/biete-mobile-stuff.359/index.rss"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}
 
You must log in or register to reply here.

Similar threads

Brais
Spanish Translation: Standard Library
Replies
0
Views
5
Brais
Brais
chocodz
Closed Standard Library
Replies
1
Views
451
chocodz
chocodz
D
Standard Library by Xon - FRENCH translation [Deleted]
Replies
3
Views
528
Ozzy47
Ozzy47
Back
Top Bottom