Issue: [4.1 Beta 4] 1) Wiki pages are erroneously awaiting moderation after upgrade, 2) Undefined method when changing page moderation status via ?do=moderate

Issue Tools
- View Changes

October 13, 2019 2:51 PM

ACL

Regular Member

[4.1 Beta 4] 1) Wiki pages are erroneously awaiting moderation after upgrade, 2) Undefined method when changing page moderation status via ?do=moderate

1) After upgrading my offline test site from VW4.1 Beta 3 b003 to Beta 4 b001... All previously published wiki pages are erroneously awaiting moderation. There are no new entries in the XF approval queue.

----

2) When trying to change the moderation status of a single page to "Approve" (via Options -> Change approval status), an undefined method is encountered. However, closing the error and refreshing the page does reveal that the page approval state did change and is no longer pending moderation.
Call to undefined method XF\Logger::log() in src/addons/vw/vw/_core/model/modlog/xf2.php at line 59

Code:

vw_ModLog_Model_XF2->mod_add() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 219
vw_UI_iMod_Action_Approve_Controller->process_approve_generic() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 164
vw_UI_iMod_Action_Approve_Controller->perform_doapprove() in src/addons/vw/vw/_core/controller/ui/imod/action/base/vw.php at line 91
vw_UI_iMod_Action_base_Controller->process() in src/addons/vw/vw/Handler/InlineMod/Base/AbstractAction.php at line 183
vw\vw\Handler\InlineMod\Base\AbstractAction->applyToEntity() in src/XF/InlineMod/AbstractAction.php at line 87
XF\InlineMod\AbstractAction->applyInternal() in src/XF/InlineMod/AbstractAction.php at line 80
XF\InlineMod\AbstractAction->apply() in src/XF/Pub/Controller/InlineMod.php at line 131
XF\Pub\Controller\InlineMod->actionPerform() in src/addons/vw/vw/XF/Pub/Controller/InlineMod.php at line 41
vw\vw\XF\Pub\Controller\InlineMod->actionPerform() in src/XF/Mvc/Dispatcher.php at line 321
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 244
XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 100
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 50
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2178
XF\App->run() in src/XF.php at line 390
XF::runApp() in index.php at line 20

Sending the page back into the moderation queue triggers the same undefined method error but with a slightly different stack trace. Despite the error, an approval queue item is created. Approving the wiki page from the approval queue does not trigger any undefined method error.

Code:

vw_ModLog_Model_XF2->mod_add() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 219
vw_UI_iMod_Action_Approve_Controller->process_approve_generic() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 164
vw_UI_iMod_Action_Approve_Controller->perform_doapprove() in src/addons/vw/vw/_core/controller/ui/imod/action/base/vw.php at line 91
vw_UI_iMod_Action_base_Controller->process() in src/addons/vw/vw/Handler/InlineMod/Base/AbstractAction.php at line 183
vw\vw\Handler\InlineMod\Base\AbstractAction->applyToEntity() in src/XF/InlineMod/AbstractAction.php at line 87
XF\InlineMod\AbstractAction->applyInternal() in src/XF/InlineMod/AbstractAction.php at line 80
XF\InlineMod\AbstractAction->apply() in src/XF/Pub/Controller/InlineMod.php at line 131
XF\Pub\Controller\InlineMod->actionPerform() in src/addons/vw/vw/XF/Pub/Controller/InlineMod.php at line 41
vw\vw\XF\Pub\Controller\InlineMod->actionPerform() in src/XF/Mvc/Dispatcher.php at line 321
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 244
XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 100
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 50
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2178
XF\App->run() in src/XF.php at line 390
XF::runApp() in index.php at line 20

Issue Details

Issue Number 5894

Issue Type Bug

Project VaultWiki 4.x Series

Category Install / Upgrade

Status Fixed

Priority 3 - Loss of Functionality

Affected Version 4.1.0 Beta 4

Fixed Version 4.1.0 Beta 4

Milestone (none)

Software DependencyXenForo 2.x

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 1

Assigned Users (none)

Tags (none)

October 13, 2019 5:06 PM
pegasus

VaultWiki Team
1) Fixed the following in the next build:
- Automatic moderation state changes don't create an entry in the approval queue, making it harder to find the moderated items.

