User talk:Theaitetos

From mediawiki.org
(Redirected from User talk:ThetaBot)
Latest comment: 2 years ago by Theaitetos in topic DPL and MW 1.35
  • Please always sign messages (--~~~~).
  • Create new messages always at the bottom.
  • Please continue discussions always where they've been started.

DPL and MW 1.19[edit]

Hi Theaitetos, I'm very sorry, but DPL does not work with MW 1.19, at least not completely. Some functions are definitely causing serious malfuncitions. If you call some list types the whole page will not appear but two lines of PHP error messages. This is reported by several users and by the way not really suprisingly, as DPL is no longer maintained. Where did you get your information of DPL being fully operational? Bye --Robis 16:37, 10 August 2012 (UTC)Reply

As shown in the example here, this wiki is running DPL 2.0 along with MediaWiki 1.19. Which version of DPL are you running? --Theaitetos (talk) 17:05, 10 August 2012 (UTC)Reply
Ah, from what I found there is only DPL 1.9.x. But where is the 2.0 version available? Thank you so much --Robis (talk) 05:18, 11 August 2012 (UTC)Reply
DPL 1.9 runs on MediaWiki 1.19 and DPL2.0 will be released soon. --Theaitetos (talk) 14:34, 15 August 2012 (UTC)Reply
A new version of DPL has been released and is running fully stable on Mediawiki 1.19. --Theaitetos (talk) 22:40, 1 September 2012 (UTC)Reply

dpl question[edit]

Possible you can help me here? Yukii (talk) 18:37, 31 March 2013 (UTC)Reply

Done. --Theaitetos (talk) 19:49, 31 March 2013 (UTC)Reply

dpl question Again...[edit]

Hey Theaitetos,

danke nochmal für deine Hilfe von Letztens. Ich habe leider wieder mal ein Problem mit dpl und das Manual scheint mir hier auch keine Hilfe zu sein. Würde mich freuen wenn du mir hierzu vielleicht einen Tipp geben könntest. :) Beste grüße Yukii (talk) 09:08, 28 June 2013 (UTC)Reply

Habe deine Frage (hoffentlich) beantwortet. Viele Grüße und schönes Wochenende, Theaitetos (talk) 10:30, 28 June 2013 (UTC)Reply
Ja, mein Grundlegendes Problem ist somit erstmal behoben. Vielen Herzlichen Dank! Ich hab nun mal das
| includematch = @\¦\s*Drops\s*=.*\[\[Axe\]\]@i
so übernommen und dann in die Vorlage eingepasst. Funktioniert ganz gut. Die andere Variante überreise ich grad im moment nicht, das gugg ich mir aber nochmal später an. Ist das "Ressourcen" schonender? Yukii (talk) 13:50, 28 June 2013 (UTC)Reply
Keine Ursache. Ja, es ist auch deutlich Ressourcen schonender, aber vor allem muss man nicht so viele Eventualitäten bei regulären Ausdrücken beachten. --Theaitetos (talk) 13:52, 28 June 2013 (UTC)Reply

Na dann werde ich mir auf allefälle dies mal näher ansehen müssen :) Ressourcen schonen kann nicht schaden. Jetzt ist mir grad noch ein zweites problem aufgefallen, vielleicht hast du auch hierfür eine lösung:

