Change 668193 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Only show reply buttons if user can edit the page

https://gerrit.wikimedia.org/r/668193

The patch above proposes hiding the reply links if the user can't edit the page. We should discuss with @iamjessklein and @ppelberg what this means for the UX.

@Esanders / @matmarex:, can y'all confirm: Beyond someone who is logged out landing on a talk page that is protected, who – if anyone – else would be impacted by the decision we are making in this task?

⚠️ Note: the questions below can be disregarded for now. Reason: I suspect I misinterpreted the scope of this change and would like to make sure I understand it clearly before purusing the below...

Questions

• 1. Does the below accurately and exhaustively describe what people who are logged out *currently* see/experience when viewing a page that is protected? [i]
  • Article page
    • People will see the article content WITHOUT any edit affordances being visible. Read: no section [ edit ] links and no Edit tabs atop the page.
  • Talk page
    • What people can see and interact with on a talk page is NOT impacted by the protection level of the content page to which the talk page is related.
• 2. @matmarex, what is leading you to propose hiding [ reply ] links? I ask this question considering the following:
  • Protecting talk pages goes against convention at some wikis, and perhaps many others. [ii][iii][iv]
  • Few pages in the talk namespace seem to be protected at the wikis I checked:
    • ar.wiki: 5 talk pages are protected. See: https://w.wiki/357K.
    • jv.wiki: 0 talk pages are protected. See: https://w.wiki/357M.
    • zh.wiki: 6 talk pages are protected: See: https://w.wiki/357N
    • en.wiki: <500 talk pages are protected: See: https://w.wiki/357P.
  • Being able to talk on the talk page of a protected page (a mouthful!) seems like an important way for people to suggest edits to a page they cannot directly edit.

i. Example of a protected page: https://en.wikipedia.org/wiki/Barack_Obama
ii. Talk pages are not usually protected, and are semi-protected only for a limited duration in the most severe cases of vandalism. | en:Wikipedia:Protection_policy#Article_talk_pages
iii. Discussion pages are generally unsecured except in some exceptional circumstance. (English via Google Translate) | ru:Wikipedia: Partial page protection
iv. An administrator can completely block a banned user discussion page if that page, the only page that the member has the ability to edit, is being continuously mis-modified. (English via Google Translate) | vi: Wikipedia: Provisions for page locking

The same logic would apply to blocked users, so it's not just protected talk pages.

If a contributor is logged out we should provide on-page messaging telling them to log in order to engage in the conversation.

Option 1: Show reply links but have them disabled but provide a message to the Contributor explaining why and how to log in.
Option 2: Don't show reply links but have a general message on the page explaining why and how to log in.

My preference is Option 1 because it provides contextual guidance to the contributor.

Conversation with @Esanders:

Ed thinks that this is a duplicate issue to T270803

There are a few complications:

1. There are a few reasons why someone might not be able to reply (not being logged in, protected page, user banned)

Proposed Solution:

• Reply link (and future button) is enabled, before we draw anything on the page we draw a modal
• Modal options:
  • message with login prompt for logged out users
  • call to action where they can learn more about why they were blocked and links to contest it, something similar to:

• message with a lock for protected content

Note: this is not ideal, because it happens after the user clicks the link/button but it's better than having absolutely no indicator.

2. Pages could be made up of multiple pages (transcluded sections) so you might be able to edit the subpage but not the first page in that cluster.

Proposed Solution: Do the same as the solution above, however, the tradeoff with this is that because of the nested nature of the replies, some links within a cluster could have different access levels (and so for each reply link we have the different messages).

So in a nutshell, we can't do Option 2 from T276393#6917560 (no links but banner message), but we can do Option 1 (show links but with lots of special situation handling).

In T276393#6921475, @iamjessklein wrote:

Conversation with @Esanders:
So in a nutshell, we can't do Option 2 from T276393#6917560 (no links but banner message), but we can do Option 1 (show links but with lots of special situation handling).

@iamjessklein, the context you and @Esanders shared is helpful and leading me to think that for now we ought to hide the [ reply] links entirely for people who have been blocked from editing Wikipedia and for people who are logged out and are viewing a talk page that's been protected.

Here is what's leading me to propose hiding [ reply ] links in these scnearios:

1. I think we can assume that it is unlikely for a Junior Contributor seeking to make good faith edits will find themselves in either of the scenarios the decision we are making here will have an impact on. See Question 2 in T276393#6899170.
2. I think the likelihood of someone landing on a protected page that contains conversations transcluded from unprotected pages is low enough for us not to design for it.
3. Considering "1." I do not think it is worth going through the effort of showing [ reply ] links and implementing the special modal handling that would be required for people to understand why the [ reply ] links are not functional.

• @Esanders / @iamjessklein: please comment if you think there are issue with what I'm proposing above.

Note: I recognize that moving forward with hiding the [ reply ] links we would be defying the Requirements I put forth in T276393#6907279. I think that's okay considering the above.

