Kategorie Diskussion:Wikipedia:Seite mit Skriptfehlern

IMDb ?

Wie genau werden die Seiten hier in diese Kategorie gestellt und welche Fehler werden dabei abgefragt? Die Hinweise auf der Vorderseite verstehe ich nicht und sie helfen mir auch nicht wirklich weiter. (ich kenne andere Fehler, wo beispielsweise ein Zeichen im Datumsformat falsch ist, das ist aber hier nicht der Auslöser)

• Es kommt hin und wieder vor, dass ein Artikel hier erscheint der seit Monaten nicht verändert wurde. Aktuell Cole Hauser (seit 31. Oktober 2015 ohne Änderung.
• Auffallend ist dabei, dass eine Entfernung des optionalen Parameters aus der Vorlage:IMDb {{IMDb|nm0369513}} → {{IMDb}} geändert wird.
• Die Meldung selbst wird aber leiden nicht im Artikel angezeigt so dass ich nie weiß, ob das wirklich der Auslöser war. Zumindest ist anschließend die Seiten nicht mehr in der Kategorie.
  • Beispiele: IMDb, IMDb, IMDb

Ein weiteres Problem ist es, dass ich trotz des neuen Auswahlkriteriums in der BEO, diese Kategorie nicht angezeigt bekommen. Gestern Abend war die Seite „definitiv“ noch nicht dort gelistet, also sollte ich diesen Eintrag heute sehen können. Dafür habe ich die Seite ja probehalber in die BEO aufgenommen.

• Meine Frage ist, was soll ich damit machen? Bisher habe ich, wie gesagt, immer den Parameter entfernt, nur ist mir nicht klar wieso die Seiten plötzlich auftauchen, ob, und wenn ja, wo da eine Änderung erfolgte und wie ich das sehen könnte.
• Was für mich auch wichtig wäre, ist die Anzeige der Fehlerkat im Artikel, damit ich vor dem Speichern sehen kann, ob der Fehler durch meine Änderung behoben wurde. So muss ich immer zur Kategorie zurückspringen und schauen, ob die Seite noch angezeigt wird oder nicht.

Falls hier zufällig jemand mitlesen sollte, lasse ich den „Cole Hauser“ mal so wie er ist. --Liebe Grüße, Lómelinde Diskussion 08:24, 24. Jan. 2016 (CET)

Oh nee, ich habe es scheinbar weggepurgt. Zumindest ist er jetzt wieder raus. Ich weiß echt nie was ich damit anfangen soll. Ich mag keine Kategorien. --Liebe Grüße, Lómelinde Diskussion 09:13, 24. Jan. 2016 (CET)

Das war Hamsterhusten, das Phantom der Operationen.

Das Modul hatte vielleicht mal einen Fehler, der sofort wieder behoben wurde, oder war vom Server irrtümlich mal kurz falsch ausgewertet und dadurch kategorisiert worden; vielleicht war eine Seite nicht vorhanden oder nicht zugreifbar gewesen.

In dem Moment, in dem jemand den Artikel anfasst, kommt es wieder zum Bewusstsein, und der nicht vorhandene Fehler verschwindet wieder aus der Kategorie.

Wenn im Artikel weder eine Fehlermeldung noch eine Wartungskat steht, dann kannst du eine Eintragung des Artikels umseitig ignorieren, das hatte sich bloß noch nicht rumgesprochen.

LG --PerfektesChaos 12:41, 24. Jan. 2016 (CET)

O.k. Wenn keine Meldung dann einfach mal einen Nulledit oder so. Komisch ist aber, dass man dort dann „immer“ den Parameter herausnehmen kann. Vielleicht hat es ja doch irgendwo damit etwas zu tun, dass die Seite kurzzeitig erfasst wird, weil der Parameter überflüssig geworden ist. Dankeschön für die Info. --Liebe Grüße, Lómelinde Diskussion 13:56, 24. Jan. 2016 (CET)

Der fehlende IMDb-Parameter wird aus der Registrierung des Artikels beim Wikidata-Projekt gefischt, und das könnte ursächlich sein, dass es zu einem temporären Fehler kommt, weil dieses ab und zu nicht schnell genug antwortet, aber wenn dann erneut jemand die Seite anfasst, dann doch wieder heil und kein Fehler mehr, aber die Eintragung im Klassenbuch lebt noch eine Weile. LG --PerfektesChaos 14:09, 24. Jan. 2016 (CET)

Läuft wieder voll

Läuft wieder voll - Teil 1

Ich habe in den letzten Tag etwas über 1600 Artikel per Nulledit aus der Kat entfernt, pro Tag kommen aber ca. 100 neue dazu. Hast du eine Idee @PerfektesChaos: woran das liegen könnte? -- Quotengrote (D|B) 10:27, 28. Jul. 2017 (CEST)

Siehe auch hier.

• Das mit den Nulledits ist lieb gemeint, aber setze deine Arbetskraft besser für wihtige Sachen ein. Das verschwindet von selbst wieder.
• Es scheint momentan (gutes Dutzend Enträge) um Filme und Radsport zu gehen; ursächlich sind wohl Wikidata-Zugriffe. Die Lua-Programmierer dort kriegen es einfach nicht auf die Kette, nach jedem Zugriff auf Wikidata erstmal nachzuprüfen, ob der Wert nach Form und Inhalt auch dem entspricht, was sie erwartet hätten, Abweichungen davon zu erkennen und geeignet alternativ zu verfahren; statt dessen verlassen sie sich blind darauf, dass die Datentypen und Formate so sind wie sie hoffen, und das Modul stürzt dann an dieser Stelle ab und schlägt in der umseitigen Kat auf.

LG --PerfektesChaos 10:44, 28. Jul. 2017 (CEST)

Arbeit macht es kaum, das läuft automatisch, so sieht Lómelinde dann wenigstens nur noch die echt kaputten Fälle. Aber dann weiß ich Bescheid, danke. -- Quotengrote (D|B) 10:48, 28. Jul. 2017 (CEST)

Also von "selbst verschwinden" sehe ich nichts, werden jeden Tag mehr. -- Quotengrote (D|B) 18:16, 1. Aug. 2017 (CEST)

Klar werden es immer mehr, solange die Ursache nicht beseitigt ist. Nur ein Bot, welcher Nulledits durchführt, kann hier symptomatisch eingreifen. ÅñŧóñŜûŝî (Ð) 18:41, 1. Aug. 2017 (CEST)

Den Bot könnte ich anbieten. -- Quotengrote (D|B) 18:45, 1. Aug. 2017 (CEST)

Wenn er keinerlei (!) Änderungen vornimmt, dann erzeugt er keine Artikelversionen und dann darf er notfalls auch ohne Flag laufen. Du solltest aber nach ca. zehn Seiten mal nachschauen, ob er wirklich nichts geändert hat. Zumindest kurz nach dem Botlauf kann man dann evtl. echte Fehler in der Kat finden. ÅñŧóñŜûŝî (Ð) 18:51, 1. Aug. 2017 (CEST)

Kein Sorge, Botflag habe ich und hab die Kategorie auch schon dreimal leer gemacht, waren bis jetzt ca. 2000 Artikel. -- Quotengrote (D|B) 18:53, 1. Aug. 2017 (CEST)

purge + linkupdate geht auch und erzeugt niemals eine Version. Ansonsten gibt der API-Response auch ein nochange-Flag mit, so das man nach dem ersten echten Edit abbrechen könnte. Der Umherirrende 20:24, 1. Aug. 2017 (CEST)

• Die Einträge verschwinden ganz von selbst wieder nach einiger Zeit, dafür poppen zehn neue Seiten auf.
• Die Ursache sind die pfuschenden Programmierer in Radsport und Film; momentan anscheinend mal wieder großes Kino.
• Modul:Kinostarts dürfte der Verursacher sein; der Programmierer dort weiß auch genau, dass er nach seinen Änderungen diese Kat hier im Auge behalten muss, kümmert sich aber einen Scheiß drum.
• Mit einem Bot auf einen glücklicheren Moment für die Wikidata-Abfrage zu hoffen löst das Problem nicht.
• Es wird hier permanent und turnusmäßig der gesamte Artikelbestand der RFF immer wieder von Neuem aufschlagen und ein paar Wochen verweilen. Wenn der Bot mal eine Seite verscheucht, ist dieser Artikel eine Woche später wieder da.
• Die Lösung kann nicht sein, dass man permanent auf dem Server purges anfordert, sondern muss in der Korrektur der unzulänglichen Lua-Module liegen.
• Abgesehen davon: Wenn die Kat immer wieder leergeräumt wurde, sieht es für die Programmierer so aus, als ob sie alles richtig gemacht hätten.

VG --PerfektesChaos 10:19, 2. Aug. 2017 (CEST)

@Queryzo: @Nicola: Du bist doch groß beim Radsport dabei, vllt weißt du da was genaueres, davon schlagen auch relativ viele Artikel von auf, gesehen habe ich immer die IB-Einbindung von Wikidata. -- Quotengrote (D|B) 11:58, 2. Aug. 2017 (CEST)

Das Modul:Kinostarts wird m.E. nicht im ANR verwendet. Der Umgangston von PerfektesChaos lässt wieder mal zu wünschen übrig. –Queryzo ?! 11:46, 2. Aug. 2017 (CEST)

Das Modul wird über invoke zB hier verwendet. -- Quotengrote (D|B) 12:00, 2. Aug. 2017 (CEST)

Diese Vorlage ist nur ein Testfall und wird in genau einem Artikel eingebunden. –Queryzo ?! 12:11, 2. Aug. 2017 (CEST)

(BK)

mea culpa, hatte nicht weiter gesucht nachdem ich die erste verwendung gefunden hatte ;-) -- Quotengrote (D|B) 13:46, 2. Aug. 2017 (CEST)

