Wikibooks:Reading room/Technical Assistance

Replacement filing cabinet.svgArchivesWikibooks Discussion Rooms
Discussions Assistance Requests
General | Proposals | Projects | Featured books General | Technical | Administrative Deletion | Undeletion | Import | Permissions

Welcome to the Technical Assistance reading room. Get assistance on questions related to MediaWiki markup, CSS, JavaScript, and such as they relate to Wikibooks. This is not a general-purpose technical support room.

To submit a bug notice or feature request for the MediaWiki software, visit Phabricator.

To get more information about the MediaWiki software, or to download your own copy, visit MediaWiki

There are also two IRC channels for technical help: #mediawiki for issues about the software, and #wikimedia-tech for WMF server or configuration issues.

Renaming Book PagesEdit

How do I rename a Book Page? When I change the name of the Book Page, it seems that the link to the old page is broken and I have copy the old content to the new page that was created as a result of renaming. TIA!

--Rjbfigueroa (discusscontribs)

@Rjbfigueroa: Can you give an example of a page you wanted to move, and where you wanted to move it to, so we can see what happened?

Fwiw, here's how to move a page, if you're using Vector skin (in the desktop interface, rather than the mobile one): View the page you want to move (not its talk page). There should be a control bar at the top of the browser, and way over on the far right of it there should be a dropdown menu. The only option on that menu should be either "rename" or "move"; use that. --Pi zero (discusscontribs)

Scroll bars on preformatted blocksEdit

Since this morning, a new phenomenon: each preformatted block in my sandbox has an inactive scroll bar. Is this a new feature of MediaWiki software? Something I've activated by my styling edits? Thanks, ... PeterEasthope (discusscontribs) 22:42, 12 April 2020 (UTC)

OK I've played around a bit, and this is what I've found out:
  • On my system the scroll-bars display on the Chrome browser but not on the Firefox browser.
  • It seems related to the font-size: small; property; if this is removed they go away.
  • But a better solution is to add the overflow:hidden; property, e.g. like <pre style="font-family: monospace, monospace; font-size: small; line-height:1.1; font-weight: bold; background-color: white; border: none; padding: 0;overflow:hidden;">. They then seem to disappear.
I think its some sort of Chrome or Mediwiki bug, can't see why non-functional scroll bars would appear. Tested it on Wikipedia and you get the same thing. But anyway my last point seems to be a workaround that can be used. --Jules (Mrjulesd) 09:24, 13 April 2020 (UTC). Another comment: they seem to appear dependent on the level of zoom on the page, they otherwise disappear. --Jules (Mrjulesd) 09:38, 13 April 2020 (UTC)
I saw them last night in Firefox, but don't see them anymore now. --Pi zero (discusscontribs) 16:23, 13 April 2020 (UTC)
Oh that's interesting. But you can't see them in the sandbox now the code has been changed. But the previous code was like:
$  number  =  integer | real.
$  integer  =  digit {digit} | digit {hexDigit} "H" .
$  real  =  digit {digit} "." {digit} [ScaleFactor].
$  ScaleFactor  =  ("E" | "D") ["+" | "-"] digit {digit}.
$  hexDigit  =  digit | "A" | "B" | "C" | "D" | "E" | "F".
$  digit  =  "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9".
I can't see them in firefox at all, whatever zoom level I have. But still on Chrome at certain zoom levels. Very odd, but there you go. --Jules (Mrjulesd) 18:16, 13 April 2020 (UTC)

Technical problems encountered by Wikibooks:Edit filter/URL requestsEdit

@MarkJFernandes: following on from the technical problems you're encountering at Wikibooks:Edit filter/URL requests. Basically they're very curious and I no real understanding of what's going on here. But I would like to ask some questions.

  Question: Are you autoconfirmed? You can tell by going to Special:Preferences; under "Member of groups:" does it state "Autoconfirmed users"? See Wikibooks:Autoconfirmed users for an explanation.

The reason I'm asking is that Ive looked at your account at , and I've seem a curious thing; according to the log you were "2020-04-15 14:42 autoconfirmed user Automatic". But looking at your "User groups" field it is blank. That shouldn't be the case; e.g. look at my one at .