I think the likelihood of someone landing on a protected page that contains conversations transcluded from unprotected pages is low enough for us not to design for it.

I don't know if we can say what the likelihood of this happening is for blocked users, especially now we have partial blocks.

Considering "1." I do not think it is worth going through the effort of showing [ reply ] links and implementing the special modal handling that would be required for people to understand why the [ reply ] links are not functional.

Leaving the links in and showing the error message is probably the easiest solution at this point, as it what we have implemented already for cases when the reply tool doesn't work due to complex templates.

We can keep the modal's simple and just show a text message "... because you are blocked" or "... because this page is protected" in the first iteration.

In T276393#6925840, @Esanders wrote:

Considering "1." I do not think it is worth going through the effort of showing [ reply ] links and implementing the special modal handling that would be required for people to understand why the [ reply ] links are not functional.

Leaving the links in and showing the error message is probably the easiest solution at this point, as it what we have implemented already for cases when the reply tool doesn't work due to complex templates.

We can keep the modal's simple and just show a text message "... because you are blocked" or "... because this page is protected" in the first iteration.

What @Esanders is proposing sounds like a good first step. I've updated the task description with these implementation details.

In T276393#6923803, @ppelberg wrote:

2. I think the likelihood of someone landing on a protected page that contains conversations transcluded from unprotected pages is low enough for us not to design for it.

I think it’s worth noting that nothing prevents this from happening the other way round, that is, the main page is not protected, but the transcluded page is. For example I recently came across a wiki (unfortunately I don’t remember which) where old request pages (requests for rights, as far as I remember) are protected. If these requests are transcluded for a short time after being closed, comments within these transcluded parts cannot be replied to, while eventual comments on the main page can. Probably this is also rare, but not impossible either.

That should be fine as well.

Change 668193 abandoned by Bartosz Dziewoński:
[mediawiki/extensions/DiscussionTools@master] Only show reply buttons if user can edit the page

Reason:

https://gerrit.wikimedia.org/r/668193

Change 674658 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Check if you can edit the page before opening the tools

https://gerrit.wikimedia.org/r/674658

I set up a demo wiki for testing: https://patchdemo.wmflabs.org/wikis/a8da9c890a/. Instructions:

• Log in as: [with password 'patchdemo1']
  • Alice (who is an administrator) [edit: I forgot to make this user an administrator, fixed now]
  • Bob (who is a normal user)
  • Mallory (who is blocked)
• Test on pages:
  • Protected discussion
  • Normal discussion
  • Protected board (which transcludes the two "discussion" pages)
  • Normal board (which transcludes the two "discussion" pages)
• Try both tools:
  • Reply tool
  • New topic tool

Example error messages (same as the ones shown in wikitext editor):

Note that the error messages on Wikimedia wikis are going to look different, since many wikis customized them (especially the large ones).

Note also that they mention editing pages, rather than adding replies or new topics. I think this is acceptable, but more importantly, I think we should not try to customize them because that's going to conflict with each wiki's customizations. If we made custom error messages, they would probably never be adjusted to link to each wiki's protection or unblocking policy etc., and even if we worked with the communities to do that, they would inevitably drift away over time and become outdated.

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/1c60f714e1/w/

Test wiki on Patch Demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/1c60f714e1/w/

Change 674658 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Check if you can edit the page before opening the tools

https://gerrit.wikimedia.org/r/674658

I logged in as Mallory, and https://patchdemo.wmflabs.org/wikis/a8da9c890a/w/index.php?title=Talk:Normal_board&action=edit gives me:

[5db0d179a84316700496fd73] /wikis/a8da9c890a/w/index.php?title=Talk:Normal_board&action=edit RuntimeException: SFS IP file contents and file md5 do not match!

Backtrace:

from /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(222)
#0 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(86): MediaWiki\StopForumSpam\DenyListUpdate::fetchDenyListIPsRemote()
#1 /srv/patchdemo-wikis/a8da9c890a/w/includes/libs/objectcache/wancache/WANObjectCache.php(1600): MediaWiki\StopForumSpam\DenyListUpdate::MediaWiki\StopForumSpam\{closure}(boolean, integer, array, NULL, array)
#2 /srv/patchdemo-wikis/a8da9c890a/w/includes/libs/objectcache/wancache/WANObjectCache.php(1432): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array, array)
#3 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(90): WANObjectCache->getWithSetCallback(string, integer, Closure, array)
#4 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListUpdate.php(44): MediaWiki\StopForumSpam\DenyListUpdate::loadDenyListIPs()
#5 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/DenyListManager.php(67): MediaWiki\StopForumSpam\DenyListUpdate->doUpdate()
#6 /srv/patchdemo-wikis/a8da9c890a/w/extensions/StopForumSpam/includes/Hooks.php(142): MediaWiki\StopForumSpam\DenyListManager::isDenyListed(string)
#7 /srv/patchdemo-wikis/a8da9c890a/w/includes/HookContainer/HookContainer.php(330): MediaWiki\StopForumSpam\Hooks::onGetUserPermissionsErrorsExpensive(Title, User, string, string)
#8 /srv/patchdemo-wikis/a8da9c890a/w/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#9 /srv/patchdemo-wikis/a8da9c890a/w/includes/HookContainer/HookRunner.php(2037): MediaWiki\HookContainer\HookContainer->run(string, array)
#10 /srv/patchdemo-wikis/a8da9c890a/w/includes/Permissions/PermissionManager.php(507): MediaWiki\HookContainer\HookRunner->onGetUserPermissionsErrorsExpensive(Title, User, string, string)
#11 /srv/patchdemo-wikis/a8da9c890a/w/includes/Permissions/PermissionManager.php(457): MediaWiki\Permissions\PermissionManager->checkPermissionHooks(string, User, array, string, boolean, Title)
#12 /srv/patchdemo-wikis/a8da9c890a/w/includes/Permissions/PermissionManager.php(307): MediaWiki\Permissions\PermissionManager->getPermissionErrorsInternal(string, User, Title, string)
#13 /srv/patchdemo-wikis/a8da9c890a/w/includes/EditPage.php(736): MediaWiki\Permissions\PermissionManager->getPermissionErrors(string, User, Title, string)
#14 /srv/patchdemo-wikis/a8da9c890a/w/includes/EditPage.php(598): EditPage->getEditPermissionErrors(string)
#15 /srv/patchdemo-wikis/a8da9c890a/w/includes/actions/EditAction.php(71): EditPage->edit()
#16 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(531): EditAction->show()
#17 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(315): MediaWiki->performAction(Article, Title)
#18 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(913): MediaWiki->performRequest()
#19 /srv/patchdemo-wikis/a8da9c890a/w/includes/MediaWiki.php(546): MediaWiki->main()
#20 /srv/patchdemo-wikis/a8da9c890a/w/index.php(53): MediaWiki->run()
#21 /srv/patchdemo-wikis/a8da9c890a/w/index.php(46): wfIndexMain()
#22 {main}

(I first tried clicking on a [reply] link on the page, and I got the same error message, but without stack trace and without mentioning that it’s a RuntimeException.) I’m pretty sure that’s not how it’s supposed to work. 🙂

On Talk:Normal_discussion I managed to get the block message, and it actually consists of (permissionserrorstext-withaction: 1, (action-edit)) (the same goes for protected page message). If you change it to (permissionserrorstext-withaction: 1, (action-reply)) (and define the action-reply message), it will use the correct term in vanilla MediaWiki, and probably most Wikimedia wikis as well, unless permissionserrorstext-withaction is customized in a very unusual way (e.g. with a {{#switch: for all possible values of parameter $2). Is there a way to list all customized versions of a given MediaWiki message across Wikimedia?

I saw that as well, but it seems to have disappeared by itself now… It must be a problem with either the StopForumSpam extension (not currently enabled on Wikimedia wikis, but I was asked to add it to Patchdemo for testing), or with Patchdemo itself, and not with the changes from this task. Anyway, I disabled the extension on that demo wiki just in case, to make sure everyone can test this.

In T276393#6951820, @Tacsipacsi wrote:

On Talk:Normal_discussion I managed to get the block message, and it actually consists of (permissionserrorstext-withaction: 1, (action-edit)) (the same goes for protected page message). If you change it to (permissionserrorstext-withaction: 1, (action-reply)) (and define the action-reply message), it will use the correct term in vanilla MediaWiki, and probably most Wikimedia wikis as well, unless permissionserrorstext-withaction is customized in a very unusual way (e.g. with a {{#switch: for all possible values of parameter $2).

Hmm, that's a good point, changing that message is probably doable (although I'm afraid it's more difficult than it looks – by the point we display the message, we can't replace the message keys it was generated from, and 'action-edit' itself comes from code that checks whether the user is allowed to perform the 'edit' action, so we'd either need to define and check for the 'reply' action instead, or add a way of replacing the message without changing the logic).

However, I was mostly thinking about the more specific messages shown below that intro:

• 'blockedtext', which is customized to refer to "editing" e.g. here: https://en.wikipedia.org/wiki/MediaWiki:Blockedtext
• 'protectedpagetext', which has a parameter for the action, but it seems that only a few actions are supported: https://en.wikipedia.org/wiki/MediaWiki:Protectedpagetext (I tested in https://en.wikipedia.org/w/index.php?title=User:Matma_Rex/sandbox&oldid=1015111883, the last message has a missing icon and broken grammar)

Is there a way to list all customized versions of a given MediaWiki message across Wikimedia?

I use this: https://global-search.toolforge.org/?q=.&regex=1&namespaces=8&title=Blockedtext. I don't know if it's perfectly reliable, but it gives 317 results for this one. ;)

I just wanted to note this task may be a good workaround for T15079 issue which has never been fixed (and this is a problem for village pumps). This means Reply link for transcluded editable pages should still work.