Wikipedia Diskussion:Technik/Skin/JS

In diesen Diskussionen werden die Inhalte dieser Projektseite besprochen. Anfragen zu Problemen mit den eigenen JavaScript-Vorhaben bitte in der Werkstatt stellen.

Zum Geleit

Diese Projektseite wurde gestiftet aus der damaligen Version von Benutzer:PerfektesChaos/js/Infos RevID=90144599.

--PerfektesChaos 19:16, 26. Jun. 2011 (CEST)

Secure Server

Allerdings erfolgt der tatsächliche Abruf über das Netz vom Server nur gelegentlich, nämlich wenn sich die Skript-Quelle geändert hat oder der Browser-Cache geleert wurde bzw. turnusmäßig verfällt. – Meine Erinnerung und eine kurze Google-Suche behaupten, dass das nicht in allen Browsern so uneingeschränkt stimmt. Hat irgendwer genauere Ahnung, welche Browser Caching-Angaben bei https ignorieren, also durchaus spürbar langsamer werden könnten? --Schnark 12:20, 30. Jun. 2011 (CEST)

Na, die Würze liegt im „turnusmäßig verfällt“. Die Cache-Empfehlungen, die ein Server mitverschickt, mögen durchaus ignoriert werden. Entscheidend ist, nach welchen Regeln der Browser sich sein Cache management organisiert. Wiki-Server schicken ja standardmäßig nicht allzuviel an Cache-Empfehlungen mit. Es kann sein, dass besonders vorsichtige Browser bei jedem Zugriff einen HEAD request machen, der zwar die Aktualität verifiziert, aber das Skript nicht neu überträgt. --PerfektesChaos 13:09, 30. Jun. 2011 (CEST)

Hab es gerade mit Live HTTP Headers überprüft, bis auf den eigentlichen HTML-Quelltext wird (zumindest in Firefox) wirklich alles ordentlich gecached. Falls du meine Änderung, die ich gerade gemacht habe, nachvollziehen willst, kann ich dir eigentlich nicht einmal mein Diff-Skript empfehlen, obwohl das zumindest halbwegs zeigt, was sich verändert hat. --Schnark 09:44, 1. Jul. 2011 (CEST)

Zu https:

• Hatte zwischenzeitlich tiefer in diesem Bereich involvierten Kollegen kontaktiert. https sagt ja erst mal nur etwas über TLS, also sicheren Transport, und nicht mal über ein Zertifikat. Richtig ist, dass Browser wenigstens auf einer https-Ressource die no-store und no-cache sorgfältig beachten sollen. Server-Info-Anbieter sollen diejenigen Teile ihrer ausgelieferten Rückmeldungen, die sensible Daten enthalten, mit no-store und/oder no-cache kennzeichnen. Beim Kontoauszug wäre also der Rumpf mit den aktuellen Zahlen zu schützen; das Logo, Werbebanner und dergleichen nicht und verweilen ganz normal im Cache.
• Ich arbeite seit Jahren regelmäßig bevorzugt mit https, so auch alle Wiki-Aktivitäten. Dass meine Skripte automatisch jedes Mal neu vom Server geladen würden, wäre mir aufgefallen.
• Aus dem Alltagsgebrauch kann ich mich zu FF und IE äußern; zu Opera, Safari, Chrome hätte gelegentlich mal jemand beiläufig etwas erwähnt haben müssen.
• Offizielle Dokumente und Standards mit dieser These gibt es offenbar nicht. Richtig ist, dass Google aus diversen Foren solche Bemerkungen fischt.

Zu Skin/JS:

• Kein Problem; befindet sich im Transformationsprozess von meiner Tipp-Sammlung zu einer kleinen Anleitung für Einsteiger in die Thematik. Dazu wird sicher in der Reihenfolge noch zu sortieren und der Einstieg weicher zu gestalten sein. Am Wochenende schaue ich nochmal detaillierter rein. Dabei ziehe ich menschliche Beschränktheit der künstlichen Intelligenz eines Diff-Algorithmus vor.

