Resource icon

Standard Library by Xon 1.24.11

No permission to download
Overview Updates (91) Reviews (5) History Discussion
The patch to make \XF::options() return the expected types for some of my add-on's isn't reliably working after updating SV/StandardLib. I'm investigating but it is kinda yuck to troubleshoot :(

The workaround is to rebuild any other add-on after updating SV/StandardLib
 
Since updating to the latest version (was previously on 1.24.4), it seems like we're having a conflict between this addon and AndyB's Style Chooser Manager. With both enabled, while we could switch to specific styles, if we tried to select "use default style" the style chooser would load up a new page that's as if the popup is enclosed in the normal page container, and does not actually change the style. Links on this new page also don't work, just reloading the same page.

Confirmed the compatibility issue by disabling all addons depending on the Standard Library (issue remained), then disabling the Standard Library (issue resolved). In the reverse, disabling the Style Chooser Manager while keeping the Standard Library and all addons that relied on it gave us a working (unsorted) Style Chooser.
 
Xon said:
@Bulbagarden can you open a ticket on my site? It is definitely possible there is some conflicts, and I can work on resolving them on my site but I'll need to ask a few questions.
Click to expand...
Can do shortly. I've just been talking with AndyB, and they think they've found a fix at their end, so I'm going to try that first.

EDIT: Fix has been confirmed at AndyB's end.
 
  • Like
Reactions: Xon
After installing Standard Library (as a dependency for Thread SEO changes), a new title showed up in GA4: "Redirecting" --> now 43% of all recorded pageviews. It maps to svStandardLib_redirect_interstitial.


Since the interstitial renders inside PAGE_CONTAINER, it inherits everything embedded there. On our site that means Google Tag Manager and the Mediavine ad loader both fire on a page no human ever sees. Two consequences for ad-supported sites: analytics get skewed, and ad impressions are served on a page that is never viewed, which drags down viewability, a direct CPM input.


I can work around it with a $template check, but that means depending on the internal template name.


Would it be possible to render the interstitial outside PAGE_CONTAINER, or expose a variable like $svIsInterstitial? The page is noindex and auto-submits immediately, so it doesn't really need site chrome.


Not a bug (i guess) it works as designed. Just easy to miss, and likely affects every ad-supported site using the library.
 
This will likely effect the XF implementation too, so I'll flag it for them.

The best way is to add svStandardLib_redirect_interstitial to Prevent ads showing in these templates (aka adsDisallowedTemplates) option.

Note, you can access the template name in PAGE_CONTAINER via the existing $template variable
 
Thanks. For sites loading ad scripts directly in PAGE_CONTAINER (rather than through XF's ad system), adsDisallowedTemplates doesn't apply — the $template check is the way. Working here with:



Code: 
html
<xf:if is="!$xf.visitor.user_id AND $template != 'svStandardLib_redirect_interstitial'">


Also worth noting: the analytics side is a separate issue. GTM fires on the interstitial too, which skewed our pageview counts significantly before we excluded it the same way.
 
This breaks Xenforo2.1.15 An exception occurred: [Error] Access to undeclared static property: XF\Http\Request::$googleCloudIps in src/addons/SV/StandardLib/fake_composer/shim/RequestKnownIps.php on line 1057

FYI, its not for my site, the Admin doesnt want to update for some reason, I tried 1.18.2 as well
 
Last edited:
Xon said:
Xon updated Standard Library by Xon with a new update entry:

1.24.9



Read the rest of this update entry...
Click to expand...

XF v2.2.19 Patch 2
Standard Library by Xon I tried to update the plugin to version 1.24.9
I wanted to update the plugin, but...

Code: 
ErrorException: [E_WARNING] DOMDocument::loadXML(): Empty string supplied as input in src/XF/Util/Xml.php at line 43

    XF::handlePhpError()
    DOMDocument->loadXML() in src/XF/Util/Xml.php at line 43
    XF\Util\Xml::open() in src/XF/Util/Xml.php at line 22
    XF\Util\Xml::openFile() in src/XF/AddOn/DataType/AbstractDataType.php at line 60
    XF\AddOn\DataType\AbstractDataType->openTypeFile() in src/XF/Job/AddOnData.php at line 60
    XF\Job\AddOnData->run() in src/XF/Job/Manager.php at line 260
    XF\Job\Manager->runJobInternal() in src/XF/Job/Manager.php at line 202
    XF\Job\Manager->runJobEntry() in src/XF/Job/Manager.php at line 118
    XF\Job\Manager->runByIds() in src/XF/Admin/Controller/Tools.php at line 122
    XF\Admin\Controller\Tools->actionRunJob() in src/XF/Mvc/Dispatcher.php at line 352
    XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 259
    XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 115
    XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 57
    XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2523
    XF\App->run() in src/XF.php at line 524
    XF::runApp() in admin.php at line 13
 
None of this add-on's XML files in the src/addons/SV/StandardLib/_data directory are empty. The stack trace should have some basic arguments, and without those I can't really tell you what it was failing on.

All I can suggest is to manually delete the contents of src/addons/SV/StandardLib/_data and then re-upload the add-on's files.
 
Last edited:
Xon said:
None of this add-on's XML files in the src/addons/SV/StandardLib/_data directory are empty. The stack trace should have some basic arguments, and without those I can't really tell you what it was failing on.

All I can suggest is to manually delete the contents of src/addons/SV/StandardLib/_data and then re-upload the add-on's files.
Click to expand...

Updated the plugin. It was probably just a temporary glitch. :)
 
  • Like
