Benutzer Diskussion:Rene
Verweise & Infos
- Aktueller Wiki-Status: offline
- Abgeschlossene Diskussionen im Archiv
- Infoseite zu Server & MediaWiki-Software, Update Wiki Hinweise
Inhaltsverzeichnis
- 1 Wichtiger Hinweis zur Zukunft
- 2 Update 1.24
- 2.1 Javascript Warnung
- 2.2 Webstatistik / Server
- 2.3 Neuer Benutzer erhält Benutzerseite (erledigt)
- 2.4 SGHTML (erledigt)
- 2.5 Popups - Probleme mit Ref
- 2.6 Admins können nicht mehr alle Seiten bearbeiten (erledigt)
- 2.7 CodeEditor Übersetzung (erledigt)
- 2.8 Sichten
- 2.9 Bearbeitungszähler (erledigt)
- 2.10 Infobox Abkürzungen (erledigt)
- 2.11 Signaturnachtrag-Gadget (erledigt)
- 2.12 Onlyifuploading.js
- 2.13 Sonderzeichen, die zweite (erledigt)
- 3 SGPack für andere Wikis
- 4 Slideshow - Textabstand
- 5 Automatische Erstellung der Diskussionsseite verhindern/ändern
- 6 Nochmal...
- 7 ImageMagick
- 8 Alles Gute...
- 9 PlayMP3
- 10 Bug in SGPack
- 11 Noch ein Bug im SGPack
Wichtiger Hinweis zur Zukunft
Diskussion verschoben auf StargateWiki Diskussion:Jedipedia-Kooperation
Update 1.24
Javascript Warnung
- Beim Anmelden bekomme ich eine Java-Script-Warnung, obwohl es aktiviert ist. Die Meldung kommt nur auf der Spezial:Anmelden, sonst nirgendwo. --Ghost Profil - Admin - Diskussion - Beiträge - 20px 11:11, 21. Dez. 2014 (CET)
- Kann ich bestätigen. Die JS-Warnung kommt aber auch in den Einstellungen. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 12:52, 21. Dez. 2014 (CET)
- Tja ich habe keine Idee wie ich diesen Fehler beheben kann. Aus irgend einem Grund scheint MediaWiki die Klasse noscript nicht richtig zu setzen. Warum nur auf diesen Seiten? --Rene Bürokrat - Rückmeldung 20:46, 22. Dez. 2014 (CET)
- In der mobilen Ansicht kommt die Warnung nicht. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:42, 25. Dez. 2014 (CET)
- Bei dem Artikel zur Folge Endlosigkeit kommt der Fehler ebenfalls [1] --92.225.53.253, 02:01, 29. Dez. 2014 (CET) (Signatur nachgetragen von Col. o'neill)
- Bei mir nicht. Hast Du JavaScript vielleicht tatsächlich deaktiviert? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 10:35, 29. Dez. 2014 (CET)
- Fehler ist dort inzwischen nicht mehr vorhanden....Habe es nachts allerdings extra mit mehreren Browsern getestet, verschiedene Artikel aufgerufen und Javascript an bzw. ausgeschaltet um einen Fehler meinerseits auszuschließen --78.52.151.134, 20:28, 29. Dez. 2014 (CET)
- Anonyme Benutzer bekommen die Seite aus dem Server-Cache geliefert. Möglicherweise hängt es damit zusammen. Wenn die Seite falsch im Cache war verschwindet der Fehler erst wenn die Seite neu im Cache abgelegt wird. Das passiert spätestens nach einem Tag. --Rene Bürokrat - Rückmeldung 21:15, 29. Dez. 2014 (CET)
- Der Hinweis erscheint außerdem noch in Spezial:E-Mail-Adresse ändern und Spezial:Benutzerkonto anlegen (letztere eh nur für Admins). Es sind also nur manche Spezialseiten mit Benutzerkontenbezug. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:08, 5. Jan. 2015 (CET)
- Anonyme Benutzer bekommen die Seite aus dem Server-Cache geliefert. Möglicherweise hängt es damit zusammen. Wenn die Seite falsch im Cache war verschwindet der Fehler erst wenn die Seite neu im Cache abgelegt wird. Das passiert spätestens nach einem Tag. --Rene Bürokrat - Rückmeldung 21:15, 29. Dez. 2014 (CET)
- Fehler ist dort inzwischen nicht mehr vorhanden....Habe es nachts allerdings extra mit mehreren Browsern getestet, verschiedene Artikel aufgerufen und Javascript an bzw. ausgeschaltet um einen Fehler meinerseits auszuschließen --78.52.151.134, 20:28, 29. Dez. 2014 (CET)
- Bei mir nicht. Hast Du JavaScript vielleicht tatsächlich deaktiviert? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 10:35, 29. Dez. 2014 (CET)
- Bei dem Artikel zur Folge Endlosigkeit kommt der Fehler ebenfalls [1] --92.225.53.253, 02:01, 29. Dez. 2014 (CET) (Signatur nachgetragen von Col. o'neill)
- In der mobilen Ansicht kommt die Warnung nicht. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:42, 25. Dez. 2014 (CET)
- Tja ich habe keine Idee wie ich diesen Fehler beheben kann. Aus irgend einem Grund scheint MediaWiki die Klasse noscript nicht richtig zu setzen. Warum nur auf diesen Seiten? --Rene Bürokrat - Rückmeldung 20:46, 22. Dez. 2014 (CET)
Also ich habe mir mal angesehen was beim laden der Seiten passiert. Das Problem ist, soweit ich das erkennen kann, das die Seite Commons.css nicht geladen wird. Dadurch ist natürlich auch die Definition .noscript { display: none; } nicht vorhanden und die Box wird angezeigt. Warum das so ist konnte ich aber noch nicht ermitteln. --Rene Bürokrat - Rückmeldung 22:45, 8. Jan. 2015 (CET)
- Auf MediaWiki.org ist es das gleiche. Für diese Seiten wird eine spezielle CSS Seite geladen. Möglicherweise damit man sich diese wichtigen Seiten nicht kaputt machen kann. Das bedeutet es ist keine Fehler sondern ein Feature . Stellt sich die Frage was tun. --Rene Bürokrat - Rückmeldung 23:38, 8. Jan. 2015 (CET)
- Hmm stimmt, offenbar hat man das aus Sicherheitsgründen mit MW 1.23 implementiert - besonders gut anzukommen scheint es aber beiweitem nicht überall und man findet einige Diskussionen dazu. Das hier könnte aber die Lösung sein. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:32, 9. Jan. 2015 (CET)
- Nachtrag: Da die DefaultSettings.php dafür auch bearbeitet werden muss, ist das natürlich keine optimale Lösung und man muss das im Grunde bei jedem MW-Upgrade wiederholen (sollte auf die Upgrade-Liste). Besser aber als den Fehler ständig angezeigt zu bekommen. Gerade Neulinge werden dadurch sicherlich etwas verunsichert. Bitte probier das daher mal aus. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:06, 30. Jan. 2015 (CET)
Webstatistik / Server
- Die Webstatistik sollte mal aktualisiert werden, sie ist schließlich auf der Hauptseite verlinkt und jetzt dann fast 4 Jahre alt... --Ghost Profil - Admin - Diskussion - Beiträge - 20px 10:55, 24. Dez. 2014 (CET)
- Richtig aber momentan ungünstig. Da der Server neu aufgesetzt wurde sind die Daten nicht sehr aussagekräftig. --Rene Bürokrat - Rückmeldung 23:29, 8. Jan. 2015 (CET)
- Aktualisierung von StargateWiki:Server nicht vergessen.--Ghost Profil - Admin - Diskussion - Beiträge - 20px 11:34, 24. Dez. 2014 (CET)
- Da müsste wirklich mal aufgeräumt werden.--Rene Bürokrat - Rückmeldung 23:29, 8. Jan. 2015 (CET)
- Ich finde, den veralteten Kram kann man einfach entfernen. Zu den Backups hat man jetzt auf der Seite drei Stellen mit unterschiedlichen Informationen - das irritiert nur.^^ --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:38, 9. Jan. 2015 (CET)
Neuer Benutzer erhält Benutzerseite (erledigt)
Nach erfolgreicher Benutzerkontenbestätigung wird für den bestätigten Benutzer automatisch die Benutzerseite angelegt - sinnvoll? --D5B Offline - Diskussion 14:07, 25. Dez. 2014 (CET)
- Eigentlich absolut nicht. Wo steht das? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:42, 25. Dez. 2014 (CET)
- Hier. (Anmerkung: Philipp hat mir auf dem Testserver Büro-Rechte gegeben.) --D5B Offline - Diskussion 16:26, 25. Dez. 2014 (CET)
- Da die Seiten leer erstelt werden ist das nicht ganz so unsinnig wie ich erst dachte. Aber: So wird NewArticle umgangen und die Möglichkeit, sich das Template für Benutzerseiten einzufügen, damit auch. Wenn man das also ändern kann: Gut wär's schon. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:04, 29. Dez. 2014 (CET)
- Die Seite wird von der Erweiterung ConfirmAccount erstellt. Ich habe den Code geändert, Benutzer:Rene/Upgrade_Wiki#ConfirmAccount. Ich denke damit sollte das Problem behoben sein.--Rene Bürokrat - Rückmeldung 23:26, 8. Jan. 2015 (CET)
- Da die Seiten leer erstelt werden ist das nicht ganz so unsinnig wie ich erst dachte. Aber: So wird NewArticle umgangen und die Möglichkeit, sich das Template für Benutzerseiten einzufügen, damit auch. Wenn man das also ändern kann: Gut wär's schon. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:04, 29. Dez. 2014 (CET)
- Hier. (Anmerkung: Philipp hat mir auf dem Testserver Büro-Rechte gegeben.) --D5B Offline - Diskussion 16:26, 25. Dez. 2014 (CET)
SGHTML (erledigt)
Nochmal zum SGHtml (hier, damit es nicht übersehen wird): Du hast nach der Anpassung geschrieben: Kleiner Fehler auf der ersten Seiten (es wird ein Pfeil erzeugt obwohl die Bedingungen nicht stimmen), kann ich mir momentan nicht erklären. 22:56, 21. Dez. 2014 (CET) Ich habe das nur auf der Hauptseite festgestellt und dort lag es daran, dass die Themen-Überschrift nicht wie die anderen h2-Überschriften manuell eine id bekommen hat. Das habe ich eben behoben (sprich auch dieser h2 eine id verpasst) und der Pfeil ist weg. Das könnte auch bei den anderen Fällen helfen bzw. Dir beim fixen. :) --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:40, 31. Dez. 2014 (CET)
- Danke, mir war es nur auf der Hauptseite aufgefallen. Irgendwie konnte ich den Fehler nicht finden, weil eigentlich der Code der ersetzt wurde nicht zum Muster gepasst hat. Möglicherweise hat mir da irgend ein Cache in die Suppe gespuckt. --Rene Bürokrat - Rückmeldung 16:47, 4. Jan. 2015 (CET)
Popups - Probleme mit Ref
Die Popups-Extension scheint sich nicht mit Cites zu vertragen. Wenn in den ersten beiden Sätzen der verlinkten Seite (die ja zur Vorschau benutzt werden) eine EpRef-Vorlage vorkommt, wird statt der normalen Vorschau der entsprechende references-Eintrag angezeigt - und bei Episoden dazu noch mit falscher Darstellung. Beispiel: Stargate Atlantis --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:42, 31. Dez. 2014 (CET)
- Das ist in der Tat merkwürdig. Es könnte auch an Extension:TextExtracts liegen. Ich habe mal kurz etwas ausprobiert aber das hat nicht geholfen. Elemente der Klasse noexcerpt sollen eigentlich ausgelassen werden. Im Test Wiki habe ich damit nur erreicht das der Artikel komplett aus der Vorschau entfernt wurde. Nicht gerade hilfreich. --Rene Bürokrat - Rückmeldung 18:01, 1. Jan. 2015 (CET)
- Besteht evtl. ein Zusammenhang mit der Ignorierung/Falschsetzung der Klasse noscript an manchen Stellen? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 12:56, 2. Jan. 2015 (CET)
- Nach meinen Ermittlungen zu dem Problem, Nein. Ich muss mich mal mit den Einstellungen der Erweiterungen beschäftigen. --Rene Bürokrat - Rückmeldung 23:44, 8. Jan. 2015 (CET)
- Bei SGA ist der Anfangssatz zu lang, wodurch einzig und allein der reference-Eintrag angezeigt wird. Hier noch ein Beispiel mit kürzerem Satz und damit Text und reference-Eintrag: Shen Xiaoyi --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:22, 10. Jan. 2015 (CET)
- Nachtrag: Bei der Vector-Vorschau werden die entsprechenden reference-Einträge auch schon direkt unten angezeigt, wenn man nur einen Abschnitt (also ohne ShowRef) bearbeitet bzw. dessen Vorschau anzeigen lässt. In der "vollständigen" Vorschau ist das nicht so, aber insofern kann es auch (teils) an der etwas neuen Funktionsweise der Cite-Extension liegen. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 21:04, 12. Jan. 2015 (CET)
- Nachtrag 2: Offenbar verhält sich die neue Cite-Version auch in den Artikeln selbst etwas anders als früher: Ist kein references-Tag gegeben, werden die Einträge einfach ganz unten auf der Seite angezeigt (vgl. hier). Damit dürfte das zusammenhängen. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:01, 14. Jan. 2015 (CET)
- Nach meinen Ermittlungen zu dem Problem, Nein. Ich muss mich mal mit den Einstellungen der Erweiterungen beschäftigen. --Rene Bürokrat - Rückmeldung 23:44, 8. Jan. 2015 (CET)
- Besteht evtl. ein Zusammenhang mit der Ignorierung/Falschsetzung der Klasse noscript an manchen Stellen? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 12:56, 2. Jan. 2015 (CET)
Admins können nicht mehr alle Seiten bearbeiten (erledigt)
Admins können die Benutzerseiten anderer User nicht mehr bearbeiten. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 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. --Rene Bürokrat - Rückmeldung 22:59, 1. 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... --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 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? --Rene Bürokrat - Rückmeldung 17:42, 8. Jan. 2015 (CET)
- Einfach im Editor Strg.+F drücken. Und welche drei Meldungen sind denn übersetzt? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 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 ACE Editor. Dafür gibt es keine deutschen Texte. --Rene Bürokrat - 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...^^ --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:52, 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 ACE Editor. Dafür gibt es keine deutschen Texte. --Rene Bürokrat - Rückmeldung 19:37, 8. Jan. 2015 (CET)
- Einfach im Editor Strg.+F drücken. Und welche drei Meldungen sind denn übersetzt? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:45, 8. Jan. 2015 (CET)
Sichten
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: SG1 1x02 Der Feind in seinem Körper --SimeonBenutzerseiteDiskussion 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. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 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. --Rene Bürokrat - Rückmeldung 19:41, 8. Jan. 2015 (CET)
- Es liegt an der Vorlage:! - da
{{!}}
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? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:52, 8. Jan. 2015 (CET)
- Es liegt an der Vorlage:! - da
- 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. --Rene Bürokrat - Rückmeldung 19:41, 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? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 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. --Rene Bürokrat - Rückmeldung 23:33, 20. Jan. 2015 (CET)
- Es sollte eigentlich reichen, in den LocalSettings.php
$wgUseRCPatrol = false;
hinzuzufügen. Offenbar gibt es momentan dann noch einen 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 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...^^ --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:41, 30. Jan. 2015 (CET)
- Es sollte eigentlich reichen, in den LocalSettings.php
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. --Rene Bürokrat - Rückmeldung 20:43, 27. Jan. 2015 (CET)
- Ahhh, das erklärt auch direkt, wieso in letzter Zeit die Linklisten eine Unendlichkeit gebraucht haben, sich zu updaten. Hauptsache es ist jetzt behoben - Danke! --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 20:59, 27. Jan. 2015 (CET)
Bearbeitungszähler (erledigt)
CFs Bearbeitungszähler (Vorlage:Bearbeitungen) funktioniert nicht mehr. Wenn ein nicht existierender Username angegeben wird, wird korrekt 0 angezeigt, ansonsten lädt sich die Funktion zu Tode. In den letzten MW-Versionen wurde das ein oder andere an den ListEvents geändert, daher würde ich vermuten, dass die Vorlage an sich noch funktioniert, nur dass das Auslesen angepasst werden muss. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:40, 6. 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. --Rene Bürokrat - Rückmeldung 21:41, 6. Jan. 2015 (CET)
- Dass das JS dort angepasst werden muss ist klar, an der Vorlage selbst liegt es kaum (dort steht eh kaum etwas drin). Nur hätte ich es nicht hierhin geschrieben, wenn es Aussicht darauf gäbe, dass CF sich das tatsächlich ansieht. Der ist ja leider seit 2012 inaktiv und kann dementsprechend nicht helfen. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:55, 7. Jan. 2015 (CET)
- Da habe ich wohl nicht richtig gelesen. Ich dachte er war Dezember 2014 noch aktiv aber ja es war 2012. Fremder Javscript Code ist nicht so mein Ding aber ich schau mal ob ich was herausfinde. --Rene Bürokrat - Rückmeldung 00:49, 8. Jan. 2015 (CET)
- Ich habe mal versucht das Teil zu verstehen. Ich gebe auf! Das ist ohne Anleitung nicht zu verstehen. Und wenn ich mir ansehen auf wie wenigen Seiten das Teil eingesetzt wird würde ich eigentlich sagen: "Weg damit". Ich hab es zwar etwas zum laufen gebracht aber die Laufzeit ist grausam und die Lösung (einfach die Zeit auf 0 gesetzt) ist auch nicht wirklich toll. --Rene Bürokrat - Rückmeldung 20:34, 8. Jan. 2015 (CET)
- Da habe ich wohl nicht richtig gelesen. Ich dachte er war Dezember 2014 noch aktiv aber ja es war 2012. Fremder Javscript Code ist nicht so mein Ding aber ich schau mal ob ich was herausfinde. --Rene Bürokrat - Rückmeldung 00:49, 8. Jan. 2015 (CET)
- Dass das JS dort angepasst werden muss ist klar, an der Vorlage selbst liegt es kaum (dort steht eh kaum etwas drin). Nur hätte ich es nicht hierhin geschrieben, wenn es Aussicht darauf gäbe, dass CF sich das tatsächlich ansieht. Der ist ja leider seit 2012 inaktiv und kann dementsprechend nicht helfen. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:55, 7. Jan. 2015 (CET)
Puh, es hat die ein oder andere Stunde gedauert, aber ich glaube mittlerweile steige ich durch das Skript durch. Jedenfalls habe ich schließlich gefunden, woran der Fehler lag. Seit MW 1.23 gibt es den bisher abgefragten lestart/ucstart-Wert nicht mehr, das war denen nicht eindeutig genug (nach dem Motto es könnten ja viele Edits in einer Sekunde stattfinden) - siehe hier. Seitdem gibt es stattdessen lecontinue/uccontinue, wo nun zusätzlich eine revid angegeben wird. Anstatt z.B. „2014-05-01T10:14:03Z“ kriegt man jetzt also „20140501101403|309943“. Das war ja auch der Teil, den Du geändert hattest, nur wenn immer eine 0 da steht, ist das ja nicht so sinnvoll. Leider ist das in den MW-ReleaseNotes nicht gerade mit griffigen Stichwörtern gelistet gewesen, weshalb ich zunächst nicht darauf gestoßen bin. Jetzt passt es aber, der Timestamp aus dem continue-Wert wird übergeben (Zusammen mit der revid funktioniert das nicht - Ich frage mich dabei halt: Wozu die beiden Teile im continue-Wert, wenn man als start-Wert eh nur den ersten übergeben kann?) und die Vorlage läuft wieder. Damit wäre auch das hier erledigt. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 01:14, 1. Feb. 2015 (CET)
Nachtrag: Ich habe den Zähler außerdem mal gerade ein kleines bisschen entrümpelt. Die Anfragen bzw. deren Ergebnisse sind jetzt nur noch etwa halb so groß wie vorher (um die 15 statt um die 30KB bei voller Ausschöpfung des Limits) und in der Summe macht das den Prozess ein kleines bisschen schneller. Außerdem habe ich eine recht überflüssige Prüfung in queryUrl entfernt, die nur wahr ergeben kann. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:17, 1. Feb. 2015 (CET)
Infobox Abkürzungen (erledigt)
Bei Infoboxen wird wenn z.B. bei "Geschlecht" m eingetragen ist nicht wie vorher Männlich angezeigt sondern weiterhin das m, genauso bei Ländercodes, wie man hier bei dem Bild sehen kann. --Felix (Diskussion) 20:07, 9. Jan. 2015 (CET)
- Fügt man Klammern hinzu passt die Anzeige wieder. Hat wohl mit der Anpassung der recursiv-Funktion im SGPack zu tun. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 20:14, 9. Jan. 2015 (CET)
- dann werd ich mich in den nächsten tagen durch die Darstellerartikel gehen und es einsetzten bzw. allgemein die Darstellerartikel ein wenig überarbeiten--Felix (Diskussion) 20:28, 9. Jan. 2015 (CET)
- Überall Klammern einzusetzen ist bestenfalls eine Notlösung, aber wohl kaum notwendig. Es ist ein Bug, der sich wahrscheinlich recht schnell beheben lässt. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 20:34, 9. Jan. 2015 (CET)
- Ich schau mir das mal an. --Rene Bürokrat - Rückmeldung 23:09, 9. Jan. 2015 (CET)
- Nachtrag: Ich habe es befürchtet das ist die folge meiner "Reparatur" der recursiv-Funktion. Bitte erst einmal nicht im Wiki ändern, ich schau mal wie ich das wieder richtig hin bekomme. --Rene Bürokrat - Rückmeldung 23:19, 9. Jan. 2015 (CET)
- Dann werd ich warten bis du des ok gibst.--Felix (Diskussion) 23:33, 9. Jan. 2015 (CET)
- Ist behoben zB Bauer --Rene Bürokrat - Rückmeldung 00:38, 10. Jan. 2015 (CET)
- Super, danke! --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 10:56, 10. Jan. 2015 (CET)
- Ist behoben zB Bauer --Rene Bürokrat - Rückmeldung 00:38, 10. Jan. 2015 (CET)
- Dann werd ich warten bis du des ok gibst.--Felix (Diskussion) 23:33, 9. Jan. 2015 (CET)
- Überall Klammern einzusetzen ist bestenfalls eine Notlösung, aber wohl kaum notwendig. Es ist ein Bug, der sich wahrscheinlich recht schnell beheben lässt. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 20:34, 9. Jan. 2015 (CET)
- dann werd ich mich in den nächsten tagen durch die Darstellerartikel gehen und es einsetzten bzw. allgemein die Darstellerartikel ein wenig überarbeiten--Felix (Diskussion) 20:28, 9. Jan. 2015 (CET)
Hmmm irgendwie ist das mit den Kürzeln eine never ending story...
Ich wollte gerade die kl-Funktion entfernen, als mir aufgefallen ist, dass die Klammern sich jetzt wieder genau wie vor dem SGPack-Update verhalten: Sie werden nur angezeigt, wenn ein Nicht-Link-Wort eingegeben wird, das nicht definiert ist. Mit einem Link zu etwas nicht definiertem fallen die Klammern wieder weg und bei normalen Kürzeln werden sie natürlich auch nicht angezeigt. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:51, 10. Jan. 2015 (CET)
- Das ist etwas nervig. Ich hatte es auf dem TestWiki getestet - ohne Probleme [2]. Hier im Wiki funktioniert es nicht. Ich muss wohl erst mal prüfen wie recursiv "nackt" funktioniert, also ohne die Vorlage Kürzel. --Rene Bürokrat - Rückmeldung 18:29, 11. Jan. 2015 (CET)
- Also ich habe eine saubere Vorlage angelegt, Benutzer:Rene/VTest und die Anweisung recursiv damit getestet Benutzer:Rene/Test. Damit funktioniert alles wie es soll. Also ist möglicherweise die Vorlage Kürzel nicht in Ordnung? --Rene Bürokrat - Rückmeldung 20:28, 11. Jan. 2015 (CET)
- Es scheint tatsächlich an einigen der, aber eben nicht allen, Kürzelvorlagen zu liegen - hier z.B. funktioniert das perfekt wie es soll. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 21:02, 12. Jan. 2015 (CET)
- Also ich habe eine saubere Vorlage angelegt, Benutzer:Rene/VTest und die Anweisung recursiv damit getestet Benutzer:Rene/Test. Damit funktioniert alles wie es soll. Also ist möglicherweise die Vorlage Kürzel nicht in Ordnung? --Rene Bürokrat - Rückmeldung 20:28, 11. Jan. 2015 (CET)
Signaturnachtrag-Gadget (erledigt)
Das funktioniert nicht mehr, wie mir gerade auffällt. Die Parameter bleiben einfach leer. Kann das mit einer Anpassung der ddinsert-Erweiterung zu tun haben oder ist auch hier einfach das Script anzupassen? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:46, 19. Jan. 2015 (CET)
- Ich tippe auf das Script aber ohne das ich mir das angesehen habe. --Rene Bürokrat - Rückmeldung 23:31, 20. Jan. 2015 (CET)
- Es war in der Tat das Script. Offenbar kriegen die select-Elemente in der neuen Version des SGPacks einen Zufallswert ins name-Attribut integriert. Zuvor war der Name einfach „Auswahl“, jetzt ist es „DDSelect-“ und eine mehrstellige Zufallszahl hintendran. Im Skript war dementsprechend der jQuery-Selektor falsch gesetzt, ich habe ihn jetzt einfach auf alles gestellt, was mit „DDSelect-“ anfängt. Das Gadget funktioniert nun auch wieder. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:17, 30. Jan. 2015 (CET)
- Du hast recht das habe ich geändert weil es Probleme mit einem der Skripte gab. Hat mir beim Testen immer die Ausgabe umgebaut weil es „Auswahl“ für ein eigenes Element benutzt hat. Weiß leider nicht mehr welches Skript es war. Eigentlich dachte ich das ich es irgendwo erwähnt hätte aber ich finde es nicht. Also wohl doch vergessen. --Rene Bürokrat - Rückmeldung 22:40, 30. Jan. 2015 (CET)
- Übrigens musste ich das Skript gerade nochmal anpassen, weil der value der option-Elemente mittlerweile nur noch ein kompletter Zeichensalat ist. Zuvor war mittendrin wenigstens noch der eigentliche Name zu finden, jetzt nicht mehr. Stattdessen ist es die codierte Zusammensetzung der einzufügenden Vorlage und dem sample-Wert (z.B. für die Altersberechnung steht in den Edittools:
<ddvalue show="Altersberechnung" sample="Jahr|Monatsnummer (optional)|Tag (optional)">{{Alter|+}}</ddvalue>
und der value des option-Elements ist nun%7b%7b%41%6c%74%65%72%7c%2b%7d%7d%2b%4a%61%68%72%7c%4d%6f%6e%61%74%73%6e%75%6d%6d%65%72%20%28%6f%70%74%69%6f%6e%61%6c%29%7c%54%61%67%20%28%6f%70%74%69%6f%6e%61%6c%29
(also decodiert:{{Alter|+}}+Jahr|Monatsnummer (optional)|Tag (optional)
). Ich habe das Gadget jetzt das innerHTML prüfen lassen. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 22:18, 8. Feb. 2015 (CET)
- Übrigens musste ich das Skript gerade nochmal anpassen, weil der value der option-Elemente mittlerweile nur noch ein kompletter Zeichensalat ist. Zuvor war mittendrin wenigstens noch der eigentliche Name zu finden, jetzt nicht mehr. Stattdessen ist es die codierte Zusammensetzung der einzufügenden Vorlage und dem sample-Wert (z.B. für die Altersberechnung steht in den Edittools:
- Du hast recht das habe ich geändert weil es Probleme mit einem der Skripte gab. Hat mir beim Testen immer die Ausgabe umgebaut weil es „Auswahl“ für ein eigenes Element benutzt hat. Weiß leider nicht mehr welches Skript es war. Eigentlich dachte ich das ich es irgendwo erwähnt hätte aber ich finde es nicht. Also wohl doch vergessen. --Rene Bürokrat - Rückmeldung 22:40, 30. Jan. 2015 (CET)
- Es war in der Tat das Script. Offenbar kriegen die select-Elemente in der neuen Version des SGPacks einen Zufallswert ins name-Attribut integriert. Zuvor war der Name einfach „Auswahl“, jetzt ist es „DDSelect-“ und eine mehrstellige Zufallszahl hintendran. Im Skript war dementsprechend der jQuery-Selektor falsch gesetzt, ich habe ihn jetzt einfach auf alles gestellt, was mit „DDSelect-“ anfängt. Das Gadget funktioniert nun auch wieder. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:17, 30. Jan. 2015 (CET)
Onlyifuploading.js
Ich sehe gerade, die Onlyifuploading.js gibt einen Fehler aus: Offenbar gibt es die Funktion licenseSelectorCheck() nicht mehr oder sie ist jetzt woanders. Zumindest gibt es einen ReferenceError und das Script arbeitet nicht / wird nicht angezeigt. Ich habe mal die MW-Releasenotes seit 1.18 durchsucht, aber nichts dazu gefunden. Hier wird die Funktion aber - wenn auch schon seit Jahren - als veraltet gelistet. Sie dürfte demzufolge noch nicht vollends entfernt sein. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 20:22, 21. Jan. 2015 (CET)
- Neue Version, die man natürlich noch anpassen muss: MediaWiki:Onlyifuploading.js --Rene Bürokrat - Rückmeldung 14:56, 22. Jan. 2015 (CET)
- Ah, okay. Allerdings haben die dort nichts mit Lizenzen drin. Ich habe die licenseSelectorCheck() mal testweise auskommentiert, die richtige Lizenz wir gewählt, aber es gibt keine Preview... --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 20:01, 22. Jan. 2015 (CET)
Sonderzeichen, die zweite (erledigt)
Das hier ist aus irgendeinem Grund wieder fehlerhaft wie vorher: Die Edittools fügen z.B. {{Begriffsklärung}}
ein. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:32, 7. Mär. 2015 (CET)
- Ich bin überrascht. Der Fehler war definitiv behoben, ich muss prüfen was da passiert ist. --Rene Bürokrat - Rückmeldung 21:42, 8. Mär. 2015 (CET)
- Sollte mittlerweile behoben sein, siehe hier. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 21:35, 25. Jun. 2020 (CEST)
SGPack für andere Wikis
Hab gerade den SGPack in zwei anderen Wikis neu installieren lassen und bisher festgestellt:
- MediaWiki:Sghtml-keywords enthält standardmäßig Stargate Wiki-Keywords (Stargate,Stargate SG-1,Stargate Atlantis,Stargate Universe,Stargate Lexikon). Gibts ne Möglichkeit, die Seite standardmäßig iwie leer zu machen? --D5B Offline - Diskussion 14:28, 4. Jan. 2015 (CET)
- Dazu müsste man in der Datei SGPack.i18n.php die Werte aus dem Array löschen. Dort stehen übrigens sowieso nicht die Werte die wir benutzen. Ich kann das also beim nächsten Update mit einem leeren Eintrag ausliefern. --Rene Bürokrat - Rückmeldung 15:38, 4. Jan. 2015 (CET)
- Okay, danke! Wie erfahren Externe von Updates? --D5B Offline - Diskussion 16:40, 4. Jan. 2015 (CET)
- Dazu müsste man in der Datei SGPack.i18n.php die Werte aus dem Array löschen. Dort stehen übrigens sowieso nicht die Werte die wir benutzen. Ich kann das also beim nächsten Update mit einem leeren Eintrag ausliefern. --Rene Bürokrat - Rückmeldung 15:38, 4. Jan. 2015 (CET)
- Nur ne Kleinigkeit: Benutzer:Rene/SGPack#SGHtml - hab gerade die Lizenzen der beiden Bilder Datei:Bearbeiten.png und Datei:Blue up.gif gesehen. Diese sind ja im SGPack enthalten, aber stehen unter der GNU-Lizenz für freie Dokumentation. Folglich zwingst Du (als Autor) den Nutzer des SGPacks damit dazu, dich als Autor und die Quelle zu nennen. Bloß wo soll er das machen? Die Bilder liegen ja bloß auf dem Server, ne Wikiseite wie bei uns haben diese Dateien ja erstmal nicht automatisch. Ich schlage vor, die Lizenz zu ändern. --D5B Offline - Diskussion 19:35, 4. Jan. 2015 (CET)
- Okay danke für den Hinweis. Ach, bitte ändere nach Möglichkeit keine Einstellungen am Test Wiki. Habe gerade 30 Minuten gesucht warum plötzlich Seiten gesperrt sind. Hatte einen Fehler am SGPack vermutet. Ich mache den Warnhinweis größer. --Rene Bürokrat - Rückmeldung 19:58, 4. Jan. 2015 (CET)
- Sorry, mein Fehler. Habs allen Admins und Philipp gemeldet und dich vergessen. Tut mir leid. Aber die Einstellungen von mir machen doch eig schon Sinn, oder? --D5B Offline - Diskussion 20:28, 4. Jan. 2015 (CET)
- Tja irgendwie nicht. Ich konnte als Admin plötzlich keine Vorlagen mehr bearbeiten. Das ist nicht sinnvoll oder? Kann aber kein Fehler vom SGPack gewesen sein weil der immer die Seite freigegeben hat. Davon abgesehen mache ich auch Tests als IP um zu sehen was geht.
- Zur Lizenz. Ich habe jetzt zwei Icons aus einem Public Domain Set benutzt. Die Angaben zur Quelle stehen auf Spezial:Version in der Beschreibung zum Pack. Ich denke damit sind die Bedingungen erfüllt. Icon Set --Rene Bürokrat - Rückmeldung 21:07, 4. Jan. 2015 (CET)
- Ich habe beide alten Bilder mal ersetzt und gelöscht. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:06, 18. Jan. 2015 (CET)
- Sorry, mein Fehler. Habs allen Admins und Philipp gemeldet und dich vergessen. Tut mir leid. Aber die Einstellungen von mir machen doch eig schon Sinn, oder? --D5B Offline - Diskussion 20:28, 4. Jan. 2015 (CET)
- Okay danke für den Hinweis. Ach, bitte ändere nach Möglichkeit keine Einstellungen am Test Wiki. Habe gerade 30 Minuten gesucht warum plötzlich Seiten gesperrt sind. Hatte einen Fehler am SGPack vermutet. Ich mache den Warnhinweis größer. --Rene Bürokrat - Rückmeldung 19:58, 4. Jan. 2015 (CET)
- @Rene: Vielen Dank!! --D5B Offline - Diskussion 16:23, 18. Jan. 2015 (CET)
Slideshow - Textabstand
Ich glaube, das war vor einiger Zeit noch nicht so (ggf. liegt es an Cycle2), aber jetzt ist der Text fix an einer Stelle, unabhängig von der Größe des (neuen) Bildes. Dadurch verschwindet er manchmal hinter höheren Bildern bzw. steht bei kleineren sehr weit darunter. Könntest Du den Textabstand relativ zum unteren Bildrand setzen? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:28, 7. Jan. 2015 (CET)
- Also ich habe nur die JS Bibliothek ausgewechselt. Die Position des Textes war immer ganz unten. War bei sehr unterschiedlichen Bildgrößen schon immer ein Ärgernis. Auf der Demoseite ist dafür ja ein schönes Beispiel. Ein verdecken des Textes kann ich nicht erkennen. Im Code wird die Unterschrift beachtet und etwas Platz gelassen. Hast du eine Seite wo dieser Fehler auftritt? --Rene Bürokrat - Rückmeldung 00:43, 8. Jan. 2015 (CET)
- hier vor meinem Edit gestern war es so. Lustigerweise variiert die Anzeige bei mir gerade, mal ist der Text generell weiter unten (->Fehler tritt nicht auf), mal wie ich ihn gestern gesehen habe (Fehler tritt auf). Hier zur Sicherheit Screenshots von der fehlerhaften Anzeige. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 07:36, 8. Jan. 2015 (CET)
Automatische Erstellung der Diskussionsseite verhindern/ändern
In anderen Wikis, wo ich tätig bin, wird bei der Bestätigung eines Accounts automatisch die Diskussionsseite des Benutzers erstellt mit einem MediaWiki-Standardtext. Ich habe aber in den MediaWiki-Systemnachrichten diesen Text nicht ändern können. Da dies bei UNS hier nicht so ist, meine Frage: Was muss man machen, um dies zu ändern bzw. den Text anzupassen? --D5B Offline - Diskussion 13:00, 10. Jan. 2015 (CET)
- Extension:NewUserMessage - Ist es das? --D5B Offline - Diskussion 19:39, 13. Jan. 2015 (CET)
- Abschnitt übersehen oder weißt Du's nicht? --D5B Offline - Diskussion 16:03, 18. Jan. 2015 (CET)
- Diese Erweiterung ist bei uns ja nicht installiert. Ich weiß es momentan wirklich nicht. Ich tippe aber eher auf Extension:ConfirmAccount. Die benutzen wir und die Erweiterung legt Seiten für den Benutzer an. Das war ja hier ein Problem, weil wir das nicht wollten. --Rene Bürokrat - Rückmeldung 23:25, 20. Jan. 2015 (CET)
Nochmal...
...zu dieser Geschichte: Ich habe via API mal die ID der "unzugänglichen" Seite ausgeben lassen (8087), der Namensraum ist tatsächlich im System der HNR (0). Ich wollte die Seite mit ID statt Titel löschen, aber über das Formular wird es dann doch wieder die falsche Seite (29418). Ich habs auch mal mit direkter Übergabe des EditTokens bzw. DeleteTokens über die URL versucht, aber ich lande dann trotzdem wieder beim Formular. Kennst Du eine Möglichkeit, das über die ID direkt zu machen, ohne dass es dann wieder auf den Seitentitel und damit auf die falsche Seite umgewälzt wird (ggf. direkt in der DB - Extensions machen das ja auch irgendwie direkt darüber...)? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 22:30, 17. Jan. 2015 (CET)
- Ich habe keine Ahnung. Habe ein wenig in der DB gesucht aber so wirklich schlau geworden bin ich nicht. --Rene Bürokrat - Rückmeldung 23:26, 20. Jan. 2015 (CET)
Hilft vielleicht hiervon nochmal was? Das Problem war da ja immerhin schonmal in der DB identifiziert. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 21:18, 11. Jul. 2015 (CEST)
Nachdem ich mich in der letzten Zeit etwas mehr mit der API auseinander gesetzt habe, habe ich beide fehlerhaften Einträge ("Portal:Völker" in den doppelten Weiterleitungen und "Portal:Völker/Menschen" in den kaputten Weiterleitungen) gerade eben entfernt, über die API lässt sich eine Seite auch rein mit der pageId statt dem title löschen. Das waren hier die 8087 für "Portal:Völker" und 5494 für "Portal:Völker/Menschen". Beide Spezialseiten sind jetzt wieder leer. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:32, 24. Aug. 2015 (CEST)
ImageMagick
Hi,
Irgendwie wird der transparente Hintergrund von SVGs bei kleineren Größen nicht mehr übernommen und stattdessen ist weiß zu sehen. Offenbar soll man dafür das Command -background none
nutzen. Könntest Du das bitte fixen? --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 15:45, 15. Feb. 2015 (CET)
- So einfach ist das nicht. Es gibt keine Variable mit der man die Parameter für imagemagick festlegen kann. Das macht die Wiki Software irgendwo. Ich kann nur den Pfad angeben in dem imagemagick liegt. $wgImageMagickConvertCommand --Rene Bürokrat - Rückmeldung 22:21, 15. Feb. 2015 (CET)
- Ja, die Variable hatte ich zuvor in der LocalSettings schon gesehen. Ich hatte gedacht, man kann wie in der normalen Kommandozeile einfach den Befehl dahintersetzen. Wenn das aber nicht geht: Es müsste im includes-Verzeichnis eigentlich eine Image.php geben, die habe ich aber da nicht gefunden. Offenbar ist die irgendwoanders in dem Ordnerlabyrinth...^^ Dort müsste es jedenfalls eine Zeile geben, die mit $cmd = $wgImageMagickConvertCommand anfängt und dahinter sollten die Commands stehen. Oder muss man das speziell für den SVG-Dateityp woanders machen? Man hat via FTP ja leider keine Suchfunktion...
- Übrigens: Oben in #Sichten (16:41, 30. Jan. 2015) und in #Javascript Warnung (16:06, 30. Jan. 2015) stehen noch zwei Dinge aus.
- --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 23:09, 15. Feb. 2015 (CET)
Alles Gute...
...zum Geburtstag! --Philipp [ Bürokrat · Disk · ] 08:54, 23. Apr. 2015 (CEST)
- Von mir ebenso! :) --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 09:01, 23. Apr. 2015 (CEST)
- Alles Gute! rorret D 14:31, 23. Apr. 2015 (CEST)
- Auch von mir herzlichen Glückwunsch! :) --D5B Offline - Diskussion 17:28, 23. Apr. 2015 (CEST)
- Alles Gute! rorret D 14:31, 23. Apr. 2015 (CEST)
Vielen Dank, auch an alle die nur in Gedanken bei mir waren --Rene Bürokrat - Rückmeldung 16:10, 24. Apr. 2015 (CEST)
PlayMP3
Wenn man mehrere Audios mit Komma getrennt einbindet, werden falsche Links (z.B. Datei:Kawoosh.mp3,Kawoosh(en).mp3) erzeugt. Lässt sich durch andere Nutzung der Vorlage umgehen, ist aber natürlich unschön.
Ich erinnere auch nochmal an die drei bei 23:09, 15. Feb. 2015 genannten Dinge.
--Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 02:45, 1. Jun. 2015 (CEST)
Bug in SGPack
Die #recursiv-Funktion hat einen kleinen Bug, der dazu führt, dass Zeichenketten, die ohne Leerzeichen o.ä. unmittelbar nach den ignorierten Links übergeben werden, auch zu Kürzeln verarbeitet werden. Das betrifft insbesondere Fälle wie [[Olesianer]]in
(OlesianerInderin (Flagge)), hier wird der Link ignoriert aber das in
ungewollt als Kürzel interpretiert (und damit zu Inderin (Flagge)). Ich wüsste keinen Fall, wo dieses Verhalten gewollt ist, deshalb sollte es reichen, als Fix dafür in SGPack_body.php Z. 735 das Regex-Suchmuster entsprechend ergänzen zu (\[\[.*?\]\][a-zA-ZäöüßÄÖÜ]*|\(.*?\))
. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 16:58, 24. Apr. 2020 (CEST)
Noch ein Bug im SGPack
Wieder mal die recursiv-Funktion (thx D5B fürs 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:
{{Kürzel|Rang|text {{Ep|SGA|2x02}} text|k}}}}
wird statt text SGA 2x02 Der Eindringling text
zu:
SGA 2x02 Der Eindringling
kSGAkDer Eindringling</span> text
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 (<span style="display:none">SGA_02x02</span>[[Stargate Atlantis|SGA]]<span> </span>2x02<span style="white-space:nowrap">[[Der Eindringling]]</span>
) direkt einsetzen oder, wie in D5Bs verlinktem Edit, stattdessen einen Link in eine 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:
{{Kürzel|Rang|text {{EpLink|SGA|2x02}} text|k}}}}
wird wie erwartet zu:
text Der Eindringling text
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:
{{#recursiv:Review|text {{Ep|SGA|2x02}} text|}}
wird statt "nur" dem kaputten Link [[StargateWiki:Review#text SGA 2x02 Der Eindringling text|text SGA 2x02 Der Eindringling text]]
zu:
[[StargateWiki:Review#|]][[StargateWiki:Review#SGA|SGA]][[StargateWiki:Review#|]][[StargateWiki:Review#Der Eindringling|Der Eindringling]]</span> 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:
{{#recursiv:--|text [[Bild:Smile.gif]] text|}}
wird statt der einfachen, einzelnen Trennlinie mangels weiteren definierten Parametern zu:
Hingegen mit einer seltenen Vorlage ohne Link in der Ausgabe:
{{#recursiv:--|text {{Kürzel/Rang|usmc-pvt}} text|}}
wird wie erwartet zu:
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.
--Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 19:15, 17. Nov. 2022 (CET)
- Sobald eckige Klammern im Text verwendet werden, splittet der verwendete Regex
'/(\[\[.*?\]\]|\(.*?\))/i'
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:'/(\(.*?\))/i'
. - Mit diesen Änderungen liefern
{{#recursiv:Review|text {{Ep|SGA|2x02}} text|}}
und{{#recursiv:--|text [[Bild:Smile.gif]] text|}}
die erwarteten Ergebnisse. - Die Infobox crasht damit auch nicht mehr, allerdings tritt dann ein Fehler der Kürzelvorlage zu Tage:
{{Kürzel|Rang|<br />''in {{Ep|SGA|2x01}} aber''<br />|k}}
erzeugt nurk
als Ausgabe und nichtin SGA 2x01 Die Belagerung, Teil 3 aber
. Ich gehe davon aus, dass das ein Substitutionsfehler in der Vorlage ist. - --Ghost Profil - Admin - Diskussion - Beiträge - 20px 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
$output .= $para;
) 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. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 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
{{#recursiv:--|text [[Bild:Smile.gif]] text|}}
als eine Linie, das Bild und eine Linie interpretiert wird und bringt noch einige andere Probleme mit sich, wie etwa dasstext [[Link]] text
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{{Ep|SGA|2x02}}
oder legitimer Wikitext, sondern pures HTML. --Ghost Profil - Admin - Diskussion - Beiträge - 20px 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
text [[Link]] text
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.abc [[def (ghi)]] jkl (mno)
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
</span>
einfügt. --Col. o'neill ( Ich bin gerade offline | Admin | Kontakt) 17:15, 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
- 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
- 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