LG --PerfektesChaos 10:22, 1. Jul. 2011 (CEST)

Habe soeben im IE die mutmaßliche Quelle des Gerüchtes in den Foren gefunden. Es gibt im IE eine Einstellung Verschlüsselte Seiten nicht auf dem Datenträger speichern – Vorgabe (IE8): "Seiten speichern". --PerfektesChaos 17:53, 3. Jul. 2011 (CEST)

Unterseiten ausgliedern

Das Baby hier ist im letzten halben Jahr ganz schön fett geworden. Ich plane die Ausgliederung von

• /Variablen
• /mw
• /WikEd (mit WP:WikEd will ich mich nicht gemein machen)

RFC --PerfektesChaos 23:18, 13. Nov. 2011 (CET)

Klingt gut. Ich gehe mal davon aus, mit /mw meinst du die mediaWiki.-Api? Oder gleich alles inklusive Spezialseiten-Plugins und deprecations (wikibits.js)?

Was mir zu dem ganzen noch fehlt ist ein wenig Einführung für absolute Beginners: „Mir gefällt was nicht, ich möchte das ändern“. Wo schaue ich nach, was es schon gibt? Was mache ich mit js, css, beidem? Was ist mir js, css, beidem möglich? Wie fange ich an? Soll ich dafür eine neue Technik-, Technik/Skin- Unterseite anfangen? -- ✓ ^Bergi 13:22, 14. Nov. 2011 (CET)

1. /mw meint: deutschsprachige Doku zum mw.-Objekt, also API. Das wäre ein zusammenhängendes Sammelgebiet und thematisch geschlossen auf einer Unterseite darstellbar.
2. In 2011 ist es noch etwas früh, aber im Laufe des Jahres 2012 käme eine Unterseite /Veraltet in Frage, auf der mindestens zu Referenz- und Kompatibilitätszwecken von wikibits bis dontcountme bisherige Praktiken dokumentiert bleiben.
3. Eine Art Technik/Skin/Tutorial für desorientierte Einsteiger wäre eine gute Idee. Momentan wird schon eine gewisse Strategie als bekannt vorausgesetzt: Mache ich es mit CSS, brauche ich JS, muss ich mich mit der GUI befassen, reicht ein Häkchen bei den Helferlein, könnte es ein Benutzerskript sein oder etwas vom Toolserver?

Beste Grüße --PerfektesChaos 09:58, 15. Nov. 2011 (CET)

/mw + /Variablen – dies wär’ der erste Streich. Shortcuts okay? --PerfektesChaos 22:05, 29. Nov. 2011 (CET)

Testen vor dem Speichern

„Nur im Edit-Fall ließe sich zumindest eine Funktion an die Veränderung des Textfeldes binden.“

Wie ist das zu verstehen? --Seth Cohen (Diskussion) 18:11, 16. Sep. 2012 (CEST)

Vielleicht möchtest du, dass beim Editieren eines JS-Quellcodes automatisch irgendwas passiert; etwa weil der Text sich in bestimmter Weise geändert hat. Oder du möchtest gar den JS-Quellcode automatisiert verändern. Das geht, wenn überhaupt, nur nach dem Öffnen zum Bearbeiten – vielleicht ist das sogar ein Versehen und soll auch nicht sein. Auf submit hin (nach Vorschau) passiert nichts mehr aus dem Bereich der Standard-Skripte, soweit hin und wieder zu beobachten. LG --PerfektesChaos 21:03, 16. Sep. 2012 (CEST)

Jetzt hast du mich noch mehr verwirrt. ;-) --Seth Cohen 21:22, 16. Sep. 2012 (CEST)

