Benutzer Diskussion:Rene: Unterschied zwischen den Versionen

<big>Verweise & Infos</big>

** [[Benutzer Diskussion:Rene/Archiv 1|Seite 1]], [[Benutzer Diskussion:Rene/Archiv 2|Seite 2]], [[Benutzer Diskussion:Rene/Archiv 3|Seite 3]], [[Benutzer Diskussion:Rene/Archiv 4|Seite 4]], [[Benutzer Diskussion:Rene/Archiv 5|Seite 5]], [[Benutzer Diskussion:Rene/Archiv 6|Seite 6]], [[Benutzer Diskussion:Rene/Archiv 7|Seite 7]], [[Benutzer Diskussion:Rene/Archiv 8|Seite 8]], [[Benutzer Diskussion:Rene/Archiv 9|Seite 9]], [[Benutzer Diskussion:Rene/Archiv 10|Seite 10]], [[Benutzer Diskussion:Rene/Archiv 11|Seite 11 (teilweise noch offen)]]

* [[StarGateWiki:Server|Infoseite zu Server & MediaWiki-Software]], [[Benutzer:Rene/Upgrade Wiki|Update Wiki Hinweise]]

=== Admins können nicht mehr alle Seiten bearbeiten (erledigt) ===

Admins können die Benutzerseiten anderer User nicht mehr bearbeiten. --{{Benutzer:Col. o'neill/sig}} 18:05, 31. Dez. 2014 (CET)

:Update für SGPack schreibe ich gerade. Ist eigentlich fertig aber ich will es noch mal prüfen. Habe noch ein paar Anpassungen an MW 1.24 gemacht. Ich hoffe ich habe alle "alten" Funktionen erwischt, damit beim nächsten Update alles ohne Probleme geht. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 22:59, 1. Jan. 2015 (CET)

::Update installiert. Bearbeitung ist wieder möglich. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 21:45, 8. Jan. 2015 (CET)

 

=== CodeEditor Übersetzung (erledigt) ===

Könntest Du beim Codeeditor noch die Nachrichten übersetzen? Also z.B. "Search for", "CaseSensitive Search" und je nach dem ob das geht auch die Fehlermeldungen. Ich habe vergeblich nach einer Möglichkeit gesucht, das selbst über eine MW-Seite anzupassen... --{{Benutzer:Col. o'neill/sig}} 20:29, 2. Jan. 2015 (CET)

:Also es gibt scheinbar drei Meldungen die der Editor ausgibt. Diese drei sind in über hundert Sprachen übersetzt bereits enthalten. Die von dir angegeben Meldungen finde ich nicht, ich finde die Suche nicht mal im Editor. Wie kommt man da hin? [[Bild:Sad.gif]] --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 17:42, 8. Jan. 2015 (CET)

::Einfach im Editor Strg.+F drücken. Und welche drei Meldungen sind denn übersetzt? --{{Benutzer:Col. o'neill/sig}} 17:45, 8. Jan. 2015 (CET)

:::"Codeeditor ein- und ausschalten", "Das Dokument enthält Fehler willst du es wirklich speichern?" sowie die Beschreibung auf der Versionsseite. Die Texte die du meinst gehören zum [http://ace.c9.io/#nav=about ACE Editor]. Dafür gibt es keine deutschen Texte. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 19:37, 8. Jan. 2015 (CET)

::::Oh, okay. Schade. Naja, dann muss man halt ein wenig Englisch können, wenn man den CodeEditor benutzt. Sollte ja eigentlich kaum ein Problem sein...^^ --{{Benutzer:Col. o'neill/sig}} 19:52, 8. Jan. 2015 (CET)

 

Ich habe beobachtet, dass bei vielen Seiten im HNR die Meldung über eine ungesichtete Version erscheint obwohl die akuellste Version gesichtete ist (gesichtete und ungesichtete identisch), kann das an der Umstellung liegen? Beispiel: {{Ep|SG1|1x02}} --{{Benutzer:Simeon/sig}} 22:43, 2. Jan. 2015 (CET)

:Ich sehe keine solchen Fälle. Ich vermute aber, dass das die üblichen Meldungen wegen Änderungen an einer eingebundenen Vorlage / einem Bild waren. Die gab es schon vorher und sind normal. Das ist kein Bug. --{{Benutzer:Col. o'neill/sig}} 09:47, 3. Jan. 2015 (CET)

::Soweit ich gesehen habe liegt es tatsächlich an Vorlagen. Eine [[Vorlage:!!]] habe ich als gesichtet markiert. Ich habe allerdings auch einen Artikel gefunden der wegen der [[Vorlage:!]] gesichtet werden soll. Diese Vorlage gibt es aber gar nicht. [[Bild:Surprised.gif]]--[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 19:41, 8. Jan. 2015 (CET)

:::Es liegt an der Vorlage:! - da <code><nowiki>{{!}}</nowiki></code> mittlerweile aber fest in MW integriert ist und man keine extra Vorlage mehr dafür braucht, habe ich die vor einigen Tagen gelöscht. Da es eine sehr elementare Vorlage ist, wird sie (indirekt) auf einer Menge Seiten eingebunden und die Sicht-Funktion will ja immer, dass man Seiten mit geänderten eingebundenen Vorlagen und Dateien nochmal sichtet. In diesem Fall ist die Änderung die Löschung der Vorlage und damit das Zurückgreifen auf die MW-"Vorlage". Daher werden jede Menge Seiten als zu sichten angezeigt. Das ist nichts neues und war, wie gesagt, vorher auch schon so, wenn man eine Datei oder Vorlage geändert hat. Vorher halt natürlich nicht in dem Ausmaße - es ist aber eben kein Fehler und softwareseitig gehört das so. Mir stellt sich gerade jetzt aber die Frage, ob es nicht sinnvoll wäre, es abzuschalten, dass man Seiten mit geänderten eingebundenen Elementen neu sichten muss. In den Letzten Änderungen entgeht uns ohnehin nichts mehr und Vorlagen können ja von Spam-IPs etc. ohnehin nicht geändert werden. Alles was dieser Hinweis tut ist überflüssig irritieren/stören und eine Menge Seiten als unmarkiert zu kennzeichnen. Kann man diese spezielle Funktion nicht einfach deaktivieren? --{{Benutzer:Col. o'neill/sig}} 19:52, 8. Jan. 2015 (CET)

::::Wenn mir einer sagt wie[[Bild:VeryHappy.gif]]. Das ist etwas verzwickt. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 23:44, 8. Jan. 2015 (CET)

Aktuell muss man Bearbeitungen im HNR sowohl kontrollieren als auch sichten. Eins von beiden sollte ja reichen - wofür brauchen wir diese Kontroll-Geschichte eigentlich noch, wenn es das Sichten gibt? --{{Benutzer:Col. o'neill/sig}} 18:36, 6. Jan. 2015 (CET)

:Ganz ehrlich. Ich bin mit dem Sichten und der Versionskontrolle nie ganz warm geworden. Ich war damals froh das es so weit gelaufen ist. Vielleicht muss sich da mal jemand wirklich mit befassen was man einstellen muss. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 23:33, 20. Jan. 2015 (CET)

::Es sollte eigentlich reichen, in den LocalSettings.php <code>$wgUseRCPatrol = false;</code> hinzuzufügen. Offenbar gibt es momentan dann noch einen [https://phabricator.wikimedia.org/T44246 kleinen Bug], durch den man in den Logbüchern die Kontroll-Einträge nicht mehr ausblenden kann - allerdings gibt es dafür bereits länger [https://gerrit.wikimedia.org/r/#/c/42279/ einen Patch]. Wie auch bei der JS-Warnungs-Sache muss dabei u.A. die DefaultSettings.php bearbeitet werden, d.h. das Ganze muss (wenn MW den Bug bis dahin nicht behoben haben wird) evtl. bei jedem MW-Upgrade nochmal gemacht werden. Am besten also erstmal im Testwiki testen...^^ --{{Benutzer:Col. o'neill/sig}} 16:41, 30. Jan. 2015 (CET)

----

Es gab leider einen Fehler im Skript das regelmäßig runJobs ausführt. Habe das Skript gerade manuell ausgeführt, hat über zwei Stunden gedauert weil es beim laufen noch zusätzliche Jobs angelegt hat. Da unter anderem die Vorlage:! bearbeitet wurde hoffe ich die merkwürdigen Sichtungsmeldungen sind jetzt weg. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 20:43, 27. Jan. 2015 (CET)

:Ahhh, das erklärt auch direkt, wieso in letzter Zeit [[StargateWiki:Technik-Zentrale/Archiv#Aktualisierung der Linklisten|die Linklisten eine Unendlichkeit gebraucht haben, sich zu updaten]]. Hauptsache es ist jetzt behoben - Danke! --{{Benutzer:Col. o'neill/sig}} 20:59, 27. Jan. 2015 (CET)

 

:Das sollte sich nach Möglichkeit [[Benutzer:CF]] ansehen. Ich vermute das man das Javascript [[Benutzer:CF/revisionMainspaceCounter.js]] in [[Mediawiki:Common.js]] anpassen muss. --[[Benutzer:Rene|Rene]] ^{[[Hilfe:Bürokraten|Bürokrat]] - [[Benutzer Diskussion:Rene|Rückmeldung]]} 21:41, 6. Jan. 2015 (CET)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Wieder mal die recursiv-Funktion (thx [[Benutzer:D5B|D5B]] fürs [http://stargate-wiki.de/w/index.php?title=Pat_Meyers&diff=344489&oldid=343241 entdecken], in dem speziellen Fall hat der Bug die ganze Infobox drumrum gleich mit zerhackt). Hier bin ich selbst nicht sicher, wo genau der Ursprung des Problems liegt. Irgendwie scheinen Links im übergebenen Text unter bestimmten Bedingungen zu einer falschen Aufteilung und Verarbeitung des Textes zu führen.

Aufgefallen dadurch, dass die recursiv-Erweiterung es anscheinend nicht verträgt, wenn die [[Vorlage:Ep]] im übergebenen Text ist und gleichzeitig ein Zusatzparameter existiert:

<code><nowiki>{{Kürzel|Rang|text {{Ep|SGA|2x02}} text|k}}}}</nowiki></code>

{{Kasten|1={{Kürzel|Rang|text {{Ep|SGA|2x02}} text|k}}}}

Man sieht, dass hier anscheinend an den Grenzen der beiden durch die Ep-Vorlage ausgegebenen Links gesplittet wird und so fünf Fragmente entstehen, unterwegs werden aber eben auch Parameter falsch verarbeitet, das "k" taucht im Klartext auf und der erste Text ebenso wie das öffnende span-tag verschwinden komplett. Dabei ist auch egal, ob der Zusatzparameter für die Zielvorlage definiert ist oder nicht - Hauptsache es wird an der Stelle noch etwas übergeben. In diesem Beispiel ist das Problem nicht mehr zu sehen, wenn kein Zusatzparameter (oben das k) mehr übergeben wird. Ebenso kann man den durch die Ep-Vorlage erzeugten Code (<code><nowiki><span style="display:none">SGA_02x02</span>[[Stargate Atlantis|SGA]]<span> </span>2x02<span style="white-space:nowrap">[[Der Eindringling]]</span></nowiki></code>) direkt einsetzen oder, wie in D5Bs verlinktem Edit, stattdessen einen Link in eine [[Vorlage:Anmerkung|Anmerkung]] packen und das Ergebnis schaut OK aus. Zumindest sichtbar ist der Fehler hier zwar mit der Ep-Vorlage aber nicht mit z.B. der verwandten EpLink oder EpName, die ebenso die carray-Erweiterung benutzen aber nur einen statt mehrere Links erzeugen:

wird wie erwartet zu:

Es ist aber auch nicht auf die Kürzelvorlage beschränkt, z.B. mit [[Vorlage:Review]] manuell in #recursiv eingesetzt wird die falsche Aufteilung in fünf Fragmente nochmal deutlicher und hier ist das Problem auch ohne Zusatzparameter zu sehen:

<code><nowiki>{{#recursiv:Review|text {{Ep|SGA|2x02}} text|}}</nowiki></code>

wird statt "nur" dem kaputten Link <code>[[StargateWiki:Review#text {{Ep|SGA|2x02}} text|text {{Ep|SGA|2x02}} text]]</code> zu:

{{Kasten|1={{#recursiv:Review|text {{Ep|SGA|2x02}} text|}}}}

Auch mit anderen Zielvorlagen wird nochmal deutlicher, dass die übergebene Vorlage im Text allgemein fälschlicherweise zu oft aufgerufen wird, wenn irgendeine Vorlage mit Links in der Ausgabe übergeben wird. Auch mit einem, ohne den Umweg über eine Vorlage direkt eingefügten Link im Text wird wieder gesplittet in den Teil vor dem Link, innerhalb des Links, und nach dem Link:

<code><nowiki>{{#recursiv:--|text [[Bild:Smile.gif]] text|}}</nowiki></code>

wird statt der einfachen, einzelnen Trennlinie mangels weiteren definierten Parametern zu:

{{Kasten|1={{#recursiv:--|text [[Bild:Smile.gif]] text|}}}}

Hingegen mit einer seltenen Vorlage ohne Link in der Ausgabe:

<code><nowiki>{{#recursiv:--|text {{Kürzel/Rang|usmc-pvt}} text|}}</nowiki></code>

wird wie erwartet zu:

{{Kasten|1={{#recursiv:--|text {{Kürzel/Rang|usmc-pvt}} text|}}}}

Mit etwas Glück geht das Verhalten über Umwege auf das oben schon angesprochene Problem mit der Linkbehandlung zurück. Mit etwas Pech und mit Blick darauf, dass nicht nur überhaupt an den Links gesplittet wird sondern auch der Input allgemein falsch verarbeitet wird, einzelne Teile verschwinden usw, ist es ein zusätzliches Problem.

--{{Benutzer:Col. o'neill/sig}} 19:15, 17. Nov. 2022 (CET)

: Sobald eckige Klammern im Text verwendet werden, splittet der verwendete Regex <code><nowiki>'/(\[\[.*?\]\]|\(.*?\))/i'</nowiki></code> diese auf und schickt somit alles vor, den Text in der Klammer und nach der Klammer einzeln an die Vorlage. Das kann behoben werden, indem der Regex eckige Klammer nicht als Trennzeichen ansieht: <code><nowiki>'/(\(.*?\))/i'</nowiki></code>.

: Mit diesen Änderungen liefern <code><nowiki>{{#recursiv:Review|text {{Ep|SGA|2x02}} text|}}</nowiki></code> und <code><nowiki>{{#recursiv:--|text [[Bild:Smile.gif]] text|}}</nowiki></code> die erwarteten Ergebnisse.

: Die Infobox crasht damit auch nicht mehr, allerdings tritt dann ein Fehler der Kürzelvorlage zu Tage: <code><nowiki>{{Kürzel|Rang|<br />''in {{Ep|SGA|2x01}} aber''<br />|k}}</nowiki></code> erzeugt nur <code>k</code> als Ausgabe und nicht <code>{{Kürzel|Rang|''in {{Ep|SGA|2x01}} aber''}}</code>. Ich gehe davon aus, dass das ein Substitutionsfehler in der Vorlage ist.

: --{{Benutzer:Ghost/Signatur}}  14:22, 22. Nov. 2022 (CET)

::Ah, stimmt, klar wird dann nach Links gesplittet. Die eckigen Klammern einfach rauszulassen scheint mir aber keine gute Lösung, die hatten ja schon ihren Grund - nur scheint die Implementierung den Zweck nicht so recht zu erfüllen. Die eckigen Klammern werden extra gesucht, weil Ausdrücke in Links allgemein ignoriert werden sollen, wahrscheinlich mit Blick auf Links wie [[Green (SGU)]], innerhalb derer sichergestellt werden soll, dass die Kürzelvorlage keinen Blödsinn macht bzw. es allgemein keinen Grund gibt, die Vorlage arbeiten zu lassen. Nur scheint der Code das nicht zu tun, es wird zwar nach Links gesplittet aber die Links werden trotzdem mit verarbeitet wie Ausdrücke in runden Klammern auch... oder verlässt sich der Code darauf, dass der Link hoffentlich unverändert durch die Kürzelvorlage zurückkommt wenn man ihn komplett übergibt und das dann am Ende erkannt werden kann? Stattdessen scheint mir sinnvoller, ähnlich wie beim "ausklammern" der geklammerten Teile beim Verarbeiten der $para-Elemente Links durch Suchen nach den eckigen Klammern rauszufiltern und einfach ohne weitere Verarbeitung unverändert zu übergeben (also <code>$output .= $para;</code>) wie bei leeren, fertig verarbeiteten Resultaten.

::Wie Du schon sagst behebt das alles aber nur einen Teil des Problems. Gut, die Infobox dürfte zerhackt worden sein, weil das öffnende span-tag zwischen den beiden Links aus der Ep-Vorlage komplett gelöscht bzw. ersetzt wurde und nur das schließende übrig blieb, wodurch die ganze Elemente-Struktur da den Bach runterging. Wenn der Text komplett ersetzt oder gelöscht wird bleibt auch kein halbes HTML-Element übrig und das Problem stellt sich nicht mehr. Trotzdem sollte der Nicht-Kürzel-Text nicht ersetzt oder gelöscht sondern unverändert erhalten bleiben. Und der k-Parameter hat im Ergebnis auch nichts zu suchen. So ist die Kürzelvorlage auch gebaut und Deine direkte Einbindung ohne recursiv-Umweg oben demonstriert auch, dass die Vorlage selbst das korrekt löst. Das müsste dann eher ein zweites (drittes) Problem in der recursive-Funktion des SGPack sein. Ich sehe mit meiner geringen PHP-Erfahrung allerdings nicht wirklich, wo genau. --{{Benutzer:Col. o'neill/sig}} 19:51, 22. Nov. 2022 (CET)

::: Das Problem ist tatsächlich eher, dass darauf vertraut wird, dass die Vorlage es unverändert durchschleift. Ich habe Links mal explizit vom Weiterreichen ausgeschlossen, das sorgt dann aber dafür, dass <code><nowiki>{{#recursiv:--|text [[Bild:Smile.gif]] text|}}</nowiki></code> als eine Linie, das Bild und eine Linie interpretiert wird und bringt noch einige andere Probleme mit sich, wie etwa dass <code><nowiki>text [[Link]] text</nowiki></code> aufgespalten wird in drei Teile und jeder der Teile von recursive gehandhabt wird. Die Problematik, dass die Infobox bricht kommt daher, dass die Ep-Vorlage puren HTML Code zurückgibt, der dann von der recursive Funktion aufgelöst wird. Der Input ist daher nicht <code><nowiki>{{Ep|SGA|2x02}}</nowiki></code> oder legitimer Wikitext, sondern pures HTML. --{{Benutzer:Ghost/Signatur}}  15:34, 23. Nov. 2022 (CET)

::::Danke fürs Testen! Stimmt, mein Vorschlag von oben ist dann keine vollständige Lösung, wenngleich die in der Beschreibung erwähnte Funktion, Links zu ignorieren mit Blick auf Kürzelvorlagen dann tatsächlich erfüllt wäre. Die Dreiteilung von <code><nowiki>text [[Link]] text</nowiki></code> ist insofern auch vom jetzigen Stand aus gewolltes Verhalten, im Kontext von Kürzeln soll ja dann gerade der Link ignoriert bzw. durchgeschleift werden und der nicht geklammerte Rest wird der Vorlage überlassen. Trotzdem wäre es mit Blick auf Nicht-Kürzelvorlagen wohl doch sinnvoller, die Link-Sonderbehandlung zu lösen, ohne explizit an den Linkgrenzen zu splitten. Dann müsste allerdings komplexer gesucht werden, also wirklich explizit nach evtl. noch offenen eckigen Klammern um die runden Klammern herum - und falls es da welche gibt können eigentlich alle drei aktuellen Fragmente (das direkt davor, das aktuelle und das direkt danach) ignoriert bzw. durchgeschleift werden, da in z.B. <code><nowiki>abc [[def (ghi)]] jkl (mno)</nowiki></code> das einzige relevante der anhand der runden Klammern entstehenden vier Fragmente das letzte ist.

::::Und das alles ändert weiterhin nichts am Hauptproblem, dass einzelne Fragmente durch die recursive-Funktion gelöscht / durch den separaten Parameter ersetzt werden, obwohl die Vorlage selbst sie korrekterweise einfach unverändert zurückgibt und die weiteren Parameter nichts im Ergebnis verloren haben und von der Vorlage auch eigentlich gar nicht mehr zurückgegeben werden. Die Ep-Vorlage gibt wie oben beschrieben u.a. ein span-tag zum Verhindern eines Zeilenumbruchs zurück, zusätzlich zu den Links in normaler Wikisyntax. Das ist an und für sich kein Problem, die Infobox ist wie gesagt nur deshalb zerhackt, weil durch die erwähnte falsche Löschung / Ersetzung des Fragments zwischen den beiden Links in Wikisyntax das öffnende span-tag plötzlich fehlt und nur das schließende danach erhalten bleibt. Auch ohne Ep-Vorlage lässt sich der resultierende Kollaps der Infobox simulieren, indem man einfach an der Stelle nur ein {{Code|</span>}} einfügt. --{{Benutzer:Col. o'neill/sig}} 17:15, 23. Nov. 2022 (CET)