Now I really don't understand why these should contradict each other, an I feel there may be a technical problem with your account. --Jules (Mrjulesd) 12:54, 15 April 2020 (UTC)

@Mrjulesd: thanks for looking into this in some detail. So I am not in the autoconfirmed group—I'm only in the Users group. I'm exceptionally new to Wikibooks, so perhaps `there are some hoops I need to jump through` before things start running more smoothly for me?
--MarkJFernandes (discusscontribs) 13:33, 15 April 2020 (UTC)
OK thanks. I've been trying to work out the meaning of the xtools page. What it could mean is that you are going to be autoconfirmed at 14:42 GMT today (it is currently 13:52). Now if you get autoconfirmed it could mean that problems will decrease, as most edit filters don't apply to autoconfirmed users. So it might be worth waiting a while and see if you get autoconfirmed; if so you may find that it solves your problems.
Now I'm not saying that this will happen, but I think it would fit in with your en.wikibooks account, that was registered 14:42, 11 April 2020. Since it takes 4 days for autoconfirmed status, it all makes logic to me. --Jules (Mrjulesd) 13:58, 15 April 2020 (UTC)

How to tag words and phrases in a book, such that Wikibooks can then automatically generate an index using such tags?Edit

If you read the text at, you'll see that Wikibooks says that a navigation template can be used to create an index. However, after clicking the related hyperlink, I can't seem to find information about how to do this. Can someone point me in the right direction?

--MarkJFernandes (discusscontribs) 17:37, 17 April 2020 (UTC)

  • @MarkJFernandes: My best guess —which of course could be quite wrong— is that the reference you're asking about, where it says a navigation template can be used to create an index, doesn't mean there's any way to automatically create an index, it just means that if you do want to create an index, you can use a navigation template as a way of making it available throughout the book. I have put some thought into this sort of thing myself, and have lately developed an extensive glossary for the Conlang wikibook (Conlang/Appendix/Glossary), but I'm continually thinking about ways to improve it. Part of my idea there is that, since we don't really like to have links in the middle of a book that go out of the book altogether, all the "outward" links in the body of the book could go to the glossary, and then only at the end of each glossary entry would there be links out of the book. (Likely at some point I'll construct some sort of semi-automated assistant to help with that glossary, based on the dialog tools, and perhaps then I can generalize that... but that's not all going to happen tomorrow.) --Pi zero (discusscontribs) 19:13, 17 April 2020 (UTC)
@Pi zero: thanks for your reply. Not sure whether I agree that external links should only be in the glossary. I'm quite happy for external links to be in the main body of the work.
Coming back to the idea of tagging key words and phrases for automatic index generation, I think such a facility would be great. When using online reading resources, I often use any indexes in such resources. I have some coding skills—just wondering whether I could code the template for such a facility. Perhaps someone could point me in the right direction for creating such a template?
--MarkJFernandes (discusscontribs) 07:34, 18 April 2020 (UTC)
@MarkJFernandes: Two miscellaneous thoughts.
  • As an alternative to an index as-such, you might consider {{book search}} (you can see it used on the main page of Conlang, at the top of the right-hand panel).
  • Minimizing (but not completely eliminating) links outgoing from a book is just usual in Wikibooks culture, as part of the coherence of a book (part of what makes a book a book). Avoiding outgoing links entirely in the book body is something I'm experimenting with, partly because the Conlang book has so many outgoing links. It allows providing commentary on each outgoing link, that will be encountered by each reader following that link as they pass through its glossary entry, provided some effort is put into offering brief-but-valuable perspective in each glossary entry.