Sorry. Nochmal: Normalerweise werden deine Standardfunktionen ausgeführt, die du in deine common.js etc. geschrieben hast. Das ist bei einer Seite mit JS-Quellcode meist weniger ergiebig. Wenn du trotzdem über deine common.js irgendwas automatisch mit dem Quellcode deines Skriptes anstellen möchtest, ginge das vermutlich maximal beim ersten Öffnen der Seite. (Ich mache gern sowas und fluche, dass es nicht geht.) Hoffentlich jetzt besser? LG --PerfektesChaos 22:07, 16. Sep. 2012 (CEST)

Ja, besser. Vielen Dank! --Seth Cohen 22:33, 16. Sep. 2012 (CEST)

Werden die wirklich nicht ausgeführt, und gilt das dann nur für die common.js? Wenn ich mein längst nicht mehr verwendetes externISBN.js zum Bearbeiten öffne, hinterher die Vorschau öffne, und anschließend die Änderungen zeigen lasse, habe ich immer – nach jeder dieser Aktionen – Wikiblame und Unsigned in den Portlet-Links. Und dass ich die dort haben möchte steht in meiner vector.js, die muss also ausgeführt worden sein. Dito stehen über Schnarks Modulverwaltung eingefügte Extras im Editor zur Verfügung etc. Ich kann keinerlei Einschränkung erkennen. Per Firebug ist ebenfalls zu sehen, dass reichlich Skripte geladen wurden. --Ivla^Disk. 22:51, 16. Sep. 2012 (CEST) P.S.:Ich finde zwar in der "Übersicht" von Firebug common.js nicht wieder, aber das von mir dort gesetzte hotcat_no_autocommit steht in allen oben genannten Bearbeitungssituationen auf 1, die wurde also verarbeitet.--Ivla^Disk. 23:23, 16. Sep. 2012 (CEST)

Es ist gut, dass ihr nachfragt; daraus ergibt sich eine Gelegenheit, mal wieder zu aktualisieren und den Stand der Dinge zu prüfen.

• Die Fußnote verweist auf 2011; MW 1.17; damals war das in der deWP wohl auch so, zurzeit nicht mehr und ich werde mir einen geeigneten Aktualisierungstext einfallen lassen.
• In der enWP war das irgendwann in diesem Frühjahr/Sommer noch wie beschrieben gewesen, im Moment nicht mehr; im testwiki: ist es weiterhin der Fall.
• Technischer Hintergrund:
  • Wenn wir die Vorschau zu einem normalen Wikitext anfordern, bekommen wir vom Server eine komplette neue HTML-Seite. Vorlagen müssen in der aktuellen Form eingebunden werden, Wikilinks sind zu klassifizieren, ob redlink oder redirect. Beim Aufbau der neuen HTML-Seite werden die Standard-Skripte common.js und vector.js ausgeführt; und nur dann.
  • Bei den CSS+JS-Seiten ist die Situation anders: Um die (nur schwarz-weiße) Vorschau zu generieren, kann der Abschnitt der HTML-Seite spontan ersetzt werden durch

    "<pre>" + escape(TEXTAREA-Inhalt) + "</pre>"

  • Man braucht also den Server nicht zu kontaktieren; die submit-Anfrage wird nicht abgeschickt. Damit bleibt in der Seite auch der ursprüngliche Inhalt des TEXTAREA zu Beginn der Bearbeitung hinterlegt. Dann kann man aber den ursprünglichen und momentanen Inhalt von TEXTAREA lokal miteinander vergleichen und nur den entsprechenden Abschnitt der HTML-Seite durch das Diffpage-Resultat ersetzen, ohne die Seite neu abzurufen.
  • Auf dem testwiki: wird auch nur der Diffpage-Abschnitt zum momentanen TEXTAREA-Inhalt vom Server abgefordert und nicht die ganze Seite.
  • Schnark und WikEd vergleichen in lokalem JavaScript den TEXTAREA-Wikitext mit der Version vom Server. Sie bauen keine neue Seite auf, könnten das ja auch nicht.
  • Irgendwo gibt es die Anregung, den diff-Algorithmus in JavaScript zu verwenden (sowas gibt es irgendwo im Web) und bei CSS+JS überhaupt nicht mehr zwischendurch mit dem Server zu kommunizieren. Sofern es keinen BK gibt, würde das völlig ausreichen.
  • Um das JS auszuführen, würde in diesem Modus ausreichen (ohne erneutes Ausführen von common.js und vector.js)

    eval(TEXTAREA-Inhalt-String)

