insource:/\<\<[a-z]/i lasteditdate:>=2025-12-01

works
and a sequence of

insource:/\<\<[AaBb]/

with "AaBb" iterating till "YyzZ" works too without any timeout.

I have the following problematic patterns:

It smells, that the problem is not the search logic, since in https://de.wikipedia.org/wiki/Special:search you can search for insource:https insource:/\[https:\/\/[^ \]]*/ and there are results. The search take ~24 seconds. The same search in the API-Sandbox or with wget fails always after 15,x seconds.

Yesterday, the english sandbox returned an error. Today it works.

The problem can be reproduced on the API-Sandox

Thanks. This solves half of the problem. Sometimes, but extreme seldom, once every few month a background process hangs. It seems(!) it waits forever for some API-Answer (maybe name resolving or something other strange problem) but I cannot identify the real problem. Debug-Output would create Gigabytes (or even more) of data until this happens.

Do not blame me! Until spring '24 when cron-jobs were allowed, I had a watchdog job which did this restart automagically when needed. But now, it is impossible for me. So every tool needs a nurse to check if the tool is still running or for some reason (or no reason) down.

libwww-perl/6.68 is the record holder (3 times more visits that PetalBot). But PetalBot was the one, who found really time-consuming urls.

bd808: ·The Problem with the tool show up when you do a

tail review-lag.err

wget -q -O - https://viaf.org/en/viaf/data without the training slash works

@fnegri: My query had this problem since June 6th.

Liz: Explain tells you in which order the query is processed and which index (if there is some) is used. This is an output of the database itself and you may find some (more or less) helpful information on the Website of the mariadb database (or sometimes on mysql pages).

For my query: https://quarry.wmcloud.org/query/83617

I tried https://quarry.wmcloud.org/query/83617 multiple times since T366909 was closed, and it never finished. What can a simple user do to prevent running into this problem? Starting again and again does not work.

after about two hours, some output came.

Oh my god! I have written some code in C with the gzip-library and there was no such delay. I really did not expect such a behaviour.

My solution for tool persondata:

Just jlocal parts. The watchdog and I think a cleanup of log files. Nothing important.

@taavi: Great job in finding this problem. Now the mother of all questions: Do we need tideways? Does any tool use its functionality?

Sorry, I am too dumb to understand what I should do. Source for the C#-Program of Wikihistory can be found at https://persondata.toolforge.org/WikiHistory_src.zip the php-part is a wrapper using the database, and redis. I chmod a+rx wikihistory, so it is public readable. The php wrapper is: dewiki_update_new.php

I tried the following:
Create an Aptfile like

@nskaggs Okay. I have already read that magic "Aptfile".

The file I used:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
        xmlns:schema="http://schema.org/"
        xmlns:gndo="https://d-nb.info/standards/elementset/gnd#"
        xmlns:lib="http://purl.org/library/"
        xmlns:owl="http://www.w3.org/2002/07/owl#"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
        xmlns:skos="http://www.w3.org/2004/02/skos/core#"
        xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
        xmlns:editeur="https://ns.editeur.org/thema/"
        xmlns:geo="http://www.opengis.net/ont/geosparql#"
        xmlns:umbel="http://umbel.org/umbel#"
        xmlns:naf="https://id.loc.gov/authorities/names/"
        xmlns:rdau="http://rdaregistry.info/Elements/u/"
        xmlns:sf="http://www.opengis.net/ont/sf#"
        xmlns:bflc="http://id.loc.gov/ontologies/bflc/"
        xmlns:thesoz="http://lod.gesis.org/thesoz/"
        xmlns:dcterms="http://purl.org/dc/terms/"
        xmlns:isbd="http://iflastandards.info/ns/isbd/elements/"
        xmlns:foaf="http://xmlns.com/foaf/0.1/"
        xmlns:mesh="http://id.nlm.nih.gov/mesh/vocab#"
        xmlns:ram="https://data.bnf.fr/ark:/12148/"
        xmlns:mo="http://purl.org/ontology/mo/"
        xmlns:marcRole="http://id.loc.gov/vocabulary/relators/"
        xmlns:agrelon="https://d-nb.info/standards/elementset/agrelon#"
        xmlns:dcmitype="http://purl.org/dc/dcmitype/"
        xmlns:nsogg="https://purl.org/bncf/tid/"
        xmlns:dnbt="https://d-nb.info/standards/elementset/dnb#"
        xmlns:dbp="http://dbpedia.org/property/"
        xmlns:embne="https://datos.bne.es/resource/"
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:dnb_intern="http://dnb.de/"
        xmlns:madsrdf="http://www.loc.gov/mads/rdf/v1#"
        xmlns:cidoc="http://www.cidoc-crm.org/cidoc-crm/"
        xmlns:v="http://www.w3.org/2006/vcard/ns#"
        xmlns:ebu="http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#"
        xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
        xmlns:gbv="http://purl.org/ontology/gbv/"
        xmlns:bibo="http://purl.org/ontology/bibo/"
        xmlns:agrovoc="https://aims.fao.org/aos/agrovoc/"
        xmlns:lcsh="https://id.loc.gov/authorities/subjects/"
        xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="https://d-nb.info/gnd/4000002-3">
        <wdrs:describedby>
                <rdf:Description rdf:about="https://d-nb.info/gnd/4000002-3/about">
                        <dcterms:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/"/>
                        <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2010-01-06T12:56:50.000</dcterms:modified>
                        <gndo:descriptionLevel rdf:resource="https://d-nb.info/standards/vocab/gnd/description-level#1"/>
                </rdf:Description>
        </wdrs:describedby>
        <gndo:gndIdentifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string">4000002-3</gndo:gndIdentifier>
        <gndo:oldAuthorityNumber rdf:datatype="http://www.w3.org/2001/XMLSchema#string">(DE-588c)4000002-3</gndo:oldAuthorityNumber>
        <gndo:relatedDdcWithDegreeOfDeterminacy2 rdf:resource="http://dewey.info/class/621.381537/"/>
        <gndo:preferredNameForTheSubjectHeading rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A 302 D</gndo:preferredNameForTheSubjectHeading>
        <gndo:broaderTermGeneral rdf:resource="https://d-nb.info/gnd/4027242-4"/>
        <gndo:gndSubjectCategory rdf:resource="https://d-nb.info/standards/vocab/gnd/gnd-sc#31.9b"/>
        <rdf:type rdf:resource="https://d-nb.info/standards/elementset/gnd#SubjectHeadingSensoStricto"/>
