MediaWiki talk:Clearyourcache/Archive 1

Archive 1

Konqueror instructions give unexpected result

Request: Change '''Mozilla/Safari/Konqueror:''' to '''Mozilla/Safari:'''; change '''Opera:''' to '''Konqueror/Opera:'''

Rationale: The current version of the message says that pressing Ctrl-Shift-R clears the browser cache in Konqueror (as well as in other browsers). For Konqueror, this is incorrect—in fact, pressing Ctrl-Shift-R closes the "active view", which closes the active pane when using split windows or (more frequently) closes the browser tab/window. Obviously, for someone following the given instructions, this would be a very unexpected result. As it says at Wikipedia:Bypass your cache#Konqueror, Konqueror only requires pressing the "Reload" button on the toolbar or (like Opera) pressing just F5. It's therefore more accurate that Konqueror be listed alongside Opera in this message than listed with Safari and Mozilla. Thanks. — Jeff | (talk) | 01:05, 7 June 2006 (UTC)

Done. —Ruud 01:04, 11 June 2006 (UTC)

warning

There is a worm spreading that tricks users into thinking they have been blocked and telling them to past a template into their monobook.js, this results in the same code running on their account. I have added a warning to slow the spread of this worm. HighInBC ^{(Need help? Ask me)} 20:31, 29 January 2007 (UTC)

Please add a link to Wikipedia:Help_desk so that a naive user can tell where to ask about questionable code.

If you have been directed here because of a note on your talk page, please be very certain you know the user who left it for you. If not, the code may contain malicious content, which can compromise your account and lead to your being blocked. If you are unsure about whether the code is safe, you can ask at the help desk.

Thanks CMummert · talk 03:36, 31 January 2007 (UTC)

Done. HighInBC ^{(Need help? Ask me)} 04:12, 31 January 2007 (UTC)

If there is some malicious code doing the rounds, shouldn't this message be visible on all JavaScript pages? What's stopping somebody from adding that code to a page that isn't called monobook.js? J Di 16:16, 6 March 2007 (UTC)

