Page MenuHomePhabricator

(semi-)page protection editnotices in VisualEditor display in the wrong order
Closed, ResolvedPublic

Description

See discussion: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_184#Page_notices_in_VisualEditor

The page protection notice is kinda UI clutter. We just say the page is protected, and then dump the long log for the protection. Not sure why it's needed at all for most cases, but would like to propose an option to turn it off. The only editors who will see it are the ones who can edit the page anyway, and semi-protection is not quite a big deal to have to be aware about (besides, we have the lock icons too).

For VE, in /includes/ApiVisualEditor.php, this can be added as a configuration option to line 318. That way, individual wikis will be able to hide this. Should just be a few lines of code around that line to implement, I think, so a quick change hopefully?

Picture: (see notice # 1)

protection-notice.png (1×788 px, 348 KB)

On some devices (like my 13" Mac), it's so big it completely hides the 2nd notice (which is the important one).

Event Timeline

Can you clarify what you mean, or include a screenshot? As far as I can tell, editnotices are not shown at all in the mobile version, for better or worse.

@matmarex whoops, I didn't mean mobile. I'm getting my tasks mixed up (as I've something similar to the opposite for mobile). Sorry, will update to clear it up.

Proc renamed this task from Add option to hide page protection editnotices on mobile to Add option to hide (semi-)page protection editnotices in VisualEditor.Sep 21 2020, 6:38 PM
Proc updated the task description. (Show Details)
Proc updated the task description. (Show Details)
JTannerWMF moved this task from To Triage to Triaged on the VisualEditor board.
JTannerWMF added a project: UX-Debt.
JTannerWMF added a subscriber: JTannerWMF.

Thanks for filing this, the Editing team can not prioritize at this at this time.

These are the same edit notices as the old wikitext editor, and I don't think we should be hiding any in the visual editor. If that notice is useless, then it should be removed from all editors.

@matmarex imo it's pretty useless, but maybe removing it from all editors may prove a bit more work (in terms of process)?

Would it be feasible/less work to move it to the bottom in VE (ie below the page notice)? Noting that in the old wikitext editor it's also below the page notice. That would at least make it stand out less, and make the useful notices more visible.

@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?

Would it be feasible/less work to move it to the bottom in VE (ie below the page notice)? Noting that in the old wikitext editor it's also below the page notice. That would at least make it stand out less, and make the useful notices more visible.

Oh, indeed, they definitely should be in the same order in both editors. That should be an easy fix.

@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?

I'd be happy to review a patch to fix the order in VisualEditor (the code is in includes/ApiVisualEditor.php, search for // Get edit notices). Although if you're not interested in this, I'll probably submit a patch myself.

I'm not sure how I feel about actually changing the edit notice. I assume it's there for a reason, and someone might be relying on it.

Although if you're not interested in this, I'll probably submit a patch myself.

@matmarex Feel free :) -- I don't think I'll get around to it at present.

I'm not sure how I feel about actually changing the edit notice. I assume it's there for a reason, and someone might be relying on it.

Well, technically speaking, the code actually considers two types of 'protection notices' separately, the semi-protection ones, and the non-semi-protection (eg full protection) ones. I'd only want to disable the semi-protection one, not the other ones.

To kinda summarise my points at the enwiki discussion (linked above): maybe the full protection ones are useful, but the semi-protection ones (i.e. editing is limited to confirmed users; 10 posts and 4 days) I don't think are. Note also that one doesn't see the notice if they're not confirmed - they can only see if it if they can edit the page, so the notice + dumping the verbose log is a bit clutter-y. The full prot ones may make sense, admittedly, because admins/privileged editors should want to be aware that it's protected because of a content dispute / other non-trivial reason, so they know to be more cautious. But the semi-prots don't really tell you anything at all - it's a very basic & common level of protection, and as such doesn't suggest the editor do anything differently at all. Some way to be able to configure this in either wmf-config, or interface admins at a wiki level, is maybe another idea?

Just my 2c.

Change 634386 had a related patch set uploaded (by ProcrastinatingReader; owner: ProcrastinatingReader):
[mediawiki/extensions/VisualEditor@master] Fix editnotice order in VisualEditor

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

@matmarex got around to the ordering, at least, in above patch. Could you see if it's all good, when you have time?

Change 634386 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Fix editnotice order in VisualEditor

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

ppelberg claimed this task.
matmarex renamed this task from Add option to hide (semi-)page protection editnotices in VisualEditor to (semi-)page protection editnotices in VisualEditor display in the wrong order.Oct 23 2020, 3:53 PM

@matmarex @ppelberg the patch I released was somewhat tangential to what I intended this issue to be (it's an improvement, but not a 'fix' in my eyes). I'd still like to focus on hiding these details (at least the semi-protection ones) in that message entirely, if it's something I can swing by whoever needs to sign off on this. It's really irritating for me to see that regular long log dump on every other page, most of which I just can't see a use for. On pages without an actual notice, it pops up anyway (when in its absence nothing would pop-up) and slightly throws one off. Just doesn't feel like it belongs.

Would it be better to now open a new task for this?

@matmarex ping again on the above. Alternatively, could we provide the log entry as a param to the template rather than forcefully including it via code, so a local project could collapse/trim it if they want (such as on the Pending Changes messages, see https://en.wikipedia.org/w/index.php?title=Inner_Mongolia&action=edit for example.

$protectionNotices[] = $this->msg( $noticeMsg )->parseAsBlock() . $this->getLastLogEntry( $title, 'protect' );

Okay, I'm mildly misunderstanding how the FlaggedRevs one works. Looks like it's part of /frontend/FlaggedRevsXML.php line #364 (function logDetailsToggle()).

	/**
	 * Generates (show/hide) JS toggle HTML
	 * @return string
	 */
	public static function logDetailsToggle() {
		$toggle = '<a class="fr-toggle-text" title="' .
			wfMessage( 'revreview-log-details-title' )->escaped() . '" >' .
			wfMessage( 'revreview-log-details-show' )->escaped() . '</a>';
		return '<span id="mw-fr-logtoggle" class="fr-logtoggle-details" style="display:none;">' .
			wfMessage( 'parentheses' )->rawParams( $toggle )->escaped() . '</span>';
	}

Still, that approach is much cleaner than dumping the full log. Happy with any of the above options, whichever we can get merged, so long as we can stop dumping an obscure log message to everyone?