</rdf:Description>
</rdf:RDF>

@Cyberpower678 no problem. No additional maintainer is needed, at least for now.

Wikihistory uses php *and* mono in the same script. Is there a cookbook (for dummies) explaining step by step what to do?

Q: Currently I am using jlocal for a watchdog process which is checking one relatively critical job and the website for the tool. Is there is replacement?

The original problem on deWP is solved, yea! But @akosiaris wrote on Apr 15 2022, 10:53 AM some statements which I sadly cannot reproduce. So maybe @akosiaris may decide if this one shall be closed.

Okay. My browser is a little bit old. Firefox, chrome an Opera shows a page. However, an input field within the head section is always misplaced, ignored by newer browsers, causing a blank page on my oldish browser.

I do not want to create an account on microsoft owned pages. Sorry, hardcore-linuxer

Some GB deleted.

Currently all seem to work.

Wow! So fast! Thanks!

I still need a container with mono and php7.x combined.

Just found out, that percent-encoding of the slash in the articles titles helps:

Today there is an error in dewiki_p - Database

For me(!) --logdir would be enough. I just want to have a (relative) clean home directory.

Is --logdir documented somewhere? The online man pages does not show it. Option -help does not show it too.

Was only on 20th and 21th of July. After those days I did never see such a timeout.

As you can see in the screenshot, the LOADING of https://de.wikipedia.org/wiki/Spezial:Beobachtungsliste (German watchlist) takes 91 seconds.

Attached is a screenshot of the network-timinig from the developer tools of my browser.

I think(!) the reason is some default value
https://de.wikipedia.org/w/api.php?action=query&format=json&meta=userinfo&ascii=1&formatversion=2&uiprop=options

When you have a new created account (or when you never changed your settings of the timezone), you will see the same information as not logged in with one hour off for the other half of the year.

In just merged T309506 I mention https://de.wikipedia.org/wiki/Wikipedia:Café which is also affected.

Every browser, not only chrome! Even Lynx shows the same behaviour, the original report was based on Firefox.

I tried this one with chrome and no login:

Firefox: Output is: "Wednesday, May 25, 2022, 15:01:39 Central European Summer Time"

I have Linux and in /etc/sysconfig/clock I readTIMEZONE="Europe/Berlin"

A screenshot of Hillary Clinton in enWP with all sections collapsed

Not really severe. I was just confused, why a tiny small article is in some category of errorness articles, when there is no error. Was the description of replacements wrong?

There is definitely some cache involved!

This one says "Deprecation: Alias no longer supported."
curl -X POST 'https://de.wikipedia.org/api/rest_v1/media/math/check/tex' -d 'q=\and x'; echo

It is gone! The category is gone! Both on the german page and on https://www.mediawiki.org/wiki/Extension:Math/T305613 (see at top from Physikerwelt)

Thx!

Setting lelimit to 4 (or larger) works fine

The message is not a Problem.

I mentioned https://de.wikipedia.org/wiki/Spezial:Einstellungen because testing the final solution should take a look at that page too.

The Hotfix is just a part of the story. There are still lowercase letters in https://de.wikipedia.org/wiki/Spezial:Einstellungen (or if you prefer english: https://de.wikipedia.org/wiki/Special:Preferences )

This is now 16 years old and still nasty.

The nesting can be seen in enWP too, Example: https://en.wikipedia.org/wiki/J._Golden_Kimball#Service_as_a_Seventy (just one of a lot of examples) However, in enWP I did not find an example where such a nesting is used for the first picture.

Real-Life example: https://de.wikipedia.org/wiki/Altersfreigabe?useskin=modern or an english page: https://en.wikipedia.org/wiki/Mestizo?useskin=monobook

At the very bottom of the window there is a scrollbar (not just below the gallery). Firefox 78.8.0esr openSuse 15.2 or Chromium 89.0.4389.90 (openSUSE Build) (64-Bit)

At least one occurrence of this error can be reproduced with a simple query like "Select page_title, page_title from page where page_id = 1", see T265155 or look at https://quarry.wmflabs.org/query/53652