Gestern waren es ausschließlich Filme und Radelei gewesen – also was anderes aus der RFF; so finde ich auf Anhieb Vorlage:Wartung-Film. Jetzt sind auch Film&Fernsehen dabei, aber noch weitere Themen. VG --PerfektesChaos 12:03, 2. Aug. 2017 (CEST)

Die Vorlage:Wartung-Film wurde seit der letzten Meldung hier Anfang Juni nicht mehr verändert. –Queryzo ?! 12:11, 2. Aug. 2017 (CEST)

• Die Einträge, die Quotengrote mit seinem Bot durch purge wieder wegdrücken konnte, resultieren aus Wikidata-Zugriffen.
  • Wikidata antwortet manchmal in irgendwelchen Zehntelsekunden anders als eine Minute später.
  • Die Ergebnisse von Wikidata sehen (dann) zuweilen anders aus als sich die Programmierer das gedacht haben.
  • Vom Datentyp her kann das nil oder string oder auch table sein, um mal die typischen Vertreter zu nennen.
  • Wenn jemand glaubt, immer string zu bekommen, und es ist in irgendeiner Sekunde mal nil, dann stürzt das ab. Genauso, falls es mal nicht ein Einzelwert als string ist, sondern eine Gruppe von Werten als table.
  • Selbst wenn es ein string ist, dann muss der nicht so strukturiert sein, wie man sich das denkt. Vielleicht ist er leer, vielleicht anders formatiert.
  • Alles das muss vom Programmierer der Wikidata-Anwendung sorgfältig bedacht und ggf. in eine individuelle Wartungskat umgeleitet werden, zum Schluss noch global abgefangen und in eine individuelle Rückfallkat für das spezielle Modul umgeleitet werden.
  • Hier in dieser projektweiten Kat darf eigentlich überhaupt nichts mehr ankommen. Ich selbst war, glaube ich, vor drei Jahren zuletzt mal hier aufgeschlagen.