{{#dpl:
|dplcache=nmdpl-{{{1|{{PAGENAME}}}}}-1
|category=Kategorie:{{{Name|}}} Monster
|category=Kategorie:Berüchtigte Monster in {{{Name|No}}}
|namespace     = 
|includepage = {Monsterzeile} dpl 4
|includematch = /\s*Ort\s*{{=}}\s*{{#replace:{{#replace:{{{Name|}}}|(|\(}}|)|\)}}/si
|format      =,,\n
|tablesortcol= 1
|table       =class="SE-Heaventable sortable" style="width: 100%;",Name,Pos,Level,Hinterlässt,Familie
|tablerow =%%,%%,%%
}}

Dies verwende ich um Monsterdaten auslesen zu lassen. Nur leider hab ich das problem, das wenn ich Monster XY in Ort und Ort (R) habe, das er mir dann in Ort auch die Monster mit auflistet die in Ort (R) erscheinen und das ist verkehrt. Hoffe ich hab mich verständlich ausgedrückt XD Yukii (talk) 14:31, 28 June 2013 (UTC)Reply

Ich habe mir einmal den Rummager Beetle und West-Sarutabaruta angesehen. Das Problem ist, dass du die Vorlage:Monsterzeile ausliest und dass diese gleich mehrfach eingebunden wird.
Übrigens: Generell bevorzuge ich es, wenn Einträge nicht automatisch in Wikilinks umgewandelt werden (in der Vorlage [[{{{Ort|}}}]]), sondern dass man diese manuell angibt (auf der Seite Ort=[[blabla]]), da das für Wiki-Neulinge verständlicher und weniger fehleranfällig ist; dann könnte man auch im includematch einfacher auf \[\[blabla\]\] testen. Falls du es aber so beibehalten willst, dann empfehle ich mal Folgendes zu versuchen:
{{#dplvar:set|NAME|{{#replace:{{#replace:{{{Name|}}}|(|\(}}|)|\)}}}}
{{#dpl:
…
|includematch = /\s*Ort\s*=\s*{{#dplvar:NAME}}/si
|distinct = strict
|format      =,,\n,
…
--Theaitetos (talk) 14:57, 28 June 2013 (UTC)Reply


  • Wieso fühl ich mich grad gestalkt? XD Du wirst vielleicht lachen, wir hatten früher das genauso, das man alles mit Wikilinks macht, das stiftete eher verwirrung als ohne ^^; Leider funktioniert dein Vorschlag hier nicht :\ aber ist ein interessanter ansatz Yukii (talk) 15:29, 28 June 2013 (UTC)Reply
Biste ein Mädchen? Wenn nicht, dann stalk ich dich auch nicht. =P Du verlinkst auf deiner Seite auf dein Wiki und dann musste ich nur noch nach Teilen des DPL-Aufrufs suchen. Das Problem ohne Wikilinks ist eben, dass du ein Ende definieren musst für deinen regulären Ausdruck, denn ohne Ende trifft es natürlich auch alle Seiten die mit {{{Name|}}} anfangen und dann irgendwie weitergehen. Du könntest das Folgende einmal ausprobieren, aber wie gesagt, besonders elegant ist es nicht: |includematch = /\¦\s*Ort\s*=\s*{{#dplvar:NAME}}\s*\¦/si. --Theaitetos (talk) 17:04, 28 June 2013 (UTC)Reply
Naja, Mann kann auch Mann stalken ;) Gefällt dir wenigstens was du gesehen hast? XD Ok, der Code funktioniert ^^. Aber du meinst definitiv das dpl sinnvoller wäre, wenn man in den vorlagen direkt die Wikilinks setzt? Hats das dann nur was mit dem Auslesen zu tun oder wirkt sich das noch in irgendeiner art aus? Yukii (talk) 17:11, 28 June 2013 (UTC)Reply
Vielleicht hast du ja auch ne süße Schwester. =P
Das hat weniger mit DPL als mit einem einfachen Suchbefehl zu tun. Beispiel:
  • Du hast die Seiten Militär, Militäreinsatz, Militärfahrzeug und Militärfahrzeugführer.
  1. Suchbefehl: Militär. Ergebnis: Alle 4 Seiten, denn in allen 4 Seiten steckt das gesuchte Wort Militär.
  2. Suchbefehl: Militärfahrzeug. Ergebnis: 2 Seiten, denn in den beiden Seiten Militärfahrzeug und Militärfahrzeugführer steckt das gesuchte Wort Militärfahrzeug.
Du suchtest mit deinem ursprünglichen includematch-Befehl nach Namen wie West-Sarutabaruta und dies kommt natürlich in beiden Einträgen vor, sowohl in |Ort=West-Sarutabaruta als auch in |Ort=West-Sarutabaruta (R). Um das Zweite auszuschließen musst du dann eben ein "Ende" angeben, sodass der Suchstring nicht auf beide Einträge passt; und das geht eben sehr gut, wenn Wikilinks verwendet werden, denn der Suchbefehl [[West-Sarutabaruta]] passt nun nicht mehr auf [[West-Sarutabaruta (R)]]. --Theaitetos (talk) 17:35, 28 June 2013 (UTC)Reply
  • Ich glaub meine schwester ist viel zu Alt um "süß" zu sein XD Da muss ich dich wohl leider Enttäuschen.
    Achso ist das. So kann ich das ganze natürlich gut nachvollziehen. Das bequatsch ich mal mit meinem Kollegen, klingt so natürlich sehr sinnvoll. Notfalls müssen wir da nochmal nacharbeiten (es lebe Spezial: Text Ersetzen) XD Aber die Info werde ich mich mir natürlich gleich mal für mein zweites Wiki zu einem Online game merken. Denn das würde mir schon einige probleme ersparen die ich im Wiki 1.0 des gleichen spiels hatte... Da hat sich das nachfragen für mich heute wohl sehr gelohnt :) ich würde sagen, du hast ein bier bei mir gut - sofern sich mal die situation ergeben sollte ;)
    Hast du vllt noch nen Tipp was ich bei dpl beachten bezüglich Performance? Vielleicht ergeben sich mir da noch möglichkeiten auf die ich nicht gekommen bin :) Beste grüße aus Landshut! Yukii (talk) 18:00, 28 June 2013 (UTC)Reply
Nichte, Tochter, … irgendwas um die 20, bin da nicht wählerisch. =P
Danke, aber ich trinke kein Bier. Da du überall schon den dplcache benutzt, gibt es kaum etwas, was man bezüglich der Performance noch beachten müsste. Es gibt natürlich immer noch die Möglichkeit einen DPL-Aufruf zu substitutieren (und über Bots regelmäßig neu zu substituieren), aber das lohnt sich nur bei großen Seiten die nur aus einem solchen DPL-Aufruf bestehen. --Theaitetos (talk) 11:51, 29 June 2013 (UTC)Reply
  • Nichte eher xD Für ne Tochter bin ich wohl selbst noch zu jung :)
  • Sagmal, gibt es eine möglichkeit wie ich den ausgelesenen "Namen" Kaschieren kann? Bsp. Ich lass einen Namen wie in meinem Fall nun "Gartenarbeit Rezepte/Tontopf" ausgeben. Nun möchte ich den Namen gerne mit "Tontopf" kaschieren und trotzdem auf Gartenarbeit Rezepte/Tontopf verlinken lassen. Geht das? Yukii (talk) 09:54, 1 July 2013 (UTC)Reply
Ach, ich hatte mit 11 mein erstes Mal, wenn da was schief gegangen wäre, dann hätte ich jetzt ein Kind in der Pubertät. =P
Ja, verlinke einfach mit [[%PAGE%|%TITLE%]] statt nur mit [[%PAGE%]] und füge noch den folgenden Befehl in den DPL-Aufruf ein:
|replaceintitle = @\/.*@,
Das führt ein RegEx-Suchen-und-Ersetzen auf die %TITLE%-Variable durch (%TITLE% ≙ {{PAGENAME}}), und im konkreten Fall hier wird alles ab dem "/" ersetzt mit dem, was hinter dem Komma steht – also mit nix und wird damit effektiv entfernt. --Theaitetos (talk) 22:32, 1 July 2013 (UTC)Reply
Da kann ich nur sagen: DITO! ;D
Ich gehe davon aus das ich dass "[[%PAGE%|%TITLE%]]" in die Vorlage einbinden muss, die er auslesen soll. Werde das ganze mal ausprobieren.
Zweite Frage: DPL liest den Namen ja immer an erster Stelle aus - ich würde ich gerne in einer Tabelle an zweiter oder dritter stelle anzeigen lassen - geht das auch? Yukii (talk) 05:31, 5 July 2013 (UTC)Reply
Was meinst du mit "in die Vorlage einbauen"? Die Variablen lassen sich nur in DPL verwenden.
Das kommt darauf an wie du die DPL-Ausgabe formatierst. Wenn du format= verwendest, dann wird nur das angezeigt, was du explizit angibst. Wenn du table= verwendest, dann musst du für die erste Tabellenspaltenüberschrift nur - hinschreiben und der Name wird unterdrückt. Du kannst ihn wieder einfügen, indem du im include= statement an gewünschter Stelle [[%PAGE%]] angibst. --Theaitetos (talk) 15:11, 5 July 2013 (UTC)Reply
Ach klaro... Irgendwie war gestern nicht mein Tag......
Ok, das muss ich mal Ausprobieren. Bin gespannt ob ich das nun überrissen habe ;) Danke nochmal für dein Wissen :D Yukii (talk) 07:19, 6 July 2013 (UTC)Reply


  • Eine Frage hätte ich noch. Wie stelle ich es an, wenn der Indcludematch nicht nur auf einen Parameter abzielen soll, sondern auf Zwei oder drei?. Das ich beispielsweise sage |includematch = /\s*Name\s*=\s*TEST1/si/ und ebenso /\s*Name2\s*=\s*TEST2/si/, geht das? Yukii (talk) 10:20, 9 July 2013 (UTC)Reply
Einfach als einen Ausdruck schreiben: |includematch = /\s*Name\s*=\s*TEST1.*\¦\s*Name2\s*=\s*TEST2/si. --Theaitetos (talk) 12:25, 11 July 2013 (UTC)Reply
  • Interessant, ich hab rumprobiert wie blöd aber darauf bin ich nicht gekommen *rofl* ... Jetzt hab ich noch ne dumme Frage ^^; Ich schaffs Patou nicht, das dass hier mir richtig nach Level Sortiert wird. Gibts hierbei einen Trick? Mit ordermethod= schein ich dass nicht hinzubekommen... du hast doch bestimmt ne lösung für sowas? Yukii (talk) 18:35, 12 July 2013 (UTC)Reply
So, ich bin wieder da. Es scheint aber alles zu klappen, denn die Sortierung nach Level ist da, oder? --Theaitetos (talk) 21:03, 25 July 2013 (UTC)Reply
  • Hallo Theiatetos, entschuldige das ich dir jetzt erst antworte. Ich hatte ein wenig bei fremdsprachigen Sites geschaut und dort etwas gefunden das ich prompt mal ausprobiert habe. Da es funktionierte, bin cih natürlich dabei geblieben ;). Ich hätte da noch eine frage bezüglich den Includematch auf 2 bis 3 Parameter. Ich würde gerne so wie Test 1 oder Test 2 = NAME - das was ich probiert hatte, ging bis dato leider nicht. Du hast dich sicherlich ne idee dafür oder? Yukii (talk) 19:02, 12 August 2013 (UTC)Reply
Das würde ich ohne includematch per Vorlage lösen, d.h. in dein include= schreibst du die Vorlage rein, die benutzt werden soll (bspw. include = {Monsterzeile} dpl 4 und in der Vorlage führst du dann die Abfrage mit String-Funktionen durch. Z.B. wäre {{#if: {{#pos: .{{{Test 1|}}}.{{{Test 2|}}}.{{{Test 3|}}}. | .NAME.}} | ja | nein }} eine Oder-Abfrage "Ist Test 1 = NAME oder Test 2 = NAME oder Test 3 = NAME ?" --Theaitetos (talk) 08:58, 13 August 2013 (UTC)Reply
  • Die Idee ist gut. An das #pos hab ich jetzt gar nicht gedacht. Meine Vorlage sieht jetzt so aus:
{{#if: {{#pos: .{{{Kristall|}}}.{{{Kristall 1|}}}.{{{Kristall 2|}}}. | .Blitzkristall.}} | [[Datei:{{{Name}}}icon.png|20px|{{{Name}}}|link={{{Name}}}]] [[{{{Name}}}]] x {{{Anzahl|}}}
{{!}}
[[Datei:{{{Topf}}}icon.png|20px|{{{Topf}}}|link={{{Topf|}}}]][[{{{Topf|}}}]]
{{!}}[[Datei:{{{Samen}}}icon.png|20px|{{{Samen}}}|link={{{Samen|}}}]] [[{{{Samen|}}}]]<noinclude>[[Kategorie:Vorlagen (DPL)|{{PAGENAME}}]]</noinclude> | }}
Ich habe es korrigiert. Habe mich mal im Forum registriert, aber im Wiki kann ich mich trotzdem nicht anmelden.
Wie auch immer: Die Vorlage musst du gleichzeitig für die Formatierung deiner Tabelleneinträge verwenden, denn nur weil die Vorlage keine weiteren Inhalte einbindet von Einträgen ohne .Blitzkristall., heißt ja nicht, dass darum der ganze Output jener Einträge verhindert wird. D.h. ich habe die ganze Tabellenzeile jetzt in die Vorlage integriert (|- | | etc.); den Seitennamen kann man mit dem automatischen Parameter {{{%PAGE%}}} (= %PAGE% in DPL) einbinden. Auf table= sollte man dann ganz verzichten und die Tabelle manuell um die DPL-Abfrage herumbauen. Den dplcache= kannst du wieder einfügen, den habe ich nur für den Test entfernt, da man beim Testen keine gecacheten Abfragen haben will. format= ,,, sollte aber stehenbleiben, um automatische Formatierungen zu verhindern. --Theaitetos (talk) 16:59, 13 August 2013 (UTC)Reply


  • Hey Theaitetos, nice work! Sag ich da nur :) Interessant. Ich hab gerade meinen (lang ersehnten) Bot Account übers Forum angelegt und kann mich mit diesem im Wiki auch Anmelden. Hast du irgendeine Fehlermeldung bekommen?
  • Interessantes vorgehen. Ich kann wohl noch ne Menge von dir Lernen XD Ich müsste noch "Blitzkristall" gegen einen Parameter wechseln. Im prinzip verwende ich das Auslesen über eine Vorlage. In der Voralge gibt es den Parameter "Name" und dieser kann dementsprechend "Blitzkristall", "Wasserkristall", "Feuerkristall etc heißen.
{{#dpl:
|namespace = 
|category = Blitzkristall verwendet bei Gartenarbeit
|include = {Link G} dpl kristall verwendung
|format      = ,,,
}}

Hier kann ich zwar "Blitzkristall" durch {{{Name}}} ersetzen, aber in der include Vorlage ist mir dies ja so nicht möglich. Dafür auch noch nen Vorschlag parat? Yukii (talk) 17:37, 13 August 2013 (UTC)Reply

Ich habe das Passwort geändert und es hat funktioniert. Scheint als wären Sonderzeichen noch ein Problem, zumindest eines der folgenden: }=[@"
Du kannst mit #dplvar Variablen definieren. Wenn du jetzt statt dem Feuerkristall den Blitzkristall abfragen willst, dann änder einfach den Wert der Variablen entsprechend. --Theaitetos (talk) 18:23, 13 August 2013 (UTC)Reply
  • Interessant. Ich vermute mal das liegt vielleicht am phpbb3 Forum. Werde das mal checken :D
  • Das sind solche Momente, bei denen ich mit meinem Kopf gnadenlos auf der Tischplatte lande -.- So einfach und Simpel, mein hirn ist dochlangsam Reif für einen Ordentlich Urlaub. Noch zwei Arbeitstage... :3 Achja, falls du mal lust hast zu quatschen via Skype --> Yukii2 oder via ICQ --> 257-870-656. Ich würde mich freuen Yukii (talk) 18:42, 13 August 2013 (UTC)Reply

DPL-Problem (hab auch eines)[edit]

Hallo Theaitetos, Ich hab da ein mittelgroßes Promblem bei der gemeinsamen Nutzung von #dpl und #ask (SWM) auf einer Seite. Ich hab das ganze mal bei der DPL-Diskussionsseite reingepostet. Könntest Du mal drüberschauen? Vielen lieben Dank! Ciannicay (talk) 18:20, 13 November 2013 (UTC)Reply

Probleme bei der Kombination zweier semantischer Extensions auf der selben Seite sind immer so eine Sache. Ich kenne die SIO-Extension nicht, weswegen es wohl lange dauern könnte herauszufinden, an welcher Stelle die beiden Extensions in Konflikt geraten. Ich kann nur empfehlen es so handzuhaben, dass der Konflikt nicht auftritt, bspw. DPL nur nach SIO-Einbindungen oder nur in der Tag-Form auf der selben Seite zu verwenden. Sorry --Theaitetos (talk) 18:44, 13 November 2013 (UTC)Reply
Leider bin ich nicht in der Lage es zu verhindern, denn das System gehört meinem Brötchengeber und mal eben 10k User davon abzuhalten was zu nutzen was ihnen lieb und teuer ist, dürfte verständlicherweise schwierig sein. Große Updates sind leider auch tabu (nachdem wir dieses Jahr ein update hatten - das erste in 4 Jahren...), aber nen Patch könnte ich evtl. durchdrücken. Das Problem tritt nur bei |include= Statements auf, normales #dpl funktioniert hervorragend. Das Problem als solches scheint in die gleiche Richtung zu gehen wie das Problem bei denen dpl den Hook "ParserClearState" scheinbar zu früh nutzt. (siehe https://bugzilla.wikimedia.org/show_bug.cgi?id=21502) Bei dem Bugzilla-Eintrag ist insbesondere der letzte Kommentar derjeneige auf den ich mich beziehe. Kannst Du bitte mal fahnden, ob der Fehler etwa immer noch vorhanden ist - ich mein, der wurde ja doch schon 2009/2011 reported... --Ciannicay (talk) 19:10, 13 November 2013 (UTC) (typos editiert: Ciannicay (talk) 12:10, 18 November 2013 (UTC))Reply
Gleich noch ne Frage zu DPL V2.01 (also der aktuellen Version). Kann die auf einem Mediawiki 1.17.5 problemlos eingesetzt werden? Gibt es eventuell weitere Abhängigkeiten? (Sorry für solch banale Fragen) --Ciannicay (talk) 14:24, 18 November 2013 (UTC)Reply
Zur letzten Frage: Ja, DPL kann mit allen neuen MW-Versionen eingesetzt werden. Ausführlich getestet habe ich es bisher zwar nur bis 1.19, aber 1.20+ sollten mWn auch keine Probleme darstellen.
Zur anderen Frage: Ich weiß es nicht mit Sicherheit, glaube aber auch, dass das damals behoben wurde. Das Problem ist, dass ich damals noch nicht an der Extension mitgewirkt habe, sondern erst später hinzukam – zudem gab/gibt es für DPL immer noch eine eigene Seite, auf der die Bugs gemeldet werden sollten, weswegen ich auch nicht weiß ob Algorithmix damals auch Bugzilla überprüft hat.
Eine Frage zu deinem Problem: Wenn du "skipthispage=no" weglässt, erscheint der Fehler dann immer noch? Eventuell liegt es ja auch daran, dass die Seite selbst dann überprüft wird. Probier auch bitte mal, ob sich etwas ändert, wenn du "dplcache = Test1" als Parameter im DPL-Aufruf setzt. --Theaitetos (talk) 19:15, 18 November 2013 (UTC)Reply
Sehr gut, wenn das bis 1.19 getestet ist, dann wird's wohl mit unserer 1.17.5 laufen. Nachdem Du nicht auf Abhängigkeiten eingegangen bist, nehme ich mal an es gibt keine. Damit sollte ich in der Lage sein ein "Patchen" zu beauftragen.
Ich dacht immer Gero wollte auf der Sonderseite nur die Weiterentwicklungswünsche haben - zumal ja auch ein Teil der Buzillaeinträge scheinbar bearbeitet wurden. Egal. Ich darf hier eigentlich nicht so tief rein, aber ich hab mir mal den Code angeschaut, dieser ParserHook ist hincht mehr im aktuellen Code drin, daher gehe ich davon aus, dass das behoben wurde - ach da in der Historie stehts, das ist mit der 1.9.x wieder raus genommen worden, weil es Konflikte mit der Extension CITE gab.
Ich habe leichte Probleme dieses "skipthispage=no" weg zu lassen, weil es ja eben genau ein weiter oben in der Seite befindlicher Wert aus einem Template ist, welcher weiterverwendet werden soll. Wenn ich aber zu Testzwecken diesen Wert aus einer anderen Seite nehme, so tritt der Fehler leider weiterhin auf :(. So, jetzt auch noch den dplcache getestet - keinerlei Veränderungen.
In DPL.php ist relativ weit oben eine Sonderbehandlung für die CITE Erweiterung drinnen, welche berücksichtigt, dass CITE evtl. nen Hook auf parser->ClearState hat. Nun ist es so, dass auch SIO diesen Hook nutzt. Kann hier eine weitere Sonderlocke im Code notwendig werden? --Ciannicay (talk) 16:55, 19 November 2013 (UTC)Reply
Da ich mir jetzt doch den Code mal komplett durchlese stolpere ich halt auch über Sachen, die irgendwie komisch sind:
Da steht doch in der Versionshistorie (in der DPLSetup.php)
"eliminated calls to parser->clearState and parser->transformMsg, now CITE and DPL work togetheras a consequence a patch to LinkHolderArray.php is needed".
So weit, so gut. ABER warum sind dann noch calls da? (in DPL.php)
// now clear the state
$this->mParser->clearState(); // eliminated to avoid conflicht with CITE extension
// restore Cite Object
Hmm, also wenn die Calls eigentlich weg sein sollen, warum finde ich die dann noch in der AKTUELLEN Version im Git? --Ciannicay (talk) 14:23, 20 November 2013 (UTC)Reply
Die Calls sollen nicht weg sein, da sie benötigt werden. Der Konflikt mit der CITE-Extension wurde dahingehend gelöst, dass sämtliche temporären CITE-Objekte in andere Objekte zwischengespeichert werden, die nicht von clearState erfasst werden, und danach werden diese Werte wieder in die ursprünglichen Objekte zurückgebracht. Um für SIO einen ähnlichen Workaround zu implementieren müsste man wissen welche Objekte aus SIO alle zwischengespeichert werden müssten. --Theaitetos (talk) 18:33, 20 November 2013 (UTC)Reply
Hmm, dann hab ich wohl das mit dem "eliminated" falsch verstanden für mich klang das nach "wurden entfernt". Egal. Ich hab Deine letzte Antwort mal übersetzt und an Yaron weitergegeben. Er hat zwar eigentlich nicht viel Lust in dem Code der bei Ihm nur noch wegen Abwärtskompatibilität drinnen ist rumzuwühlen, aber er schaut mal.
Ist Dir eigentlich eine weitere Installation bekannt, bei der SIO und DPL zeitgleich genutzt werden? --Ciannicay (talk) 11:38, 22 November 2013 (UTC)Reply
Nein, mir ist leider keine weitere Installation bekannt. Es ist ohnehin sehr, sehr selten, dass DPL und SMW gleichzeitig in einem Wiki genutzt werden, da die eine Extension fast alles der jeweilig anderen darstellen kann. Die meisten fragen daher eher "DPL oder SMW, was soll ich benutzen?" Allerdings könntest du im Bienenstock suchen: WikiApiary greift auch immer ab, welche Extensions in einem Wiki installiert sind und da könntest du welche finden, die beide Extensions haben. --Theaitetos (talk) 11:42, 22 November 2013 (UTC)Reply
Komisch, die Frage hatte sich bei uns nie gestellt. Wir wollten DPL wegen der Einfachheit und der Aktualität der Ergebnisse (direktes abgrasen der Seiten) und SMW wegen den Formularen etc. (Und da die Admins einfach gesagt haben: Semantic bundle und gut is.). Sind nicht im Bienenstock nur extern zugänglich Wiki's? Weil unsere rund 60 einzelnen Wiki's wird man dann dort eher nicht finden (alle rein firmenintern und hinter der Firewall) --Ciannicay (talk) 14:36, 25 November 2013 (UTC)Reply

DPL and noincludes[edit]

This is Moviesign, but apparently someone in Japan has taken that username, so I am movie-sign here. Thank you very much for helping me with my DPL code. That is some fancy regexp work there! I have a number of questions, if you have time to answer.

  1. If DPL does not work with normal transclusion, why does my code work at all? Is it an undocumented feature or unsupported behavior that I should not rely on because it may break in the future? I was this close -][- to having it working :)
  2. Could I simplify that beautiful regexp by specifying includetrim = true and removing the part that trims whitespace? Or is it better to do it all in the same filter?
  3. Can I use a regexp filter with include = * ? The reason I ask this is because I do want a full calendar with every date represented even if there is no ==On This Day== heading. My database experience is limited, but I think I want a "Left Join" type of result, displaying the date heading for every date regardless of content. I was planning on eventually creating a page that actually looks like a calendar, with squares in rows, etc.

Thanks for your time. —Movie-sign (talk) 22:58, 6 March 2014 (UTC)Reply

Hello,
  1. It's not as if DPL doesn't work with normal transclusion. DPL just works different than normal transclusion, but it is able to parse transcluded content from normal transclusion. But generally this is very undesired, since there is no reason to do any normal transclusion. DPL is specifically made to retrieve content from other pages – your job when creating a DPL call is to tell DPL exactly which content to transclude from what page. DPL is not meant to take "orders" from the content of the transcluded page itself (like a <noinclude></noinclude>-order).
  2. You could, but I prefer trimming the content, that is transcluded directly. If, for example, you were to transclude two different sections of a page, includetrim would just trim whitespace in front and at the end of the whole transcluded content, while the regex allows trimming of the whitespace of every single transcluded section. Which is why I prefer the regex version, so you don't have to switch back and forth depending on the numbers of transclusions.
  3. Yes, that's possible too. When you do so, best have some of those desired pages open for edit, so you can look at the source of the page and write your regex accordingly: include=* will take the entire page, from the very beginning to the very end.
--Theaitetos (talk) 23:18, 6 March 2014 (UTC)Reply
Thanks for your help. Now that I understand the reason for the odd behavior, I can fix it. Of course, if I can craft a sufficiently intelligent regex to use with include = * then this will all be moot. —Movie-sign (talk) 17:04, 8 March 2014 (UTC)Reply

Revision-related queries improvements[edit]

Hi,

I have coded a modification on DPLMain.php on the DPL project. It dramatically improves the performance for the operations on revision. You should have received the patch via mail by Gero Scholz. a month ago. Can it be commited? Should I send you the patch? Should I contact another person? Ftiercel (talk) 09:36, 27 July 2014 (UTC)Reply

Hmmm, I changed my main email beginning this year and Gero probably sent it to my old account. Can you send it to me directly? I'll have a look then and test it next week. --Theaitetos (talk) 14:52, 27 July 2014 (UTC)Reply
Now you should have received my mail. Ftiercel (talk) 18:54, 28 July 2014 (UTC)Reply
Yes, I got the e-mail. I'll look at your code, do a little test and implement it this weekend – unless you want to implement it yourself on Git (to have the proper attribution to you)? Whatever you decide, thank you very much for the contribution! --Theaitetos (talk) 01:37, 30 July 2014 (UTC)Reply
Whatever. The most important is the commit. Ftiercel (talk) 18:22, 1 August 2014 (UTC)Reply

Kleines problem mit DPL mal wieder[edit]

Hey Theaitetos,

ich hab nochmal ein kleines problem und würde mich freuen, falls du mal 5 minuten findest dir es anzusehen. Ich würde gerne hier das Automatische einbinden des Seitennames unterbinden sprich die Punkte:

  • Bestiarium: Gladiator 01
  • Bestiarium: Gladiator 02
  • Bestiarium: Gladiator 03
  • etc.

Mit "replaceintitle" komme ich zum Beispiel nicht auf mein Ziel. Hast du vielleicht eine kleine Idee für mich? Yukii (talk) 18:31, 30 August 2014 (UTC)Reply

Einfach die automatischen Formatierungen mit format=,,, aussetzen. Es gab wohl auch ein kleines Cache-Problem. --Theaitetos (talk) 20:57, 30 August 2014 (UTC)Reply
Ahhh...! Vielen herzlichen Dank :) Darauf wäre ich jetzt nicht gekommen -.-' Du bist mal wieder meine Rettung :) Yukii (talk) 07:56, 31 August 2014 (UTC)Reply

Execandexit not setting dplvars[edit]

Hi Theaitetos!

I created a new project in Phabricator (T76065) and I'm hoping you will take a look at it. The {{#dpl:execandexit=geturlargs}} feature no longer seems to be setting any dplvars. Thanks for any help you can provide. —Movie-sign (talk) 19:32, 26 November 2014 (UTC) AKA Moviesign on the Forgotten Realms WikiReply

DPL 3.0 Beta 5[edit]

DPL 3.0 Beta 5 is packaged and ready for testing. This is close to a release candidate assuming no more major bugs are discovered. Alexia E. Smith (talk) 17:44, 18 December 2014 (UTC)Reply

Kurze frage zu DPL[edit]

Hallo Theaitetos!

Dank deinen bisherigen Tipps bin ich ganz gut mit der Erweiterung klar gekommen, echt klasse das ganze. Jedoch habe ich nun eine kurze Rückfrage, da ich jetzt Aufgrund eines Server-Umzugs (Nginx/Varnish Cache/PHP5-FPM) etwas Probleme mit der Erweiterung bekommen habe. Mich würde Interessieren ob die Erweiterung auch mit folgenden Versionen von PHP und MySQL läuft:

  • MediaWiki 1.25.1
  • PHP 5.6.9-0+deb8u1 (fpm-fcgi)
  • MySQL 5.5.43-0+deb8u1
  • DPL-Verion 2.3.0

Der Grund für meine Frage ist folgende Fehlermeldung: [error] 894#0: *4835 FastCGI sent in stderr: "PHP message: PHP Strict Standards: Only variables should be assigned by reference in /extensions/DynamicPageList/DPLMain.php on line 53" while reading response header from upstream,[..]

Wenn ich mir die Datei ansehe und Zeile 53 raussuche, steht dort:

$dbr =& wfGetDB( DB_SLAVE );

Hast du vielleicht eine Idee?

Mit besten grüßen Yukii (talk) 20:12, 18 July 2015 (UTC)Reply

Müsste funktionieren ja; steht denn in den Patchnotes was davon, dass da was bezüglich der Datenbankaufrufe geändert wurde? Bin Mitte September wieder aus dem Urlaub zurück, wenn du bis dahin warten willst. --Theaitetos (talk) 15:41, 6 August 2015 (UTC)Reply

Frage zu DPL[edit]

Hallo Theaitetos,

entschuldige das ich dich nochmal Stören muss. Ich könnte nochmal kurz Hilfe gebrauchen. Ich möchte in dieser Vorlage via Count = 25 Artikel anzeigen lassen, jedoch möchte ich das über mehrere "seiten" machen. D.h. ich möchte aus der Kategorie Begleiter auf Seite 1 die ersten 25 haben und auf seite 2 die nächsten 25 usw. Nur ich finde keine Möglichkeit wie ich das realisieren kann. Geht das überhaupt was ich da vorhabe? :D Mit besten grüßen Yukii (talk) 13:59, 28 September 2016 (UTC)Reply

Hallo nochmal ;D Hab mein Problem mit "offset" Lösen können :D Beste Grüßen Yukii (talk) 17:30, 1 October 2016 (UTC)Reply

Mal wieder eine Frage zu DPL ^^[edit]

Hallo Theaitetos!

Jetzt hab ich doch nochmal eine Frage und ich hoffe du kannst mir diese Beantworten.

Ich möchte hier eine Übersicht der Begleiter (Links die Icons) erstellen und rechts eine Ausgabe bestimmter Parameter die im Artikel enthalten sind. Läuft auch soweit ganz gut. Nur wenn man jetzt das Chocobo-Küken anklickt (3 Reihe, 2 Symbol von Links) erscheint in der Übersicht die Daten zu Chocobo-Küken (soweit OK) und leider auch zu Schwarzes Chocobo-Küken. Ich dachte ich könnte das evtl. mit includematch lösen wie ja schon einmal, aber das scheint mir nicht die Lösung zu sein. Hast du vielleicht eine Idee für mich? Beste Grüße Yukii (talk) 22:47, 22 January 2017 (UTC)Reply

Hallo Yukii. Das scheinen mir weniger DPL-Probleme als CSS/JS-Probleme zu sein. Ich habe beim Schwarzen Chocobo-Küken und dem Mini-Pilz einmal die [[]] um den Namen herum entfernt. Seitdem werden die beiden beim Klicken auch angezeigt – den DPL-Cache musst du beim debuggen einfach mal aus dem DPL-Aufruf ausklammern, damit man es sieht. Damit "Schwarzes Chocobo-Küken" beim Anklicken nicht angezeigt wird wenn du auf "Chocobo-Küken" klickst, musst du den Namen des Togglers verändern, denn Leerzeichen wirken in CSS wie Trennzeichen; nenn es also "Schwarzes-Chocobo-Küken" o.ä. bei der Benennung der CSS-Klasse. Du musst halt irgendwie die Leerzeichen im Parameter {{{Name|}}} der Vorlage:Infobox Begleiter icon dpl ersetzen und im Toggler ebenso. --Theaitetos (talk) 11:15, 23 January 2017 (UTC)Reply
Hallo Theaitetos! Also darauf wäre ich jetzt echt nicht gekommen XD Mittlerweile bin ich schon ein Stückchen weiter dank dir. Eben wurde mir zwar noch das "Schwarze Chocobo Küken" beim "Chocobo-Küken" angezeigt, aber seitdem ich jetzt dem Toggler gesagt habe bei leerzeichen soll er stattdessen ein Plus setzen, mag er mir die Begleiter nicht mehr anzeigen die einen Leerzeichen im Namen haben. In Vorlage:Infobox Begleiter icon dpl habe ich jetzt das gleiche gesetzt wie fürn den toggler (wirkt sich hierrüber aus), aber das scheint ihm nicht zu passen. Hast du vielleicht auch hier einen Denkanstoß für ich? Beste Grüße Yukii (talk) 11:43, 23 January 2017 (UTC)Reply
Probier es noch mal mit geleertem Cache. --Theaitetos (talk) 12:38, 23 January 2017 (UTC)Reply
Du bist ein Genie! :D Ich wusste gar nicht das es dplreplace gibt o.o. Vielen herzlichen Dank :) Ich tüfftel sein Wochen rum, hätte ich mal früher gefragt :) Beste Grüße Yukii (talk) 12:58, 23 January 2017 (UTC)Reply
Keine Ursache. #dplreplace funktioniert wie #replace, allerdings mit regulären Ausdrücken. Viel Spaß noch! --Theaitetos (talk) 11:09, 24 January 2017 (UTC)Reply

Ist ein wechsel sinnvoll?[edit]

Hallo Theaitetos!

Ich mal wieder :D Ich strebe momentan wieder ein Update der Wiki Software und der Extensions an. Aktuell nutze ich als Plugin ja DynamicPageList (third-party) und seit einiger Zeit gibt es ja die neue Version DynamicPageList3 an deren Entwicklung du ja auch beteiligt warst. Macht es Sinn die Erweiterung zu Wechseln? Wird dann alles wie gewohnt noch funktionieren? Worin liegt der Unterschied in den beiden Versionen? Mit besten Grüßen Yukii (talk) 18:04, 30 August 2017 (UTC)Reply

Ja, die Version kann man verwenden. Diese neue Version ist hauptsächlich eine inner-programmatische Überarbeitung ohne große Änderungen für die Nutzer. Die Überarbeitung wurde aber nicht von mir gemacht, auch wenn ich immer informiert wurde. Die Überarbeiterin hat das für ihre Firma gemacht, die DPL sehr intensiv nutzt und die Überarbeitung auch finanziell stemmen konnte. Ich hätte so viel Zeit nicht gehabt. Selbst ausgeführlich getestet habe ich das neue DPL nicht, aber die Bug Reports bekomme ich auch und es sieht wirklich toll aus! Kannst mir ja mal schreiben wie es so war. --Theaitetos (talk) 19:48, 30 August 2017 (UTC)Reply

DPL und Tabellen[edit]

Hallo Theaitetos!

Ich habe wieder mal eine Frage und hoffe du kannst mir da vielleicht da Helfen. Wenn ich via DPL Daten auslese und diese in einer Tabelle ausgebe, kommt es vor das die Letzte Spalte manchmal Frei bleibt, wenn Beispielsweise ein NPC den Gegenstand auf zwei Arten verkauft (Beispiel hier). Gibt es da einen Trick das er die Daten trotzdem in jeder Zeile auspuckt? Interessanterweise geschieht das immer nur am Ende der Zeile. Die ersten Spalten werden nie Zusammengefasst wenn der Inhalt identisch ist.

Vielen Dank und Beste grüße! Yukii (talk) 08:02, 25 February 2018 (UTC)Reply

Hallo Yukii, dein Beispiel ist nicht sehr gut, da muss man sich ja erst durch den Quellcode mehrerer Seiten quälen bevor man überhaupt erkennt wo die DPL-Abfrage ist und wie sie in die anderen Vorlagen eingeführt ist. Kannst du irgendwo eine Beispielseite erzeugen (bspw. Substitution der Vorlagen) sodass die entsprechende DPL-Abfrage direkt im Code der Seite zu sehen ist? --Theaitetos (talk) 13:03, 25 February 2018 (UTC)Reply

Sorry, du hast recht. Ich bin das ganze ja schon gewohnt ;) Ich hoffe das hilft dir weiter :) Yukii (talk) 15:33, 25 February 2018 (UTC)Reply