The code caused the user to send talk-page messages to other users trying to frighten them into installing something in their monobook.js. (Frightening users into installing something into some other JS page just wouldn't be self-perpetuating.) As far as I know, the code's been eliminated now (all pages containing it were deleted), and the message has frightened at least one user into thinking their monobook had been infected when it hadn't, so toning down the message might make more sense (e.g., 'Note that this page is your personal user scripts page. Do not edit this page unless you intend to install a user script; if you think you may have installed something here by mistake, contact the Help desk.'). --ais523 18:45, 6 March 2007 (UTC)

change link

{{editprotected}}

Perhaps a link to the technical village pump might be more useful than one to the help desk, since those people would be more able to understand js, and the village pump is meant for more drawn out discussions (if needed). Gracenotes^T § 21:18, 30 March 2007 (UTC)

I originally thought that VPT would be irritated by newbies asking whether or not obviously safe scripts are safe. Do you think that will be a problem? If not, I will be glad to change the tag. CMummert · talk 02:44, 31 March 2007 (UTC)

Help Desk people are pretty good at directing users elsewhere, although this may be annoying to some people. It may also be useful in theory to have a "safe scripts" page (protected, of course), but in practice this seems too cumbersome. At the help desk, by the way, few .js queries appear; maybe one or two every five days, and almost none are related to worries about malicious code. I think that the VPT people are patient when it comes to user javascript, and there would be no significant influx of people. But an argument could go either way. Gracenotes^T § 05:00, 31 March 2007 (UTC)

I got a 'is my monobook infected' question on my talk page once (the monobook of the user in question was blank); they don't come up very often at all at the Help Desk (which spends most of its time telling users the correct place to ask). --ais523 14:46, 31 March 2007 (UTC)

the change has been made. CMummert · talk 14:49, 31 March 2007 (UTC)

Thank you. Gracenotes^T § 21:48, 1 April 2007 (UTC)

Note: appears on preferences

This message appears at Special:Preferences, as well as on user .js pages. Its main purpose is to inform the user of clearing their cache, but understandably something... bad could happen on both pages. Could the security message be generalized? Gracenotes^T § 01:22, 8 May 2007 (UTC)

Changed to default on pref for now, more specific? Also, where is the header on MediaWiki:Clearyourcache coming from? Prodego ^talk 03:01, 8 May 2007 (UTC)

Heh, bad setup. Fixed. Prodego ^talk 03:15, 8 May 2007 (UTC)

Now it doesn't have the warning, but hopefully illicit code shouldn't too much of a problem, I hope. Gracenotes^T § 05:10, 8 May 2007 (UTC)

Safari

{{editprotected}}Could someone make the Safari cache separet. It doesn't look like it's working the same way Mozilla is, at least not on a Mac. [ ⌘, ⌥, E ] or [ Command, Option, E ] works. --Steinninn 14:03, 16 July 2007 (UTC)

Done. Cheers. --MZMcBride 19:23, 6 August 2007 (UTC)

Some changes

{{editprotected}} I propose this new version. It fixes the bad HTML in the monobook.js message. It also prints both messages on the monobook.js page now, instead of only the warning (seems more consistent to me that way). And it fixes the statement for Safari (ctrl-reload button is big time bogus on Safari. It is shift-Reload and even that is no longer required [1]. --TheDJ (talk • contribs) 00:24, 4 June 2008 (UTC)

 Done. —Remember the dot ^(talk) 03:23, 4 June 2008 (UTC)

This information is incorrect!

Opera DOES NOT clear the CSS cache on any kind of reload - You have to close down the browser (as it keeps them in memory also) and manually go in and clear all the files out of the 'styles' folder where they are cached - this is a real pain in the #@$. You can even set opera to not cache anything at all - but it still does!!! This is an extremely frustrating problem. If I set the browser to not cache anything, I expect it to. . .that's right, NOT CACHE ANYTHING. . .but it does all the same. To me this is a MASSIVE breach of personal security. Maybe other browsers do this as well, but I like opera and I'd like it to be obey the commands it's supposed to obey. But back to the css file problem. . .IE's control + F5 is much easier for web developers - I wish the opera team would fix this discrepency. If anyone knows of a way to easily bypass opera's cache and force reload the css file, please email me, I'd love to find a solution. P.S. All versions of opera have this problem, including opera 9. (webmaster@earthsociety.org) --131.217.6.6 01:57, 30 June 2006 (UTC)

There are instructions for setting up a shortcut to refresh the CSS here: http://operawiki.info/OperaUserCSS. I have not tested to see if they work. —Preceding unsigned comment added by 64.81.73.35 (talk) 23:03, 17 October 2008 (UTC)

This message currently claims that any reload in Mozilla will "clear" (better termed "bypass") the cache. This is not the case. Wikipedia:Bypass your cache contains the correct instruction, which is to hold down Shift while reloading; this is also true for Safari, and probably Konqueror (see Wikipedia talk:Bypass your cache for evidence in support of this).

I don't know if anyone will spot this here, and presumably the default message in the software will also need changing, but I'll have to follow up other channels later. But if a sysop/admin does come past, please amend this page appropriately; thank you. - IMSoP 23:49, 4 Dec 2004 (UTC)

It should also be noted that Opera is a fiend for caches, and users will specifically have to load their new CSS (or delete their cache) by viewing and refreshing their raw CSS, that is in the sense of &action=raw&ctype=text/css. - Vague | Rant 08:48, Jan 2, 2005 (UTC)

Is it true then that Opera, unlike every other browser we have information on, will clear most things from cache just by pressing F5? Or are we, in fact, missing the correct procedure for doing this (nobody's added anything for Opera to Wikipedia:Bypass your cache yet...)? Certainly http://www.opera.com/features/keyboard/ doesn't show anything different for "hard" refresh, but does that mean it will always clear cache, that it will never do so, or just that the information is top secret? - IMSoP 22:34, 15 Jan 2005 (UTC)

Opera will always completely reload from server if a manual reload is forced (F5) — if that file is marked as newer (timestamp). So if the Wikipedia properly updates timestamps on file change, a reload is sufficient. Jordi·✆ 23:36, 15 Jan 2005 (UTC)

To add on this: Opera appears to be the only browser which actually does what the standards ask for, and listen to the server. As such it is a "fiend for caches", as files are only updated when the file on server is timestamped newer than the cached copy. Jordi·✆ 23:39, 15 Jan 2005 (UTC)

From my experiments, it actually seems to do worse than other browsers: a normal reload from Mozilla or Firefox reveals plenty of "304 Not Modified" responses in my Apache log, indicating that it asked whether there was a newer version, and got the answer "no" - for the wiki page itself, and for all the associated bumph that needs getting (JS, CSS, images, etc); however, the whole point of a "hard refresh" aka "force reload" is that it offers the user the option to not ask this question, but refreshes the cache anyway, in case "normal operation" is not behaving correctly.

Opera, on the other hand, does not offer the user this override, and furthermore - according to my testing today (on Opera 8.02 for Linux) - doesn't send an If-Modified-Since header for the actual wiki page, only the other files. So unless MediaWiki is doing something other than "what the standards ask for", I can only assume that Opera is behaving according to its own rules. In fact, this seems to tally with the idea that browsing to ...&action=raw&ctype=text/css and hitting refresh will cause a proper reload - Opera is effectively doing a "force reload" on the current primary URL, while using the cache for any referenced bits and bobs.

One conclusion of all which is that the instructions for Opera should be removed from this message, unless replaced with some longer workaround instructions. - IMSoP 23:33, 17 August 2005 (UTC)

Script documentation

This discussion was moved here from my talk page. --David Göthberg (talk) 04:57, 3 December 2009 (UTC)

Hi David.
I hope you enjoy your break. :)
I seem to remember that you posted some thoughts on .js documentation somewhere, but I don't remember where (and neither really what you said). I was thinking that we can abuse MediaWiki:Clearyourcache to check if there is a /doc subpage, which it can then display in the normal {{documentation}} style at the top of the script. It can't of course be used to categorize or interwiki or something like that, and it isn't super efficient since it won't get cached, as far as I understand it, but it can show usage information which is currently not handled consistently.
Cheers, Amalthea 10:21, 8 May 2009 (UTC)

Oh, and since you're currently playing with documentation subpages, here's a hackish innovative idea for .js and .css documentation. :) Amalthea 13:07, 30 November 2009 (UTC)

Ah right, I forgot to answer this message. Well, here goes:

Right, using the system message(s) that go on top of the .css and .js pages to load a /doc subpage could probably work. But many scripts are already long and adding the documentation on top of them can make it very long. After some discussions with the people over at Wikipedia:WikiProject User scripts and some testing I realised it is easier and better to do like many of them already do. So I used their method for my two user scripts, I think you won't have any problems finding the documentation for them. See User:Davidgothberg/newmessageshistory.js and User:Davidgothberg/clock.js. And normally I don't link to the .js page of those scripts, but instead I link directly to the documentation. Most users don't need to see the code anyway. And compare their/my naming to using a /doc page:

User:Davidgothberg/newmessageshistory

User:Davidgothberg/newmessageshistory.js/doc

So the current system is neater. Oh, that gave an idea: Instead of using the system message to load and insert a /doc page, lets just detect if there is a page with the same name as the script, but without the ending .css or .js, and simply just show a link to that page. And of course add some explanation what the link is. Checking the file ending is slightly ugly in template code, but doable. Using JavaScript for it is nicer. And users that are looking at scripts probably have JavaScript enabled, so we should perhaps do it in JavaScript. We should of course add an empty div with an id in the right place in the system message so it is easy and efficient to insert the link from JavaScript. But give me some time to ponder if I can come up with a nicer way to detect the file ending from template code.

I think we should do this for User and Wikipedia space, but not MediaWiki space. Since for the MediaWiki .css and .js files we already have the praxis to use the talk page.

--David Göthberg (talk) 17:39, 30 November 2009 (UTC)

Yep, I like clickable bluelinks. :) One thing to consider is whether someone has an idea how to inject a centralized documentation page for e.g. all those twinkle or friendly scripts. All I got is having a subpage with a fixed name (/docpage) that contains the name of the centralized doc page. For such highly used scripts like Twinkle or Friendly it makes sense since the subscripts are linked to in places as well, and getting to the centralized doc would be neat, and worth the bother to create the subpages. Doing it with soft redirects like you favor with template documentation in such cases is a bit more of a hassle here if documentation isn't transcluded and only available by soft redirect in the first place – we end up with a double redirect, in effect. Not mission critical though. Amalthea 18:33, 30 November 2009 (UTC)