• Es war lieb gemeint, aber keine gute Idee, die Dinger immer wieder wegzudrücken, weil dadurch nicht mehr rekonstruiert werden kann, seit wann wer was zuerst ausgelöst hatte.
• Seit etwa einem halben Jahr ist diese Kat nicht mehr einsetzbar, weil diverse Leute ihre Fehler parallel hier auflaufen lassen.
  • Es muss aber jeder Fehler sofort beseitigt werden, weil sonst nicht mehr nachvollziehbar ist, welche aktuelle Änderung hier aufschlägt und von welchem Modul sie stammt.
  • Jetzt stehen Fehler aller beteiligten Module durcheinander drin.
• Man kann jetzt nur noch eins machen: Sich einen Artikel raussuchen, in dem möglichst wenig Vorlagen vorkommen und dementsprechend maximal ein Modul, und bei dem die Programmierfehler beheben.
  • Wobei die seit Jahren stabilen Bibliotheksmodule ohne Wikidata ziemlich unverdächtig sind; also ein Artikel, bei dem ein in den letzten Monaten geändertes oder mit Wikidata arbeitendes Modul auftritt und sonst keine anderen oder nur wenige robuste Bibliotheksmodule.
• Es dauert ggf. einige Monate, bis ein Artikel hier aufschlägt, weil die Änderung einer Vorlage oder eines Moduls nicht sofort alle einbindenden Artikel hier einsortieren lassen muss. Dass eine Änderung schon einige Wochen her ist, heißt noch gar nichts.
• Irgendwelches Bot-purgen der Kategorie ist weder erforderlich noch sinnvoll; nachdem ein Programmierfehler beseitigt wurde, verschwinden die von selbst wieder.
  • Wenn man linkupdate-purgen möchte, dann genau diejenigen Seiten, die ein kürzlich repariertes Modul einbinden.

Viel Spaß --PerfektesChaos 14:07, 2. Aug. 2017 (CEST)

Es kommt mir hier ein bisschen vor wie in der Politik: Alle weisen die Schuld von sich und keiner will die Verantwortung übernehmen. Ich würde folgende Vorgehensweise vorschlagen: Vorlage:Wartung-Film auskommentieren und dann sämtliche einsortierten Artikel purgen. Dann dürfte der Fehler weg sein und auch nicht mehr auftauchen. Die Vorlage wird dann wieder scharf geschaltet wenn sie korrigiert ist. 129.13.72.198 14:26, 2. Aug. 2017 (CEST)

Da die Vorlage nur zu Wartungszwecken eingerichtet wurde, kann sie gern zu Wartungszwecken auf einen Leerstring zurückgesetzt werden. –Queryzo ?! 16:49, 2. Aug. 2017 (CEST)

Gut, dann mach das mal, die Vorlage ist vollgesperrt. 88.67.125.95 19:38, 2. Aug. 2017 (CEST)

Läuft wieder voll - Editmarke 2

Es würde wohl vorerst reichen, die Vorlage aus der Vorlage:IMDb auszuklammern. –Queryzo ?! 07:38, 3. Aug. 2017 (CEST)

Und warum machst du das dann nicht? 129.13.72.198 09:23, 3. Aug. 2017 (CEST)