Schöne Woche --PerfektesChaos 09:54, 17. Sep. 2012 (CEST)

importScript / importStylesheet

Angeblich sind diese noch nicht wirklich deprecated. Sollte man dies nicht erwähnen?[1] (Was sich ja auch in der ausgiebigen und ungeminderten Nutzung in den Allgemein-Scripten zeigt!?) -- ΠЄΡΉΛΙʘ 14:14, 3. Nov. 2012 (CET)

Sie sind schon allein deshalb unerwünscht, weil sie im globalen Namensraum stehen und nicht Komponenten des mw-Objekts sind.

Die Geschichte klemmt am fehlenden RL3 für Gadgets und Benutzerskripte, an dem ich seit einem Jahr keinen Fortschritt sehe.

Von der bei Einführung des RL vorgenommenen Integration der .load() unter mw.loader distanziert man sich mittlerweile. Man will sich eigentlich jetzt bei mw.loader auf RL-Modul-systematische Funktionalität beschränken. Im Raum steht eine neue Funktion mw.util.load(), die möglicherweise einmal die Funktionen von mw.loader.load(), importScript() und importStylesheet() wahrnehmen könnte und, wenn man pfiffig wäre, aus der Zeichenketten-Analyse des Arguments herauslesen könnte, ob es in eckigen Klammern steht, eine URL ist oder ein blanker pageName; man weiß auch, ob das auf .js oder .css endet (Bock, wenn weder noch).

Dass ob der unhandlichen URL die überholten Funktionen mit einfachem Seitennamen weiter benutzt werden, ist niemand zu verübeln. Gleichwohl ist das keine Grundlage für zukunftsträchtige Weiterentwicklung. Die Diskussion dort und die verlinkten Bugs sind mir geläufig; 2010/2011 tauchen Schnark und ich dort auch auf.

LG --PerfektesChaos 14:44, 3. Nov. 2012 (CET)

Ich habe mehrfach gelesen (kann ich gern raussuchen), dass ganz ausdrücklich zur Verwendung von importScript geraten und von der mw-Syntax abgeraten wird. Das würde ich deshalb auch hier beibehalten. --TMg 23:19, 12. Jan. 2013 (CET)

→ Wikipedia:Technik/Skin/JS/Obsolet #Einbindungen – da schnattert alles wild durcheinander. Du hast das immer bei genau einem MW-Beteiligten gelesen. --PerfektesChaos 23:53, 12. Jan. 2013 (CET)

Nein, sicher nicht. Die neue Syntax ist völlig unnötig verkompliziert. Warum sollte man jeden Benutzer dazu zwingen, diesen Wust in die eigene common.js zu kopieren, nur um eine Skinmodifikation zu aktivieren? importScript wird noch viele Jahre lang funktionieren, wahrscheinlich für immer. --TMg 00:53, 13. Jan. 2013 (CET)

• Niemand wird hier zu irgendwas „gezwungen“. Dreh mir bitte nicht das Wort in der Tastatur herum.
  • Umseitig steht an erster Stelle importScript(), eingeleitet mit den Worten „In der Praxis wird man hierfür“.
  • Erst an dritter Stelle kommt unter „Laden über URL“ mw.loader.load().
