Minimal test code:
mw.hook( 'postEdit' ).add( function() {
console.log( mw.config.get( 'wgPostEdit' ) );
} );This returns null in both VE and the 2017 wikitext editor.
Description
Description
Details
Details
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | BUG REPORT | Daimona | T316726 Can't close Registration popup on arabic wikipedia | ||
| Open | None | T240041 wgPostEdit is not set/updated after editing with VE or 2017 wikitext editor |
Event Timeline
Comment Actions
Leaving to the team to triage. Please see https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities
Comment Actions
Hello @ppelberg! The Campaigns team is interested in this ticket and was wondering if it could potentially be added to the Editing team's backlog? Basically, for our new event registration tool (see documentation), we have a feature where a pop-up appears after someone creates an event page in the event namespace (which asks if the user wants to enable registration on the page). I have attached a screenshot example below. This feature currently works if the user is creating an event page with the source editor. However, the pop-up does not appear if they create the event page with VE. From our understanding, the reason why is due to the work outlined in this ticket. In that case, do you think it would be possible for the Editing team to take on this work any time soon? Thank you in advance!
BTW, you can test the event registration feature on the beta cluster. It is not yet released to any live wikis, but we are planning to release to our first live wiki (Meta-wiki) around October. Also, we *do* have a work-around for users (the button to 'enable registration' is still displayed at the top of the page), but we would ideally like this fixed, if possible.
Example of correct behavior when an event page was created with source editor:
No pop-up displayed if event page created with VE:
Comment Actions
Thank you for the ping, @ifried and for making it easy for me to understand and experience the issue you are describing for myself.
I'll talk this over with the Editing Team engineers and report back here with what work we think would be involved with fixing this and when we might be able to take on said work.
Comment Actions
We don't set wgPostEdit (that could probably be adding to jsconfigvars in ApiVisualEditorEdit.php), but when we fire the postEdit hook, the target still exists, so you can check if it's a new page by looking at ve.init.target.pageExists.
https://www.mediawiki.org/wiki/Manual:Interface/JavaScript#wgPostEdit can also be restored but I don't think you're interested in that...
Comment Actions
Actually that won't work for page creations because we redirect setting venotify. We can set wgPostEdit when that happens though, based on venotify...
Comment Actions
Change 823653 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget: Set wgPostEdit when redirecting after save
Comment Actions
The above patch partially resolves this issue by setting wgPostEdit when redirecting after save. As VE always redirects after save when creating a new page this should be sufficient for your use case @ifried, however wgPostEdit is still not set after edits to existing pages, so we should leave this task open.
Comment Actions
Change 823653 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget: Set wgPostEdit when redirecting after save
Comment Actions
Could this fix have caused T316726? The postEdit hook is now fired twice, which for event pages results in an unresponsive popup, and for ordinary pages in a double "Your edit was published" notification on page creation.
Comment Actions
Hello @ppelberg, sorry to bug you on this again :) It looks like a bug appeared that is related to this ticket (see comment above). If the team could take a look when they get a chance, that would be great, and feel free to reach out if you have any questions. Thanks in advance!
Comment Actions
Change 833453 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/extensions/VisualEditor@master] Follow-up Ieba322fd: Don't generate postedit notification now we set config var
Comment Actions
The above patch fixes the double-firing issue, don't know if this fixes T316726 but should be easy enough to test.
Comment Actions
Change 833453 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Follow-up Ieba322fd: Don't generate postedit notification now we set config var
Comment Actions
Change 997277 had a related patch set uploaded (by Bartosz Dziewoński; author: Esanders):
[mediawiki/extensions/VisualEditor@REL1_39] Follow-up Ieba322fd: Don't generate postedit notification now we set config var
Comment Actions
Change 997277 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@REL1_39] Follow-up Ieba322fd: Don't generate postedit notification now we set config var
Comment Actions
@ppelberg: Hi, all related patches in Gerrit have been merged. Can this task be resolved (via Add Action... → Change Status in the dropdown menu), or is there more to do in this task? Asking as you are set as task assignee. Thanks in advance!
Comment Actions
@ppelberg: Removing task assignee as this open task has been assigned for more than two years - See the email sent to task assignee on October 11th.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!