With ultra-short URL, the webmaster has to make sure that the search engines, Let's Encrypt, etc. receive files, rather than wiki pages, when requesting robots.txt, .sitemap, etc. That has to be done by the frontend web server.

The workaround is this:

$wgHooks ['GetLocalURL'] [] = function (Title $title, string &$url, string $_): bool {
	if (mb_substr ($title->getText (), 0, 1) === '/'
		&& !strpos ($url, '.', 2)
		&& $title->getNamespace () === 0
		&& !MWNamespace::hasSubpages (0) // -- the same as $title->getNamespace () but faster
	) {
		$url = '/.' . $url;
	}
	return true;
};

Bump.

Is there a reason not to submit a patch, summarising the improvements above, immediately?

I did a simple test, though not in MediaWiki environment, and found out that simply

return value:gsub( '\n[ \t]+%*', '\n*' )

without any string.find() will be about 27% faster.

See LuaSpecials.

In T357668#9546649, @Lucas_Werkmeister_WMDE wrote:

I think this might happen since Set target to $wgExternalLinkTarget because, in Parser::getExternalLinkAttribs(), the $rel returned by getExternalLinkTarget() can actually be null?

In T66460#9538883, @SD0001 wrote:

https://gerrit.wikimedia.org/r/113759

Now that graphs are no more,

@Tgr, could you please approve the change, or reject it, or send it to someone else for reviewing?

Bump.

@Kghbln, have you managed to show a fragment of a CSV-file?

In T355208#9466632, @Kghbln wrote:

In T355208#9465340, @alex-mashin wrote:

With start line > 1 CSV with headers will not work. start line and end line are applied to the file before it is parsed and header line is taken into account. You can use header lines = 1 to guarantee that the headers are included, and, therefore, columns have correct names.

Thanks for the info. Good to know. Hmm, this is a noob question, but how can I retrieve just the content from the lines, e.g., five to ten, disregarding the lines one to four? Looks like this is not directly possible. Probably, I have to go via the #store_external_table: parser function and query the data wherever and however I stored them.

With start line > 1 CSV with headers will not work. start line and end line are applied to the file before it is parsed and header line is taken into account. You can use header lines = 1 to guarantee that the headers are included, and, therefore, columns have correct names.

In T354050#9427995, @Izno wrote:

Subgrid is currently at editor's draft, which is not usually sufficiently stable to add to CSS sanitizer.

require 'Module:…' and mw.loadData '…' clauses are effectively links.

Have you tried Page Exchange?

@Sugarbravo, does it work now?

Waiting till the 24th of November.

Already fixed in January.

@Sugarbravo, have you updated the extension and made sure that JOINs work, so that this task can be closed?

In T350297#9320843, @Sugarbravo wrote:

Thank you fixing this quickly. Will it be ported back to 3.2 or is this for the next version?

I have updated my patch so that it reproduces the old behaviour of join on. Please note that, in mySQL or MariaDB, that join will always be an inner join, since there is no way to set the type of join in this syntax.

I have never heard that a table used in a query could be omitted from the from clause, and that mentioning it in the join on would be enough. However, I have submitted a patch allowing this.

What is the database engine, to which {{#get_db_data:}} connects?

In T344578#9106334, @Yaron_Koren wrote:

It sounds like you are using the REL1_35 branch of Page Forms. You should switch to the most recent version of Page Forms, which thankfully still supports MW 1.35 - I think this particular bug, or set of bugs, was fixed a long time ago.

I would like to note that it is already doable with External Data.

@Platinops, please upgrade and see if the patch has helped.

Why don't you enable inline SVG, which can be generated by whatever mechanism that is available in MediaWiki, including Scribunto, templates or parser functions?

In T329417#8695129, @sbassett wrote:

@alex-mashin - I also cannot seem to reproduce this issue under REL1_35 using MediaWiki Docker to serve/test locally. I've tried several variations of the signature within the task description and I can't get an XSS payload to actually execute. Can you tell us a little more about the wiki and/or test environment where this issue was confirmed? Perhaps it's doing something a bit different from a basic MediaWiki install...

This dependency was introduced by f5f258a by rvogel (@Osnard).

And the failing tests were caused by bug 76584.

Thank you, @hashar. I tried to output some diagnostic information, which contained binary data, for a test that had succeeded on my development server but failed when run on MediaWiki gerrit. I sanitised the output, and this issue disappeared, although the test still fails.