Danke, so ist erkennbar was passiert. Der DPL-Aufruf ruft eine Seite auf (Händlermarionette Nr. 012P) und nicht direkt die Vorlagen. Daher wird die Vorlage Template:Infobox NPC auch nur so oft eingebunden, wie diese Vorlage auf der Seite vorkommt: 1 Mal. Die Vorlage Template:Händlerzeile wird ebenso oft aufgerufen wie sie auf dieser Seite vorkommt und dann per Filterung (includematch) von dir auf die jeweiligen Erwähnungen beschränkt: 2 Mal. Die Tabelle fügt immer automatisch am Anfang den Namen der Seite hinzu (bei jeder neuen Zeile), sodass das Problem an dieser Stelle kaschiert wird: denn auch der Name der Seite würde sonst nur 1 Mal angezeigt werden. Erst nachdem alle Händlerzeilen-Aufrufe abgearbeitet sind geht DPL über dazu die Infobox NPC-Vorlage abzurufen und einzubinden, weswegen der Regionsteil nur einmal ganz am Ende erscheint.
Es gibt mehrere Möglichkeiten das zu ändern. Die eleganteste (und einfachste) dürfte sein, indem du den DPL-Aufruf teilst und die Region-Einbindung per DPL in die Vorlage:Händlerzeile preis dpl einbaust. D.h. entferne
{Infobox NPC} verkauf dpl
sodass nur noch
|includepage = {Händlerzeile} preis dpl
da steht. Dann ändere Vorlage:Händlerzeile preis dpl indem du dort am Ende den DPL-Aufruf für die Regionsangabe einbindest, bspw.:
{{#dpl:
|page = {{{%PAGE%}}}
|namespace = 
|includepage = {Infobox NPC} verkauf dpl
|format      = ,¦¦,,
|suppresserrors = true
}}
Dadurch wird dann am Ende jedes Händlerzeilen-Aufrufs die Regionsangabe eingebunden. Das sollte dann funktionieren. --Theaitetos (talk) 20:00, 25 February 2018 (UTC)Reply
Ich hab das mal ausprobiert. 1:1 wie von dir beschrieben. Passt noch nicht so ganz, aber ein interessanter Ansatz Yukii (talk) 08:52, 26 February 2018 (UTC)Reply
Sorry, eine Verwechslung meinerseits. Der DPL-Selektor im Aufruf sollte "title=" sein, nicht "page=", also einfach "|title = {{{%PAGE%}}}". --Theaitetos (talk) 23:18, 26 February 2018 (UTC)Reply