I assume that each of those script names only exist once, not that many users have all those scripts under their user page, right? So yeah, in your case simply creating the "doc" pages for each of them and put an actual hard redirect in them is the "easy" solution. But sure, we can detect other things, like if we are on "User:AzaToth/twinkleunlink.js" then we can first check if the normal doc page "User:AzaToth/twinkleunlink" exist, if not then we can check if "User:AzaToth/twinkleu*" exist, and if not then "User:AzaToth/twinkl*". Thus we can make a single doc that gets automatically linked from many sub-scripts. Similar to the syntax we use for {{if pagename}}. Of course, you would probably not put the doc text in "User:AzaToth/twinkl*", since that looks bad if you want to list it at other places, instead you would just put a hard redirect there pointing to "User:AzaToth/twinkle" or wherever you have chosen to put the actual doc page. Actually, checking for "User:AzaToth/twinkl*" is much simpler than checking for "User:AzaToth/twinkleunlink", since "User:AzaToth/twinkl*" has a fixed length, while we have to use the nasty {{str len}} to convert "User:AzaToth/twinkleunlink.js" to "User:AzaToth/twinkleunlink".

By the way, I can even make it so that you can put a kind of redirect in "User:AzaToth/twinkl*" that can be interpreted by the template code, so it won't show User:AzaToth/twinkl* as link above the script, instead it will show User:AzaToth/twinkle. There's several ways I can make such "redirects" that can be interpreted from template code.

