Aloha ;)

Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus.

Von „gut funktionierend“ ist der Mechanismus weit entfernt (zumal es kein „Mechanismus“ ist), denn das wird einem so nicht vermittelt. Das heißt, ich hätte meine Änderung einfach machen und darauf vertrauen sollen, dass ein Berechtigter die Änderung zeitnah(!!) ins Beispiel übernimmt‽ Woher soll man’s wissen?

Da hast du Recht; das sollte besser kommuniziert werden, um Autoren mehr Sicherheit zu geben. Vielleicht kann auf die Editierungs-Seite ein entsprechender Hinweis?

Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?

Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus.

?? Was hat das mit den Beispielcodes zu tun? Die Problematik besteht auch für die Texte im Wiki.

Nein. Die Problematik besteht für die Texte im Wiki weniger, da Vandalismus auf statischen Beispiel-Seiten größere Auswirkungen hat als auf Wiki-Seiten, die durch die Wiki-Software gehen. Für die Texte im Wiki (und das, was im BeispielCode steht) hat ein Vandalismus so wenig schlimme Folgen, dass es (beim aktuellen Umfang an Änderungen) ausreicht, Vandalismus zu reparieren statt präventiv dagegen vorzugehen. Für die statischen Beispielseiten gilt das nicht im gleichen Maße.

Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen

Ja, man begibt sich in eine Abhängigkeit. Was wenn CodePen morgen ankündigt, übermorgen dicht zu machen?

Ich halte die anderen beiden Argumente, die ich beispielhaft gebracht habe, für stärker, aber ja.

Vorteil wäre: fremder Code läuft in einer Sandbox, CodePen hat sich darum schon gekümmert.

Auch wenn du Recht hast - inwiefern ist das ein Vorteil gegenüber der bisherigen Lösung, die durch manuelle Kontrolle durch ausgewählte Benutzer auch verhindert, dass schädliche Inhalte ausgeführt werden?

und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut

Bullshit.

Naja. Ich sehe die Eigenschaften, die CodePen (einfach so) als Alternative zum bisherigen Mechanismus auszeichnet, nicht. CodePen lässt sich vielleicht als Alternative zu frickle handeln, aber eine Verwendung von CodePen löst die Probleme, die dazu führen, dass statische Beispielseiten im Moment nur eingeschränkt bearbeitbar sind, nicht, und ist demnach dazu auch keine echte Alternative - wenn-dann müsste man hier über einen Sichtungsmechanismus als Alternative nachdenken, gerne auch zusätzlich zum CodePen-Vorschlag, aber CodePen alleine löst gar nichts. Deshalb meine Vermutung eines Nebenkriegsschauplatz von frickle vs. CodePen. Selbst wenn die Unterstellung vielleicht nicht zutrifft bleibt trotzdem das Problem, dass CodePen alleine keine ausreichende Alternative darstellt.

Grüße,

RIDER