Mal ne andere Frage[edit]

Hallo Theaitetos,

ich hätte mal eine nicht DPL bezogene frage. Ich suche schon seit einiger Zeit nach einer Möglichkeit das statt der IP-Adresse der User sowas wie ein "Wiki-Nutzer" stattdessen erscheint. Aber ich bin unter Extensions nicht fündig geworden und auch sonst nicht so wirklich. Hast du da vielleicht eine Idee oder schon Erfahrung damit? :D Yukii (talk) 17:49, 11 April 2018 (UTC)Reply

Keine Ahnung. Ich weiß nicht, ob man da was machen kann, denn es scheint mir doch eine zentrale Funktion zu sein. Ich sehe auch wenig Nutzen darin, denn dann kann man anonymen Nutzern keine Nachrichten mehr auf ihren IP-Benutzerseiten hinterlassen o.ä. Du könntest höchstens mal schauen, ob es eine Extension für eine Art "Gast-Account" gibt, in den man automatisch eingeloggt wird. --Theaitetos (talk) 20:49, 11 April 2018 (UTC)Reply

Schade. Nach Extensions habe ich schon geschaut. Ich dachte das könnte ein netter Bonus zum Thema DSGVO sein ;) Yukii (talk) 12:31, 12 April 2018 (UTC)Reply