• Niemand tippt alles das zeichenweise über die Tastatur ein. Man holt sich sinnvollerweise mit C&P das Zeugs und schreibt seinen eigenen Benutzernamen drüber, und den Titel der eigenen Seite. Genau den gleichen Aufwand hat man auch, wenn man sich mit C&P ein Muster für importScript holt.
• Während beim Laden mit importScript erst nach 31 Tagen geprüft wird, ob die Ressource noch aktuell ist, lässt sich dies bei der URL explizit steuern. Schreibt man nur für sich allein, kann man bei Bedarf seinen persönlichen Browser-Cache selbst löschen. Bietet man ein Skript einem größeren und letztlich unübersehbaren Kreis von Benutzern an, sollte man dieses Intervall verkürzen, bis ein Bugfix auch bei den Anwendern ankommt oder ein bereits dokumentiertes neues Feature auch tatsächlich wirksam wird.
• Hinter importScript und mw.loader.load stehen unterschiedliche Implementierungen; sie sind mitnichten einfache Weiterleitungen. Während mit Einführung des asynchronen Ladens mw.loader.load zuerst klarkam, hingen ältere Implementierungen mit importScript, welches in der legacy auch nur noch notgepflegt wird.
• Dass importScript auf ewig funktionieren würden, ist Wunschdenken. Höchstens, wenn es auf Projektebene simuliert wird. Ich erinnere an die kurzfristigen Abschaltungen und Funktionsänderungen von messageBox(), mw.util.$content, jsMsg(), mw.util.jsMessage().
• Das eigentliche Ärgernis ist, dass es seit Frühjahr 2012 keinerlei Fortschritt in Sachen Einbindungen von Wiki-Ressourcen gibt, und zwar im aktuellen Zustand. Phantasiert wird von „RL2“ und „Gadgets 3.0“, tatsächlich sind weder Aktivitäten in gerrit noch in den periodischen Arbeitsberichten erkennbar. Programmierung im JavaScript-Bereich erfolgt nur, wenn es auf MW-Ebene den Server-Ressourcen hilft; was auf Projekt-Ebene oder gar auf Benutzer-Niveau passiert, ist völlig wurscht. Was da an Diskussionsbeiträgen vom Stapel gelassen wird, heißt im Klartext nur: „Wir haben keine Lust, oder keine Zeit.“ Ob die personelle Ausstattung hier reicht oder das Personal durch höhere Order mit buntem Spielkram beschäftigt wird, kann ich nicht überblicken. Aufräumen und Modernisieren und Straffen der riesenhaft angewachsenen Basis-Software ist dringend angesagt.

VG --PerfektesChaos 10:52, 13. Jan. 2013 (CET)

Bitte entschuldige, ich hatte nur deine Löschung gesehen. Im verbliebenen Text steht es nach wie vor genau so, wie ich es auch vertreten würde. Warum sich da nichts bewegt, ist mir ebenfalls ein Rätsel. Überhaupt werden mir die Prioritäten der Foundation immer unverständlicher. Da werden Funktionen eingeführt, die niemand vermisst hat, pünktlich zum geplanten Projektabschluss klopft man sich auf die Schultern und ab da gibt es niemanden mehr, der sich um die Behebung von Bugs kümmert. --TMg 20:45, 13. Jan. 2013 (CET)

Akzeptiert und vergessen. – Clear Cache. – War was? --PerfektesChaos 20:59, 13. Jan. 2013 (CET)

Nur mal so als Gedanke zum Geschriebenen: Ist es nicht generell unsinnig, das Browsercaching an Parameter zu binden, die jeder Benutzer in seiner common/vector/monobook.js-Datei individuell wiederholen muss? Warum wird das nicht dem Skriptentwickler überlassen? Er ist der einzige, der überhaupt Änderungen auslösen und entscheiden kann, welche Änderung sofort an alle Benutzer ausgeliefert werden muss (geschlossene Sicherheitslücke) oder ob das im Laufe der nächsten paar Wochen sukzessive erfolgen kann. Wie ich anderswo so ausliefere, weiß ich. Wie mache ich das hier? --TMg 18:19, 16. Jan. 2013 (CET)