Reactions: Xon
@Xon please check a possible issue with numeric add-on requirements

After installing a required add-on, another add-on may still report that the dependency is missing

It looks like the newly installed add-on is present in addon.cache but is temporarily missing from addon.versionCache

isVersionValid() checks the version string cache before handling a numeric version_id

SV\StandardLib\Repository\AddOnRepository.php:

Code: 
            /** @var ?string $installedVersionString */
            $installedVersionString = $existingAddOnsVersionStrings[$productKey] ?? null;
            if ($installedVersionString === null)
            {
                return [false, false];
            }
possbile fix:

PHP: 
 /** @var ?string $installedVersionString */
$installedVersionId = $existingAddOnVersionIds[$productKey] ?? null;

if (strpos($version, '.') === false && is_numeric($version))
{
    return [
        $installedVersionId !== null,
        $installedVersionId !== null && $installedVersionId >= (int) $version
    ];
}



A little deeper research:
  1. XF creates the add-on record with active = 1 but temporarily sets is_processing = 1.
  2. SV\StandardLib\XF\AddOn\DataManager calls rebuildAddOnVersionCache() and excludes add-ons currently being processed:
WHERE active = 1 AND is_processing = 0
  1. As a result add-on is not added to addon.versionCache while the main addon.cache already contains it
  1. Standard Library’s validator requires the dependency to be present in both places:
    the numeric version_id cache and the string-based addon.versionCache

    This causes the dependency check to fail
 
Last edited:
This add-on rebuilds the addon.versionCache blob just before the addon.version blob is updated.

If you updated StandardLib at the same time, what could be happening is the xf_addon.is_processing flag is rendering the add-on into a partial zombie state when updating SV/StandardLib add-on and other add-ons in the same web request.

How are you triggering this? The stock CLI installer can't trigger this, and the web installer should do a web request per stage of updating an addon which should force every add-on into a seperate web request
 
Last edited:
Xon said:
This add-on rebuilds the addon.versionCache blob just before the addon.version blob is updated. The version check code itself is fine.

This probably is happening due to the is_processing flag is rendering the add-on into a partial zombie state when updating SV/StandardLib add-on and other add-ons in the same web request.

How are you triggering this? The stock CLI installer can't trigger this, and the web installer should do a web request per stage of updating an addon which should force every add-on into a seperate web request
Click to expand...

In my case it was
  • Install add-on A without any dependencies
  • Install add-on B
  • Upload an update for add-on A that now requires add-on B
  • The upload fails with a missing dependency error, even though add-on B is already installed and enabled
 
Painbaker said:
XF creates the add-on record with active = 1 but temporarily sets is_processing = 1.
Click to expand...
I hate the is_processing flag so much. When this flag is cleared it should trigger a rebuild of the addon.versionCache.

Bet it is a stupid race condition :(
 
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