Page MenuHomePhabricator

Anonymous users editing a page do not trigger Cargo to update a table.
Closed, InvalidPublic

Description

I am investigating an issue where a null page edit is required to force Cargo to update a table. I have been unable to reproduce it until now.

If a logged in user creates or edits a page with #cargo_store the corresponding Cargo table is updated as expected.

When an anonymous logged out user does the same the corresponding Cargo is not updated and requires a logged in user to null edit the page to force the update. I have been looking through the code, but I am not seeing any user based checks that would appear to cause this.

This is example is where I reproduce it. https://futuramaworldsoftomorrow.gamepedia.com/ClassCargoTest

Event Timeline

Alexia created this task.Jan 31 2018, 8:05 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 31 2018, 8:05 PM

I can't replicate this problem. Does this happen every time? And does it happen with regular page edits, or form edits, or both?

(I've heard of such a problem happening with bot edits, but not with regular anonymous edits. Though I can't replicate the bot edits problem either.)

Changes using the source code editor have not been updating the cargo since about November. Visual edits (edit link not edit source link) save to the cargo fine. Since most users make changes via the source code editor, we have been running a recreate on the tables every few days as a workaround.

It may not be related, but table rows have also been getting duplicated somehow. More difficult to reproduce since we don't know what triggers it. Thought would mention on off chance it is a byproduct.

Thanks in advance for helping us figure this one out. It has been driving us nuts!

Alexia added a comment.Feb 1 2018, 8:02 AM

Regular page edits through the standard source editor are what cause this behavior.

I am going to setup a brand new wiki this morning and test only with Cargo enabled. I am wandering if there is a third party extension that might be interfering.

Alexia added a comment.Feb 1 2018, 4:14 PM

Morning update: I have found that the hook "PageContentSaveComplete" is not being ran or being interrupted somehow. The onPageContentSaveComplete function in Cargo never gets called.

Alexia closed this task as Invalid.Feb 1 2018, 4:26 PM

I found the issue. Another extension was throwing an exception for logged out users that was causing this issue for Cargo. However, due to an exception handling change in MediaWiki 1.29 those kind of exceptions were quietly being dropped and MediaWiki would go on pretending everything was fine.

Aha! That's a great discovery. I wonder if the same thing is occurring for the people having a problem with bot edits.

Is this other extension public, or one of your proprietary ones? (If it's public, I'd like to know which it is.)

Alexia added a comment.Feb 1 2018, 4:39 PM

Proprietary - Extension:Social

This was the entire change. Basically it had not been updated for MediaWiki's newer API for atomic database transactions.

diff --git a/extensions/Social/classes/socialPrompt.php b/extensions/Social/classes/socialPrompt.php
index 8bfe8da20..2df5bc035 100644
--- a/extensions/Social/classes/socialPrompt.php
+++ b/extensions/Social/classes/socialPrompt.php
@@ -115,7 +115,6 @@ class socialPrompt {
                 __METHOD__
             );
         }
-        $this->DB->commit(__METHOD__, 'flush');
 
         return true;
     }

Okay, very interesting. (Calling DB->close() might work here too, but I'm not sure.)

Alexia added a comment.Feb 1 2018, 7:03 PM

Many years ago there were several third party extensions that had a habit of opening new database transactions, but never closing them. So as a work around in several of Hydra's own extensions we put $db->commit() in place to fix them breaking transactions.