# Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab Miscellaneous
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Older discussions, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

## Module:Redirect

I am confident in Lua, but I thought I would ask for help instead, so I do not break anything. Concerning Module:Redirect, which retrieves the target of a redirect page, the module uses .prefixedText to return the target of the page. However, I am looking to add (not necessarily replace) the option to use .fullText, and return the contents from that call.

For example, calling {{#invoke:redirect|main|List of Daredevil episodes|fulltext=y}} would return "Daredevil (TV series)#Episodes", where {{#invoke:redirect|main|List of Daredevil episodes}} would still return "Daredevil (TV series)".

This is so that I can check if a redirecting page links to a particular section on a the target article (e.g. the example already given), or if it does not. (For example, Vikings (season 5) redirects to "List of Vikings episodes", no section.) Cheers. -- AlexTW 09:32, 19 March 2017 (UTC)

@Mr. Stradivarius and Wnt: Pinging some major contributors to the module. -- AlexTW 15:55, 19 March 2017 (UTC)
The .prefixedText was added subsequent to my editing, and I don't think I ever thought about this issue. The edit summary for Stradivarius' addition here credits for the request, so I'll ping him. Wnt (talk) 16:11, 19 March 2017 (UTC)
While I imagine this change would not affect most modules using the getTarget function, some of them may be relying on the fact that the returned title string doesn't include a fragment, so adding one may break them. To avoid breaking them, there are basically two choices: a) go through all the modules using getTarget and alter them to work with fragments if that is necessary (that search gets 103 hits, so it's doable); or b) edit the getTarget function in such a way that it doesn't break existing uses. For b) you could add a flag to either return a fragment or not, or my preferred solution would be to write another function like getTarget that returns a mw.title object instead of a string, and then use that function from the main function instead. If I were to write getTarget again, I'd make it return a title object, as that is more flexible than just a string. — Mr. Stradivarius ♪ talk ♪ 22:34, 19 March 2017 (UTC)
Thanks for the reply. So, there wouldn't be a way to do it just for this module? -- AlexTW 01:01, 20 March 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I wasn't thinking about fullText when I wrote that originally. My preference now is actually to switch to that altogether, assuming that it wouldn't break anything. Jackmcbarn (talk) 17:34, 20 March 2017 (UTC)

Would this be allowable? -- AlexTW 09:25, 23 March 2017 (UTC)
Sure, it sounds fine to me. Just make sure you don't break any of the modules that use Module:Redirect, that's all. :) — Mr. Stradivarius ♪ talk ♪ 14:45, 23 March 2017 (UTC)
Also, I'm not too sure what you mean by "a way to do it just for this module". Pretty much anything is possible - for example, you could copy the whole contents of Module:Redirect to a new module and then just edit that a little if you wanted. The important thing is what is going to be maintainable and reusable over the long run. Imagine that you are going to have to come back in six months and edit this module again - what would you do to make that process as easy as possible for yourself? — Mr. Stradivarius ♪ talk ♪ 14:50, 23 March 2017 (UTC)
I can think of a straightforward if inefficient way to go about this. You set up a parameter fulltext as suggested which makes FullTextFlag true; otherwise it's false. Then you replace *.prefixedText with FullTextFlag and *.fullText or *.prefixedText wherever it appears in the module. Then you preview each of the modules where you change the invoke to have the fulltext parameter set, and if need be save them like that for a few days/weeks to see if you get complaints. When every calling module (saving the most used for last) has successfully had the parameter set, you can then safely change that code above to *.fullText. And with no further complaints, you can revert each of the modules you changed the parameter in before. There are probably more sophisticated ways to do this... I personally don't think I'd trust my ability to preview all those modules and/or write up sufficient tests for all of them at once before committing to an edit. Wnt (talk) 22:43, 24 March 2017 (UTC)

## Are you using the (really) old wikitext editor?

Is anyone here using a wikitext editor that gives you a toolbar that looks like this (possibly with a few more buttons):

If you're using this, can you tell me why (e.g., personal preference, a tool that hasn't been ported to the 2010 wikitext editor, just never bothered to switch, anything)? Whatamidoing (WMF) (talk) 01:02, 21 March 2017 (UTC)