Hey Ho :D Jetzt hab ich noch mal ne andere Frage... Wie Fit bist du den was .htaccess und MediaWiki angeht? Ich glaub ich mach da irgendwas Falsch... Ich zweifle schon an mir selbst xD Yukii (talk) 17:39, 30 April 2018 (UTC)Reply

Hilfe mit DPL benötigt[edit]

Servus Theaitetos,

ich hoffe dir gehts gut trotz der ganzen Corona-Geschichte.

Ich habe hier eine sehr verzwacktes Problem und ich weiß nicht weiter... Vielleicht kannst du mir ja einen schritt weiter helfen. Ich versuche derzeit das hier an dieser Stelle nachzubauen. Zum Verständnis für dich: Das sind Gegenstände die an die jeweiligen Orten Geernten, Abgeholzt oder Abgebaut werden können. Dadurch tauchen die natürlich an vielen stellen auf.

Problem:

  • Wenn der Gegenstand, sowie die Erdscherbe auf dem Bild, an mehreren Orten erscheint, würde ich das gerne Zusammenfassen und vermeiden das der gleiche Gegenstand mehrfach aufgelistet wird, so wie jetzt. Ich weiß nur nicht wie...

Viele grüße Yukii (talk) 10:37, 28 September 2020 (UTC)Reply

