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

bzcomputers

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


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

Well-known member
Change the line:
PHP:
if ($app->container('app.classType') !== 'Pub')
to
PHP:
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

Well-known member
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

Well-known member
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.
 
Top