Weil die Vermutung, dass es (wieder mal) an den Vorlagen IMDb/Wartung-Film liegt (nachdem der Radsport offenbar gefixt ist), auf der Hand liegt. Man kann gern durch Vorlagenänderung zigtausende Artikel purgen, vermutlich würden die meisten oder alle Artikel dann aus dieser Kategorie verschwinden. Oder man setzt sich endlich mal ran und versucht das eigentliche Problem zu lösen, denn sonst taucht es alle paar Monate wieder auf. PerfektesChaos sieht diese Aufgabe allein beim Programmierer, allerdings bin ich hierbei auf Hilfe angewiesen. Denn möglicherweise gibt es auch Probleme in den Bibliotheksmodulen, immerhin werden in den genannten Vorlagen keine "Eigenkreationen" (mehr) verwendet. Hierzu ist anzumerken, dass z.B. am Modul:Wikidata auch fortlaufend gearbeitet wird. Zwar werden neue Funktionen wie die Funktion p.isSubclass vorher getestet, das heißt aber nicht, dass diese komplett bugfrei sind. Zu genannter Funktion gab es Anfang Juni bereits einen Bugfix, dieser bezog sich auf die von PerfektesChaos bereits angesprochene Problematik von Rückgabewerten, die auf der dortigen Disk auch kontrovers diskutiert wurde. @Yellowcard: Zur Info. –Queryzo ?! 10:48, 3. Aug. 2017 (CEST)

Wenn diese „auskommentiert“ wäre, dann nur diejenigen Seiten purgen, in denen diese immer noch eingebunden wäre; heißt: deren Programmierung durch einen leeren String ersetzen (<onlyinclude></onlyinclude>).

Weil umseitig auch nicht-Film beteiligt ist, muss es noch mehr Fehler und Module geben.

Die Kat war mehrere Jahre lang praktisch leer, und Einträge hielten sich nur wenige Stunden. Dann kam Radsport, dann Wikidata und schließlich RFF; seit Ende 2016 gibt es Dauergäste, deren Programmierer sich weigern ihre Fehler zu beseitigen.

VG --PerfektesChaos 14:54, 2. Aug. 2017 (CEST)

Es gibt zig Radsport-Artikel, die ein nicht-existentes Modul einbinden. Darunter auch Vorlage:Cycling race/listofstages/Doku (die sich auch in dieser Wartungskategorie befindet). Von einer Dokuseite sollte man eigentlich erwarten, dass sie fehlerfrei ist. Aber was soll man von einem Portal erwarten, dem es offensichtlich scheißegal ist, dass es zwei völlig redundante Infoboxen für Radrennen gibt? 129.13.72.198 15:09, 2. Aug. 2017 (CEST)

Das habe ich mal auskommentiert und durch eine Emulation ersetzt. Statt mit pcall das fehlende Modul aufzurufen, wird den Variablen jetzt direkt "nil" zugewiesen. ÅñŧóñŜûŝî (Ð) 22:25, 2. Aug. 2017 (CEST)

Das hat jetzt die Radsport-Seiten aus der Kategorie gekegelt, immerhin. 88.67.125.95 22:53, 2. Aug. 2017 (CEST)

⇐⇐ Es sind fast alles Personen. Es muss also noch eine Vorlage sein, welche in Personenartikeln vorkommt. Das kann eigentlich nur Vorlage:IMDb sein. ÅñŧóñŜûŝî (Ð) 17:54, 3. Aug. 2017 (CEST)

Mittlerweile sind auch Artikel wie 20. Februar in der Kategorie, bei denen der Übeltäter keine Filmvorlage sein kann. 129.13.72.198 09:25, 4. Aug. 2017 (CEST)

Läuft wieder voll - Editmarke 3

---

• Ich schrieb oben, man suche sich kurze Seiten heraus, bei denen möglichst wenig Vorlagen und Module auftreten.
• BD:Berthold Werner ist so ein Fall.
• Dort wird in BD:Berthold Werner #Test rumgespielt; offenbar der einzige Aufruf.
• Wozu immer das gut sei mag und ob das auf einer BD sinnvoll wäre oder nicht – es darf auf gar keinen Fall dazu kommen, dass das Modul mit Skriptfehler abstürzt und hier aufschlägt. Wenn es etwas Verbotenes ist, dann muss eine klare Fehlermeldung erscheinen, notfalls einfach eine leere Zeichenkette zurückgegeben werden; aber nie und nimmer in dieser Kat auftauchen. Und die Situation, in der das #invoke erfolgt, muss sauber analysiert werden und es dürfen keinerlei Annahmen gemacht werden, diese und jene Umstände und Voraussetzungen würden schon irgendwie gegeben und erfüllt sein.

VG --PerfektesChaos 10:33, 4. Aug. 2017 (CEST)

Wie willst du Skriptfehler finden, welche nach einiger Zeit aber nicht direkt nach einem Nulledit (!) quasi "von selbst" wieder verschwinden? Siehe dazu den nächten Abschnitt.

(BK)

1. Das von mir soeben benannte Beispiel ist aber auch nach purge-linkupdate-rekursiv noch kategorisiert.
2. Indem so sorgfältig programmiert wird, dass nach jedem gefahrenträchtigen Zugriff auf Wikidata überprüft wird, welchen Datentyp das hat, wie ggf. eine Zeichenkette formatiert sei, und man nicht einfach im Blindflug dran glaubt, es wäre immer alles wie normal, und fertig. Auch dies schrieb ich bereits.
3. Indem abschließend auf verbleibende error ein catch gelegt wird und dies in eine Wartungskat für ein bestimmtes Modul und ggf. eine bestimmte Funktion geleitet wird, und nicht pauschal diese projektweite Rückfallkat versaut wird.
4. Wenn man nicht selbst zuvor bereits überprüft hatte, dass der Datumsparameter vom Typ string ist, sondern der irgendwie vom Himmel gefallen war, dann darf man weder trim() noch sonstwas damit machen. Könnte eine table mit mehreren Tagen sein, könnte nil sein. Wer mit externen Daten hantiert, ohne ihren Typ zu prüfen, sollte die Finger von Software lassen, die in eine halbe Million Artikel eingebunden werden soll.

