EntityBase.php:266

Issue Tools
- View Changes

3 Weeks Ago 7:42 AM

wolven

New Member

ErrorException: [E_WARNING] call_user_func_array() expects parameter 1 to be a valid callback, class 'vw_DM_Comment_Controller' does not have a method 'where' src/addons/vw/vw/XF/Entity/EntityBase.php:266

Upgrade 4.1.4 to 4.1.4 breaks a different add on

Hi pegasus,
New bug encountered: Upgrade 4.1.4 -> 4.1.5 ran smooth. Installing a different add-on generates this messages:

#0 [internal function]: XF::handlePhpError(2, '[E_WARNING] cal...', '/var/www/vhosts...', 266, Array)
#1 src/addons/vw/vw/XF/Entity/EntityBase.php(266): call_user_func_array(Array, Array)
#2 src/addons/SV/ContentRatings/Job/ContentRatingData.php(89): vw\vw\XF\Entity\EntityBase->__call('where', Array)
#3 src/XF/Job/Manager.php(260): SV\ContentRatings\Job\ContentRatingData->run(7.96987)
#4 src/XF/Job/Manager.php(202): XF\Job\Manager->runJobInternal(Array, 7.96987)
#5 src/XF/Job/Manager.php(86): XF\Job\Manager->runJobEntry(Array, 7.96987)
#6 src/XF/Admin/Controller/Tools.php(141): XF\Job\Manager->runQueue(true, 8)
#7 src/XF/Mvc/Dispatcher.php(352): XF\Admin\Controller\Tools->actionRunJob(Object(XF\Mvc\ParameterBag))
#8 src/XF/Mvc/Dispatcher.php(259): XF\Mvc\Dispatcher->dispatchClass('XF:Tools', 'RunJob', Object(XF\Mvc\RouteMatch), Object(XF\Admin\Controller\Tools), NULL)
#9 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XF\Admin\Controller\Tools), NULL)
#10 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#11 src/XF/App.php(2353): XF\Mvc\Dispatcher->run()
#12 src/XF.php(524): XF\App->run()
#13 admin.php(13): XF::runApp('XF\\Admin\\App')
#14 {main}

Please advice
Cheers Knut

Issue Details

Issue Number 6303

Issue Type Bug

Project VaultWiki 4.x Series

Category Admin Panel

Status Not a Bug

Priority 4 - Warnings / Script Errors

Affected Version 4.1.4

Fixed Version (none)

Milestone (none)

Software DependencyXenForo 2.x

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags bug

2 Weeks Ago 11:47 AM

pegasus

VaultWiki Team

It seems like there is a bug in SV ContentRatings. I can't see the code, but judging from the error it is calling ::where on an Entity, when XenForo's base Entity class does not have a ::where method. I suspect it intends to call ::where on a Finder but somewhere along the way it uses the wrong object.

Reply
2 Weeks Ago 4:01 AM

wolven

New Member

ok fair. I will ask them.
I don't understand the error messages refers to vw_DM_Controller doesn' have a method "where". So I thought this function might have the problem.

Cheers

Reply
2 Weeks Ago 7:56 AM

wolven

New Member

I'v got answer from Content rating developer. Here it is:

Basically; this occurs if the entity content type field is a full class path instead of the expected short entity format.

I'm kinda surprised this hasn't triggered XF bugs as a pile of the code assumes the use of short-class names for the entity content type field.

He basically meant some of your functions disrespect the format. He made an adapted version of his add-on. You might consider to change yours accordingly.

The relevant code he refers to is:

PHP Code:

$reactHandler = $reactionRepo->getReactionHandler($contentType, false, $isLike); if (!$reactHandler) { return $this->complete(); } try { $entityName = $this->app->getContentTypeEntity($contentType, false); $structure = $this->app->em()->getEntityStructure($entityName); } catch(\Exception $e) { \XF::logException($e, true, 'Broken reaction implementation for content-type; ' . $contentType); return $this->complete(); } if ($isLike && empty($structure->relations['Likes']) || !$isLike && empty($structure->relations['Reactions'])) { // unknown relationship return $this->complete(); } $primaryKey = $structure->primaryKey; if (\is_array($primaryKey) && \count($primaryKey) === 1) { $primaryKey = \reset($primaryKey); } if (\is_array($primaryKey)) { // only a singular primary key is supported return $this->complete(); } $finder = $this->app->em()->getFinder($entityName, false); if (\is_array($this->data['ids'])) { if (!$this->data['ids']) { return $this->complete(); } $finder->whereId($this->data['ids']); } $batchEnd = $this->data['start'] + $this->data['batch']; $finder->where($primaryKey, '>', $this->data['start']) ->where($primaryKey, '<', $batchEnd) ->limit($this->data['batch']) ->order($primaryKey)

Reply
2 Weeks Ago 11:20 AM

pegasus

VaultWiki Team

I found one case of XenForo using the entityName in getFinder as the shortName, which is in the basic search handler. We never had a problem here, since VaultWiki uses a custom search handler anyway.

However, it seems this one usage is inconsistent with other XenForo code. In most other places, XenForo uses the entityId (from getContentTypeFieldValue) to get the entity $structure. And then gets the entity $shortName which is a property of the $structure. getFinder expects the $shortName.

I don't really see a way to fix this on our end without namespacing all the classes, and without completely upending VaultWiki's own add-on system. This would entail a full rewrite of all of VaultWiki, which would probably take years, and prevent new development in other areas during that time. I don't feel this is worth it when the only issue is 1 known add-on conflict with an add-on that doesn't get used with VaultWiki anyway (VaultWiki already has content ratings that should be more accurate averages and are tightly linked with various other aspects of the software).

You have to remember that much of the underlying architecture of VaultWiki was written in 2010, long before anyone knew what XenForo 2's code would look like. We later redesigned a lot of core logic in VaultWiki to be more like XenForo 2 rather than other forum softwares or versions, but it was never fully rewritten. XenForo 2's add-on architecture (handler classes, class extensions, etc) has allowed VaultWiki to use a lot of pre-XenForo 2 code without significant rewrites, because we can define how XenForo 2 interacts with the VaultWiki codebase.

I have said it before, and I still feel SV Content Ratings is disrespecting XenForo's add-on format by automatically assuming that other add-ons should be using their ratings, and automatically assuming code/data patterns for those add-ons, without respecting existing content-type handlers for those add-ons, and without respecting the XenForo standard of requiring an add-on to provide its own content-type handler class. That is, VaultWiki should be the one required to provide a handler class for SV Content Ratings, and if one is not provided, then SV Content Ratings should just ignore VaultWiki -- SV Content Ratings should not be assuming what the handler class would be like.

Reply

+ Reply

All times are GMT -4. The time now is 6:24 AM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: ErrorException: [E_WARNING] call_user_func_array() expects parameter 1 to be a valid callback, class 'vw_DM_Comment_Controller' does not have a method 'where' src/addons/vw/vw/XF/Entity/EntityBase.php:266

Issue Tools