|mediawiki/extensions/DismissableSiteNotice : master||Update code that hides site notice from search engines|
- Mentioned Here
- rSVN41679: Merging DismissableSiteNotice extension into core.
rSVN41706: * fixing bugs with DismissableSitenotice merge:
rSVN41958: Revert merge of DismissableSiteNotice into the core (r41679 and subsequent…
T107399: Make top queue fully asynchronous
@Jules78120 reported an issue with MediaWiki:AnonNotice on the French Wikipedia today, where the notice was added at the bottom left of the page and not at the top.
Could this be related to the use of document.write as well?
I've not experienced this issue with a fresh install of the 1.26 release with the DismissableSiteNotice extension I made last night. Edit: actually, I do.
These improvements were lost when the core merge was reverted in r41958 by Tim Starling. Maybe now would be an appropriate time to salvage some of those improvements and ditch document.write altogether?
I agree that the sitenotice feature should be dismissable without having to install an extension. Wasn't there an issue with the non-js version that made search engines index the sitenotice?
I guess the “quick fix” for now is to replace the current
$notice = Html::inlineScript( Xml::encodeJsCall( 'document.write', array( $notice ) ) );
with something like
$notice = Html::inlineScript( Xml::encodeJsCall( '$('#content').prepend', array( $notice ) ) );
(not quite sure about how encodeJsCall works).
See here for the code.
This probably is related.
I've not experienced this issue with a fresh install of the 1.26 release with the DismissableSiteNotice extension I made last night.
Whether the site notice ends up at the bottom of the page would depend on whether the "mediawiki.legacy.wikibits" module, which overrides document.write, is executed before the embedded script containing the document.write() call.
Here are links to the commits @ashley was talking about:
We need the banner for the WikiMOOC that will be launch the
22 february. The banner will probably be on wikipedia one month or 15 days before the launch (i don't know exactly). But it will be in few months.
early january says Jules. Registrations have started and we have failed to put the banner for the registrations . And we expect we can put it for the next time.
@Aklapper Do you think the priority could be review as "unbreak now" ?
@Jules78120 if you have more details on dates ...
Our goal is to put the banner on Wikipedia from early January.
This banner is really very important: without it, the project (we are 15 Wikipedians working hard on this project since May 2015! More than 1000 hours of work...) will have much less impact... :(.
Because the banner didn't work when we tried to use it monday, we have for now only 200 enrolled, which is far less than what we expect. I hope you will be able to help us on that problem.
I hope you will be able to help us.
Do you think the priority could be review as "unbreak now" ?
No, there is a workaround: use CentralNotice. https://meta.wikimedia.org/wiki/CentralNotice/Usage_guidelines
Please don't add more comments specific to your campaign here, instead ask help on https://meta.wikimedia.org/wiki/WM:RFH
This workaround is an absolutely unacceptable one for any and all non-WMF sites. CentralNotice is extremely heavy and a lot more complicated to install than DismissableSiteNotice.
Based on some quick tests I ran locally, the current (git master) version of DismissableSiteNotice fails to position the notice correctly in about or over half of the cases. This becomes especially problematic if and when you have extensions like ShoutWiki Ads which somehow append things (in this case, a leaderboard ad) to the sitenotice area.