The functions mentioned are not really broken but non-performant. For instance, I was using about 100.000 split operations in 250 templates. Firstly, I did it with mw.text.split(), and it took about 3,000 ms. Then I replaced these convenient but slow functions with Lua functions like match() and gmatch(), and the same took only a few ms. 3,000 ms computing time is really much and finally it caused an allocation-time error.

I think I found the failure: it is a damaged / erroneous mw.text library, especially mw.text.split and mw.text.trim!

From https://de.wikivoyage.org/wiki/Spezial:Version I learned that the last Mediawiki version is of

Now I am making several changes on https://de.wikivoyage.org/wiki/Modul:VCard and its submodules. To prevent (many) error messages I am checking https://de.wikivoyage.org/wiki/Kategorie:Seiten_mit_Skriptfehlern (pages with scripting failures) twice per day and after code changes. That's why I think that the jump in time consumption occurred 12 (or not more then 24) hours ago. The time consumption of https://de.wikivoyage.org/wiki/Halle_(Saale) is checked weekly because it is one of the most time consuming articles. We would earlier detect the changes by Debian upgrades made in January, 2021. We observed similar results to December 2021 a few days ago.

The increase of computing time of the functions mentioned is about a factor of 30!

At the German Wikivoyage, Reading preferences (Enable page previews (quick previews of a topic while reading a page)) are not available.

See T267296, too

It is not the first time that the map server is not working properly (T231964, T226412). But these malfunctions should not block drawing map structures which are not fetched from the mapserver/OSM database. The non-database structures are drawn only after a successful fetching of geolines and geoshape objects. If the fetching failed then the drawing of non-database structures will be blocked because of errors of JavaScript promises. This should not happen in any case. That's why I propose the following two changes:

The map server returns a 404 error.

Some tests on https://de.wikivoyage.org/wiki/Kairo/Ta%E1%B8%A5r%C4%ABr-Platz

The same error occurs on English Wikivoyage, too.

I was surprised, too. And I did not made any changes (yesterday morning I only added some maintenance categories). The computing times for addStatementUsage oscillate (between 400 and 900 ms) but they are clearly reduced. I think yesterday the 1.36.0-wmf.14 Mediawiki branch was deployed at Wikivoyage. Maybe that means to find the cause we had to look for it outside of Wikibase. Unless I'm very much mistaken addStatementUsage only makes a registration of entities and properties used. This should not be expensive. But I have no idea what happens at the registration and what went wrong.

The computing times for Scribunto_LuaSandboxCallback::getEntity and Scribunto_LuaSandboxCallback::addStatementUsage did not change much, but only that of Scribunto_LuaSandboxCallback::addStatementUsage changed drastically. The number of properties fetched increased within the last four weeks only by one which cannot explain the increase of computing time of this simple function. Maybe there is a problem with the accumulator/cache or database.

I am not sure if T263999 is the real cause for this bug. But I cannot exclude this cause, or maybe both bugs have a joint cause elsewhere. addStatementUsage only registers the use of an entity and a property and has maybe nothing to do with functions in which a language was specified.

The Wikivoyage template vCard can use up to 50 statements per template (see table ParWD at Module:VCard/Params, too). About 5 addStatementUsage calls per template on average are not really much even for an entity which is already loaded (loading takes only about 2.5 ms). Within the last weeks we added only one statement (P3025: open days). Therefore, the number of addStatementUsage calls increased only by a few percent.

This Mediawiki Extension is licensed under GNU General Public Licence 2.0 or later. Author was Roland Unger.

If the bug is caused by cache limitations: Maybe a simple destructor entity:remove() would help. People told me that all entities are cached until the end of article parsing. But most of the entities are used in only one template and must not be cached any longer.

I tried to remove the museum section from https://de.wikivoyage.org/wiki/Halle_(Saale) and to stop using qualifiers and references from entities but the bug remained.

See also T189409.

It seems that it is a sudden spike. The computing time only for addStatementUsage jumped from about 600 ms to 5000 ms (all Lua stuff from about 4.5 sec to about 9 sec). Within the last two weeks I added and optimized the analysis of opening hours to our vCard template. As in the past I used the same technique to prevent retrieving data from Wikidata. We are using several tables like this: https://de.wikivoyage.org/wiki/Modul:Hours/i18n with prepared data. On this way there is usually only one getEntity call per template. The number of entities used increased within the last two weeks only by about 1. Of course I added some statements to the Wikidata datasets (mainly of museums) to test the display of opening hours. Within the last two weeks there was no significant change. The core functions were added already on Sep. 26, 2020.