But hang on. Having many subscripts like that is fairly unusual, isn't it? So this is an exception. So we should probably not add lots of code to cater for it. And making it complex would also cost a long documentation about how to use this doc system...

--David Göthberg (talk) 01:08, 1 December 2009 (UTC)

End, discussion moved here from my talk page. --David Göthberg (talk) 04:57, 3 December 2009 (UTC)

I have now looked at the different MediaWiki messages involved, and yes, it seems the best place to put this is in MediaWiki:Clearyourcache. I have tested the code for it in my user space and it worked well. So I now think we should do it with template code. I think it should only show when in user space (on top of both .js and .css pages). When at for instance User:Davidgothberg/clock.js, then it could look something like this:

Note: After saving, you have to bypass your browser's cache to see the changes. Internet Explorer: hold down the Ctrl key and click the Refresh or Reload button. Firefox: hold down the Shift key while clicking Reload (or press Ctrl-Shift-R). Opera users have to clear their caches through Tools→Preferences; see the instructions for Opera. Konqueror and Safari users can just click the Reload button.

We could add an icon, for instance the icon we use in some other documentation related templates:

Note: After saving, you have to bypass your browser's cache to see the changes. Internet Explorer: hold down the Ctrl key and click the Refresh or Reload button. Firefox: hold down the Shift key while clicking Reload (or press Ctrl-Shift-R). Opera users have to clear their caches through Tools→Preferences; see the instructions for Opera. Konqueror and Safari users can just click the Reload button.

Another nice option is the image we use in some other messages in that place:

But since the message is only one line, then I think the icon takes up to much space. So I prefer without the icon.

I think that instead of testing if the doc page exist we could always link to the doc page. It will probably be a red link in most cases, but it means we show people where to put the documentation. (And they can of course use that page to redirect to where they actually have the doc if they prefer some other place.) We will of course not show this message on top of the personal skin files, just on other script pages in user space. Then the message itself could be worded something like this:

So, what does everyone think about this?

--David Göthberg (talk) 04:57, 3 December 2009 (UTC)

I for one would very much like having an icon. Considering the cruft that follows, I think most editors would very much like to have their attention drawn to the documentation link. Experienced editors will always have an easy time turning the icon off if it annoys them.
Hmm, and/or how about making it closer to the style of {{documentation}}, in particular by using the same background color? My brain at least is already conditioned to go straight to it when I look at a template page. Oh, and you convinced me that placing it on a separate page instead of transcluding it is the best way. Thanks & Cheers, Amalthea 00:20, 12 December 2009 (UTC)