DPL and MW 1.35[edit]

Hello Theaitetos, Hi, I'm not exactly sure the best way to get in contact with the team working on DPL2 and DPL3 (I see you listed on both, and several overlapping members on each extension's page). At current both DPL2/third-party and DPL3 have been flagged as incompatible with MediaWiki 1.35 (LTS) due to lack of actor support (see: T267824 and T6402), causing database errors and as such has been flagged as incompatible on the extension page and not recommended for use on production wikis. We decided to switch back to DPL2 from DPL3 for testing, then discovered that DPL built-in variables also no longer work in surrogate/phantom templates under MediaWiki 1.35. We get the literal text output for the %PAGE% and other built-in variables, instead of the value of those variables as documented. We rely fairly heavily on surrogate/phantom templates to retrieve template parameter values, in combination with built-in dpl variables and parser functions and I see on wikiapiary there are about 600 wiki currently using DPL2/3. We're trying to determine if we need to stay at 3.33, or downgrade to 3.31 LTS in lieu of the current LTS not being supported. Is there any way that users can donate to the project in the hopes of an update for compatibility with the current release of MediaWiki? Or can someone lend insight as to if there are plans to continue maintaining the extension? Thanks! TiltedCerebellum (talk) 08:47, 14 November 2020 (UTC)Reply

Hello TiltedCerebellum, sorry for the late reply, but I haven't had any interest in maintaining this extension ever since the Wikimedia Foundation decided to mess with it. DPL2 has always been a private project, but none of my predecessors nor myself have any time to maintain it. DPL3 just lists me as it is built upon DPL2. If I recall correctly, Alexia Smith rewrote the extension on behalf of a corporation or has some corporate backing for her maintenance activity, so you should ask her whether she keeps DPL3 up to date. --Theaitetos (talk) 17:32, 15 November 2021 (UTC)Reply
Or better yet, Universal Omega (talk · contribs) (as long as he has the time to look into it). Although still active on GitHub, Alexia E. Smith (talk · contribs) bowed out of the MediaWiki sphere last northern fall (just as DPL3's actor migration issues at the time were starting to become largely apparent). The Gamepedia/HydraWiki team (whom she was once part of) moved to Fandom in December 2018, and updates across their suite of extensions have dwindled down to the point of sparseness or nonexistence since then. --Slgrandson (talk) 22:10, 1 December 2021 (UTC)Reply
Oh, they're inactive now as well? Guess that's how things are, thx for the info, Slgrandson. --Theaitetos (talk) 07:01, 2 December 2021 (UTC)Reply