--Pi zero (discusscontribs) 11:32, 18 April 2020 (UTC)
@Pi zero: thanks for some useful advice/guidance. In regard to the search box, I did think about whether indexes were really needed given that you can just use a search box to search for specific words/phrases. It should be noted that many modern online reading resources (such as manuals) still do include indexes perhaps pointing to them adding value over simply having a search box. Indexes give a good overview of different important elements found in the narrative of a book, beyond what you get with just a table of contents. Because semantic relations in language often are alphabetical (such as for example 'computer software' coming just after 'computer platform' with both being associated [because both are about computers]), alphabetical indexes can be extra helpful. To be honest, adding an index isn't essential for my book, but it is on the wish list.
I'm very much new to Wikibooks, so I may make a few mistakes in my thinking related to Wikibooks books. However, the book I'm working on has very many external links mostly to Wikipedia articles, and I feel that this is the right thing to do. The idea is to provide users with an easy way to learn about highlighted terms and phrases. It's just about extra information that I believe shouldn't be in the book, but is usefully linked-to, to provide extra and sometimes essential explanations about things. In respect to book coherence, my opinion is that if I put the linked-to material in the book, the book would lose its coherence, because it would become over-bloated and also because it would be out-of-date due to the otherwise linked-to material being updated more frequently than the book. I'll concede that including a glossary is perhaps another good way to provide such extra information, but then you still have the issue about material becoming quickly out-of-date.
--MarkJFernandes (discusscontribs) 13:41, 18 April 2020 (UTC)
@MarkJFernandes: While we're on the subject(s),
  • I'm a big believer in manually processed indices and glossaries and such, rather than mere automatic searches. Yes, automatic searches can be a useful tool. I learned my way around libraries pre-internet, though, when they had physical card catalogs, thousands upon thousands of index cards all carefully crafted with individual thought; and when those were replaced by on-line catalogs, at most (not all) libraries the quality of searches went down by quite a lot. Turns out the software for those on-line catalogs allowed all the nuanced information from the old physical cards to be put in, and if you did that you could produce a really awesome on-line search system, which a few libraries actually did with excellent results; but most libraries just had somebody type in the minimal information, and almost all the deep information in the old cards was just thrown away. So, like I said, I really favor indices and glossaries with a lot of customized thought gone into them. This also means that if an index were to be generated, I would favor some means of guaranteeing that hand-crafted information goes into it, both when it is first set up, and in however it is maintained. As an example to think about, we have on Wikibooks a hierarchical arrangement of "shelves", starting at Wikibooks Stacks/Departments; all the sorting and listing is handed semi-automatically, but human beings decide how to hierarchically order the shelves, and human beings decide, for each book, what shelves it should be placed on. Thus, the individual decisions that go into forming the shelves are distributed to where the users are who have the knowledge to inform those decisions.
  • Regarding links out of a book. Part of what makes a book a book is that it is, to a significant extent, self-contained. Usually there is a particular order in which the modules are meant to be read; a relatively few books aren't exactly linear in that sense, but then the modules within them are generally of a specialized sort (like Wikijunior:Solar System, or Wikijunior:The Elements). Links going out of the book are less intensive than, say, the cross-links between articles on Wikipedia. There is also a difference between the projects in depth: a wikibook can go very much further into the details of its subject than a Wikipedia article would. There is, in effect, a hierarchy of how a book module is linked: we're most casual about linking to elsewhere in the same book, a bit more reluctant to link to (or into) another wikibook, a bit more hesitant still to link to a page on another project in the wikimedia sisterhood (such as Wikipedia), and decidedly more cautious about "external links", i.e. links to outside the wikimedia sisterhood, since that involves a definite drop in trust/privacy of the server. (All of the wikimedia sisterhood prefers to set off external links so readers are especially aware before clicking one of those.)

    Which said, although it's clearly desirable to minimize links out of a book, it's not always clear how best to go about it. What sort of measures make sense depends on the character of each individual book. I'm hoping, with the thing I'm trying for the Conlang glossary, to add to our vocabulary of techniques for this sort of thing. It seems to work quite well for that particular book, but I only offer it as food for thought, as the circumstances of your particular book are unlikely to exactly duplicate those of Conlang.

--Pi zero (discusscontribs) 15:58, 18 April 2020 (UTC)

👍🏽   👤

Book search that lists more than one result per pageEdit

I've tried out the {{book search}} and the {{search box}} templates on the book on which I'm working. They work as they were intended. However, for my book, I would like for more than one result found in a page to be returned, when more than one match is found in a page. As far as I can tell, these templates, and the standard Wiki search functionality across the Wiki Foundation sites, do not have this functionality.

I would like more than one result to be returned, because each chapter (some of which are quite long) is contained each on its own page. I feel this is better than splitting the chapter up into several web pages—it makes browser searches (Ctrl+F, etc.) easier and also makes following the narrative that runs through any one chapter easier (IMHO).