VG --PerfektesChaos 11:07, 4. Aug. 2017 (CEST)

Das da blindlings auf Rückgabewerte vertraut wird, ist mir auch schon aufgefallen. Entweder man greift das ab und reagiert aktiv, oder man behandelt es zumindest symptomatisch und schreibt z. b. bei Strings als Rückgabe einen Defaultwert dahinter, also statt sowas wie

    variable = GibMirDenString(para1, para2)
    zahl = #variable

besser entweder

    variable = GibMirDenString(para1, para2) or ""
    zahl = #variable

oder

    variable = GibMirDenString(para1, para2)
    if variable then
        zahl = #variable
    else
        zahl= 0 -- hier kann man auch weiteres einbauen.
    end

Dann kommt zwar ggf. inhaltlich Unsinn zurück, aber der Skriptfehler kann dann weg sein. ÅñŧóñŜûŝî (Ð) 12:03, 4. Aug. 2017 (CEST)

Die Vorlage:Commonscat löst diesen Fehler ebenfalls aus. ÅñŧóñŜûŝî (Ð) 08:38, 6. Aug. 2017 (CEST)

Skriptfehler bei Infoboxen

Benötigte Links: Modul:Wikidata, Vorlage:Infobox Software

Bei der Vorlage:Infobox Software ist gestern im Artikel MySQL in der Infobox bei der Versionsangabe eine Fehlermeldung aufgetaucht, dass in der Zeile 207 bei #yearstr der Längenoperator auf einen Nil-Wert angewendet wird. Quelltextauszug:

201   local function normalizeDate(date)
202       date = mw.text.trim(date, "+")
203       -- extract year
204       local yearstr = mw.ustring.match(date, "^\-?%d+")
205       local year = tonumber(yearstr)
206       -- remove leading zeros of year
207       return year .. mw.ustring.sub(date, #yearstr + 1), year
208   end

Der Aufruf lautet: {{#invoke:Wikidata|claim|Version}}. Dieser Fehler war auch nach einem Nulledit des Artikels noch da und ist inzwischen verschwunden, obwohl das Modul - nach vergeblichen Reparaturversuchen von mir - und die Vorlage im gleichen Zustand wie gestern sind. ÅñŧóñŜûŝî (Ð) 10:48, 4. Aug. 2017 (CEST)

Das passt, neuerdings kriege ich viele Aussetzer der Funktion formatDate(), die auf normalizeDate() zurückgreift. m.E. müsste in der Funktion zunächst die Gültigkeit der Variable date geprüft werden. Ein einfaches

	if date then
          ...
        end

wird aber wohl nicht reichen, da formatDate() und die Funktion printDatavalueTime() darauf vorbereitet werden müssen, dass es ggf. keinen Rückgabewert gibt. –Queryzo ?! 10:58, 4. Aug. 2017 (CEST)

Kann der von der Wikisoftware markierte Backslash eine Rolle spielen? Z.B., weil er maskiert werden muss? Auf jeden Fall müssen ausnahmslos alle (!) Rückgabewerte von Funktionen, welche mit Wikidata-Daten arbeiten, auf Gültigkeit geprüft werden. Wenn das nicht reicht, so muss die Funktion einen erkennbaren Fehlerwert liefern und das Skript kontrolliert enden. Bei einem String kann das beispielsweise "???" sein. Informationen über Fehler kann man bei Lua einfach über einen zusätzlichen Fehlercode an die aufrufende Funktion zurückgeben:

    function MeineFunktion(Patrameterliste)
        -- ...
        -- ...
        -- ...
        return Ergebnis, Fehlercode
    end
    -- ...
    -- ...
    -- Aufruf:
    Ergebnis, isOk = MeineFunktion(Patrameterliste)

ÅñŧóñŜûŝî (Ð) 12:06, 4. Aug. 2017 (CEST)

Der Backslash maskiert den folgenden Bindestrich, das ganze wird schließlich durch das ^ negiert, heißt: Finde alle Zahlen, denen nicht ein Bindestrich voransteht. Im RegExr funktioniert der Regex z.B. für +2017-09-21T00:00:00Z einwandfrei (ohne führendes "+", das durch trim() entfernt wird). Ich vermute eher, dass date bei Wikidata-Aussetzern leer ist. –Queryzo ?! 13:34, 4. Aug. 2017 (CEST)

Das ist sehr wahrscheinlich. Ich kenne die Art und Weise, wie das Modul auf Daten zugreift, noch nicht. Ist das irgendwo beschrieben? Dem Quelltext nach vermute ich irgendwelche Aufrufe mit mw. am Anfang. Es muss unterschieden werden, ob diese Funktionen bei fehlenden / falschen Daten nur leere Strings oder gar nil zurückgeben. Wie sieht der Inhalt dieser Variable date denn beim Aufruf korrekter Weise aus? Immer im so wie in deinem Beispiel, also immer '+'YYYY-MM-DD'T'hh:mm:ss<Zone>? ÅñŧóñŜûŝî (Ð) 14:17, 4. Aug. 2017 (CEST)

@Yellowcard, Mps, MichaelSchoenitzer, Pasleim: Könnte einer von euch mal auf das Modul draufgucken? –Queryzo ?! 12:12, 7. Aug. 2017 (CEST)

^\-?%d+ heißt gib den Text am Anfang (^) zurück, der optional (?) mit einem Bindestrich/Minus (\-, der Backslash ist zum Escapen notwendig, da ein bloßes - für den Quantifikator non-greedy, 0 oder mehr Vorkommen steht – die üblichen PCRE verwenden stattdessen *?) anfängt, gefolgt von Zahlen (%d+) beginnt.

Der Fehler lässt darauf schließen dass der Regex keinen Treffer hat – wäre date = nil, dann hätte man schon bei Zeile 202 einen Fehler bekommen, da mw.text.trim kein nil akzeptiert. Ein Fehler bei Zeile 207 kann nur auftreten wenn date leer ("") ist, mit Whitespace beginnt oder kein Datum ist. Man könnte natürlich extrem defensiv programmieren, allerdings wäre es besser mal ein Beispiel zu haben, wenn Wikidata fehlerhafte Daten zurückgibt und wie diese ausschauen, zumal in Kategorie:Wikipedia:Seite mit Skriptfehlern auch Seiten mit {{Begriffsklärung}} aufgeführt werden, wo lediglich die pageId-Funktion aufgerufen wird und ich mich frage was bei diese simplen Funktion für ein Skriptfehler auftreten soll. --Mps、かみまみた^Disk. 23:57, 8. Aug. 2017 (CEST)

@Mps: Ich habe den Fehler (oder einen anderen?) nun auf frischer Tat ertappt, vielleicht hilft das bei der Fehlersuche:

–Queryzo ?! 10:35, 10. Aug. 2017 (CEST)

Interessant, das ist in ein Fehler der in dem Mediawiki-Softwareteil der für uns die Wikidata-Funktionen bereitstellt (siehe https://github.com/wikimedia/mediawiki-extensions-Wikidata/blob/master/extensions/Wikibase/client/includes/DataAccess/Scribunto/mw.wikibase.entity.lua#L77) auftritt. Da würde es auch nichts bringen wenn wir immer nur auf gültige Daten prüfen würden, sondern wir müssten zusätzlich auch jeden mw.wikibase-Aufruf in einen pcall verpacken, da anscheinend auch Basisfunktionen des Frameworks jederzeit nicht verfügbar sein könnten. Die Ursache für diesen und unseren Fehler scheint aber dieselbe, das manchmal der Wikidata-Server keine oder fehlerhafte Daten zurückliefert. --Mps、かみまみた^Disk. 22:03, 10. Aug. 2017 (CEST)

Es ist doch ganz bestimmt ein Fehler, wenn man in einer exportierten Funktion - also meistens "p.funktionsname" - "nil" zurückgeben will. Genaugenommen lösche ich damit ein Frame-Element aus der Parametertabelle. Das sollte man dringend ändern und "" zuweisen. ÅñŧóñŜûŝî (Ð) 14:56, 10. Aug. 2017 (CEST)

Tue ich das? Wenn ich folgende Testfunktion Modul:Benutzer:Mps/Test die nil zurückgibt hier aufrufe ({{#invoke:Benutzer:Mps/Test|Null}} = "", und ein Roundtrip: {{Str len|{{#invoke:Benutzer:Mps/Test|Null}}}} = 0) gibt es keinen Fehler. Die Doku (https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Frame_object) erwähnt auch nicht, dass das Ergebnis im Frame-Argument landet und scheibt weiter oben nur "whatever values are returned will be passed through tostring() and then concatenated with no separator. This string is incorporated into the wikitext as the result of the {{#invoke:}}." nil zurückgeben scheint also ok zu sein. --Mps、かみまみた^Disk. 22:03, 10. Aug. 2017 (CEST)

Da stellt sich die Frage: "Was gibt er bei "return nil" genau zurück?" Den leeren String oder das Wort "nil"? Ähnlich bei boolschen Werten: Gibt es bei "return false" den leeren String (also 'falsch' in Wikisyntax) oder den String "false" (also 'wahr' in Wikisyntax) zurück? Ich habe einen kleinen Test gemacht. Vermutlich bewirkt "return nil" einen leeren String und "return false" tatsächlich den String "false"... Es wäre auch interessant, ob es bei der Rückgabe an den Wikiparser versteckte Skriptfehler geben kann. ÅñŧóñŜûŝî (Ð) 22:35, 10. Aug. 2017 (CEST)

Das mit den Rückgabewerten ist korrekt. Glaubt ihr dass wir das hinkriegen oder sollten wir WMDE benachrichtigen? Spontan fällt mir da nur Birgit Müller ein. –Queryzo ?! 07:51, 11. Aug. 2017 (CEST)

Habe T171392 gefunden, dort geht es um andere Sprache der Benutzeroberfläche, das hat aber ein schneller Test hier keine Unterschiede gezeigt. Es gibt aber auch ein Fix für lua. Vielleicht reicht es auch noch etwas zu warten. Anderseits kann es auch ein Fehler im lua-Wikidata-Code sein. Der Umherirrende 19:52, 17. Aug. 2017 (CEST)

• Es mag sein, dass es momentan serverseitig zu Häufungen an Interwiki-Problemen kommt; aber diese Ausfälle von Wikidata-Resultaten gibt es schon seit Jahren.
• Unser eigenes Zeugs ist auch ziemlich buggy, mehrere Fehler wurden ja jetzt bereits identifiziert.
• Es hat also keinen Sinn, die Hände in den Schoß zu legen und darauf zu warten, dass MediaWiki einem alles regeln würde.
• Weil oben die Frage aufgeworfen wurde, wie die Rückgabewerte von Funktionen beim #invoke aussehen würden: Das ist seit Jahr und Tag nachzulesen unter Hilfe:Lua/Modul im Wiki #Rückgabewert einer Funktion für Vorlagen.
• Defensives Programmieren wäre übrigens mal eine schlaue Idee.

VG --PerfektesChaos 21:36, 17. Aug. 2017 (CEST)

@PerfektesChaos: Klar ist defensives programmieren zweckmäßig. Insbesondere sollte man Variablenwerte, welche "von irgendwo draußen", also nicht aus einer Funktion des gleichen Moduls, stammen, sorgfältig prüfen. Ebenso sinnvoll wäre es, im Modul:Wikidata mal alle Return-Befehle der exportierten Funktionen auf explizite Stringrückgabe zu prüfen. Das Modul gibt an mehreren Stellen nil oder "false" an den Wikiparser zurück:

1. Zeile 560: result ist entweder "true" oder "false", also immer "wiki-wahr" (=nichtleerer String).
2. Zeile 569: Ist dieses If nicht erfüllt, endet die Funktion ohne Return-Befehl.
3. Zeile 580: Auch hier: Ist dieses If nicht erfüllt, endet die Funktion ohne Return-Befehl.
4. Zeilen 606, 612, 617 (evtl. auch 724): Wird kein Defaultwert an die Funktion übergeben, wird hier nil zurückgegeben (sollte ein Leerstring sein, widerspricht aber der zitierten Hilfeseite)
5. Zeilen 633 und 636: bedingte Rückgabe von String "false", also "wiki-wahr".
6. Zeilen 665 und 667: gibt einen boolschen Wert zurück, also entweder "true" oder "false", also immer "wiki-wahr".
7. Zeile 730: Rückgabewet von "param" kann nil sein.

das liese sich noch fortsetzen.

Wenn du soviel Wert auf defensive Programmierung legst, dann schlage ich vor, du kämmst das Modul mal durch und behebst derartige Ungereimtheiten. Gruß von ÅñŧóñŜûŝî (Ð) 22:56, 18. Aug. 2017 (CEST)

• Bedaure, ich habe eine ToDo-Liste mit Hunderten an offenen Punkten, darunter dringliche, und nehme keine größere Aktivität mehr auf.
  • Hier müsste ich nach einer Änderung auch noch ausgiebig mit Wikidata-Werten testen, und danach noch für Rückfragen und verursachte Nebenwirkungen und Folgen zur Verfügung stehen.
  • Verantworlich für die ordnungsgemäße Programmierung sind diejenigen, die bisher an dem Modul editiert hatten.
  • Ich mache nur noch neue Sachen, die sich in etwa einer Viertelstunde wieder abschließen lassen.
    • Ein wenig triviales Formatieren für zwischendurch, so zur Entspannung.
    • Oder ein Disku-Beitrag wie dieser hier.
  • Ansonsten habe ich für weit über Hundert Gadgets, Bibliotheksmodule und Vorlagenpakete usw. die Betreuungsverantwortung.
• Es müssen immer zwei Typen von Lua-Funktionen sauber unterschieden werden:
  1. Aufruf per #invoke
     • Adressat ist die Vorlagenprogrammierung.
     • Einziger Parameter ist (frame) (selten keiner).
     • Rückgabewert ist immer string.
       • Ggf. return r or ""
       • tostring(nil) ist "nil", wie jeder leicht herausfinden kann.
  2. Funktionsaufruf für andere Lua-Funktion
     • Parameter sind allerlei außer frame.
     • Rückgabewert hat viele Typen.
       • string oder table usw. signalisiert, dass inhaltlich wertvolle Informationen bekannt sind.
       • nil oder edler false signalisiert, dass keine Informationen verfügbar sind.
       • Ein tostring() darf hier niemals erfolgen.
• Neben „defensiv“ gibt es noch ein Konzept: design by contract. Heißt:
  1. Es gibt vertrauenswürdige Funktionen aus dem eigenen Modul oder robusten, als sauber bekannten Bibliotheksmodulen, die immer ihren Vertrag einhalten.
     • Hier kann man darauf vertrauen, dass sie sich wie dokumentiert verhalten.
     • Zusätzliches Rumanalysieren ist schlecht für die Performance.
     • Alles andere ist nach Datentyp und Formatierung zunächst zu prüfen, triviale Nickeligkeiten stillschweigend zu heilen, ansonsten angemessen auf Fehler zu reagieren, ggf. melden.
     • Alles, was per #invoke aus einer Wiki-Seite kommt, gilt grundsätzlich als zweifelhaft.
     • Alle Dateneintragungen (string) in Wikidata gelten hinsichtlich der Formatierung grundsätzlich als zweifelhaft.
     • Wenn die Verbindung im Server zur Datenbank von Wikidata bekanntermaßen zeitweise instabil ist, dann müssen alle Rückgabewerte von dort auf Vertragstreue geprüft werden, notfalls mit pcall() abgefangen werden.
       • Das mw-Bibliotheksmodul sollte das aber tunlichst selber machen und entweder Rückgabewerte intern wieder vertragstreu normalisieren, oder aber offiziell mögliche ausgelöste Problemsituationen per error() auch in der Doku beschreiben.
       • Wenn eine Funktion dokumentiert, dass sie auch exception neben dem normalen Rücksprung vorsieht, dann muss sie immer mit pcall() (entspräche dem catch, error() ist das throw in Lua) verwendet werden.
       • Inhaltliche Eintragungen in Wikidata können unterschiedliche Datentypen haben, etwa string (ein Wert), table (mehrere Werte, etwa mehrere strings), vielleicht mal number, sonst nil (false).
  2. Die Doku der Funktion ist der Vertrag. Taugt die Doku nix, ist der Vertrag Murks und die Funktion auch.

VG --PerfektesChaos 14:51, 19. Aug. 2017 (CEST)

@PerfektesChaos: Ok. Danke für die Info. Ich bräuchte noch einen Tipp von dir: Soweit ich weis, wird eine Funktion mit dem Aufruf

result = funktionsname(Parameterliste)

Bei Verwendung von pcall mit

isOk, result = pcall(funktionsname, Parameterliste)

aufgerufen.

Wie lautet die Syntax, wenn ich damit frame:expandTemplate{ title = pagename, args = {} } mit pcall aufrufen will? ÅñŧóñŜûŝî (Ð) 19:55, 19. Aug. 2017 (CEST)

Vorlage:Defekter Weblink

... macht mal wieder Ärger. Sie füllt die Kategorie. ÅñŧóñŜûŝî (Ð) 21:06, 9. Apr. 2021 (CEST)

???????????? Ich seh nix.

Da gibt es nur eine einzige Artikel-Disk, von der die Vorderseite auch wegen Wikidata oder zu großer Seite mit zu viel Zeugs abgeraucht ist.

Du musst nicht immer wegen irgendwelcher Phantome auf dem Server Alarm schlagen. Meist verschwindet das dann nach ein paar Tagen ganz von selbst. Wenn die Seiten zu viel Syntaxgedöns und Wikidata machen, und der Server gleichzeitig überbeansprucht ist, dann reißen die schon mal das physische Zeitlimit.

VG --PerfektesChaos 16:27, 10. Apr. 2021 (CEST)

@PerfektesChaos: Dazu kann ich nur sagen, dass der Skriptfehler verschwindet, wenn die Einbindung auskommentiert wird. Ob das mit dieser "Pseudoeinbindung" - ich nenne das mal so - des Artikels zusammenhängt, musst du wissen. Der Artikel muss dazu nicht auf der Liste der Seiten mit Skriptfehlern auftauchen. Modul:Vorlage:Defekter Weblink ist ein von dir erstelltes und betreutes Modul. Es obliegt dir, durch geignete Änderungen am Modul dafür zu sorgen, dass Wikidata-Müll nicht auf die Einbindung durchschlägt. Ebenso, dass es keine derartigen Phantom-Einträge gibt. ÅñŧóñŜûŝî (Ð) 18:33, 10. Apr. 2021 (CEST)

Es gibt den Artikel Vergleich von BSD-Betriebssystemen mit zurzeit 10 Wikidata-Skriptfehlern, und der schlägt genauso auf die Disk durch.

Das wissen alle Leute, die sich mit dieser Experten-Wartungskategorie für Lua-Skriptfehler befassen, und wissen es auch zu ignorieren.

Über diese eine Diskussion:Vergleich von BSD-Betriebssystemen hinaus ist umseitig nichts kategorisiert, also mach hier keinen Aufstand.

BNS --PerfektesChaos 18:42, 10. Apr. 2021 (CEST)

Vorlagen mit Monstercode

Es gibt hier etliche Vorlagen, welche extrem lange laufen und spätestens beim Massenaufruf per frame:expandTemplate eine Zeitüberschreitung bewirken. Dazu zählen die Vorlagen wie Vorlage:Metadaten Gebäudezahl AT Siedlung mit ihrem 100000-Einträge-Switch. Das ganze per Vorlage:HWZ dutzende mal aufgerufen und dann ist Ende der Fahnenstange. Wenns doch mal geklappt hat, dann ist das Ergebnis im Cache und die Seite verschwindet aus der Kat, bis einer etwas ändert. Da wäre auch mal ein Ansatz, die Kat leer zu halten. ÅñŧóñŜûŝî (Ð) 19:57, 10. Apr. 2021 (CEST)