XF 2.2 Cannot declare class ...because the name is already in use in src/XF/Extension.php at line 171

[bzcomputers]

I've got this error popping up on my Resource Manage pages after I recently updated an add-on...

Ads Manager 2 by Siropu [Paid]

Siropu updated Ads Manager 2 by Siropu with a new update entry: Got a repeating error on all Resource pages making them unusable after this latest update...

xenforo.com

The full error is: ErrorException: [E_WARNING] Cannot declare class Siropu\AdsManager\XFRM\Pub\Controller\XFCP_ResourceItem, because the name is already in use in src/XF/Extension.php at line 171.

Further looking into it the error and the XenForo file referenced src/XF/Extension.php at line 171. When going to that location, in extension.php, I do see notations in the XenForo file saying "// TODO: there may be a situation where this fails. If we've changed the extensions after classes have
// been loaded, it's possible these classes will already be loaded with a different config. Figure out
// how to handle that if possible. Remains to be seen if it comes up (mostly relating to add-on imports)."

I've had to completely disable my Resource Manager now (been over 2 weeks on a live site) since the error began occurring. Yes, I reported the issue to the add-on author and also opened a ticket with XenForo but at this point I haven't gotten any solutions or suggestions. Just putting this out there to get a few more eyes on it and see if someone else with a little more XenForo programming knowledge than me might be able to point me in the right direction to getting this fixed. Thanks.

 

[PaulB]

Change the line:

if ($app->container('app.classType') !== 'Pub')

to

if (\XF::app()->container('app.classType') !== 'Pub')

Shouldn’t it be $c['app.classType']? I’m on my phone at the moment, but I’ll verify in a bit.

Will this also affect cron jobs? While that’s probably desirable in most cases, it could have unintended consequences for some add-ons, so it’s worth noting.

With all that being said, it’s increasingly sounding as though this is an issue with MariaDB itself, not XenForo’s handling of replication.

 

[Xon]

Shouldn’t it be $c['app.classType']? I’m on my phone at the moment, but I’ll verify in a bit.

This would work, but they end up being the same thing anyway. (I need to poke at \XF::app() in other parts of my config.php anyway)

Will this also affect cron jobs? While that’s probably desirable in most cases, it could have unintended consequences for some add-ons, so it’s worth noting.

Cron-jobs dispatched via job.php will have the public app-type, so this should work as expected for normal users.

With all that being said, it’s increasingly sounding as though this is an issue with MariaDB itself, not XenForo’s handling of replication.

I would say this is an inconsistent transaction handling issue, as the select & update statements are potentially different servers.

 

[PaulB]

This would work, but they end up being the same thing anyway.

I think there are some circumstances in which calling \XF::app() from config.php can have unexpected side effects, so it's probably better to encourage people to use $c unless they have a specific reason to use \XF::app().

I would say this is an inconsistent transaction handling issue, as the select & update statements are potentially different servers.

Nothing XenForo does should ever be able to cause a corrupt table, though.

 

[VersoBit]

so it's probably better to encourage people to use $c unless they have a specific reason to use \XF::app().

There’s a lot of things that are still missing from XF’s documentation. This would be one of those things if that’s the case.