Can anyone give me any pointers on how I can satisfactorily resolve these issues?

My thoughts on a solution:

  1. create a directory/folder for each sub-section of the chapters;
  2. proceed to create one wiki page for each subsection (in the directory), that on-the-fly extracts (via something like an 'includes' statement) the subsection from its source chapter page;
  3. on each of these subsection pages, have a link that links back to the subsection as present on the corresponding chapter page;
  4. now when book search is performed, each of these sub-section pages can return a hit, potentially resulting in more than one result per chapter, which whilst not always providing a perfect correspondence to matches, perhaps is acceptable at least for my particular book.

The above solution seems okay but I don't know how to implement the 'includes' functionality—anyone have any ideas?

--MarkJFernandes (discusscontribs) 08:54, 28 April 2020 (UTC)

ADDENDUM NOTE: it appears that the Wiki transclusion functionality can probably implement the 'includes' functionality mentioned (see Transclusion). --MarkJFernandes (discusscontribs) 06:34, 29 April 2020 (UTC)
Some thoughts. Well, okay, I've ended up writing rather a lot, below; it's all reasonably brief and to-the-point until I start talking about dialog; well... half-sorry about that, but it is relevant.
  • The essential problem is that the wiki-search feature provided by the wiki platform is, conceptually, separate from the string-search provided by the user's web-browser. They don't actually complement each other as one might hope they would; it's more like, they awkwardly divide up the task into separate domains, and each of them insists on handling only one half of the task, while the user is obliged to switch from one mode to the other halfway through their search. That is, the on-wiki search imitates internet search engines (and probably uses one), which have pages as their end targets; while the browser string-search locates occurrences of that string on the particular page that is being viewed. If these are the tools available to you, and you want to find all the occurrences of a string on all the various pages of the book where the string occurs, you have to use the two successively, finding the pages with the first tool and then using string search on each page. A compounding problem is that both these tools are blind to semantics: they search for a string mechanically, without regard to the actual meaning of things. Taking meaning into account is the function of a humanly-constructed index. Sometimes one will see a really sophisticated index in a book, under a particular keyword, distinguish somehow between one or more primary/major references to the keyword, and a bunch of secondary/minor allusions.
  • If you had a really good index, what would you like to be its targets?
  • Btw: The standard terminology set out for Wikibooks long ago calls the content pages of a book "modules"; it never really caught on, perhaps because it's neither standard enough to come naturally to users as they arrive at the project, nor gets used heavily enough once the user arrives to make an impression on them. As an illustration of the latter, on Wikinews the term "lede" is so ubiquitous that pretty much everyone ends up knowing what it means.
  • Would it be satisfactory for an index to target section-headings within modules? This is what I did with the Conlang glossary, though rarely have I wanted to link a single keyword to more than one section within the same module.
  • The problem is then how to assemble such an index. There are some devices I think could be useful for this, some of which are more ready-for-prime-time than others.
  • There may be ways to accomplish a great deal without relying too heavily on the parts that are less developed atm. For instance, the Wikibooks Stacks get along, more or less, with less tooling than I would imagine eventually bringing to bear on them. An index-building device might work from embedded meta-information in each section of each module, specifying what index entries ought to target that section. One would then want to extract this meta-information from each module and collate it all to generate an index; and there are a range of different levels of semi-automation that might be employed for that.
  • I should perhaps explain about the overall plan that surrounds the "dialog tools", because this has to do with what the parts are, how they are meant to be used together, and which parts are more ready-for-prime-time that others. (And this, alas, is where the length of this comment gets away from me...)
  • It all starts with the notion that wikis could become vastly more powerful, wholly transforming the nature of the medium, if only they could have interactive elements freely placed on them: imagine a wiki page with a variety of text input fields (along with perhaps occasional drop-down menus and checkboxes), and a bunch of buttons one could click each of which would take data from the input fields and send it somewhere to have something done with it. With a small number of simple templates that would allow specifying elements of these kinds, so they could be placed on the wiki page via wiki markup (things like, say, {{dialog/text}}, {{dialog/checkbox}}, {{dialog/button}}, etc.). The good news is, that can be done, and I basically have done that and it's available on Wikibooks now. But there are some caveats. To make these simple primitive elements practical to use, you need about three additional things. (I'd always figured that, once you had the primitive elements, there'd be a long process of learning idioms for how to use them, details of which would be inherently impossible to anticipate before one had the tools available to actually work with.) You can read about the simple primitive elements, btw (I mentioned this once earlier, I see), at Help:Dialog.
  • You need a way to organize sets of pages into coherent "semi-automated assistants"; these assistants are, more-or-less, "wizards" for performing particular tasks. I've set up a way of grouping the pages of an assistant together that's inspired by the way Wikibooks groups the pages of a book together. (The primitive-tool development, btw, is happening on Wikinews, because the license there is more permissive than other sisters, so the tools can be exported from there to, say, Wikibooks. The latest version of things hasn't been ported over to Wikibooks yet; I'm waiting for the latest improvements to be just a bit more stable before tangling with that.)
  • The main example of an assistant that I already have working is Breadboard. (Basically, it lets you write wiki markup that depends on template-parameters and test it by specifying what the values of the template-parameters should be; actually those aren't template parameters, they're dialog parameters, but, close enough for most purposes.)
  • You need some peripheral tools to help with doing, e.g., complicated transformations on the contents of web pages that the wiki platform isn't good at but that you also do not want to have to build into the dialog tools (because it's logically separate from the native function of the dialog tools). I explicitly want users to specify everything in wiki markup, which I consider essential to the reason wikis are a successful concept (I'm actually rather passionate about this); I believe the Wikimedia Foundation has been shooting itself in the foot, for many years now, by trying to migrate away from wiki markup to other languages, like Lua. I only use Lua, or even javascript, to build tools whose purpose is to help users not have to use anything but wiki markup.
  • The primary peripheral tool I've created is {{evalx}} (mostly an interface, as it happens, for Lua Module:Wikilisp). And evalx I've found immensely useful. It should be able to do things like combing through a module of a wikibook to extract meta-information from it that specifies how to build index entries targeting sections of that module, or using that extracted information to update an index page. With... some careful thought about how best to arrange those things. And perhaps a bit of dialog to direct the input to, and output from, the evalx template.
  • Ideally, ordinary users would contribute to assistants in the same way they contribute to ordinary wiki documents (such as wikibooks), and so assistants would be "grown" by crowdsourcing. Likely this ideal should be striven for but won't ever be perfectly achieved. But, whenever a wiki task is performed over and over and is tedious or tricky requiring some expertise, it's a good candidate for an assistant. And here's the thing: building and maintaining assistants is a task that's tedious and tricky requiring some expertise. So it's an obvious choice to build an assistant for building-and-maintaining assistants; a "meta-assistant". This would probably go a very long way toward making assistants more practical. Can that even be done? I think so, yes; but I expect it to be fiendishly tricky to tease out just how to do it. I'm working on it; but right now that's the number-one cause of slow development of the whole dialog-based-assistant concept, and it's nothing to shake a stick at.
--Pi zero (discusscontribs) 14:28, 28 April 2020 (UTC)

👍🏽   👤

A link in a preformatted textEdit

Inside a preformatted text, Mediawiki notation for a link is treated as content. My attempt is visible in the sandbox. When installed in the book, link text "IRQ" should anchor to Oberon/S3/irqs. Ideas? Thanks, ... PeterEasthope (discusscontribs) 22:23, 2 May 2020 (UTC)

@PeterEasthope: this can be done, but only in a very roundabout way:
  • Add <templatestyles src="TemplateStyles/Oberon/styles.css" /> to your sandbox.
  • Remove the pre tags, but add one extra space to each line that was formally in the pre tags.
  • If you need to, edit Template:TemplateStyles/Oberon/styles.css to change any values to the pre tag (ask me if you are unsure).
Explanation: unfortunately the standard pre tags strip any markup from inside them. However if you add a space before a line, it automatically adds (invisible) pre tags but without stripping out markup. So this is a useful workaround if you need the pre tags, but you want to include markup/HTML inside them.
If you have problems, I could edit your sandbox to show you if you wanted me to. --Jules (Mrjulesd) 00:40, 3 May 2020 (UTC)

Automatically labeling chapter references as chapter referencesEdit

I would like to know how to have the print version render all the chapters' references in such a way that the heading labels for them reflect the context in which they are displayed depending on whether that is the print version or the normal chapter view.

Or, what is the way to automatically specify a relevant heading that labels each block of references as belonging to a specific chapter in the print version? That would move them to the end of the book then. I ask because when using the Print Version of the wikibook on OpenSSH the book becomes peppered with headings labelled "References". That is fine in the context of individual chapters but confusing in the context of a whole book presented all at once, especially since the are given the same semantic markup as the real headings and that makes generating an automatic table of contents impossible as they require manual intervention to fix. If I re-label each set of references in-place to give them a more descriptive title relevant for the context of the Print Version then it looks quite silly in the context of individual chapters.

Maybe there is already some feature, function, or best-practice work-around?

I ask because some years ago, I did print the book to paper but it required massive layout editing in regards to the table of contents before becoming actually ready for printing. Larsnooden (discusscontribs) 04:42, 3 May 2020 (UTC)

@Larsnooden: I appreciate you breaking this down but I still can't visualize it. Can you please be very explicit? Like, "I want each chapter to have a section that says 'Chapter 1 References' at the end before Chapter 2 starts" or somesuch? If you have a graphic, that would help. —Justin (koavf)TCM 07:08, 3 May 2020 (UTC)
If you look at the automatic table of contents at the the Print Version of the wikibook on OpenSSH you see the subheading "References" repeated throughout the book, such as 1.3, 2.5, 3.3, 7.5, and so on. That's kind of awkward placement. If you look at the corresponding chapters online, then they look ok individually. Would there be a way to have them all moved to the very end of the Print Version like in many traditional printed books? Or, if they stay in place, is there some conditional formatting that can show one type semantic markup when rendering individual, online chapters versus when the book is rendered as an all-in-one Print Version? The could show up as bold text in the print version but as heading level 2 or something in the online version. Larsnooden (discusscontribs) 07:22, 3 May 2020 (UTC)
Gotcha. Okay, so the goal is to have all references in one place at the end of the book: which is a sensible request. The solution here would be something like (thinking out loud)... using CSS to have it only display on the Web and have nodisplay in print and then include a second references table at the very end that has the opposite CSS. Seems like this should be something built into {{Printable}} but that would take some serious doing in CSS (at least for me). I definitely welcome others who have more elegant solutions but I think something like that can work. —Justin (koavf)TCM 07:42, 3 May 2020 (UTC)
I propose to just add <noinclude> around each "References" paragraph to do the trick. Then, only one "References" paragraph can be added at the end of OpenSSH/Print version. JackPotte (discusscontribs) 09:06, 3 May 2020 (UTC)
I tried with the <noinclude> markup with one chapter and then preview of the print version. Neither it nor the unadjusted references from all the other chapters show at the end of the preview of the print version. Even if I include a {{reflist}} there at the end of the print version, no references show up at the end. Larsnooden (discusscontribs) 09:31, 3 May 2020 (UTC)
@Larsnooden: and what about now? JackPotte (discusscontribs) 10:16, 3 May 2020 (UTC)
Nice! That does the book-level end notes for the Print Version while leaving the normal chapters as they are. I'll take a close look over the next day or two, but that seems to be the solution. Larsnooden (discusscontribs) 11:04, 3 May 2020 (UTC)

Some CSS for Vector has been simplifiedEdit


I'd like to make a double-check about a change that was announced in Tech/News/2020/21.

Over-qualified CSS selectors have been changed. div#p-personal, div#p-navigation, div#p-interaction, div#p-tb, div#p-lang, div#p-namespaces or div#p-variants are now all removed of the div qualifier, as in for example it is #p-personal, #p-navigation …. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. This only impacts the Vector skin.

On this wiki, this impacted or still impacts the following pages:

How to proceed now? Just visit all these pages and remove div# before these CSS selectors if it hasn't been removed so far.

Thank you! SGrabarczuk (WMF) (discusscontribs) 13:01, 25 May 2020 (UTC)