However, I can state that the description of all pages becoming moderated is incorrect, as I have upgraded 3 XF2 sites and this was not the case. On one site I had only 2 pages that were automatically moderated.

The Beta 4 process aims to correct an issue from all previous versions of VaultWiki: it was possible to create a publicly visible page where the current edit of the page was actually still waiting for approval, was soft-deleted, or was denied approval. For such pages, there are a number of potential problems, including that users should not be able to view something that wasn't approved.

The Beta 4 upgrade script locates all such affected pages and sends them back to the approval queue.

Normally this was only possible when performing rare rollbacks or purges which involved unapproved target edits.
But under XenForo 2 and Beta 2-3, it was easier to get pages like this, due to integration with XenForo's spam checker, which was sending the first edit of a page to the moderation queue rather than the page itself, if it met the spam criteria.

So the pages now being moderated is working as designed.

I recognize the missing approval-queue entries will make them harder to find. I suppose we are in need of a new special page for listing content of various approval states. In the mean time, the following query should give you the titles of pages needing approval:

Code:

SELECT r.titlekey, p.visible FROM vw_page AS p LEFT JOIN vw_nodetype AS t ON (t.accesskey = 'Page') LEFT JOIN vw_route AS r ON (p.pageid = r.itemid AND r.itemtypeid = t.`id`) WHERE p.visible != 1

visible = 0 is awaiting approval, 2 = rejected, 3 = soft-deleted

2) Fixed in the next build. In src/addons/vw/vw/_core/model/modlog/xf.php, find:

Code:

XF::app()->logger->log

Replace with:

Code:

XF::app()->logger()->moderatorLogger()->log
Reply
October 14, 2019 2:28 AM
ACL

Regular Member
Originally Posted by pegasus

However, I can state that the description of all pages becoming moderated is incorrect, as I have upgraded 3 XF2 sites and this was not the case. On one site I had only 2 pages that were automatically moderated.

The Beta 4 process aims to correct an issue from all previous versions of VaultWiki: it was possible to create a publicly visible page where the current edit of the page was actually still waiting for approval, was soft-deleted, or was denied approval.
[...]
under XenForo 2 and Beta 2-3, it was easier to get pages like this, due to integration with XenForo's spam checker, which was sending the first edit of a page to the moderation queue rather than the page itself, if it met the spam criteria.

I see. I experienced the mass changing of page status back to pending moderated on my offline test site. Within this environment, just about all of these pages have only ever been edited by an administrator level account with the following relevant permissions:

Are edits to the wiki index NOT moderated?: Yes
Are new attachments NOT moderated? Yes
Are edits to attachments NOT moderated? Yes
Are new wiki pages NOT moderated? Yes
Are edits to wiki pages NOT moderated? Yes
Are new Categories NOT moderated? Yes

In case it is of relevance, the XF permission "Bypass spam check" is set to No.

As an administrator, I've looked through the page lists for each Area and every item that wasn't already soft-deleted is showing in the structured item list as pending moderation. The exceptions are two pages that I have since changed the moderation status of myself (via Options -> Change approval status), and Area main pages. For example:

Attachment 1702

Originally Posted by pegasus

I recognize the missing approval-queue entries will make them harder to find. I suppose we are in need of a new special page for listing content of various approval states.

In theory, inline moderation mass-approving would be an easy solution for manually going through and 're-approving' the affected pages.

4.1 Beta 4 b002 reveals another issue when attempting to change the moderation status of pages inline. The method vw\vw\Handler\ModeratorLog\Page::getActionPhraseName is reported as not being compatible with the parent class.

ErrorException: [E_WARNING] Declaration of vw\vw\Handler\ModeratorLog\Page::getActionPhraseName(vw\v w\Handler\ModeratorLog\ModeratorLog $log) should be compatible with vw\vw\Handler\ModeratorLog\base::getActionPhraseName(XF\E ntity\ModeratorLog $log) in src/addons/vw/vw/Handler/ModeratorLog/Page.php at line 17

Code:

XF::handlePhpError() in src/addons/vw/vw/Handler/ModeratorLog/Page.php at line 17 include() in src/vendor/composer/ClassLoader.php at line 444 Composer\Autoload\includeFile() in src/vendor/composer/ClassLoader.php at line 322 Composer\Autoload\ClassLoader->loadClass() spl_autoload_call() class_exists() in src/XF/ModeratorLog/Logger.php at line 192 XF\ModeratorLog\Logger->handler() in src/XF/ModeratorLog/Logger.php at line 121 XF\ModeratorLog\Logger->log() in src/addons/vw/vw/_core/model/modlog/xf2.php at line 59 vw_ModLog_Model_XF2->mod_add() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 219 vw_UI_iMod_Action_Approve_Controller->process_approve_generic() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 164 vw_UI_iMod_Action_Approve_Controller->perform_doapprove() in src/addons/vw/vw/_core/controller/ui/imod/action/base/vw.php at line 91 vw_UI_iMod_Action_base_Controller->process() in src/addons/vw/vw/Handler/InlineMod/Base/AbstractAction.php at line 183 vw\vw\Handler\InlineMod\Base\AbstractAction->applyToEntity() in src/XF/InlineMod/AbstractAction.php at line 87 XF\InlineMod\AbstractAction->applyInternal() in src/XF/InlineMod/AbstractAction.php at line 80 XF\InlineMod\AbstractAction->apply() in src/XF/Pub/Controller/InlineMod.php at line 131 XF\Pub\Controller\InlineMod->actionPerform() in src/addons/vw/vw/XF/Pub/Controller/InlineMod.php at line 41 vw\vw\XF\Pub\Controller\InlineMod->actionPerform() in src/XF/Mvc/Dispatcher.php at line 321 XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 244 XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 100 XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 50 XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2178 XF\App->run() in src/XF.php at line 390 XF::runApp() in index.php at line 20
Reply
October 14, 2019 10:43 AM
pegasus

VaultWiki Team
Fixed the moderator log compatibility error in the current build.

In the current build patched the following, which was caused by a typo in the upgrade script (where the letter e was used instead of a p):

- The 4.1.0 Beta 4 upgrade script approved all non-public edits (changing all awaiting approval, rejected, and soft-deleted to approved). For each one approved in this way, it changed the page visibility of up to 1000 likely-unrelated pages to match the old visibility state of the changed edit, starting from the first page in the database (the index). It looks like that the more edits you have matching the old visibility state <= the number your server can process in 10 seconds (to a max of 1000), the fewer pages will likely be affected (for each page, every matching edit is re-processed). So basically, as long as all matching edits could be processed in 10 seconds, then the number of pages affected by the bug would be equal to the number of times the server could re-process those all those same edits again in a loop (+1 page). Since you had a large number of pages affected, you likely had a small number of non-public edits.

On the site where I found that only 2 pages were affected, I had a modest number of matching edits, but it is more likely that I only noticed 2 pages. Since the site has a large number of areas, I will have to go through using the database method I mentioned and check the affected pages (looks to be closer to 20 on that site).

I am glad we caught this issue before too many people performed the upgrade.

For users with very large numbers of pages affected before the patch, rather than manually approving the pages, they may want to simply approve all pages, then worry about re-deleting spammy ones later.
- In MySQL, run the following query:

Code:

UPDATE vw_page SET visible = 1

After doing this, use your forum software's built-in tools to rebuild the search index for wiki pages.
Some counters would be wrong, but this may be an acceptable tradeoff depending on the work of performing all the inline moderation actions.
Reply
October 14, 2019 11:36 AM
ACL

Regular Member
Thanks for looking at this again and making further changes.

I have downloaded a new copy of Beta 4 b002 and have a new issue when using inline moderation. This time, when attempting to approve pages:
XenForo reports that two mandatory values are missing from the ModeratorLog entity:
Please enter a value for the required field 'discussion_content_type'.
Please enter a value for the required field 'discussion_content_id'.

When attempting to unapprove pages:
Call to undefined method vw_UI_iMod_Action_Approve_Controller:rocess_doapprove() in src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php at line 133

Code:

vw_UI_iMod_Action_Approve_Controller->perform_dounapprove() in src/addons/vw/vw/_core/controller/ui/imod/action/base/vw.php at line 91 vw_UI_iMod_Action_base_Controller->process() in src/addons/vw/vw/Handler/InlineMod/Base/AbstractAction.php at line 183 vw\vw\Handler\InlineMod\Base\AbstractAction->applyToEntity() in src/XF/InlineMod/AbstractAction.php at line 87 XF\InlineMod\AbstractAction->applyInternal() in src/XF/InlineMod/AbstractAction.php at line 80 XF\InlineMod\AbstractAction->apply() in src/XF/Pub/Controller/InlineMod.php at line 131 XF\Pub\Controller\InlineMod->actionPerform() in src/addons/vw/vw/XF/Pub/Controller/InlineMod.php at line 41 vw\vw\XF\Pub\Controller\InlineMod->actionPerform() in src/XF/Mvc/Dispatcher.php at line 321 XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 244 XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 100 XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 50 XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2178 XF\App->run() in src/XF.php at line 390 XF::runApp() in index.php at line 20

Originally Posted by pegasus

I am glad we caught this issue before too many people performed the upgrade.

Me too . Fortunately in my case, the 'damage' (if you can call it that) is confined to a test site that I don't care about. Current plans are that my public site will shortly migrate to XF2.1 with VW Beta 3 b003, and we'll remain on that build for at least the next 2 months during an anticipated high traffic period. Newer builds could still be tried elsewhere (e.g. separate test site) during this time.
Reply
October 14, 2019 11:43 AM
pegasus

VaultWiki Team
In src/addons/vw/vw/Handler/ModeratorLog/base.php, find:

Code:

$log->content_url = $urlinfo['url'];

AFTER it, add:

Code:

$log->discussion_content_type = $this->contentType; $log->discussion_content_id = $urlinfo['itemid'];

EDIT: In src/addons/vw/vw/_core/controller/ui/imod/action/approve/vw.php, find:

Code:

return $this->process_doapprove();

Replace with:

Code:

return $this->perform_doapprove();
Reply
October 14, 2019 12:30 PM

ACL

Regular Member

I've applied the above changes to the two files mentioned and that seems to have fixed it, thanks .

Mass-approving and unapproving pages from the Area list has identified an area for improvement, though. Once the selected pages have been approved/unapproved, I get redirected either to the changed wiki page (if only one page was selected) or the wiki index (if more than one page was selected). Ideally, it would make more sense (and match XF behaviour) for the return path to be whatever page the inline moderation action was made from. For instance, if I'm currently viewing the "Wiki Pages" Area and I submit an inline moderation action on that page, I should be returned to the "Wiki Pages" area again. This could be further enhanced by not just returning me to the area, but the exact place that the inline moderation action was submitted from, such as Page 3 of 'View all pages'.

Do you want me to move this to a new issue for easier tracking?

Reply
October 14, 2019 1:56 PM

pegasus

VaultWiki Team

This looks like a bug. Inline moderation is supposed to redirect back to the list-page that it was submitted from. It seems like the correct page is not being passed in XenForo environments.

Reply
October 16, 2019 11:51 AM

ACL

Regular Member

Originally Posted by pegasus

In the current build patched the following, which was caused by a typo in the upgrade script (where the letter e was used instead of a p):

- The 4.1.0 Beta 4 upgrade script approved all non-public edits (changing all awaiting approval, rejected, and soft-deleted to approved). For each one approved in this way, it changed the page visibility of up to 1000 likely-unrelated pages to match the old visibility state of the changed edit, starting from the first page in the database (the index).

Good news. Today I upgraded my online testing site from VW4.1 Beta 3 b002 to Beta 4 b002 and didn't come across any problems of pages falling back into a moderated state. This particular wiki only contains about 20 pages (all from an admin account). The next step will be to repeat the upgrade with a copy of my live site (of somewhere around 800 odd pages, with a mix of admin and non-admin edits).

Reply
January 7, 2020 11:43 PM

pegasus

VaultWiki Team

List-page inline moderation redirects should be fixed under XenForo 2 in the next release.

Reply

+ Reply

All times are GMT -4. The time now is 7:42 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: [4.1 Beta 4] 1) Wiki pages are erroneously awaiting moderation after upgrade, 2) Undefined method when changing page moderation status via ?do=moderate

Issue Tools