Oh nice idea, green is the standard documentation colour here at Wikipedia. So perhaps something like this:

Note: After saving, you have to bypass your browser's cache to see the changes. Internet Explorer: hold down the Ctrl key and click the Refresh or Reload button. Firefox: hold down the Shift key while clicking Reload (or press Ctrl-Shift-R). Opera users have to clear their caches through Tools→Preferences; see the instructions for Opera. Konqueror and Safari users can just click the Reload button.

I think the documentation green matches the pink above it very well. I tried some different icons and the template documentation icon looks the best here since it is not as high as the others. And as you Amalthea stated, making it look like the established documentatin makes it instantly recognisable.

I have done a little more thinking and now I think we should show that doc box in all namespaces, if the doc page exists.

So the only question remaining is if we should have that green box there even when the documentation page still does not exist? Thus supplying a red link to the possible documentation. (If we do that then we should not do it in MediaWiki space since there we usually use the talk page as the doc page.)

--David Göthberg (talk) 12:52, 13 December 2009 (UTC)

I have now created the {{script doc auto}} template that handles this detection and outputs the small green doc box with the link to the documentation page. It is more or less ready to be deployed. I have some ideas about more things that template could do, see its talk page. And I think we could continue this discussion on the talk page of that template.

--David Göthberg (talk) 14:34, 14 December 2009 (UTC)

Show editnotice

The discussion in the above section resulted in that MediaWiki:Clearyourcache automatically links to the documentation for .css and .js files. But that only helps in User space, since in MediaWiki space we don't have such script documentation. But we often have very informative editnotices.

So I have now made it so this message shows the editnotice of the .css or .js file, when in MediaWiki space. That is, it shows the editnotice already when just viewing the page. This has several advantages: Links to validate a .css file before and after editing it works already before editing it, and non-admins can now see the editnotice so the editnotice can tell them where to discuss the .css or .js page. See for instance how it looks on top of MediaWiki:Common.css and MediaWiki:Common.js.

--David Göthberg (talk) 00:34, 21 December 2009 (UTC)

This system message now feeds "notice action = view" to the editnotices, so they can choose to display other text when the page is only viewed. That is the standard parameter for editnotice "view mode", for instance when a non-admin "views the source" of a protected page. See more about that at {{editnotice load}} or Wikipedia:Editnotice.

--David Göthberg (talk) 15:47, 14 January 2010 (UTC)

MediaWiki:Clearyourcache, be more intuitive!

{{editrequest}} I made a previous request at Wikipedia:MediaWiki_messages and had no answer.

The link on "bypass your browser's cache" is misleading: it would mean that once one click on this link the browser's cache is be cleared. And it does not indicate that details and informations about other browsers can be found. When I red this message, I thought I couldn't get more information elsewhere, and was surprised to see no information regarding Google Chrome (According to usage share of web browsers, Google Chrome has now around 7% of the market share, which is more than Opera or Safari).

In short, we have to make it clearer that more information can be found at Wikipedia:Bypass your cache. Instructions for Chrome and Opera are long and complicated, it's necessary to read Wikipedia:Bypass your cache anyway. In order to keep the message short I suggest to remove instructions for Opera (around 2% market share). The result would be:

---

Note: After saving, you have to bypass your browser's cache to see the changes. Internet Explorer: hold down the Ctrl key and click the Refresh or Reload button. Firefox: hold down the Shift key while clicking Reload (or press Ctrl-Shift-R). Konqueror and Safari users can just click the Reload button. For details and instructions about other browsers, see Wikipedia:Bypass your cache.

---

Yours, Dodoïste (talk) 12:47, 24 May 2010 (UTC)

That seems a positive change.  Done — Martin (MSGJ · talk) 13:26, 24 May 2010 (UTC)

Thanks MSGJ! :-) Dodoïste (talk) 13:44, 24 May 2010 (UTC)

Konqueror -> Chrome

