Resource icon

[AL] Core Package 1.8.8

No permission to download
Overview Updates (44) History Discussion
AddonsLab updated [AL] Core Package with a new update entry:

Mobile detection library and template conditional supports

This version adds the library Mobile_Detect and adds variables available in all templates to detect if the current page is viewed on a mobile/tablet device:

Code: 
<xf:if is="$xf.isMobileBrowser">
    Visitor is using a tablet or a phone.
    <xf:if is="$xf.isTabletBrowser">
      Visitor is using a tablet.
    <xf:else />
      Visitor is using a phone.
    </xf:if>
  <xf:else />
    Visitor is using a computer/non-mobile device.
</xf:if>
Click to expand...

Read the rest of this update entry...
 
AddonsLab said:
AddonsLab updated [AL] Core Package with a new update entry:

Bug-fix in class extension tweak



Read the rest of this update entry...
Click to expand...
There is another bug.

When extending \XF\Extension class, the XF\Mvc\Entity\Manager caches a copy in a local variable. This is used when resolving XF's Repositories/Finders/Entities.

If another app_setup function runs before [AL] Core, and touches any of that core XF functionality, it will result in random "Cannot declare class XXX, because the name is already in use" error messages.

The non-public variable that is cached in the \XF\Mvc\Entity\Manager class needs to be updated. Replacing this class isn't doable as it is cached freaking everywhere. Code something like this:
PHP: 
$container['extension'] = ... ;
if ($container->isCached('em'))
{
    $em = $container['em'];
    $setter = \Closure::bind(function ($value) {
        /** @var \XF\Mvc\Entity\Manager $this */
        $this->extension = $value;
    }, $em, \get_class($em));
    $setter($container['extension']);
}
 
Xon said:
There is another bug.

When extending \XF\Extension class, the XF\Mvc\Entity\Manager caches a copy in a local variable. This is used when resolving XF's Repositories/Finders/Entities.

If another app_setup function runs before [AL] Core, and touches any of that core XF functionality, it will result in random "Cannot declare class XXX, because the name is already in use" error messages.

The non-public variable that is cached in the \XF\Mvc\Entity\Manager class needs to be updated. Replacing this class isn't doable as it is cached freaking everywhere. Code something like this:
PHP: 
$container['extension'] = ... ;
if ($container->isCached('em'))
{
    $em = $container['em'];
    $setter = \Closure::bind(function ($value) {
        /** @var \XF\Mvc\Entity\Manager $this */
        $this->extension = $value;
    }, $em, \get_class($em));
    $setter($container['extension']);
}
Click to expand...

@Xon thanks for the report. As you have noticed, I am doing the extension to somehow overcome the problem of the same add-on requiring the same class to be extended differently for XenForo 2.1.x and 2.2.x. The approach I took works by using aliases and correcting the class names in the Extension class, but I see it's too dangerous and likely to break at some point anyway, even if I resolve the problems known now. I found this discussion you participate in - https://xenforo.com/community/threa...ort-both-xf2-1-and-xf2-2.191210/#post-1499056 and your solution to the problem, which is similar to mine, but I see you managed to solve it without extending the Extension class by adding a second alias for the proxy class.

I have implemented a similar solution in my package (with credits to your code), so we can avoid extending the Extension class and get rid of all the problems:

PHP: 
<?php

namespace AL\Core;

/**
 * Class alias fixing loading of different classes for different versions of XF.
 * The solution is inspired by @Xon library at https://github.com/Xon/XenForo2-StandardLib/blob/7040b59d2b4e826fe3abe7e5071ed3796b5d304b/upload/src/addons/SV/StandardLib/Repository/Helper.php#L196
 */
class ClassAlias
{
    public static function registerVersionAlias($defaultClass)
    {
        $className = 'XF21';
        if (\XF::$versionId >= 2020000)
        {
            $className = 'XF22';
        }

        $versionClass = explode('\\', $defaultClass);
        $lastComponent = array_pop($versionClass);
        $versionClass[] = $className;
        $versionClass[] = $lastComponent;

        $versionClass = implode('\\', $versionClass);

        self::register($versionClass, $defaultClass);
    }

    public static function register($versionClass, $defaultClass)
    {
        class_alias($versionClass, $defaultClass);

        // Register an alias for the XFCP_ prefixed version to the default class
        class_alias(self::getProxyName($defaultClass), self::getProxyName($versionClass), false);
    }

    public static function getProxyName($class)
    {
        $classComponents = explode('\\', $class);
        $lastComponent = array_pop($classComponents);
        $classComponents[] = 'XFCP_' . $lastComponent;
        return implode('\\', $classComponents);
    }
}

The fix will be released soon.

Thanks again for your help!
 
AddonsLab updated [AL] Core Package with a new update entry:

Class extension system fix

The update applies a definitive fix for the class extension hack, based on suggestions from @Xon.

The update is backward-compatible with our add-ons, so applying the update will keep the current hack active, however, once you have upgraded other our add-ons to the latest versions (new versions of all Filter add-ons will be released within 24 hours to support the new system), you can disable the hack by unchecking the option Legacy Class Extension Hack in...
Click to expand...

Read the rest of this update entry...
 
You must log in or register to reply here.
Top Bottom