Maybe it is the same like T236485.

It seems that the/some cookie requests were initiated by Ajax API calls like wbgetentities.

Within the last days I made some programming (for instance on https://de.wikivoyage.org/wiki/MediaWiki:ListingEditor.js) and I am testing my changes including the check of console output. I saw the messages mentioned today for the first time. Normally only messages like "Use of "mw.RegExp.escape" is deprecated. Use mw.util.escapeRegExp() instead.", "JQMIGRATE: jQuery.fn.delegate() is deprecated", or "This page is using the deprecated ResourceLoader module "jquery.ui" occur. But today a lot of cookie messages occur including unnamed cookies like "Cookie “” has been rejected as third-party."

Different notice

I observed this on German Wikivoyage.

At the console I found the following message:

I tried to import https://de.wikipedia.org/wiki/R%C3%B6merstra%C3%9Fe_Neckar-Alb-Aare (w:de:Römerstraße Neckar-Alb-Aare) from German Wikipedia to German Wikivoyage. I got only the error message "Import fehlgeschlagen (= import failed): Main slot of revision not found in database. See T212428." but nothing else. This failure happened all the time with this page, but we did not tested it with other pages.

Error occurs with Special:Import, too, for import both from wiki and file.

The import fails on German Wikivoyage, too, from both wiki and file.

Please check public static function makeTrail( Title $title, ParserOutput $parserOutput, User $user ) in GeoCrumbsHooks.php.

This bug is occurs only from today. It seems to be a side effect of a change in another module because geocrumbs extension was last changed three weeks ago. Maybe $linkText = $parserCache->getTitleText(); fails.

Example: https://de.wikivoyage.org/wiki/Luxor

For me, a tooltip is the information on a yellow background which is based on the tags title attribute and shown on mouseover event. I do not think about the pop-up window (with title and image) which is opened by a mouse click.

See also https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2020/Wikivoyage/Permanent_update_of_Wikivoyage_nearby-articles_data_files_necessary .

In this regard I made the proposal of T179638 about two years ago.

After ten weeks nothing is done. Why?

@WMDE-leszek, for instance on the French Wikipedia and on the German Wikivoyage we added icons to the items of the "in other project" list to make them more prominent. That's why we added rules to the MediaWiki:Vector.css stylesheet. And that's why I asked to inform the communities to think about additions to other stylesheets.

This behavior occurs in other projects, too. I mentioned this in T66315. Unfortunately it is now necessary to make zero-edits to show the link in the "in other projects" list.

You should inform the communities on this (skin) change. This is necessary because the toolbox item is already vanished but the item in the "other project" list not yet available. We had to make zero-edits to make the new item visible.

I think this tool should be implemented in all branches of Wikivoyage to support the small communities.

It is well known, that OSM ways and areas could be defective. But they are shown on OpenStreetMap. Maybe more fault-tolerant functions are used at OSM as compared to these of Wikimedia. If a relation is an area maybe the shape can automatically be closed.

Missing Lua documentation is a big problem, see T225497, too.

A similar problem was described in T225592.

A similar failure was described in T215641.

It seems that the same problem occurs with geoline service.

Error messages from console:

A side effect is that the WMF's JavaScript code which organizes the creation of dynamic maps fails because it didn't check the result retrieved. At the German Wikivoyage we have two different results. One the one hand a static or missing map with WMF's script and a mainly working dynamic map after pressing the magnify button which creates a map by our tools. The map is shown with all working OSM objects and do not show all broken OSM ones.

I propose the following solution: to add weekday classes like sundays to all table cells. Then css styles can be easily added to every day of the week not only for sundays.

User scripts on de.wikivoyage.org only seldom use external modules. The dependencies are realized with mw.loader.using()/require() calls. Maybe there are missing dependencies in Kartographer. Some time ago we found such a failure (T197655).

Sometimes a runtime error (TypeError) occurs but not in any case. This error prevents proper function of mw.hook().

In case of a runtime errrors mw.hook() is sometimes not working. This can be overcome by using jQuery.ready function.

Of course, the global function call is to be adapted to use jQuery like ( function ( $ ) { ... } ( jQuery ) );

Yes, this should also include email aliases. The wikivoyage-ev.org addresses are working upto now. The @wikivoyage.org should be preserved.

wikivoyage-old.org was used only at the transfer process of the Wikivoyage domains from the servers of the Wikivoyage association to that of the Wikimedia Foundation to have a copy for comparison. According to a agreement with the Foundation we closed wikivoyage-old.org at the beginning of 2013 to prevent double content on the internet.