Looks like I am, did not know there was a later version of the editor, just the one you get by default. Keith D (talk) 01:44, 21 March 2017 (UTC)
They most don't change your preferences when potentially disruptive new options are introduced. If you go to Special:Preferences#mw-prefsection-editing and tick the box for "Enable enhanced editing toolbar", then you'll see the 2010 wikitext editor. Whatamidoing (WMF) (talk) 05:39, 21 March 2017 (UTC)
I use the old wikitext editor but have disabled the toolbars. Except for trivia, my editing is done in a text editor and the clean and simple old wikitext editor allows quick previews. Particularly when working with a module, I might preview stuff in a sandbox twenty of more times to try different things. This comment was written in a text editor. Johnuniq (talk) 06:40, 21 March 2017 (UTC)
I dislike screen clutter and have disabled the upper toolbar. There's another toolbar underneath the edit window which I haven't disabled but hardly use; the option there that I use most often is the one added by User:Anomie/unsignedhelper.js. -- John of Reading (talk) 07:19, 21 March 2017 (UTC)
I use the old one - the JavaScript payload is a lot smaller, and so page loads are noticeably quicker. It also takes up less vertical height, leaving more room for the real purpose of the page - the edit box - to fit into the viewport without scrolling down. I also don't need any of the buttons that it provides. --Redrose64 🌹 (talk) 09:43, 21 March 2017 (UTC)
"I also don't need any of the buttons that it provides." can you clarify to which toolbar 'it' refers here ? It's ambiguous. —TheDJ (talkcontribs) 10:48, 21 March 2017 (UTC)
I already stated "I use the old one" - see Wikipedia:RefToolbar, we have three available, and for me the old one is the only one that we had when I started, i.e. Wikipedia:RefToolbar/1.0; but I also don't need any of the buttons that either of the forms of Wikipedia:RefToolbar/2.0 provide.
I used the term "old" here because Whatamidoing started off by using the phrase "old wikitext editor" in conjunction with an image that shows something very similar to the Wikipedia:RefToolbar/1.0 toolbar as opposed to the 2.0 ones (although mine has several extra buttons, and some differ, so it looks much more like this except that mine doesn't have the ${\displaystyle {\sqrt {n}}}$ button that appears eighth from left in both that image and Whatamidoing's image). --Redrose64 🌹 (talk) 13:03, 21 March 2017 (UTC)
, seems like something that we could also easily measure with event logging is it not ? Or are the usage numbers too low for that ? —TheDJ (talkcontribs) 10:48, 21 March 2017 (UTC)
Event logging would count how many, but wouldn't give the "why". I'm guessing that this is an attempt to understand the usage rather than just measure it. Anomie 12:53, 21 March 2017 (UTC)
Anomie is correct: I'm trying to figure out why. The toolbar is under-maintained, rarely used (about 1 in 3,000 of the active editors), and it's not clear whether it's worth the resources to prevent death from bitrot. I was assuming that some of those ~50 editors were using it because it was the shiny new thing when they started editing in 2006, and that therefore I had a chance of finding smoe of them here. Whatamidoing (WMF) (talk) 15:22, 21 March 2017 (UTC)
I normally keep Javascript off - everything works way faster, with less worry about what hacks might be introduced into the site javascript, and also to marginally (because alas occasionally I do allow the script, like this time) reduce concern about what panopticlick techniques (cf. EFF) might be introduced, allegedly to further the endless hopeless war on sock puppets - so I don't see any of that. But when I enable it I see a different but similar bar with extra items for "special characters" and such; I'm not sure which version it is. Wnt (talk) 12:33, 21 March 2017 (UTC)
I probably would still be have the toolbar entirely disabled if it weren't for needing it to toggle CodeEditor between code and plaintext when editing things like Module and JavaScript pages. I never use it except for that. Anomie 12:53, 21 March 2017 (UTC)
Also, BTW, I note that we seem to have bug where, if you've disabled the "enhanced" WikiEditor toolbar in preferences since (probably) September 2016, the default-enabled refToolbar gadget will load it anyway due to JavaScript interpreting "0" as true rather than false like PHP does. I should fix that in MediaWiki, because it's probably affecting more than just refToolbar. Anomie 12:53, 21 March 2017 (UTC)
@Anomie: See also phab:T54542, I don't think that commit was a particular problem, it's always been a bit of a mess on that front. —TheDJ (talkcontribs) 14:01, 21 March 2017 (UTC)
Yuck, no you are right, this is significantly worse now. :( —TheDJ (talkcontribs) 14:08, 21 March 2017 (UTC)
local fix deployed. But this definitely is not nice. —TheDJ (talkcontribs) 14:24, 21 March 2017 (UTC)
I turned off the toolbar years ago (as all it does for me is allow me to accidentally click on it and reduce the amount of space available for the edit box). So lacking any toolbars, I don't know which editor I am using (other than not VisualEditor). —Kusma (t·c) 12:57, 21 March 2017 (UTC)

Um, how do I get my old toolbar back, please? I turned on "Enable enhanced editing toolbar", noted that it now took two rows to display buttons and didn't have my Cite button, and turned it back off. The new toolbar still loads despite a logout, browser restart, etc. Anomie, is this the bug you mentioned? --NeilN talk to me 13:30, 21 March 2017 (UTC)

@NeilN: should be better now, can you confirm ? —TheDJ (talkcontribs) 14:25, 21 March 2017 (UTC)
@TheDJ: Nope. I even turned "Enable enhanced editing toolbar" back on, saved, turned it back off, and saved. The "classic" toolbar appears briefly and then the new toolbar replaces it. --NeilN talk to me 14:36, 21 March 2017 (UTC)
You might have to bypass your browser cache. —TheDJ (talkcontribs) 14:54, 21 March 2017 (UTC)
Did that. Issue remains. --NeilN talk to me 15:45, 21 March 2017 (UTC)
Try going to this ApiSandbox link, verify that it looks sensible to you, and click "Make request". That should reset the preference to a better value. Anomie 16:55, 21 March 2017 (UTC)
@Anomie: That worked. Thank you. --NeilN talk to me 17:30, 21 March 2017 (UTC)
I'm still using this editor. I did try the new editor when it came out and had some problems with it. It's so long ago, I can't clearly remember what the difficulties were, but some tools/functions were either not available, or took extra clicks or typing to execute. Subsript and superscript might have been in that category, but as I say, I can't fully remember. SpinningSpark 16:06, 21 March 2017 (UTC)
I still technically use this editor, but like others have the toolbar disabled because I don't click any of the buttons (my meta CSS page shows the various clutter I hide). Long as I can continue to disable them with the 2010 editor, it wouldn't bother me to swap over. ^demon[omg plz] 16:36, 21 March 2017 (UTC)
2003 wikitext editor
It sounds like most of you (including Johnuniq, John of Reading, Kusma, Wnt, and ^demon) are using the 2003-era wikitext editor.
This is what you get with no Javascript and/or if you disable the toolbars via Special:Preferences. RedRose, have you considered switching to this one, since you don't need any of the buttons? It'd be very slightly faster for you. Whatamidoing (WMF) (talk) 17:05, 21 March 2017 (UTC)
I still use this, as it's considerably less cluttered than the "official" toolbar so isn't wasting valuable screen space with buttons I'll rarely if ever use, and the few buttons I actually use (super/subscript, hidden text, the RefTools cite button) are right there rather than buried in slow and cumbersome pop-up menus. ‑ Iridescent 17:06, 21 March 2017 (UTC)
+1 --NeilN talk to me 17:30, 21 March 2017 (UTC)
I use similarly the editor without toolbar as I never use the buttons. In case of non-trivial edits I load the contents of the edit window (via Firefox/It's all text!) into vim, edit it within vim with nice syntax highlighting for MediaWiki markup, and save it back to the edit window. --AFBorchert (talk) 17:37, 21 March 2017 (UTC)
My editor looks very much like the original image; i used to have one with all manner of buttons, bells and, possibly, a whistle, but i went back to this as all the other did was take space for stuff i didn't need. TBH, if i knew a way to get rid of the buttons at the top of this editor i might, as they are almost never of use to me. Happy days, LindsayHello 09:36, 22 March 2017 (UTC)
mw:Editor has the instructions you want (notes on the first item in the table). Whatamidoing (WMF) (talk) 20:06, 22 March 2017 (UTC)
I should add that the proper way to get custom characters on Windows involves setting some kind of custom keyboard key so that hitting say  changes the next letter, so you can a for umlaut a if you want, - for emdash etc. (There was even a way to make it three keys so you could use a for an accent and :a for an umlaut, etc) But I did that years ago on a laptop that died and forgot how; might be worth giving instructions on it somewhere prominent if anyone remembers how... Wnt (talk) 22:48, 24 March 2017 (UTC)
@Wnt: you're talking about setting up a Compose key. If our article is correct then there is no built-in way to get to get this functionality in Windows (I'm a linux user so can't verify this). Thryduulf (talk) 08:03, 28 March 2017 (UTC)

I still use this toolbar - the only button I use on it these days is "cite". I used to occasionally use "table" but not for several years I suspect. If I need to do anything more complicated I either type the wikicode directly or use visual editor. I have no idea whether I've turned it off or never turned it on, but if the former I guess it would have been a performance issue or something several years back. If it's the latter it's because I will never have seen a need to do anything with it - I use almost no scripts or gadgets (hotcat, popups, the insert bar below the editing window and tracking of phab tickets are basically it). Thryduulf (talk) 08:03, 28 March 2017 (UTC)

## Showing template nav in mobile view

Nav is an important part of a page. Can we add it to the mobile view? Golopotw (talk) 01:58, 23 March 2017 (UTC)

I guess you mean navigation templates. They are deliberately omitted in mobile to save bandwidth and screen space. Mobile does not have collapsible tables so they would all be expanded. They are excluded from the download so you cannot make them visible with user CSS. PrimeHunter (talk) 11:11, 23 March 2017 (UTC)

## Navigating between archived user talk pages

The redlink has been fixed thanks to JJMC89. -- Marchjuly (talk) 05:05, 23 March 2017 (UTC)
I've created User talk:Marchjuly/Archives/header for the top of your archive pages. Newly created archives will now use it instead of the default. If you're happy with it, it can replace the header on your existing archives. — JJMC89(T·C) 05:11, 23 March 2017 (UTC)
Thank you so much for taking the time to do all that. If you don't mind, then sure please fix the old pages as well. -- Marchjuly (talk) 05:33, 23 March 2017 (UTC)
Done. — JJMC89(T·C) 05:42, 23 March 2017 (UTC)
Thanks once again. -- Marchjuly (talk) 06:29, 23 March 2017 (UTC)

## Media widget?

Who develops the media player used to play movies on Wikipedia/Wikimedia? Is there a discussion page just for this widget? Thanks. 21:10, 23 March 2017 (UTC)

no one. I patch it up at times and have been trying to get it replaced with something more sensibel. —TheDJ (talkcontribs) 21:41, 23 March 2017 (UTC)
Do you think you could patch in a "Repeat" button? I have made cyclical animations such as this one that are meant to be looped back to the beginning and played again over and over. Thanks. 21:49, 23 March 2017 (UTC)
There is a ticket for something like that under phab:T116501. —TheDJ (talkcontribs) 21:57, 23 March 2017 (UTC)

## Afrikaans mail page

This may not be the appropriate venue, but if I try to reach the Afrikaans main page (Tuisblad), I just get a blank page

Has it been hacked? The Afrikaans community is in bed now because of the time difference, so if anyone can help here, I'd appreciate Jcwf (talk) 02:27, 24 March 2017 (UTC)

Is this still a problem? af: looks fine here. Johnuniq (talk) 02:31, 24 March 2017 (UTC)
Edit conflict. No, it is fine now. Thanks! Jcwf (talk) 02:32, 24 March 2017 (UTC)

## Module:Text count

There seems to be something wrong. For San Fernando, Cebu the list of its barangays in infobox should be …
San Isidro
Sangap

shouldn't it. Or am I doing something wrong? 112.198.82.25 (talk) 11:51, 24 March 2017 (UTC)

Sorry, don't understand. What "list of its barangays in infobox"? --Redrose64 🌹 (talk) 12:01, 24 March 2017 (UTC)
(edit conflict) Please clarify the perceived problem. Module:Text count isn't used in San Fernando, Cebu and the infobox (the box at the top right) has no mention of San Isidro or Sangap. The table in San Fernando, Cebu#Barangays mentions San Isidro and Sangat (t at the end). PrimeHunter (talk) 12:06, 24 March 2017 (UTC)
Here is another one at Siquijor, Siquijor
In infobox there is a line for {{PH barangay parts}} which takes Module:Text count. It seems like space and {{nbhyph}} are ignored.
San Fernando, Cebu#Barangays is not the problem. Wikidata for San Fernando (Q316318) shows the problem. (Sorry, Sangat) And Siquijor (Q174373). 112.198.82.25 (talk) 13:41, 24 March 2017 (UTC)
It still takes some work to figure out what problem you perceive. San Fernando, Cebu doesn't use {{PH barangay parts}} but if it's previewed there then it displays a collapsed list of the names at wikidata:Q316318#P150. Module:Text count counts the number of names. There are 21 names in the Wikidata item, there are 21 names in the list displayed by {{PH barangay parts}}, and it correctly counts there are 21. So I see no problem in Module:Text count. Are you thinking of the sorting made by Module:Sorted plain list? It places "Sangat" before "San Isidro" while it's probably more common to say space sorts before letters so "San Isidro" should come first. {{#invoke:sorted plain list|asc|San Isidro, Sangat, SanH, SanJ}} produces:
• Sangat
• SanH
• San Isidro
• SanJ
It currently ignores the space and displays in the order Sangat, SanH, San Isidro, SanJ. That's the second approach at Alphabetical order#Treatment of multiword strings. PrimeHunter (talk) 14:28, 24 March 2017 (UTC)
Pinging Frietjes who made Module:Sorted plain list. PrimeHunter (talk) 14:31, 24 March 2017 (UTC)
I'm not a Lua coder but it looks like the module simply calls the Lua function table.sort which uses a default Lua sort order. It's possible to supply your own order function but I guess it would complicate matters and hurt performance. If there is no serious problem with Lua's sort order then I think we should stick to it. Ignoring spaces and some special characters seems like a valid option to me. PrimeHunter (talk) 14:53, 24 March 2017 (UTC)
yes, the sort is based on the default string ordering in LUA. it is possible to change the comparison function (indeed we do something special for numbers) but you would need to do some additional string processing. Frietjes (talk) 18:19, 24 March 2017 (UTC)
if the question is how to have the list appear in the infobox, then the answer is that you would do this. Frietjes (talk) 18:25, 24 March 2017 (UTC)
Certainly you can add a parameter to use a different sort function; that wouldn't adversely affect performance anywhere it wasn't specified. But what order do you want? You'll have to be very clear. Wnt (talk) 22:54, 24 March 2017 (UTC)
Sorry I had a bit of it wrong when I started this question. I had the {{PH barangay parts}} ready to get the problem, as I hadn't actually committed the update. So yes it should have been same as Frietjes tried. As I said, a better looking problem can see in Siquijor, Siquijor. Basically, it should have the list emitted "normally".
{{#invoke:sorted plain list|asc|San Blas, San Carlos, San Isidro, San Tomas, Santa Fe, Santa Ursula, Santat }} produces:
• San Blas
• San Carlos
• San Isidro
• Santa Fe
• Santat
• Santa Ursula
• San Tomas

I think it should be the first approach at Alphabetical order#Treatment of multiword strings.
[
As an aside, but there was a problem with a name including a comma. There was only one. I had to change Juan Climaco, Sr. (Magdugo) to become Juan Climaco‚ Sr. (Magdugo):
{{#invoke:sorted plain list|asc|Juan Climaco, Sr. (Magdugo) }}
• Juan Climaco
• Sr. (Magdugo)
versus
{{#invoke:sorted plain list|asc|Juan Climaco‚ Sr. (Magdugo) }}
• Juan Climaco‚ Sr. (Magdugo)
]
112.198.82.25 (talk) 02:14, 25 March 2017 (UTC)
the sort order is determined by the result of the LUA string comparison, so if you want a different sort order, you have to create a different string comparison function. as for the comma in "Juan Climaco, Sr. (Magdugo)", clearly, if you asking it to split on the comma, it will split on the comma. if you have commas in the entries, then use a different delimiter. as for an actual problem in an article, when I check Toledo, Cebu there seems to be no actual problem in the list in the infobox since you used "," instead of "," for the comma. Frietjes (talk) 13:03, 25 March 2017 (UTC)
Reading the first option, it basically treats space as the highest alphabetical value, whereas the second omits it. I was disappointed to find that ~ and @ have the same treatment as space, but still {{#invoke:sorted plain list|asc|SanZZZZZZIsidro, Sangat, SanH, SanJ}} -> >
• Sangat
• SanH
• SanJ
• SanZZZZZZIsidro
. We can do a simple substitution of all the input parameter spaces to ZZZZZZs and then back again in the output, and put a note on it that the module doesn't work on text containing ZZZZZZ when the alternate sort algorithm parameter is set. Then we have a working option with only a small linear-time overhead for the substitution, rather than doing the whole sort more slowly. (This is still an awful kludge ... there must be a better way someone is about to tell me...) Wnt (talk) 19:19, 25 March 2017 (UTC)

## My user script files (local and global) and gadgets have stopped working consistently

I have local (User:StevenJ81/common.js) and global (m:User:StevenJ81/global.js) script files that I use regularly here. Up until about two weeks ago, they generally ran correctly. Every once in a while I'd have a problem that they didn't automatically load; I attributed that to issues with MediaWiki upgrades, because by a week later or so, when the next upgrade was loaded, things starting working right again. However, this time, it's been about 2.5 weeks, and things are still not working right.

Here are some technical details:

• Started two weeks ago, I think right after a MW upgrade.
• I've seen the problem on two different computers. One is running Windows 7 Enterprise, and I've had problems both under Google Chrome (my usual browser, v. 56.0.2924.87) and also under IE (v. 11.0.9600.18537). The other is running Windows 10, again with Chrome. However, I don't have the problem on my iPad (iOS 10, running Safari, running in desktop rather than mobile mode).
• Bypassing the cache helps sometimes, but not always.
• Similarly: sometimes my script files load properly, sometimes they don't. On enwiki, they probably load properly more often than they don't, but no more than about 2/3 of the time. On Meta, they rarely load properly at all.
• Looking at the JS console, even when pages run correctly, I am told I'm using some deprecated modules. When the pages don't run correctly, I also get an Uncaught TypeError: Cannot read property 'add PortletLink' of undefined and then gives me links to four different times it could not do so.
• Testing the situation by removing certain tools from the script files one at a time does not consistently help.
• To repeat: until 2.5 weeks ago, things were working correctly.
• If this were only affecting my script files, maybe that would be my problem. But it also affects gadgets and mw:Extension:Translate.

If someone can be of assistance I'd greatly appreciate it. StevenJ81 (talk) 19:06, 24 March 2017 (UTC)

That error message suggests that "mw.util" is undefined, which means the module wasn't loaded properly. Try wrapping your code in
 mw.loader.using( ['mediawiki.util'], function () {
// [rest of code]
});

Pppery 19:29, 24 March 2017 (UTC)
I already fixed your common.js script, I hope you'll be able to copy the strategy towards your global script file on meta. —TheDJ (talkcontribs) 20:55, 24 March 2017 (UTC)
Thanks to both. I'll try to get to them tomorrow night or Sunday. StevenJ81 (talk) 22:41, 24 March 2017 (UTC)
@TheDJ and Pppery: That seems to have done the job. Thank you very much. StevenJ81 (talk) 02:29, 26 March 2017 (UTC)

## Won't start a new line when it should

I've had this problem maybe 200 times in 43,000 edits spread over 7 years. (so it's only happening about once in 200 edits) So I assumed it was common and thought I could find it in the archives but couldn't. Each of these times is a case where there is a new line in the editing text but the text is all run together, i.e. there is no line break where there should be one.) when the page is displayed. Usually I can fix it by just entering a new line. This morning I just had the most stubborn one ever (at the bottom of the wp:ver talk page by the subsection title "Force line break") where the line break was badly needed where nothing I put in could cause a line break until in desperation I put in a section header just to cause a line break. This has been on many different computers although the only browser I use is Firefox. Does anyone know the cause or fix of the problem? Is it likely to show only on my computer (in which case I could just leave it) or would the problem show up all over the place? North8000 (talk) 19:55, 24 March 2017 (UTC)

. In this particular case it is because the author before you User:S Marshall, was adding raw <p>'s, without closing them with </p>. —TheDJ (talkcontribs) 20:49, 24 March 2017 (UTC)
Thanks! Also curious about the more common case where a blank line is all that it takes to fix it. North8000 (talk) 21:08, 24 March 2017 (UTC)

The default behaviour of wikitext has always been that a newline in the source does not produce a newline in the rendering. This sentence is on its own source line but the rendering doesn't show that. To get a new rendered line you need something other than a single newline, for example a blank line (i.e. two consectuive newlines), a <br />, or at least one of the two lines starting with a colon or asterisk. See more at Wikipedia:Line-break handling. PrimeHunter (talk) 21:30, 24 March 2017 (UTC)

Wow. I remember the days when <p> was a self-closing tag and closing it was frowned upon. It surprises me that closing it is now obligatory, and failing to do so creates a hard to find bug ... was MediaWiki always like that, or was something changed? Wnt (talk) 23:05, 24 March 2017 (UTC)
The wikicode parser has many quirks. I didn't know this one, but it doesn't surprise me either. When you mix html parsing, with wikicode parsing and then need several sanitizer runs, things start behaving weird :) Doubt it's new behavior however, we almost never make changes to the parser anymore (exactly because it's impossible what weird stuff would break). —TheDJ (talkcontribs) 13:05, 25 March 2017 (UTC)
That wasn't the case here, North8000 (talk · contribs) did have double newlines - and even tried changing to a triple newline - but the text still ran together. --Redrose64 🌹 (talk) 23:36, 24 March 2017 (UTC)
Yes, I was replying to "Also curious about the more common case where a blank line is all that it takes to fix it." I omitted indentation to demonstrate that a single newline has no effect. PrimeHunter (talk) 23:50, 24 March 2017 (UTC)

Thanks to all! I never noticed that a single line break never forces a new line. I guess I missed it because it's rarer to do that than I realized. Usually line breaks are also a paragraph breaks or something else like bulletting. Sincerely, North8000 (talk) 16:42, 27 March 2017 (UTC)

## Unexplained italics in an article

Several paragraphs in the Cowdenbeath article appear in italics even though they aren't enclosed in a pair of double apostrophes. It looks odd and I've tried to remove it but I've had no success and can't figure out what is causing the problem. Can anybody diagnose and fix this nonsense as it has me stumped! Keresaspa (talk) 00:58, 25 March 2017 (UTC)

this seems to fix it. My method was to remove ... stuff ... until the italics went away. The DIVs were obvious candidates, both in terms of their location immediately above the first instance, and then because they're just plain not the way we do things here. Why they had the result they had is above my pay-grade. --Tagishsimon (talk) 01:29, 25 March 2017 (UTC)
Ah, I missed those. Thank you very much though, a job well done. Keresaspa (talk) 19:49, 25 March 2017 (UTC)

## Just can not edit Wikipedia

For last 2 hours, I am unable to edit Wikipedia. "Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in."
I tried logging out and logging in. Now trying to post now from IP. -- User:Titodutta posted from the 2406:E00:100:EC26:C4E7:B356:863E:4C75 (talk) 18:00, 25 March 2017 (UTC)

See Wikipedia:Village pump (technical)/Archive 153#"Loss of session data". PrimeHunter (talk) 18:10, 25 March 2017 (UTC)
• a) login.wikimedia,org suggestion did not work here, I am using Firefox 52.0.1 (32 bit). a) I was able to to save edit from private window from my account Titodutta and b) general window anonymously (like the post above), but can not make edit once I log in to my account from Firefox. Chrome is working. --Tito Dutta (talk) 18:31, 25 March 2017 (UTC)
Have you tried to delete the cookies for wikipedia.org and wikimedia.org in Firefox? PrimeHunter (talk) 18:41, 25 March 2017 (UTC)
• I deleted wikipedia.org and wikimedia.org cookies from Firefox, and then logged in. It is  Working now. Wow. Thanks. --Tito Dutta (talk) 18:49, 25 March 2017 (UTC)

## Link to talk page goes to notices instead

The process for using Phabricator to report a bug is too difficult for me to handle. So I will just describe the bug here.

For the last few weeks, when I click on the "talk" icon in the list of links at the top right of a page, it frequently goes to notices instead. Indeed when I just hover over "talk", it says that I am selecting notices. However, after I get the notices and dismiss them, it usually works correctly the next time. JRSpriggs (talk) 00:49, 26 March 2017 (UTC)

Could you explain what is too difficult so we could improve the documentation on login and mw:How to report a bug? --Malyacko (talk) 13:55, 26 March 2017 (UTC)

## Content model change - is it valid?

I'm fixing up a series of bad edits made by Jo-Jo Eumerus (talk · contribs) to templates, and I've found this change to the content model. Was it a valid change? The page is not just CSS, it's got Wikitext as well, albeit enclosed in a <noinclude>...</noinclude>. I recall that content model changes caused a lot of trouble last year (see Wikipedia:Village pump (technical)/Archive 144#Wikitext on .js page; Wikipedia:Village pump (technical)/Archive 147#MW Error message when undoing "content model" change. --Redrose64 🌹 (talk) 19:16, 26 March 2017 (UTC)

I did test it in my user sandboxes beforehand, where it didn't change the display of the transcluded template. The issues linked there are different, the first is people having the wrong content model on a page where it is supposed to be JS and the second was an issue with how the page history interacts with content model changes. Jo-Jo Eumerus (talk, contributions) 19:21, 26 March 2017 (UTC)
Content model changes affect the display of a page, not really how it is transcluded: See User:Jo-Jo Eumerus/sandbox2, User:Jo-Jo Eumerus/sandbox3 and User:Jo-Jo Eumerus/sandbox4. Jo-Jo Eumerus (talk, contributions) 19:30, 26 March 2017 (UTC)
My humble opinion is that changing the content model should occur only when it provides a substantive benefit. I think the only effect in the above example is that Template:Divbox/style/gray looks pretty, and that is not sufficient to balance the confusion to people wondering why it looks pretty and what a content model is. On that last point, can someone explain the implications of setting a content model? The waffle at mw:Help:ChangeContentModel does not do the job. For example, does the js content model enable execution of script? Johnuniq (talk) 01:50, 27 March 2017 (UTC)
@Johnuniq: Content model changes change the way the page displays, like introducing the boxing for JSON pages, syntax highlighting in JS and CSS pages and forming the list format in MassMessage pages. So yeah, it's mostly a cosmetic thing - I'll stop doing it. Unless it's on an userspace page, then changing the content model from and to CSS/JS can cause the automatic protection that user JS and CSS enjoy to disappear (or appear), so one must be careful there. Jo-Jo Eumerus (talk, contributions) 14:46, 27 March 2017 (UTC)

## Categories for .js pages

Another editor asked me why some other editor's userland .js page was in several cleanup categories. With some testing, it appears that [[Category:]] strings are recognized no matter where they appear. In the case at hand, it was in a template that was in a JavaScript string, so the parser is actually even doing the wikitext transclusion on a JavaScript page. See User:DMacks/test.js for a demo. Should Content model=JavaScript inhibit categorization altogether? DMacks (talk) 13:38, 27 March 2017 (UTC)

.js pages have different content models which control how the page displays, but they pretty much function in the same way as regular pages, including categorization. As for inhibiting categorization, speedy deletion notices on user .js pages would become invisible to admins patrolling the CSD categories, so perhaps not. Jo-Jo Eumerus (talk, contributions) 14:48, 27 March 2017 (UTC)
This initially was not the case, but people were complaining that what links here of something like // [[User:TheDJ/script.js]] and indeed categorisation for the purpose of deletion notices etc. wasn't working. The parser basically always runs the wikicode parser on such a page, explicitly to make make sure that such things keep working. It throws away the wikicode HTML output, but keeps all the metadata connections and output. —TheDJ (talkcontribs) 14:58, 27 March 2017 (UTC)
Ooh good point about CSD, and backlinks. Is there a way to protect chunks of the code from being seen (like <nowiki>)? Obviously one could get creative and split these sorts of strings into concatenated parts, but it seems like a lot of work-around. DMacks (talk) 16:16, 27 March 2017 (UTC)
// <nowiki> and // </nowiki> can be used. You can see it in my common.js. ({{copyvio-revdel}} transclusion is prevented, so the page is not categorized.) — JJMC89(T·C) 20:13, 27 March 2017 (UTC)

Disabling is the same as in lua, see (http://dev.wikia.com/wiki/Lua_templating/Style_guide#Escaping_wikitext). — Preceding unsigned comment added by 197.218.80.220 (talk) 17:22, 27 March 2017‎ (UTC)

Another way to do it, if there is only a couple of occurrences, is to use multiple strings instead of a single string, e.g. var foocat = "[[" + "Category:Foo" + "]]"; - Evad37 [talk] 00:17, 28 March 2017 (UTC)

## Tech News: 2017-13

14:46, 27 March 2017 (UTC)

## Discussion at ANI about Wikidata use in mobile view

See Wikipedia:Administrators'_noticeboard/Incidents#Hard_to_detect_mobile_vandalism Jytdog (talk) 04:52, 28 March 2017 (UTC)

## section headings not functioning correctly

At Wikipedia:Redirects for discussion/Log/2017 March 27 there are 13 level 4 section headings, however headings 1.6-1.9 ("Agie", "Mankri", "Amtrak acs64 622" and "Twenty One Pilots (album)(redirects)") have no edit links, and their content is visible when you click to edit section 1.5 ("First aerial victory by the U.S. military") as if they were subheadings. All the wikimarkup in those sections works as expected and the anchor links from the table of contents work exactly as they should too. I can't see anything in section 1.5's code that is obvious to me but I'm no coder. Thryduulf (talk) 08:08, 28 March 2017 (UTC)

Fixed, I think. A bracket mismatch in a link meant everything after an opening {{ was considered part of a template. Nthep (talk) 08:18, 28 March 2017 (UTC)