Wikipedia:Reference desk/Archives/Computing/2019 June 26

= June 26 =

Manually referencing a wiki article without Cite extension
I have installed MediaWiki on a webserver and I want to add some references to an article. I don't have any extensions installed and I don't want to install any (from long-term maintenance reasons).

I can add after any sentence a tag with text inside it, but how could I make these refs appear in a list in the end of the article? I don't care if I should do the sorting manually or automatically as of this moment, I just need to learn how I display these in a list in a "Footnotes" section. Thanks. — Preceding unsigned comment added by 49.230.75.149 (talk) 08:17, 26 June 2019 (UTC)
 * I would add the Cite extension. Wikis are so much better with extensions added.  If you don't have WP's performance constraints, you can have useful extensions like DPL too.
 * To work without it, you might find the easiest is to create the cites on a Wiki with the extension in place (such as en:WP) and subst: its results, then copy them off to your wiki. Andy Dingley (talk) 08:57, 26 June 2019 (UTC)
 * Hello, I think that if a Wiki does better with or without extensions depends on the wiki itself and it's audience, but to the issue --- what about no-extension solutions that are being based only on Wiki syntax and maybe also some JavaScript, is there nothing for this particular need?... 49.230.75.149 (talk) 09:15, 26 June 2019 (UTC)
 * If I understand correctly, you just wish to directly link to the resource, or to an anchor on your own page. For that, see the MediaWiki syntax for linking: specifically, Link to an anchor on the same page.
 * Then, somewhere (at the bottom of your page, for example), you create your list of references, and following the same syntax guide, Setting an anchor for incoming link, tag each item in your list of references.
 * This procedure uses the built-in features of MediaWiki, and entails only slightly more manual effort than using the various reference extensions that are installed on the English Wikipedia.
 * Distinct from this procedure, you may (optionally) wish to clone your favorite Wikipedia MediaWiki templates that are commonly used to format reference links.
 * Nimur (talk) 16:28, 26 June 2019 (UTC)

MediaWiki wraps all space-indented nested content in HTML tags
To reproduce go to a MediaWiki web site with the skin "Vector", go to an edit page, add some non  HTML content, add some non   space-indented nested HTML content inside it, and save the page.

How can one turn off this behavior in MediaWiki? Thanks, 49.230.75.149 (talk) 08:45, 26 June 2019 (UTC)
 * Don't indent with spaces? This is a pretty deeply embedded behaviour in Wikitext. You're not going to remove it easily with just a bit of CSS skinning. Andy Dingley (talk) 09:29, 26 June 2019 (UTC)
 * User:Andy Dingley; okay, even if I don't indent with spaces; my keyboard doesn't have a key for tabulation-indentation and searching-finding-copying-pasting tabulation-characters feels bad to me to do repeatedly. Using an AHk approach to create a Windows keyboard shortcut is nice but not a solution for Linux users. Any another approach? 182.232.21.241 (talk) 14:57, 26 June 2019 (UTC)
 * Wiki markup uses ":" as the indent character, just as we're doing in these threads. You can either work with that, or rail against it. I find doing what it wants me to is much easier. Andy Dingley (talk) 15:00, 26 June 2019 (UTC)
 * Andy I tried that but sadly the outcome is the same (maybe ":" is actually a space-indentation and not tabulation-indentation)... The original problem seems to be in how MediaWiki PHP creates HTML and not by type of indentation (i.e spaces or tabulations). Any other idea? 182.232.21.241 (talk) 16:30, 26 June 2019 (UTC)
 * Please see WP:CHEATSHEET and H:MARKUP. These techniques were laid down eighteen years ago, they're not going to change. -- Red rose64 &#x1f339; (talk) 19:40, 26 June 2019 (UTC)
 * Hello, User:Redrose64, I read the  section in the second link you provided but I miss why nested content (in the context I described above), appears in a few different   tags instead just the parent tag (which is in my case  clause with a   condition that has a large   list with all the desired IDs.

However, some of the rows might already have the status flag column at the desired value.

So my question is, which is more efficient?
 * First fetch the IDs of the rows where the status flag is already at the desired value, and exclude them from the  list, or
 * Just do the operation with the large  list, allowing it to update even those rows with the flag already at the desired value?

J I P &#124; Talk 21:17, 26 June 2019 (UTC)
 * Benchmark both. Andy Dingley (talk) 21:25, 26 June 2019 (UTC)
 * Yes. It would be interesting to do it both ways and then try to explain why the winner is faster. Bearing in mind that we don't have all the facts about the database structure, or how many rows it has or how many "some" is. So trying to guess which one might be more efficient is a weak alternative to actually trying it! ←Baseball Bugs What's up, Doc? carrots→ 21:56, 26 June 2019 (UTC)


 * Generally speaking, updating a record is more expensive than performing a query on it. However, it's possible the DB management system might be smart enough to see that the update will result in no change to that record, and skip it. If bench-marking shows that this is not the case, then I suggest a clause on the UPDATE something like . You want the DBMS to do the work for you, as opposed to returning a couple lists and you then filtering the one based on the other, and doing updates accordingly, which would certainly be slower. SinisterLefty (talk) 22:07, 26 June 2019 (UTC)


 * Or if there are only two possible values, Y and N, have it update where status_flag = "N". ←Baseball Bugs What's up, Doc? carrots→ 22:11, 26 June 2019 (UTC)


 * That would work, but I don't believe there would be any performance difference, and we should also consider what happens if additional values are ever added, like "?". Of course, if it was a logical (T/F) value, then this isn't possible. SinisterLefty (talk) 13:07, 27 June 2019 (UTC)
 * Does SQL Server have an "explain plan" function as Oracle does? ←Baseball Bugs What's up, Doc? carrots→ 15:13, 27 June 2019 (UTC)
 * Of course. But even this isn't a guarantee of performance on its own, as we don't know the size of the tables, the distribution of data within them, and the indexing available.  Many such factors will affect the performance of both queries and it's hard to choose without knowing the sizes.
 * Then again, whenever I hear "a list of row IDs" my teeth start to grate. Why isn't this list selected within the database? If it has to be imported from outside, then are "row IDs" really a dimension which the database model should be publishing to the outside world  (it's hard to do this without them either being too constrained by the outside world to make a good table key, or else a good primary key within the DB is opaque, unwieldy or even unstable for use outside). Andy Dingley (talk) 16:42, 27 June 2019 (UTC)
 * Maybe the OP will get back and offer some more details. ←Baseball Bugs What's up, Doc? carrots→ 16:48, 27 June 2019 (UTC)


 * Agreed. If they had in mind doing something like SELECT ROW_ID WHERE (condition X) followed by UPDATE STATUS_FLAG = "Y" WHERE ROW_ID = {...}, then it would be much better to just do UPDATE STATUS_FLAG = "Y" WHERE (condition = X). It's possible they also retrieve the ROW_ID's for some type of log they keep, but then it would still make sense to do the SELECT followed by the last UPDATE. That is, don't send the same list of ROW_ID's back in the UPDATE. (The SELECT and UPDATE should perhaps be handled within a single TRANSACTION, to eliminate the possibility of a DB change happening between the SELECT and UPDATE which alters which ROW_ID's match condition X.) SinisterLefty (talk) 17:19, 27 June 2019 (UTC)