• Wie mache ich das hier? – Kurz: Zurzeit überhaupt nicht.
• Für eingebundene Ressourcen gelten auf einer Wikipedia 30 Tage zulässiges Alter (2592000 Sekunden); teils 31 Tage. Das betrifft allgemein JS, CSS; Thumbnails teilweise unbegrenzt.
• Einige zentrale Gestaltungselemente sind an die MW-Unterversion gebunden.
• Für die weltweit zentral angebotenen Ressourcen JS+CSS bei bits.mediawiki.org gilt eine Maximalspanne von 10 bzw. 300 Sekunden, die der ResourceLoader garantiert.
• Darunter fallen auch die projektweiten Standard-Ressourcen Mediawiki:Common.* und Skin dazu.
• Alle anderen projektweiten Mediawiki:*.js und .css benötigen den genannten Monat, bis sich ein Bugfix oder ein neues Feature herumspricht.
• Um dies zu lösen, ist unter dem Arbeitstitel „RL2“ auch ein neuer kleiner Namensraum Gadget: angedacht. Vor knapp einem Jahr war hier die letzte Zuckung zu beobachten.
• Für Benutzerskripte gibt es das Schlagwort „Gadget 3.0“, das jedoch nicht durch irgendeine Art von Konzept unterfüttert ist, geschweige denn eine Implementierung.
• Wenn überhaupt, dann hat sich die Seite geändert, und die Anwender bekommen eine neue Version, Ende. Ein bisschen schwanger, und dann könnte man manche Änderungen sofort den Benutzern ausliefern, oder vielleicht erst morgen oder nächste Woche – das ist zu kompliziert und unnötig.
• Eine Möglichkeit, stunden- oder minutengenau die Aktualität eingebundener Ressourcen sicherzustellen, bietet versionControl.
• Für anwendende Benutzer ist es egal. Sie tippen die URL nicht auf der Tastatur ein, sondern übernehmen mit C&P die vom Anbieter dargestellten Einbindungszeilen, fertig. Dort steht dann halt ein maxage mit drin, so dass nach einem Tag mal unauffällig nachgeguckt werden kann, ob die Seite noch aktuell ist.

--PerfektesChaos 21:28, 16. Jan. 2013 (CET)

Hinweis: [BREAKING CHANGE] Deprecated JavaScript methods to be removed in MediaWiki 1.25

Damit es möglichst viele Lesen, hier ein wichtiger Hinweis für alle JavaScript-Programmierer: [BREAKING CHANGE] Deprecated JavaScript methods to be removed in MediaWiki 1.25. — Raymond ^Disk. 18:08, 21. Sep. 2014 (CEST)

6.2 Bösartige Wiki-Seiten: unbemerkt fehlerhaft oder beabsichtigt böswillig

In: Absatz 1, Zeile 1 ist beim ersten Lesen nicht sofort offensichtlich, ob das Wort "unbemerkt" alleine steht xoder zusammen mit "fehlerhaft" gemeint ist, sowie ob sich "unbemerkt": nur auf "fehlerhaft" oder auch auf "beabsichtigt" bezieht. Erst nach ein wenig Überlegen wurde es mir klar. Deshalb mein Vorschlag: "unbemerkt fehlerhaft" und "beabsichtigt böswillig" jeweils in Anführungszeichen zu setzen, damit es "von Anfang an / sofort / ohne langes Überlegen müssen" klar ist, wie diese Wörter zusammengehören. --77.4.143.247 07:10, 19. Jan. 2019 (CET)

Das Problem verstehe ich. Danke für den Hinweis.

Die Lösung mit den Anführungszeichen gefällt mir weniger.

Ich denke eher an eine Aufteilung in zwei Sätze und habe das jetzt hoffentlich klarer formuliert.

Die Lesart war gewesen: unbemerkt {fehlerhafte OR beabsichtigt böswillige} Aktionen

VG --PerfektesChaos 18:04, 19. Jan. 2019 (CET)