SELFHTML Diskussion:Wiki/Mitarbeit FAQ

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Hinweis

Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.
  • Deshalb sollten Diskussionen über den Artikel zum Thema „Mitarbeit FAQ“ besser im SELFHTML-Forum geführt werden.
  • Unter https://forum.selfhtml.org/meta/new kannst du einen entsprechenden Beitrag erstellen.
  • Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

[Bearbeiten] Klickbare Beispiele

Moin.

Wegen der klickbaren Beispiele, die ja im Moment noch nicht funktionieren, habe ich heute früh bei mir lokal* eine quick-and-dirty-Lösung gefunden. Benötigt wird dazu:

Die erste Extension ermöglicht HTML-Code im MediaWiki-Namensraum (und nur dort, also nur für Administratoren editierbar ... was ja wegen crosssitescripting und so unabdingbar ist). Die erstellten HTML/CSS/JS-Schnipsel lassen sich ähnlich wie Vorlagen in Seiten einbauen ({{#rawmsg:foo}} spuckt das „rawHTML“ der Seite MediaWiki:rawmsg-foo aus).
Damit nicht für jedes Beispiel gleich zwei Seiten erstellt werden müssen (der Code auf einer MediaWiki:Seite und die Ausführung des Codes auf einer Seite in einem anderen Namensraum), habe ich für die Anzeige eine zentrale Seite angelegt (z.B. SELFHTML:Beispiele). Das ginge zwar auch per Spezialseite, aber Spezialseiten interpretieren den Parameter action nicht (s.u.). Dazu werden dann die DynamicFunctions benötigt. Mit deren Hilfe lassen sich GET-Parameter auslesen und im Wiki-Text verarbeiten. Die zentrale Beispielseite sieht dann in etwa so aus (wohlgemerkt: quick-and-dirty):

{{#if: {{#arg:id|}} | {{#rawmsg:{{#arg:id}} }} }}

Dort wird also die Seite MediaWiki:rawmsg-foo ausgeführt, wenn die URL ...&id=foo enthält. Der entsprechend Link ließe sich problemlos mittels Vorlage erzeugen und/oder in die Vorlage:Beispiel integrieren (es wäre sogar möglich, das Ganze zu Automatisieren – beispielsweise per DPL oder #ifexist, usw.):

[{{fullurl:SELFHTML:Beispiele | action=render&id={{{1|}}} }} Anzeigebeispiel: So sieht's aus]

Das action=render verhindert die Anzeige als MediaWiki-Seite und stellt (fast) nur den wirklich benötigten Code dar (Beispiel).

Nachteile:

  • Mit dieser Methode lässt sich ausschließlich HTML darstellen. Javascript und CSS kann man mit <script> oder <code> einfügen, aber PHP oder XML (insbesondere SVG und MathML) geht definitiv nicht (zumindest soweit ich das sehe).
  • Mit action=render lässt sich kein <head> oder DOCTYPE einfügen – das doofe MediaWiki macht um die ganze Seite immer ein blödes <p>...</p> und zwingt den Brauser damit zwangsläufig in den Quirks-Mode (möglicher Weise gibt es aber andere Extensions, die das können). Alternative wäre, auf das action=render zu verzichten, dann werden die Beispiele aber als MediaWiki-Seite dargestellt – mit Menue, Stylesheet, usw.
  • Die RawMsg-Extension lässt sich zwar wie eine Vorlage verwenden, sie interpretiert selbst aber leider keine Wiki-Syntax. Es lassen sich somit keine Parameter ({{#rawmsg:foo|bar}}) übergeben – schade zwar, aber erhöht die Sicherheit ungemein (sonst könnte man da auch ganz leicht Schadcode einschmuggeln).
  • Links haben in MediaWiki-Wikis grundsätzlich kein target-Attribut. Um die Beispiele in einem neuen Fenster anzeigen zu lassen, könte man das höchstens per javascript reinflanschen

So, ich hoffe, das war jetzt alles halbwegs verständlich und nicht zu verschwurbelt. Bei mir hat die Installation einschließlich der Vorlagen-Programmierung übrigens keine fünf Minuten gedauert ...

Grüße, --WiMu 10:34, 27. Mai 2010 (CEST)

*MediaWiki 1.16.0beta1 auf einem XAMPP 1.7.3 (Windoof 7) mit PHP 5.3.2 ...

P.S.: gerade erst eingefallen: vielleicht ließe sich statt einer Zentralen Beispielseite mit diesen DynamicFunctions auch ein link zur API setzen – irgendwas mit action=expandtemplates oder so ... ist mir aber auf die Schnelle noch nicht gelungen ...

Danke erst einmal für deine Bemühungen. Ich werde mir das auf alle Fälle in nächster Zeit zu Gemüte führen. Was den Namensraum anbelangt sähe ich es sehr ungern, Mediawiki dafür zu verwenden. Besser wäre ein eigener Namensraum, dem man separate Edit-Rechte vergeben kann. --dedlfix 20:03, 27. Mai 2010 (CEST)
theoretsich ist der Namensraum ja egal, solange er sich nur von bestimmten Nutzern (z.B. Administratoren) editieren lässt. Allerdings stehen für den MediaWiki-Namensraum soweit ich weiß PHP-Funktionen zur Verfügung, die es in anderen Namensräumen nicht gibt z.B. msg('...'). Müsste man eben nachsehen, ob der code solche Funktionen verwendet (auf den ersten Blick – bin aber auch kein PHP-Profi – tut er das nicht und man müsste nur die Zeile $title = Title::newFromText('rawmsg-'.$msg, NS_MEDIAWIKI); entsprechend anpassen). Grüße, --WiMu 14:02, 1. Jun. 2010 (CEST)
Gerade die Einschränkbarkeit des Editierens macht den Namensraum nicht mehr so egal. Die erwähnten Funktionen nützen einem hauptsächlich für das Parsen und Übersetzen in andere Sprachen. Das wird für Beispiel-Code nicht benötigt, weswegen auch hierfür der Mediawiki-NS (NS = Namespace = Namensraum) keine Vorteile bringt.
Aktueller Stand auf meinem Testsystem (1.16.0b3): Ich kann beliebig separate NS anlegen (jeweils inklusive Diskussions-NS), die eigene Editier-Berechtigungen bekommen können. Der Code kann dort auf Seiten in roher Form abgelegt werden. Damit beim Anzeigen der Seiten der Code nicht vom Parser zerhackstückt wird, musste ich mir was einfallen lassen, wie ich nur zum Anzeigen ein <source lang=…>…</source> drumherum bekomme. Das hat mich schlappe zwei Tage beansprucht, die passenden Hooks ausfindig zu machen. Schwierig war das, weil die Dokumentation meist nur mit einem knappen Satz sagt, wofür der Hook gut ist. In welcher Reihenfolge und wann was konkret gehookt wird, darf man selbst rausfinden. Schwierig war das auch, weil der eingebaute Cache berücksichtigt werden muss, in dem die Seitentexte schon vorgeparst drinliegen, dazu aber ein paar Hooks fehlen und ich Workarounds evaluieren musste. Und am Ende soll die Lösung auch noch performant sein und nicht alle naselang neu parsen oder unnötige Datenbankzugriffe ausführen. Beispielcodeseiten können also nun (auf meinem Testsystem) angelegt, bearbeitet und ordentlich angesehen werden. Zudem entstand eine eigene Datei in der SELFHTML-Extension, die mit wenigen Handgriffen den Code mit passendem Content-Type in Richtung Browser ausgeben kann. Serverunabhängiger Code (HTML, CSS, JS, XML) kann damit problemlos behandelt werden. Für PHP-Code muss ich noch eine Sandbox-Lösung erarbeiten. Zumindest sollte der Code in einem eigenen Prozess/Request laufen, damit er nicht mit irgendwelchen Mediawiki-Funktionen oder -Variablen kollidiert. --dedlfix 16:53, 3. Jun. 2010 (CEST)
Das klingt ja 1.) ziemlich Klasse 2.) ganz schön kompliziert. Wenn mal alles fertig ist ... wärst du so nett, mir das script zukommen zu lassen? *neugier* (und will ja auch gerne was bei lernen) Grüße, --WiMu 23:09, 3. Jun. 2010 (CEST)
Alles fertig ist es noch lange nicht, aber schauen kann man schon mal:
Siehe im Abschnitt Anwendung: Vorlage:Beispiel und vielleicht ein etwas mehr dokubezogenes Beispiel: HTML/Textauszeichnung.
Und das ist die SELFHTML-Extension, die die Hintergrundarbeit erledigt: SELFHTML.php Dazu kommt noch die Datei, die die Beispiele anzeigt, wenn man auf den So sieht's aus klickt: example.php und die relevanten Teile aus der LocalSettings.php
Was noch fehlt: Die Sandbox-Lösung für PHP/Perl und ein halbautomatischer Übernahmemechanismus in den Beispiel-Namensraum inklusive einer wie auch immer gearteten Benachrichtigung, wenn jemand ein Beispiel im öffentlichen Namensraum geändert hat. --dedlfix 02:06, 6. Jun. 2010 (CEST)

[Bearbeiten] Klickbare Beispiele 2

Wenn ich das alles richtig verstehe, werden dedlfix oder waldi so nach und nach die Beispiele klickbar gestalten? --Matthias 19:16, 28. Sep. 2010 (CEST)

Für das Erstellen und Editieren von klickbaren Beispielen benötigt man das „Beispiel-Admin“ Recht. Wie du schon richtig erkannt hast, haben dedlfix und ich aktuell dieses Recht inne (siehe [1]). Das muss aber nicht so bleiben ;-). Die aktuellsten Informationen diesbezüglich findest du meines Wissens nach im Forum. --Waldi 20:34, 28. Sep. 2010 (CEST)
Hallo, die klickaren Beispiele, wie sie jetzt gemacht sind, finde ich als recht gut gelöst. Einzig diese Bug ist mir aufgefallen: [2]. Da sollte noch eine Abfrage auf leere Eingaben rein.
Zur Frage der halbautomatischen Übernahme - wie oben diskutiert - würde ich vorschlagen (ich weiß nicht, inwieweit ihr euch darüber schon Gedanken gemacht habt), eine Erweiterung, wie [3] oder [4] anzusehen und in example.php die jeweils geprüfte Version auszugeben (und gleichzeitig jedem Benutzer das Recht geben, im Beispiel-Namensraum zu schreiben). Gleichzeitig könnte man versuchen, eine Code-Verdoppelung durch Einbindung der Beispiele über {{Beispiel:...}} zu machen. Viele Grüße --Moejoe000 22:10, 27. Okt. 2010 (CEST)
Danke für die Fehlermeldung, ist nun korrigiert. Zum Rest kann ich noch nichts sagen, da brauch ich mal Muße, um das zu testen. --dedlfix 18:04, 28. Okt. 2010 (CEST)

[Bearbeiten] Quelltext-Anzeige reduzieren

In anderen Diskussionen wurde sich, z.B. bei den Selektoren und dort mMn zu Recht, darüber beklagt, dass klickbare Beispiele die Seite zu stark aufblähen. Es ist aus meiner Sicht auch nicht notwendig, dass immer der komplette Quelltext in der Seite erscheint. Deshalb könnte man der Vorlage Beispiel noch ein Modul spendieren z.B.:

{{Beispiel|
  {{BeispielCodeAusführbar|Hier kommt dann der komplette Quelltext rein.}}
  {{BeispielCodeSichtbar|Hier sind die nur die wichtigen Zeilen drin}}
}}
oder das Modul BeispielCode ändern
{{Beispiel|
  {{BeispielCode| sichtbarer Quelltext | auszuführender Quelltext}}
}}
Ich weiß, dass den Bösewichten weitere Möglichkeiten einräumt, z.B. etwas ganz anderen Code auszuführen, als angezeigt wird aber 1. gibts hier keine Bösewichte und 2. irgendwas müssen die Admins ja nun auch noch machen ;-)--Matthias 09:30, 6. Jul. 2010 (CEST)
Was hältst du von der Idee, den Quelltext klappbar zu gestalten? Also dass man zwischen einer reduzierten und einer vollständigen Version umschalten kann? --dedlfix 10:44, 6. Jul. 2010 (CEST)
zusätzlich ist das bestimmt keine schlechte Idee. Aber dennoch, wenn es auf der Seite um Textauszeichnung geht reicht:
Beispiel
  ...
  <h1>Überschrift 1. Ordnung</h1>
  <h2>Überschrift 2. Ordnung</h2>
  ...
oder etwas mehr und wenn der Benutzer auf "So siehts aus" klickt, soll er trotzdem ein vollständiges und valides html-Dokument geliefert bekommen.
Soweit reduziert kann man sich das Beispiel ganz sparen und auf die allgemeinen Notationsregeln von HTML verweisen, denn die wiederholten sich dann ständig, nur mit anderen Elementnamen. Der Sinn des Beispiels ist in meinen Augen auch das Element in seinem „arttypischen Lebensraum“ zu zeigen. Also etwas mehr drumherum sollte schon zu sehen sein. Und man muss es sich in seiner Gänze auf einfache Weise ansehen können und nicht erst die Quelltextansicht des Browsers bemühen müssen.
Die bisherige Dokumentation war oftmals so aufgebaut, dass das Beispiel unverzichtbar war. Nach einem kurzen Einleitungstext stand das Beispiel und anhand dessen wurden dann die Eigenschaften des besprochenen Elements erläutert. Ich sähe es lieber, wenn die Erläuterung auch ohne Beispiel auskäme und selbiges „nur Beiwerk“ darstellt.
Ich nehme die Idee auf und schau mal, was sich draus machen lässt. --dedlfix 12:44, 6. Jul. 2010 (CEST)
Das Beispiel ist nun wirklich doll eingekürzt. Deshalb vielleicht zwei Buttons: einer schaltet zwischen vollständig und reduziert um und der andere "So siehts aus". --Matthias 12:56, 6. Jul. 2010 (CEST)
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Übersicht
Index
Mitmachen
Werkzeuge
Spenden
SELFHTML