{{editprotected}} The Konqueror browser is seldom used nowadays. It has been overtaken in popularity by Google Chrome. Konqueror should be replaced by Chrome in this message (it seems that the instructions are the same in Konqueror and Chrome - Google's help page says that Ctrl+F5 or Shift+F5 bypass the cache, but forum posts seem to suggest this doesn't really do anything more than a normal reload). — This, that, and the other (talk) 06:51, 27 December 2010 (UTC)

 Done — Martin (MSGJ · talk) 17:36, 27 December 2010 (UTC)

Cache clearing instructions

The instructions state that to see changes we should simply clear the page cache. However, when working on a script (adding, changing etc) that is imported by another (e.g. bar.js is imported by foo.js) it's foo.js that needs to be refreshed, not bar.js. Could or should something be done about this? I (as a relatively technically knowledgeable person) know which scripts need to be refreshed in order to show what changes, but many users may not, and might be quite confused when after numerous refreshes, they are still not seeing any effect. fredgandt 15:10, 9 January 2012 (UTC)

I propose the text is changed to (background colour not proposed):

Note: After saving, you will have to bypass your browser's cache to see the effect of any changes. If this script is imported by another script; it is your browser's cache of that other script that will need to be bypassed. Equally: if that other script is imported, the cache of the importer will need to be refreshed etc.

• Internet Explorer: hold down the Ctrl key and click the Refresh or Reload button.
• Firefox: hold down the Shift key while clicking Reload (or press Ctrl-Shift-R).
• Google Chrome and Safari users can just click the Reload button.

For details and instructions about other browsers, see Wikipedia:Bypass your cache.

 fredgandt 16:38, 9 January 2012 (UTC)

I find your version confusing and not very helpful: it says what user needs to do but doesn't explain how to do it. Also, do you imply that pressing Ctrl-R while viewing foo.js will only refresh this script and not the others? I don't think this is the case. — AlexSm 17:00, 9 January 2012 (UTC)

I've found that with Chrome, refreshing scripts imported to my common.js doesn't do the job. I have to either refresh my common.js or clear the cache by refreshing any page while having my inspection panel open, and selecting "Network: Disable cache". Perhaps this is Chrome specific or I am mental. fredgandt 17:10, 9 January 2012 (UTC)

P.s. The version we have now doesn't explain more than my version. So, if it is believed there isn't enough explanation about how to do it, the text would still need to be changed. fredgandt

P.p.s As stated: If foo imports bar, and bar is changed, we need to refresh foo. The present notice doesn't inform that this is the case. So no, I am not implying that refreshing foo will not refresh other scripts. I am stating, that if bar is changed, refreshing bar will not have any effect, but rather foo should be refreshed. fredgandt

Bypassing the browser's cache should bypass it for everything loaded in the page. Thus, in Firefox I've found it is enough to bypass the browser's cache on any page where the changed script is loaded, even Main page or the like. Note that if you have a script that is conditionally loaded only for File-namespace pages, you'd have to go to a File-namespace page and bypass the cache.

One thought that comes to mind is that there might be some magic that manages to load the bar.js script differently when bar.js itself is being viewed. Try changing a script and then bypassing your cache on Main page to see if that does it for you. Anomie⚔ 18:15, 9 January 2012 (UTC)

I'll be doing a fair amount of script editing in a while and will try various ways and reports back. fredgandt 19:42, 9 January 2012 (UTC)

After having a bath, something to eat, and watching some telly, I'm really rather tired. However, a few edits of a script imported to my common.js, with each refreshed differently, I can say without a doubt that simply reloading the page is not good enough. I'm too tired to do it now, but I will provide a full set of repros for anyone interested. fredgandt 22:46, 9 January 2012 (UTC)

Apologies for taking so long to get back to this. My life is in a mess and I am not concentrating on anything very well. I'll remove the edit request for now and come back when I know which way is up. fredgandt 18:59, 20 January 2012 (UTC)

Protected edit request on 31 December 2014

Please replace:

{{#switch: {{NAMESPACE}} 
| MediaWiki = 
  {{#ifexist: Template:Editnotices/Page/{{FULLPAGENAME}}
  | <!--This MediaWiki page has an editnotice, display it-->
    {{ Template:Editnotices/Page/{{FULLPAGENAME}} | notice action=view }}
  }}
| User = {{MediaWiki:Jswarning}}{{script doc auto}}
}}<span id="clearprefcache">'''Note:''' After saving, you have to bypass your browser's cache to see the changes. '''Internet Explorer:''' hold down the Ctrl key and click the Refresh or Reload button. '''Firefox:''' hold down the Shift key while clicking Reload (or press Ctrl-Shift-R). '''Google Chrome''' and '''Safari''' users can just click the Reload button. For details and instructions about other browsers, see [[Wikipedia:Bypass your cache]].</span>

with:

{{#ifeq:{{NAMESPACE}}|User|{{MediaWiki:Jswarning}}{{Script doc auto}}}}
{{#ifexist: Template:Editnotices/Page/{{FULLPAGENAME}}|{{Template:Editnotices/Page/{{FULLPAGENAME}}|notice action=view}}}}<span id="clearprefcache">'''Note:''' After saving, you have to bypass your browser's cache to see the changes. '''Internet Explorer:''' hold down the Ctrl key and click the Refresh or Reload button. '''Firefox:''' hold down the Shift key while clicking Reload (or press Ctrl-Shift-R). '''Google Chrome''' and '''Safari''' users can just click the Reload button. For details and instructions about other browsers, see [[Wikipedia:Bypass your cache]].</span>

So that users can transclude documentation or other things like github top icons that link to the repo for the script on script pages. I'm willing to discuss alternatives if there is objection to this, such as having a /doc or /header subpage for user scripts be transcluded instead of editnotices. — {{U|Technical 13}} ^{(e • t • c)} 16:42, 31 December 2014 (UTC)

Not done: @Technical 13: This should probably be discussed somewhere before it is implemented. As you say, a /header subpage rather than edit notices might be a good idea as for those of us who aren't admins, template editors or account creators. But we will need a consensus on which approach to take before we actually go through with it. Perhaps start a discussion about it on WP:VPT? — Mr. Stradivarius ^{♪ talk ♪} 09:53, 6 January 2015 (UTC)

• Fair enough Mr. S. I'll do that. — {{U|Technical 13}} ^{(e • t • c)} 13:57, 6 January 2015 (UTC)

Done — {{U|Technical 13}} ^{(e • t • c)} 14:39, 6 January 2015 (UTC)

Protected edit request on 17 September 2015

Copy the content to Template:Bypass your cache and make MediaWiki:Clearyourcache transclude this template. Also add Microsoft Edge, the Windows 10 browser. GeoffreyT2000 (talk) 02:43, 17 September 2015 (UTC)

Not done: MediaWiki:Clearyourcache and Template:Bypass your cache are quite different, so if we just replace one with the other we will lose features. Adding Microsoft Edge sounds like a good idea, but you need to specify the actual content that needs to be added to the template - admins won't write it for you. — Mr. Stradivarius ^{♪ talk ♪} 23:46, 17 September 2015 (UTC)

Edit request on other page

See MediaWiki_talk:Gadget-popups.js#Protected_edit_request_on_30_August_2018. — xaosflux ^Talk 15:56, 30 August 2018 (UTC)

Protected edit request on 24 November 2019

{{#switch: {{NAMESPACE}} | MediaWiki = {{#ifexist: Template:Editnotices/Page/{{FULLPAGENAME}} | <!--This MediaWiki page has an editnotice, display it--> {{ Template:Editnotices/Page/{{FULLPAGENAME}} | notice action=view }} }} | User = {{MediaWiki:Jswarning}}{{script doc auto}} }}<span id="clearprefcache">'''Note:''' After saving, you have to bypass your browser's cache to see the changes. '''Google Chrome''', '''Firefox''', '''Internet Explorer''' and '''Safari''': Hold down the {{key press|Shift}} key and click the ''Reload'' toolbar button. For details and instructions about other browsers, see [[Wikipedia:Bypass your cache]].</span>

I simplified the instructions to use one shortcut that works across all four browsers.

Mark Schierbecker (talk) 21:00, 24 November 2019 (UTC)

 Done — Martin (MSGJ · talk) 11:37, 25 November 2019 (UTC)