Quelltext der Seite Wikiup:Technik/Skin/JS

{{../../!header
|Text=JavaScript im Wiki-Projekt}}
Auf dieser Seite wird dargestellt, wie sich [[JavaScript]] (JS) durch Benutzer zur Programmierung in einem Wiki-Projekt einsetzen lässt.

== Einstieg ==

=== JavaScript lernen ===
Wer bereits irgendeine Programmiersprache kennt, wird mit [[JavaScript]] keine größeren Schwierigkeiten haben.

Einige Anleitungen:
{{Wikibooks|Websiteentwicklung: JavaScript|JavaScript|suffix=-}}
* [http://wiki.selfhtml.org/wiki/JavaScript SelfHTML-Wiki] (deutsch) Überblick
* [https://developer.mozilla.org/en/JavaScript/Reference Mozilla] (englisch) Detailliert; neue Entwicklungen
* [http://eloquentjavascript.net/ Eloquent Javascript] (englisch) Kursartiger Aufbau; Fokus auf Sprachstrukturen

=== Einbindung ===
[[Hilfe:Benutzer#angemeldet|Angemeldete Benutzer]] können [[../Einstellungen|Benutzer-Unterseiten mit JavaScript-Code]] anlegen.<ref>Nicht angemeldete Benutzer können [[../../Browser/Greasemonkey|Greasemonkey]] nutzen.</ref>

Schnell und einfach durch Anklicken von: [[Special:Mypage/common.js|common.js]]&nbsp;– „Gemeinsames JS aller Benutzeroberflächen“. In diese Seite die gewünschten Programmzeilen einfügen.

Wer mit mehreren [[Hilfe:Skin|Skins]] jongliert, kann zusätzlich spezifische Definitionen anlegen, etwa [[Special:Mypage/vector.js|vector.js]]. Die aktive Skin nebst einem Link zum spezifischen JS findest du unter:

* {{Hilfe/pref |rendering |Text={{int:prefs-rendering}} – Benutzeroberfläche |Hilfe=1}}

Dies wird dann anschließend an common.js aktiviert und überschreibt gleichartige Definitionen. Skin-spezifisches JS allein geht auch.

* [[Special:Mypage/common.js|Benutzer:Beispiel/common.js]] und [[Special:Mypage/common.css|Benutzer:Beispiel/common.css]] werden ggf. lokal (auf dem jeweiligen Wiki) für alle [[Hilfe:Skin|Skins]] ausgewertet.
* [[Special:Mypage/monobook.js|Benutzer:Beispiel/monobook.js]] und [[Special:Mypage/monobook.css|Benutzer:Beispiel/monobook.css]] werden ggf. lokal nur für Skin [[c:File:Power users by skin.png|Monobook]] benutzt.
Es gibt zusätzlich die Möglichkeit Konfigurationen wikiübergreifend (global) „{{int:globalcssjs-custom-css-js}}“ festzulegen.
* [[meta:Special:Mypage/global.js|m:User:Beispiel/global.js]] und [[meta:Special:Mypage/global.css|m:User:Beispiel/global.css]] (auf Meta) werden ggf. global für alle Wikimedia-Projekte und alle Skins ausgewertet.

=== {{Anker|Testen}} Testen vor dem Speichern ===
Bei einer Bearbeitung wird jedes Skript bereits ausgeführt, wenn man „Vorschau“ oder „Änderungen“ anklickt. Damit lässt sich die Funktion testen; zumindest die richtige Syntax kann überprüft werden. Wenn die Wirkung nicht auf bestimmte Seiten beschränkt ist, kann das Ergebnis getestet werden.

Wenn eine <code>.js</code>-Seite editiert wird, werden die (anderen) Standard-Skripte des Benutzers je nach aktueller Projektkonfiguration möglicherweise nur einmalig beim Öffnen zur Bearbeitung (<code>edit</code>) eingebunden; beim weiteren Bearbeiten (<code>submit</code>) nicht erneut.<ref>Das hängt mit unterschiedlichen Möglichkeiten im Fall von JS-Seiten zusammen: Um die (nur schwarz-weiße) Vorschau zu generieren, kann der Abschnitt der HTML-Seite spontan ersetzt werden durch
:: <code>"&lt;pre>" + htmlescape(TEXTAREA-Inhalt) + "&lt;/pre>"</code>
* 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.
Damit werden aber die Standard-Skripte (und ggf. weitere) nur einmalig eingebunden; spätere Änderungen daran wirken sich nicht aus, und sie werden nicht mehr aktiv ausgeführt.<br />
''Die Art der Umsetzung kann spontan und von Wiki-Projekt zu Wiki-Projekt wechseln.''</ref>

=== CodeEditor ===
Der [[../../Text/Edit/CodeEditor|CodeEditor]] bietet einen Editor für JS und CSS im Bearbeiten-Textfeld; etwa vergleichbar mit [[../../Text/Edit/wikEd|wikEd]]:
* Syntaxhighlight
* Anzeige der Zeilennummern
Seit <!-- Herbst --> 2013 wird er automatisch beim Bearbeiten der Benutzerseiten zugeschaltet, wenn der Seitenname auf <code>.js</code> (bzw.&nbsp;<code>.css</code>) endet. Seit 2014 wird auch automatisch eine Syntaxanalyse vorgenommen.

=== Test-Projekte ===
Im deutschsprachigen [http://de.wikipedia.beta.wmflabs.org/ de.wikipedia.beta] lassen sich Test-Szenarien aufbauen und sich gefahrlos und ohne andere Benutzer zu stören Seiten der deutschsprachigen Wikipedia originalgetreu simulieren. Damit kann realitätsnah, ohne echte Seiten zu beschädigen oder Versionsgeschichten aufzublähen, auch die Manipulation von Seiten oder das Verhalten bei fehlerhaftem Wikitext und Seiteninhalt erprobt werden.

Siehe dazu ausführlich [[../../Labs/Beta|WP:BETA]].

== Werkzeuge (Browser etc.) ==

Dieser Abschnitt ist mittlerweile ausgegliedert als: ''[[../../Browser/Entwicklerwerkzeuge|Technik/Browser/Entwicklerwerkzeuge]]''.

=== {{Anker|Fehlerkonsole}} Fehlermeldungen ===
Siehe ''[[../../Browser/Entwicklerwerkzeuge#Fehlerkonsole|hier]]''.

=== {{Anker|Debugging}} Fehler finden (Debugging) ===
Siehe ''[[../../Browser/Entwicklerwerkzeuge#Debugging|hier]]''.

=== {{Anker|lint}} Syntax-Analyse ===
Siehe ''[[../../Browser/Entwicklerwerkzeuge#lint|hier]]''.

=== {{Anker|run}} JavaScript eigenständig ausführen ===
Siehe ''[[../../Browser/Entwicklerwerkzeuge#run|hier]]''.

== Wiki-Seiten mit Quellcode ==

=== {{Anker|nowiki}} &lt;nowiki> in Skripten ===
Auch wenn der Inhalt dieser Seiten wie Quellcode hervorgehoben ist, wird die Wikisyntax dennoch zu Teilen beachtet. Dies hat zur Konsequenz, dass Wiki-Konstrukte im Inneren (etwa Links oder Vorlagenbeginn) erkannt werden und das Skript bei diesen Seiten also unter ''Links auf diese Seite'' aufgelistet oder gar in eine Kategorie einsortiert wird. In den meisten Fällen ist dies nicht erwünscht. Auch würde eine irgendwo enthaltene Zeichenkette <code><nowiki>~~~~</nowiki></code> zur Signatur expandiert. Aus diesem Grund empfiehlt es sich, in einer der ersten Zeilen ein auskommentiertes
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 // <nowiki>
</syntaxhighlight>
und in einer der letzten Zeilen
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 // </nowiki>
</syntaxhighlight>
zu schreiben.

Taucht irgendwo im eigenen Skript die Zeichenkette <syntaxhighlight lang="javascript" inline></nowiki></syntaxhighlight> auf, würde dies den <code>nowiki</code>-Bereich sofort beenden; das lässt sich durch Konstrukte wie <syntaxhighlight lang="javascript" inline>"</"+"nowiki>"</syntaxhighlight> verhindern.

{{Anker|WhatLinksHere}}
Manchmal ist die Interpretation des JavaScript als Wikitext jedoch erwünscht: Wenn man Skripte anderer Benutzer einbindet, so sollte man in einem Kommentar immer einen Wikilink auf die eingebundene Seite angeben, damit das einbindende Skript unter „Links auf diese Seite“ aufgelistet wird. In diesem Fall müssen die Import-Anweisungen bzw. die Kommentare mit den Wikilinks natürlich außerhalb der <code>nowiki</code>-Bereiche liegen.

=== {{Anker|redirect}} Weiterleitungsseiten ===
Die normale <code>#WEITERLEITUNG [&#91;...]]</code> ist unwirksam und würde die Ausführung der Seite verhindern.

Seit Sommer 2015 <!-- Task 35973, Task 73200, Gerrit:162491 --> wird beim [[Hilfe:Seite verschieben|Verschieben]] einer JS-Seite automatisch eine JS-Weiterleitung mittels [[#loader.load()|mw.loader.load()]] auf der bisherigen Seite generiert. Die bisherigen Verlinkungen sollten allerdings baldmöglichst aufgelöst werden, da es sonst zu merklichen Verzögerungen („Geruckel“) beim Lesen der Seiten kommen kann. Anders als bei Weiterleitungen von Wiki-Seiten, die bereits innerhalb des Servers aufgelöst werden, kommt es zu einer kompletten Runde von Netzwerk-Anfrage und Interpretation, bis die aktuellen Definitionen geladen werden können.

=== JS-Unterseiten ===
* Die Seite erhält das ''[[Wikipedia:Technik/MediaWiki/Content Model|content model]]'' <code>javascript</code> statt des sonst üblichen <code>wikitext</code>. Das hat unter anderem folgende Wirkungen:
** Vorlagen wie etwa {{Vorlage|SLA}} werden nicht expandiert dargestellt, bleiben jedoch außerhalb von [[#nowiki|nowiki-Bereichen]] wirksam.
** Bei der Seitenverschiebung wird keine Weiterleitungsseite mit <code>#REDIRECT</code> usw. angelegt. Allerdings wird seit Sommer 2015 automatisch ein Aufruf der neuen URL unter dem alten Seitennamen generiert; das verzögert die Antwort beim Benutzer durch eine zusätzliche Runde jedoch spürbar, und Einbindungen sollten dann baldmöglichst auf den neuen Seitennamen umgestellt werden.
** Der [[#CodeEditor|CodeEditor]] wird aktiviert.
** Das Vorstehende gilt seit 2018 auch für das ''content model'' <code>[[JSON]]</code>.
* Bis zu einer gewissen Maximalgröße der Seite werden die Syntaxelemente in unterschiedlichen Farben dargestellt.
* Seit Anfang 2021 werden auf Code-Seiten auch Zeilennummern angezeigt.<!-- 2021-01 Task:29531 --> 
** Eine Verlinkung auf eine bestimmte Zeile ist möglich mit dem Fragmentbezeichner <code style="white-space:nowrap">#L-1</code>, <code style="white-space:nowrap">#L-2</code>, <code style="white-space:nowrap">#L-3</code> usw.
** Ein Klick auf die Zeilennummer hebt die aktuelle Zeile hervor, und in der Adresszeile des Browsers wird die geeignete Verlinkung auf diese Zeile dargestellt.
** In aktuellen Diskussionen kann auf die momentane Version verlinkt werden.
** Weil sich der vorangehende Code im Lauf der Zeit ändern kann, wäre ggf. ein [[Hilfe:Permanentlink|PermaLink]] ratsam.
** Die Maximalgröße von Seiten mit Syntaxhervorhebung, die eine farbige Auszeichnung bei zu großen Seiten unterbindet, verhindert dann auch die Generierung der Zeilennummern.

=== Benutzerseiten ===
Für die JS-Unterseiten im Benutzernamensraum gilt:
* Sie sollten immer auf kleingeschriebenes <code>.js</code> enden, damit sie von jeder beteiligten Software sicher erkannt werden (genauso: <code>.css</code>).
* Die festgelegten Skin-spezifischen Definitionen müssen exakt so (klein) geschrieben werden wie die Skin technisch heißt. Am sichersten ist es, man generiert sie über die Einstellungen (siehe [[#Einbindung|Einbindung]]).
* Ansonsten kann Groß- und Kleinschreibung der Unterseite frei gewählt werden.
* Außer dir können nur Administratoren deine JS-Unterseite verändern, was diese jedoch nicht tun werden.
* Du kannst deine JS-Unterseite wie jede andere deiner Unterseiten löschen lassen, indem du am Anfang {{Vorlage|Löschen}} einfügst (möglichst JS-auskommentiert). Auch wenn die Vorlage nicht wie üblich dargestellt wird, funktioniert sie dennoch, sodass ein Administrator deinem Wunsch nachkommen und die Seite löschen wird.

=== {{Anker|syntaxhighlight}} Quellcode darstellen ===
Mit <code>[[Hilfe:Syntaxhighlight|&lt;syntaxhighlight>]]</code> kannst du deinen Quelltext darstellen und dabei Syntaxelemente unterscheiden, wie es auch auf dieser Seite gehandhabt wird:
<pre style="margin-left: 2em;">
 <syntaxhighlight lang="javascript">
 function meineFunktion() {
     // ...
 }
 </syntaxhighlight>
</pre>
Bis Mitte 2011 hieß das Schlüsselwort vorrangig <code>source</code> – dies wird weiterhin von der Software verstanden, sollte aber gelegentlich aktualisiert werden, weil inzwischen den menschlichen Lesern weniger vertraut.

=== {{Anker|blocker}} Blockade durch Browser-Werkzeuge ===
Siehe [[../../Browser/Ressourceneinbindung|Browser/Ressourceneinbindung]].

== Häufige Aufgaben ==

=== {{Anker|import}} Laden anderer Skripte ===
Um andere Skripte einzubinden, gibt es verschiedene Möglichkeiten, je nachdem, wo sich das einzubindende Skript befindet:

==== Laden über den Titel einer Seite ====
Der häufigste Fall besteht darin, dass man ein Skript von einer Unterseite eines bestimmten Benutzers einbinden möchte, etwa ''Benutzer:Name/skript.js''. Leider gibt es für diesen Fall keine Funktion, die in jeder Hinsicht zufriedenstellend ist.

In der Praxis wird man hierfür die Funktion <code>[[/Obsolet#importScript()|importScript]]</code> verwenden, der man als Parameter den Seitennamen übergibt:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
importScript('Benutzer:Name/skript.js'); //[[Benutzer:Name/skript.js]]
</syntaxhighlight>

Der Wikilink im JavaScript-Kommentar dient dazu, dass deine Seite über die Funktion „Links auf diese Seite“ gefunden werden kann, siehe auch [[#WhatLinksHere|oben]].

Die Funktion <code>importScript</code> gilt allerdings als „[[/Obsolet#Einbindungen|deprecated]]“ und sollte folglich in neueren Skripten nicht mehr verwendet werden. Leider gibt es (noch) keine glückliche Alternative.

==== Module auf dem Server ====
Viele häufig verwendete Skripte, darunter besonders [[jQuery]]-Plugins, können direkt vom Server geladen werden. Dazu dienen die Funktionen <code>[[/ResourceLoader#.loader.load()|mw.loader.load()]]</code> und <code>[[/ResourceLoader#.loader.using()|mw.loader.using()]]</code>. Eine Liste vorhandener Module befindet sich [[/jQuery#Standard-Module|hier]]; vollständig unter [[mw:ResourceLoader/Default modules]].

Will man beispielsweise das jQuery-Plugin <code>async</code> laden, so kann man dies mit dem Befehl <syntaxhighlight lang="javascript" inline>mw.loader.load('jquery.async');</syntaxhighlight> tun. Man kann auch mehrere Dateien gleichzeitig laden:
<syntaxhighlight lang="javascript">
mw.loader.load(['jquery.async', 'jquery.tipsy']);
</syntaxhighlight>
lädt die beiden angegebenen Module. Um bestimmten Code auszuführen, nachdem das Modul angekommen ist, verwendet man <code>mw.loader.using</code>:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
mw.loader.using('jquery.async',
                function () {
                   //dieser Code wird ausgeführt, wenn das Modul angekommen ist
                            },
                function () {
                  //dieser Code wird ausgeführt, wenn das Laden fehlschlägt
                            });
</syntaxhighlight>
Die Funktion für den Fehlerfall kann auch weggelassen werden.

==== {{Anker|loader.load()}} Laden über URL ====
Um eine JavaScript-Datei von einer bestimmten URL zu laden, wird die Funktion <code>mw.loader.load</code> verwendet.

So lädt
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
mw.loader.load("//en.wikipedia.org/w/index.php?title=User:PerfektesChaos/js/Utilities/r.js&action=raw&ctype=text/javascript");
</syntaxhighlight>
das Skript [[:en:User:PerfektesChaos/js/Utilities/r.js]] aus der englischsprachigen Wikipedia. Bei Wiki-Projekten setzt sich die URL dabei zusammen aus den [[Hilfe:URL-Parameter|Teilen]]:
* <code>title=</code> – Titel der Ressource, in URL-kodierter Form
* <code>action=raw</code> – zwingend erforderlich, weil sonst die HTML-Seite ausgeliefert wird
* <code>ctype=text/javascript</code> – zwingend erforderlich zusätzlich zum Parameter MIME-Typ (in diesem Fall der für JavaScript, bei CSS-Dateien wäre <code>ctype=text/css</code> anzugeben), weil der Server sonst den Typ <code>text/x-wiki</code> im Feld <code>Content-Type</code> des [[Hypertext Transfer Protocol|HTTP]]-[[Header]] ausliefert.
* Angaben zur [[#maxage|Mindesthaltbarkeit]] im [[Browser-Cache]]
Es ist wahlweise anzugeben:
# eine vollständige (absolute) URL; diese muss mit <code>http</code> beginnen
# eine „[[Uniform Resource Locator#Relative URL|Protokoll-relative URL]]“; diese beginnt mit <code>//</code> und „erbt“ das Protokoll (http oder https) von der momentanen Umgebung. Mittlerweile arbeiten die Wikis aber nur noch mit https, so dass gerade die sicherheitsanfälligen Skripte auch immer mit https vereinbart werden können. Für bestimmte Sicherheitsmechanismen der Browser ist es wichtig, dass hier keine Zugriffe mit einfachem http mehr erfolgen.

Die Funktion hat einen zweiten Parameter MIME-Typ. Standardwert ist <code>text/javascript</code> und kann wegfallen; bei CSS-Dateien muss aber <code>text/css</code> angegeben werden.

==== Laden mit Callback-Funktion ====
In manchen Fällen will man eine JavaScript-Datei von einer bestimmten URL laden und eine bestimmte Funktion ausführen, nachdem die Datei angekommen ist. In diesem Fall kann man <code style="white-space:nowrap;">[[/jQuery#Ajax|jQuery.getScript(''url'', ''callback'');]]</code> verwenden. Man sollte allerdings beachten, dass solche Skripte nicht aus dem Browser-Cache geladen werden können, was einerseits den Vorteil hat, dass immer die aktuelle Version verwendet wird, andererseits aber auch zu spürbaren Verzögerungen führen kann.

==== Laden von registrierten Gadgets ====
Eine sichere Methode zum Laden der aktuellen Version bietet der [[/ResourceLoader#Gadgets|ResourceLoader]]&nbsp;– vorausgesetzt, das Helferlein ist bereits für den Einsatz mit dem ResourceLoader registriert.

==== Veraltete Funktionen ====
Neben den hier vorgestellten Funktionen gibt es noch einige weitere, die aber keinerlei Vorteile bieten, vor allem <code>[[/Obsolet#importScriptURI()|importScriptURI]]</code> und <code>[[/Obsolet#includePage()|includePage]]</code>. Sie sollten im Rahmen ohnehin notwendiger Überarbeitungen bald entfernt werden.

=== {{Anker|importCSS}} Laden von CSS ===
Um CSS-Dateien einzubinden gibt es ähnliche Möglichkeiten wie für JavaScript:
* <code>[[/Obsolet#importStylesheet()|importStylesheet]]("''Benutzer:mir/Stildatei''.css");</code><br />bindet die CSS-Datei von der angegebenen Seite ein (diese Funktion ist [[/Obsolet|deprecated]])
* CSS-Datei von der angegebenen URL einbinden:
** <code>mw.loader.load("''URL''.css", "text/css");</code>
** <code>[[/Obsolet#importStylesheetURI()|importStylesheetURI]]("''URL''.css");</code> ([[/Obsolet|deprecated]])

{{Anker|addCSS}}
Über die Funktion <code style="white-space:nowrap;">[[../CSS#addCSS|mw.util.addCSS()]]</code> (veraltet: <code>appendCSS()</code> aus wikibits) kann man auch direkt CSS-Code in die Seite einfügen.

Siehe dazu ausführlich: [[../CSS#advanced|CSS – Erweiterte Möglichkeiten]].

=== {{Anker|asynchron}} Asynchrone und simultane Ausführung ===
In den ersten Jahren, bis etwa 2010, hatten Browser der Reihe nach immer nur ein Skript ausgeführt, und danach mit dem nächsten begonnen. Diese Verkettung führte zu extremen Wartezeiten, bis die Seite aufgebaut war, weil heutzutage nicht zwei oder drei Skripte abgearbeitet werden, sondern teilweise Hunderte von Komponenten.

Heutzutage versuchen die Browser, möglichst viele Skripte gleichzeitig zu starten. Muss ein Skript auf etwas warten, etwa Aufbau der Seitenstruktur (DOM) oder das Ergebnis einer API-Abfrage, dann wird die Arbeitsleistung zu einer anderen Aufgabe verlagert und nach Eintreten des ausstehenden Ereignisses auch die ursprüngliche Aktion fortgesetzt.

Für die Programmierung muss man sich heutzutage genau überlegen, von der Erfüllung welcher anderen Voraussetzungen das eigene Skript abhängig ist, ggf. auch die Bereitstellung anstoßen, und danach abwarten, bis das erfüllt worden ist.

„Synchron“ meint, dass viele Prozesse gleichzeitig abgearbeitet werden; egal, ob auf unterschiedlichen Hardware-Bauteilen oder ob die kleinen Wartezeiten zwischen Arbeitsschritten softwareseitig von anderen Prozessen ausgenutzt werden, um die Hardware optimal auszulasten. „Asynchron“ heißt das historische Verhalten, bei dem ein Skript nach dem anderen in vorhersagbarer Reihenfolge ausgeführt wird.

„Synchronisation“ heißt ein Treffpunkt, bei dem Skripte aufeinander warten, bis alle Voraussetzungen geschaffen sind, dass die Bearbeitung fortgesetzt werden kann. Die Funktionen <code>[[/ResourceLoader#.loader.using()|mw.loader.using()]]</code>, <code>[[/mw#.hook|mw.hook()]]</code> und  <code>[[#document.ready|$()]]</code> dienen genau dieser Unterstützung.

=== {{Anker|wait.ready}} Warten, bis die Seite geladen ist ===

Vor der Einführung von MediaWiki 1.17 wurde alles JavaScript am Anfang der Seite geladen, was dazu führte, dass viele Skripte erst einmal abwarten mussten, bis der Rest der Seite geladen war, denn um beispielsweise die Links auf einer Seite zu manipulieren müssen diese natürlich erst einmal vorhanden sein. Seit MediaWiki 1.17 wird JavaScript teilweise erst am Ende geladen, sodass dieses Problem nicht mehr überall auftritt. Dennoch ist es weiterhin eine gute Idee, die Ausführung von Code zu verzögern, bis die Seite geladen ist. Außerdem arbeiten moderne Browser mehrere Aufgaben parallel ab und können durchaus schon mehrere Skripte gleichzeitig ausführen, während der Aufbau des DOM noch nicht abgeschlossen worden ist.

==== {{Anker|jQuery|document.ready}} jQuery.ready ====
Insbesondere bei der Anwendung von jQuery-Funktionen auf den Seiteninhalt sollte man immer deren ''[[/jQuery#document.ready|document-ready]]''-Funktion nutzen, um die Ausführung des Codes zu verzögern:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
$(function() {
      //Code
});
</syntaxhighlight>
Statt einer anonymen Funktion kann man natürlich auch eine benannte Funktion verwenden.

Bis 2016 war auch eine gleichwirkende Funktion <code>.ready()</code> gebräuchlich; diese Form wird inzwischen nicht mehr empfohlen und sollte nach und nach umgestellt werden:<ref>[https://jquery.com/upgrade-guide/3.0/#deprecated-document-ready-handlers-other-than-jquery-function Upgrade guide Core 3.0.] jquery.com</ref>
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
jQuery(document).ready(function() {
       //Code
});
</syntaxhighlight>

==== mw.hook ====
Seit Sommer 2013 gibt es mit [[/mw#.hook|mw.hook]] eine elegante Möglichkeit, eine Referenz auf den Content zu übernehmen, die auch beim Live Preview funktioniert:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
mw.hook("wikipage.content").add(function ($content) {
   $content.find(…) //Code
});
</syntaxhighlight>
Es ist außerdem sichergestellt, dass [[/mw#.util|mw.util]] bereits geladen wurde und [[/mw#.util.$content|mw.util.$content]] zumindest einen gültigen Startwert enthält.

Wenn es sich um editierbaren Wikitext handelt (also nicht um Spezialseiten oder bloße Seitenansicht), dann ist es ratsam, nicht mehr das statische [[/mw#.util.$content|mw.util.$content]] zu verwenden, sondern den bei
[[../../MediaWiki/LivePreview|Live Preview]] oder sonstiger dynamischer Seitenvorschau aktualisierten Bereich.

==== {{Anker|OnloadHook}} Veraltete Funktionen ====
Vor der Einführung von MediaWiki 1.17 (2011) war <code>[[/Obsolet#addOnloadHook()|addOnloadHook()]]</code> die Funktion, die am häufigsten für diesen Zweck verwendet wurde. Sie führte die ihr übergebene Funktion zu dem Zeitpunkt aus, zu dem der Browser den HTML-Quelltext bis zum Ende eingelesen hatte. Inzwischen kann diese Funktion zu Problemen führen, da sie nicht mehr nur das Laden des HTML-Quelltextes abwartet, sondern auch das Laden sämtlicher darin eingebundener Bilder, etc. Dies kann das JavaScript spürbar verlangsamen. In nahezu allen Fällen kann sie ohne Probleme durch jQuery.ready ersetzt oder sogar weggelassen werden.

=== Konfigurationsvariablen auswerten ===
Eine Reihe von Parametern gibt Informationen über die MediaWiki-Installation und das Wiki-Projekt (Database) wie auch die momentane Aktion und Einzelheiten über den Artikel und Benutzer-Einstellungen. Eine Übersicht der wichtigsten Parameter ist auf der Unterseite [[/Variablen|Variablen]] aufgelistet.

=== HTML manipulieren ===

Um durch JavaScript die Seite zu verändern, kann man die üblichen Methoden zur [[Document Object Model|DOM]]-Manipulation verwenden. Alternativ stehen die Möglichkeiten von [[jQuery]] zur Verfügung. ([[/jQuery|Überblick]]; siehe auch [[../GUI|Skin/GUI]])

Für häufige Aufgaben gibt es auch spezielle Funktionen, etwa <code style="white-space:nowrap;">[[../GUI#addPortletLink|mw.util.addPortletLink()]]</code>, um einen Link in die Navigationsleiste einzufügen.

=== {{Anker|mw1.17}} Änderungen durch MediaWiki 1.17 – mw-Objekt ===

Mit Einführung von [[MediaWiki]] 1.17 im Februar 2011 sind Praktiken veraltet („deprecated“) in drei Bereichen:
* <code>[[/Obsolet#OnloadHook|addOnloadHook()]]</code> entfernen
* [[#import|Import-Funktionen]] anpassen
* [[/Variablen|Globale Variable]] durch Konfigurationsabfragen ersetzen
Das heißt: Es wird übergangsweise noch längere Zeit funktionieren, sollte aber bei neuen Skripten nicht mehr benutzt und im Zug von Überarbeitungen nach und nach aktualisiert werden.

Das mw-Objekt, das viele Hilfsfunktionen verfügbar macht, ist [[/mw|hier]] beschrieben.

=== Debug-Modus ===

In MediaWiki 1.17 neu eingeführt. In eine dynamische [[Uniform Resource Locator|URL]] (mit <code>title=</code>) wird <code>&debug=true</code> eingefügt (oder <code>?debug=true</code> an eine statische URL anhängen). Das kann explizit für die Lade-Anweisung einer Ressource erfolgen. Offenbar funktioniert dies auch für eine ganze Seite –&nbsp;etwa einen Artikel&nbsp;– und scheint sich dann auf alle „automatisch“ eingebundenen Ressourcen auszuwirken, darunter auch common.js sowie vector.js, monobook.js etc.

Im Debug-Modus unterbleibt bei Skripten und CSS das Komprimieren, was besonders beim Debuggen fehlerhafter Skripte nützlich ist.

Ab Mitte 2011 erfolgt gleichzeitig mit dem Komprimieren von JavaScript ein rudimentärer Syntax-Check, der schwere Strukturfehler meldet und das betroffene Einzelskript nicht einbindet.<!-- [[Bugzilla:28626|28626]] [[rev:91608]]) -->

Bei benutzerdefiniert geladenen Ressourcen erfolgt keine Komprimierung; langfristig sollen diese einbezogen werden.

Theoretisch könnte man in seinem Benutzerskript auch angeben:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 mw.config.set("debug", true);
 debug = true;
</syntaxhighlight>
Das hat allerdings keinerlei Folgen, weil es nicht mehr auf die bereits automatisch eingebundenen Ressourcen wirken kann.

Allerdings kann später der aktuelle Wert an die selbst importierten Ressourcen übergeben werden; um nicht immer die Versionsgeschichte belasten zu müssen, kann ein [[#Cookies|Cookie]] zum Umschalten in den Debug-Modus und zurück eingesetzt werden.<sup>[https://meta.wikimedia.org/wiki/User:Perhelion/DebugModeToggle.js [Beispiel]]</sup>

== {{Anker|cache|Cache|CACHE}} Browser-Cache ==

Eine häufige Ursache für seltsames Verhalten von Skripten und CSS-Definitionen ist, dass nicht die neuesten Versionen eingebunden sind.

Seit MediaWiki 1.17 (Anfang 2011) wird an die [[Uniform Resource Locator|URL]] der Standard-JS jedes Benutzers (<code>[[Special:Mypage/common.js|common.js]]</code> zusammen mit dem Skin-JS, etwa [[Special:Mypage/vector.js|vector.js]]) ein Zeitstempel angefügt, der die letzte Veränderung angibt. Damit wird immer die gültige Definition eingebunden; Leeren des [[Browser-Cache]] ist deshalb nicht mehr erforderlich, siehe ''[[Hilfe:Cache]]''.

Das gilt aber nicht für [[#Laden anderer Skripte|Einbindung anderer JS-Skripte]]. Hier hat jede Version die identische URL und im Browser-Cache können deshalb veraltete Versionen vorkommen; insbesondere unmittelbar nachdem man sein Nicht-Standard-Skript bearbeitet hat.

Dies gilt genau analog für CSS wie <code>[[Special:Mypage/common.css|common.css]]</code> usw.

=== {{Anker|clearCache}} Löschung von der Festplatte ===
Der auf der entsprechenden Bearbeitungs-Seite angezeigte Hinweis „Beachte: Nach dem Speichern musst du deinen Browser anweisen, die neue Version zu laden“ stimmt zwar; die weiter angegebenen Aufforderungen zum Reload sind jedoch nur begrenzt wirksam. Dieses greift nur bei Ressourcen, die unter genau diesen URL in die aktuelle Seite eingebunden worden sind. Beim angegebenen Reload würde vorrangig die folgende URL aktualisiert:
* <nowiki>https://de.wikipedia.org/wiki/Benutzer:mir/MeinSkript.js</nowiki>
Tatsächlich in die später genutzten Seiten eingebunden wird jedoch meist mit einer URL wie
* <nowiki>https://de.wikipedia.org/w/index.php?title=Benutzer:mir/MeinSkript.js&action=raw&ctype=text/javascript</nowiki>
Eher ist ein solches Reload deshalb sinnvoll auf einer Seite, in die das Skript auch eingebunden ist. Das muss nicht in jedem Namensraum und bei jeder Aktivität in gleicher Weise der Fall sein. Stehen bei der Einbindung die [[Hilfe:URL-Parameter|Parameter]] in einer anderen Reihenfolge, kommt einer hinzu oder unterscheidet sich die zulässige Groß- und Kleinschreibung, dann werden diese Varianten durch einfaches Reload nicht aktualisiert.

Sinnvoller und sicherer ist (zusätzlich):
* ''Chrome:'' Werkzeug/Schraubenschlüssel → Optionen → links: Details → Feld [Internetdaten löschen] → Häkchen mindestens bei „Cache löschen“ → Internetdaten löschen
* ''Firefox:'' [Extras] → [Einstellungen] → [Datenschutz] → [kürzlich angelegte Chronik] → Häkchen bei [Cache] (nur dort) → [Löschen]
** Frühere Versionen:<ref>[http://support.mozilla.com/de/kb/Wie%20Sie%20den%20Cache%20leeren%20k%C3%B6nnen#w_cache-leeren mozilla.com]</ref> [Extras] → [Neueste Chronik löschen] → Häkchen bei [Cache]&nbsp;(nur&nbsp;dort) → [Löschen]
* ''Internet Explorer:'' [Extras] → [Entwicklertools] → [Cache] → [Browsercache&nbsp;für&nbsp;diese&nbsp;Domain&nbsp;löschen] &nbsp; (siehe&nbsp;[[#Debugging|Debugging]])
* ''Opera:'' unter Extras → Internetspuren löschen → Individuelle Auswahl → kompletten Cache leeren

=== {{Anker|maxage}} Lebensdauer ===
Für CSS- und JS-Ressourcen von Wiki-Servern lässt sich in der URL eine Zeitdauer festlegen, während der ungeprüft die Version aus dem Cache benutzt werden soll. Nach Ablauf dieser Periode fragt der Browser beim Server nach, ob diese Version noch aktuell ist, und erhält entweder eine frischere Version oder kann die „Mindesthaltbarkeit“ um den gleichen Zeitraum verlängern:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 mw.loader.load("//de.wikipedia.org/w/index.php?title=Benutzer:mir/MeinSkript.js&action=raw&bcache=1&maxage=86400&ctype=text/javascript");
</syntaxhighlight>
Damit wird das „[[Browser-Cache#Ablaufdatum|Verfallsdatum]]“ auf <code>86400</code> Sekunden (ein Tag) für den Browser-Cache gesetzt<!--; für mögliche [[Proxy (Rechnernetz)|Proxy-Server]] sind es <code>21600</code> Sekunden (sechs Stunden)-->.

Standardmäßig wird sonst verwendet:
* <code>2678400</code> Sekunden (31 Tage) für den Browser; zeitweilig aber auch <code>0</code> Sekunden.
Der ResourceLoader generiert bei jeder abgerufenen Seite neue (unterschiedliche) URL für die Ressourcen, wenn diese sich geändert haben, und ist deshalb nicht auf das Cache-Management angewiesen. Trotzdem sind hier in [[mw:Manual:$wgResourceLoaderMaxage|$wgResourceLoaderMaxage]] Zeiträume festgelegt.

Um einen Bug im Internet Explorer (IE6) zu umgehen, der den letzten Teil einer URL als „[[Dateinamenserweiterung|Datei-Endung]]“ interpretiert, kann man vorsorglich das funktionslose <code>&*</code> zum Schluss anhängen. Weil <code>*</code> keine Dateiendung sein kann, kommt es auch im Internet Explorer nicht zu Seltsamkeiten.<!-- resources/mediawiki/mediawiki.js#l1096 -->

== {{Anker|security}} Sicherheitsaspekte ==

=== {{Anker|https}} Verschlüsselte Verbindung ===
Alle URL, mit denen Skripte eingebunden werden, sollten nunmehr ausdrücklich <code><nowiki>https://</nowiki></code> voranstellen. Ohnehin ist seit Juni 2015 keine andere Antwort mehr möglich. Sicherheitsmechanismen in Browsern könnten Ladeversuche über <code><nowiki>http://</nowiki></code> unterbinden; alle durch JS generierten Ressourcen-Einbindungen und WMF-Verlinkungen müssen ebenfalls mittels https erfolgen. Die teilweise bisher eingesetzten protokoll-relativen URL führen auch zu keinem anderen Ergebnis mehr.

Stellt man ohnehin die Einbindungen um auf [[#loader.load()|loader.load()]], kann gleich als URL benutzt werden: <nowiki>https://de.wikipedia.org/</nowiki>…

Erfolgen asynchrone API-Abfragen („Ajax“), werden sie aus Sicherheitsgründen nicht ausgeführt, wenn die Domain (de.wikipedia.org) nicht übereinstimmt; aber auch, wenn das Schema (http und https) nicht identisch ist&nbsp;– insbesondere darf eine Seite unter https keine Ajax-Inhalte unter http akzeptieren.

=== {{Anker|malicious}} Bösartige Wiki-Seiten und Skripte ===
Durch seine eingebundenen Skripte kann man unbemerkt fehlerhafte Aktionen im Namen seines WMF-Benutzerkontos ausführen. Insbesondere könnten böswillige Programmierer absichtlich Nebeneffekte in Skripten verstecken. Das wäre besonders interessant, wenn der momentane Benutzer über Administratorrechte oder mehr verfügt. Es muss noch nicht einmal vom Skript-Autor in JavaScript programmiert worden sein; es kann auch etwa auf einer besuchten Wiki-Seite ein Injection-[[Exploit]] verborgen sein. Neben wirksamen Aktivitäten, die irgendwann bemerkt werden und repariert werden können, ist auch das verdeckte Ausspähen möglich&nbsp;– von persönlichen und WMF-Informationen, die nicht öffentlich sichtbar sein sollen. Besonders einfach: Die E-Mail-Adresse oder schon die Zuordnung zwischen IP-Adresse und Wiki-Benutzer und Browser-Profil; auch ein Tracking sämtlicher besuchter Wiki-Seiten.

Normalerweise sind Klicks auf eine externe Website ungefährlich. Sowohl die Wiki-Software wie auch die gängigen Sicherheitseinstellungen der Browser verhindern [[Cross-Site Scripting]] (im weiteren Sinne) recht zuverlässig. Skripte beim angemeldeten Benutzer unterlaufen jedoch die bei der Darstellung von Wiki-Seiten erfolgte Abschirmung.

=== {{Anker|badlink}} Verlinkung ===
Die größte Sicherheitslücke, die von gutwilligen Programmierern geöffnet werden kann, entsteht durch Verlinkung (Weblink). Erst ein aktiver Klick des Benutzers auf ein Link ermöglicht die Verbindung mit der Außenwelt, während sonstige Skript-Aktivitäten durch das Sicherheitskonzept der Browser begrenzt werden.

Allgemein ist es für die Funktionalität von Links etwa auf Wiki-Seiten sinnvoll, Sonderzeichen in der [[Uniform Resource Locator|URL]] korrekt zu kodieren ([[URL-Encoding]]). Besonders wichtig ist dies aber unter Sicherheitsaspekten für die beiden Zeichenketten-Begrenzer <code>'</code> und&nbsp;<code>"</code>, weil sie eine andere Interpretation des Links ermöglichen. Wenn man die auf einer Seite oder im Ergebnis einer API-Abfrage gefundenen Zeichenketten durch das Skript in Links (auch Bild-Einbindungen) einbaut, muss sorgfältig programmiert werden.

Die aktuellen JavaScript-Standardfunktionen leisten dies nicht:
* <code>encodeURI()</code> (nur <code>"</code>)
* <code>encodeURIComponent()</code> (nur <code>"</code>)
Mit [[/Encoding|unseren eigenen Funktionen]] werden dagegen auch <code>'</code> unschädlich gemacht:
* <code>escape()</code> (veraltete JavaScript-Standardfunktion)
* <code>[[/mw#.util|mw.util.rawUrlencode()]]</code>
* <code>[[/mw#.util|mw.util.wikiUrlencode()]]</code>
* <code>[[/mw#.util|mw.util.getUrl()]]</code>

<div style="margin-left:2em;">
''Beispiel:'' Ein Skript könnte etwa einen Link zu Benutzerseiten erzeugen mit dem Code
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 var html = '<a href="/wiki/' + benutzer + '">Benutzerseite</a>'; //FALSCH!
</syntaxhighlight>
Wäre der Benutzer, auf dessen Seite verlinkt wird, nun aber [[Benutzer:X" onclick="alert('XSS');" title="y]], so würde der folgende HTML-Code erzeugt:
<syntaxhighlight lang="html4strict" style="border: none; padding: 0; margin-left: 2em;">
 <a href="/wiki/Benutzer:X" onclick="alert('XSS');" title="y">Benutzerseite</a>
</syntaxhighlight>
Beim Anklicken würde der eingeschleuste JavaScript-Code ausgeführt.

Der Code zur Link-Erzeugung sollte daher besser lauten:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 var html = mw.html.element( 'a', {href: mw.util.getUrl( benutzer )}, 'Benutzerseite' );
</syntaxhighlight>
</div><!-- Beispiel -->

=== {{Anker|evil-eval}} eval-Funktion ===
Mit der <code>eval</code>-Funktion (JavaScript-Standardfunktion) lässt sich eine beliebige Zeichenkette als JavaScript-Code auswerten. Diese Funktion sollte nur im begründeten Ausnahmefall benutzt werden. Wenn überhaupt, muss die Zeichenkette (die aus einer Wiki-Seite stammen mag) vorher auf unerwartete JavaScript-Syntax analysiert werden: Die beiden
Zeichenketten-Begrenzer&nbsp;<code>'"</code>, die Klammern&nbsp;<code>{}</code> und das Semikolon&nbsp;<code>;</code> dürfen nicht im importierten Text enthalten sein; möglichst auch nicht die Klammern&nbsp;<code>()</code>.

== URL kodieren ==
Siehe dazu ausführlich unter [[/Encoding|Encoding]].

== {{Anker|depend}} Abhängigkeit mehrerer Skripte ==
Bis Sommer 2011 wurden Skripte, die nacheinander eingebunden wurden, auch eines nach dem anderen geladen. Angenommen, es wurde vereinbart:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 importScript("Benutzer:Mir/allerlei.js");
 importScript("Benutzer:Mir/braucht1.js");
</syntaxhighlight>
Dann waren bei der Ausführung von braucht1.js die Definitionen in allerlei.js bekannt.

Mit Firefox 3.6.20 und später sowie Google Chrome werden Ressourcen aber nicht mehr nacheinander geladen, sondern das Laden wird praktisch gleichzeitig initiiert. So wird von modernen Browsern ein schnellerer Seitenaufbau bezweckt. Damit sind in braucht1.js die Funktionen von allerlei.js aber nicht verfügbar.

Nachfolgend werden Alternativlösungen vorgestellt. Dabei sind: Mir=Benutzername, allerlei.js=Skriptbibliothek mit Hilfsfunktionen, braucht1.js=Anwendungsskript, allerlei_init=irgendeine Funktion oder Variable, die in allerlei.js definiert wird.

=== Explizites Callback ===
In Benutzer:Mir/allerlei.js als letzte Zeilen:
<syntaxhighlight lang="javascript" style="margin-left:2em">
 var i;
 if ( typeof window.allerlei_callbacks === "object" ) {
    for ( i = 0;  i < window.allerlei_callbacks.length;  i++ ) {
       window.allerlei_callbacks[i]();
    }
 }
</syntaxhighlight>
und in Benutzer:Mir/braucht1.js zum Aufruf der Funktion braucht1_tuwas(), die Funktionen aus allerlei.js benötigt:
<syntaxhighlight lang="javascript" style="margin-left:2em">
 if ( typeof allerlei_init === "undefined" ) {
    if ( typeof window.allerlei_callbacks === "undefined" ) {
       window.allerlei_callbacks = [ braucht1_tuwas ];
       mw.loader.load("https://de.wikipedia.org/w/index.php?title=User:Mir/allerlei.js&action=raw&ctype=text/javascript");
    } else {
         window.allerlei_callbacks.concat([ braucht1_tuwas ]);
    }
 } else {
    window.braucht1_tuwas();
 }
</syntaxhighlight>
Das berücksichtigt auch, dass mehrere Skripte gleichzeitig allerlei.js benötigen könnten. Dies funktioniert auch in anderen Umgebungen; benötigt eine globale Variable <code>allerlei_callbacks</code>.

=== jQuery-Event ===
2011 sind auf Wiki-Seiten viele jQuery-Methoden vorhanden. Mit [[/jQuery#Ereignisse (Events)|jQuery().trigger()]] und [[/jQuery#Ereignisse (Events)|jQuery().bind()]] lässt sich dies alternativ formulieren; am Ende von allerlei.js:<!-- credits 2 Schnark: -->
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 jQuery(document).trigger('loadWikiScript', ['Mir/allerlei']);
</syntaxhighlight>
und in braucht1.js:
<syntaxhighlight lang="javascript" style="border: none; padding: 0; margin-left: 2em;">
 if (typeof(allerlei_init) === "undefined") {
    jQuery(document).bind('loadWikiScript',
                          function (e, name) {
                             if (name === 'Mir/allerlei') {
                                braucht1_tuwas();
                             }
                          });
    mw.loader.load("https://de.wikipedia.org/w/index.php?title=User:Mir/allerlei.js&action=raw&ctype=text/javascript");
 } else {
    braucht1_tuwas();
 }
</syntaxhighlight>
Dabei wird von allerlei.js ein [[Ereignis (Programmierung)|Event]] vom selbst definierten Typ „loadWikiScript“ mit einem eindeutigen Identifizierer „Mir/allerlei“ ausgelöst. In braucht1.js wurde vereinbart, dass beim Auftreten dieses Ereignisses die unbenannte Funktion ausgeführt werden soll, in der bei passendem Identifizierer die zurückgestellte Funktion ausgeführt wird.

=== ResourceLoader ===
Für die Server-seitigen Skripte gibt es mit der Funktion <code>[[/ResourceLoader#.loader.using()|mw.loader.using()]]</code> des [[/ResourceLoader|ResourceLoaders]] eine hervorragende Lösung, die genau auf diese Situation abstellt.

=== TimeOut ===
Aus mehreren Gründen ist nicht zu empfehlen, ein setTimeOut() dazu zu verwenden, alle Hundertstelsekunde nachzugucken, ob das gewünschte Skript denn inzwischen geladen wurde. Es bindet Rechnerleistung beim Betrachter; läuft unbegrenzt (solange keine andere Seite geladen wird) falls das gewünschte Skript nicht geladen werden kann; eröffnet möglicherweise neue Threads, während auf dem abgestorbenen Thread noch asynchrone Ereignisse eintreffen.

== {{Anker|Adresszeile}} Aufruf über die Browser-Adresszeile ==
Genau wie <code>http://</code> kann am Beginn einer [[Uniform Resource Locator|URL]] das Pseudo-[[Uniform Resource Locator#scheme|Schema]] <code>javascript:</code> in das Browser-Adressfeld geschrieben werden. Der anschließend eingetragene JavaScript-Code wird dann ausgeführt.<ref name="noscript.allowURLBarJS" /><ref name="FF.urlbar" /><ref name="void" /> In HTML-Dokumenten hingegen kann es sein, dass aus Sicherheitsgründen der Browser die Ausführung einer Verlinkung auf <code>javascript:</code> verweigert; beim manuellen Kopieren in die Adresszeile und aus Bookmarks wird das aber wohl akzeptiert.

Dem auszuführenden Code sind sämtliche JavaScript-Funktionsdefinitionen und auch die Werte globaler Variablen bekannt, die seit dem Laden der Seite benutzt wurden. Das lässt sich für [[../GUI#Bookmarklet|Bookmarklets]] ausnutzen, indem Funktionen und Hilfsfunktionen in den eigenen Skripten auf Vorrat definiert werden, so dass die Definition des Bookmarklets kurz und knapp ausfallen kann. Eine weitere Anwendungsmöglichkeit ist der Start von Diagnostik- und testweisen Funktionen, etwa um die Wirkung eines noch nicht vorhandenen Buttons auszuprobieren.

''Beispiel:''<br />
<code>javascript:insertNormdaten()</code><br /><code>javascript:var a=3,b=4;alert(Math.sqrt(a*a+b*b))</code>

Dieses einfache Format genügt in den meisten Fällen. Bei manchen Browserversionen und in manchen Konstellationen ist es erforderlich, ein zusätzliches Funktionsformat mit runden Klammern zu gestalten:<br /><code>javascript:(var a=3,b=4;alert(Math.sqrt(a*a+b*b));)();</code><br />Andere Browser vertragen genau dies nicht.<!-- Einfach Ausprobieren. -->
<!-- &action=edit&withJS=Benutzer:x/y.js Mitte 2011 nicht in WP-Projekten, wohl aber auf Commons -->

== Cookies ==

[[HTTP-Cookie|Browser-Cookies]] lassen sich vom etwas fortgeschrittenen Benutzer einsetzen, um besondere Ziele zu erreichen:
# Es lassen sich Konfigurationen (auch vorübergehend) ändern, ohne jedesmal die Versionsgeschichte seiner common.js usw. zu belasten.
# Es lassen sich lokal im Browser Informationen abspeichern, die die Anonymität des Benutzers gefährden und nicht weltweit sichtbar sein sollen.
Mit Werkzeugen können nun die Inhalte der Cookies editiert werden, ohne die Benutzerseiten ändern zu müssen. Man kann sich aber auch eine Benutzer-Unterseite anlegen und in ihr ein kleines Formular anzeigen, das den momentanen Inhalt aller Konfigurationswerte zeigt sowie Schaltelemente zum komfortablen Ändern der Parameter.
* ''Internet Explorer:'' [Extras] → [Entwicklertools] → [Cache] → [Cookies&nbsp;ansehen] &nbsp; – ''und wie bearbeiten?''
* ''Firefox:'' Add-On, etwa [https://addons.mozilla.org/de/firefox/addon/92079/ Add&nbsp;N&nbsp;Edit&nbsp;Cookies+] und andere; im [[Firebug]] lassen sich die Werte ansehen und auch manuell ändern.

Die [[jQuery]]-Funktion <code>[[/jQuery#jquery.cookie|jQuery.cookie()]]</code> ist in Wiki-Projekten standardmäßig vorhanden und ermöglicht einfaches Lesen und Setzen der Werte.

Zu beachten ist, dass der Inhalt des ''Pfad''-Parameters des Cookies immer „<code>/</code>“ sein sollte, damit er von beliebigen Wiki-Seiten aus gelesen werden kann.

Allzu vertraulich (Passwörter) sollten die Werte nicht sein. Ein böswilliges Skript eines anderen Benutzers könnte die Information ausspähen; es hätte aber ziemliche Schwierigkeiten, diese Daten unbemerkt und spurenlos an den neugierigen Benutzer zu übermitteln. Die Wiki-Server bekommen beim Betrachten jeder Seite die gesamte Wiki-Keksdose zu sehen.

== {{Anker|Ablauf}} Wie läuft ein Benutzer-Skript im Kontext ab? ==

Für die Modifikation von Elementen einer Wikipedia-Seite war bisher die Kenntnis des Ablaufs zwingend erforderlich gewesen, weil zu unterschiedlichen Zeitpunkten Skripte und Funktionen geladen und ausgeführt wurden und der Seiteninhalt nicht von vornherein definiert ist. Inzwischen erfolgt das Laden des Benutzerskriptes am Ende der HTML-Seite; damit ist deren Inhalt bereits bekannt. Einzelheiten änderten sich möglicherweise im Verlauf des Jahres 2011. 2012/13 ist die Weiterentwicklung irgendwie zum Erliegen gekommen; die nachstehende Abfolge gibt nur das Prinzip wieder, ist aber möglicherweise weder aktuell noch zukunftssicher.

Bei verschachtelten und verzwickten Aufrufen mehrerer Skripte, die voneinander abhängen, kann eine intensivere Beschäftigung mit den zeitlichen Abläufen erforderlich sein.

# Die Wiki-Seite wird vom Benutzer aufgerufen.
# Die HTML-Seite wird in den Browser geladen.
# Der Kopfteil <code>&lt;HEAD></code>..... der HTML-Seite wird eingelesen:
# {{Anker|oldLoadPoint}} ''Früher wurde jetzt das Skript'' <code>wikibits.js</code> ''neben anderen projektweiten Skripten geladen, und alle [[/Variablen|JavaScript-Variablen]] definiert. Weiterhin wurde bereits jetzt das benutzerdefinierte Skript wie etwa'' <code>[[Special:Mypage/vector.js|vector.js]]</code> ''geladen und abgearbeitet. Dies geschieht ab 16.&nbsp;Februar 2011 zum Schluss.''
# Seit Anfang April 2011 gibt es für die Entwickler im PHP-Bereich die Möglichkeit, bestimmte Skripte bereits im Kopfbereich zu laden und auszuführen. Dies ist wichtig, wenn das Layout der noch aufzubauenden Seite grundsätzlich beeinflusst werden soll. Allerdings vergrößert sich die Zeit etwas, bis für den Leser der Seitenaufbau beginnt. Möglicherweise wird eines Tages diese Möglichkeit auch für Benutzerskripte verfügbar gemacht; das setzt zunächst ein Haupt-Benutzerskript im Kopfbereich voraus.
# Mit [[/Obsolet#importScript()|importScript]] (bzw. [[/Obsolet#importScriptURI()|importScriptURI]]) eingebundene Skripte werden im Februar 2011 an dieser Stelle eingebunden. ''Es kann sein, dass die Einbindung plötzlich nach den anderen Skripten am Ende des Dokuments erfolgt.'' Weil die Einbindung erst von den Skripten am Ende des Dokuments ausgelöst werden kann, erfolgt das Laden und die Ausführung erst nach ihnen.
# Allgemeine Wikimedia-Styles ([[Cascading Style Sheets|CSS]]) werden geladen.
# Ein eventuelles <code>[[Special:Mypage/common.css|common.css]]</code> und anschließend die zur jeweiligen Skin gehörende <code>[[Special:Mypage/vector.css|vector.css]]</code> oder <code>[[Special:Mypage/monobook.css|monobook.css]]</code> werden geladen.
# Spezifische CSS für bestimmte Hilfsmittel und Sonderfunktionen werden geladen.
# Dann wird der eigentliche HTML-Dokumenteninhalt geladen, genauer gesagt das <code>&lt;/HEAD></code> wurde erreicht und der Abschnitt <code>&lt;BODY></code>… wird gelesen. Jetzt wird die Objektkomponente <code>document</code> mit Inhalt gefüllt; bis dahin hatte sie möglicherweise den Wert <code>null</code>, zumindest waren ihre Komponenten, die das [[Document Object Model|DOM]] bilden, undefiniert oder leer.
# Nunmehr werden alle <code>&lt;div></code> und <code>&lt;form></code> gelesen und die entsprechenden Knoten im Objekt <code>document</code> definiert.
# Als letzte Elemente vor dem <code>&lt;/BODY></code> werden (ab MediaWiki&nbsp;1.17) die Skripte gelesen und gestartet:
#* Systemskripte der MediaWiki-Software
#* Gadgets ([[Spezial:Helferlein|Helferlein]])
#* Kombiniertes Benutzer-Skript, bestehend zunächst aus dem zur Skin gehörenden wie <code>[[Special:Mypage/vector.js|vector.js]]</code> oder <code>[[Special:Mypage/monobook.js|monobook.js]]</code> und anschließend dem möglicherweise vorhandenen <code>[[Special:Mypage/common.js|common.js]]</code>
#* <code>[[/mw#.user|mw.user.options]]</code> werden (in 1.17) jetzt mit Werten belegt.
#* Vom Benutzer-Skript der Skin durch [[#import|Import]]-Aufrufe von <code>mw.loader.load()</code> <!-- oder übergangsweise <code>importScript(</code>''XYZ''<code>.js)</code> --> vorgemerkte Skripte werden geladen und gestartet, wenn dies nicht über <code>$()</code> verzögert wurde.
#* Skripte können das ursprüngliche DOM verändern.
#* Auch nachträglich zugeladene CSS-Deklarationen können noch die Darstellung des Dokuments verändern. Sie werden der <code>&lt;HEAD></code>-Sektion angefügt.
# Das HTML-Element <code>&lt;/BODY></code> wird erreicht. Das Ereignis <code>DOMContentLoaded</code> wird von neueren Browsern ausgelöst.
# [[#jQuery|jQuery]] erhält jetzt den Status <code>document.ready</code>. Mit <code>$()</code> (entsprechend <code>jQuery(document).ready()</code>) vorgemerkte Funktionen werden ausgeführt. Sie können weitere Skripte [[#import|importieren]] sowie das ursprüngliche DOM verändern.
# Ressourcen des Dokuments (vor allem Bilder) werden geladen und dargestellt. Dies erfolgte möglicherweise bereits parallel mit den vorigen Prozessen. Das gesamte Dokument wird [[HTML-Rendering|dargestellt]].
# Erst nach vollständiger Darstellung aller Elemente wird von aktuellen Browsern das Ereignis <code>window.onLoad</code> ausgelöst. Frühere Browser hatten dies bereits mit dem Lesen des <code>&lt;/BODY></code> vorgenommen. Auch ein neues DOM3.load Ereignis kann aufgetreten sein.
# Mit dem völlig veralteten <code>[[/Obsolet#addOnloadHook()|addOnloadHook()]]</code> zurückgestellte Funktionen aus den Benutzer-Skripten werden möglicherweise erst jetzt geladen. Sie können weitere Skripte [[#import|importieren]]. Das Dokument kann dadurch verändert werden; es wird dann in veränderter Form dargestellt.
# Ergebnisse [[#asynchron|asynchroner Prozesse]] (etwa API-Abfragen) können noch später eintreffen und das Dokument (DOM) verändern; es wird dann in geänderter Form dargestellt.
Grundsätzlich ist es eine gute Idee, zunächst den Aufbau der für Anwender sichtbaren Seitenelemente abzuwarten und erst danach, wenn der Mensch eine halbwegs sortierte Seite präsentiert bekam, diskret im Hintergrund Kleinigkeiten zu verbessern, unsichtbare Details an unsichtbaren Untermenüs zu justieren oder auf API-Ergebnisse zu warten.

Im Zuge der Einführung von MW 1.18 im Herbst 2011 werden weitere Techniken angewendet.
* Bei Modulen auf Server-Ebene kann bestimmt werden, ob sie frühzeitig (im HEAD) oder nach dem Seitenaufbau (LoadDocument) geladen werden sollen, um nachträglichen Layoutwechsel oder aber unnötige Wartezeit zu vermeiden.
* Für Benutzer ist dies nicht unmittelbar vorhanden, kann jedoch über $() gesteuert werden.
Es ist zu erwarten, dass die Technologie auch in 2012 weiter entwickelt wird und sich Änderungen ergeben.

== {{Anker|Server}} Server-seitige Skripte ==

Automatisch eingebundene Standardskripte der deutschsprachigen Wikipedia waren bislang:
* [[MediaWiki:Common.js]]<br />(grundlegende Definitionen, gemeinsam für alle Skins)
** [{{fullurl:Spezial:Präfixindex|prefix=Common&namespace=8 }} Unterseiten] beachten.
* [{{SERVER}}{{SCRIPTPATH}}/skins-1.19/common/wikibits.js wikibits.js] (teilweise veraltend; tatsächliche Einbindung über das [[Wikipedia:Technik/Skin/JS/ResourceLoader|Modul]] <code>mediawiki.legacy.wikibits</code>)
* [{{SERVER}}{{SCRIPTPATH}}/skins-1.19/common/ajax.js ajax.js] – Einbindung über <code>legacy</code> des ResourceLoader
* [{{SERVER}}{{SCRIPTPATH}}/skins-1.5/common/ajaxwatch.js ajaxwatch.js] – Einbindung über <code>legacy</code> des ResourceLoader
* [//bits.wikimedia.org/w/extensions-1.19/FlaggedRevs/flaggedrevs.js flaggedrevs.js]
* [//bits.wikimedia.org/w/extensions-1.19/FlaggedRevs/review.js review.js]
* <code>edit.js</code> unter <code>/skins-1.19/common/</code><br />(nur beim Editieren) – ''ungültig''<br />Siehe [[/mw#.toolbar|mw.toolbar]]
Damit wurde bis Februar 2011 die Seiten-Funktionalität unterstützt. Mit Ausnahme von MediaWiki:*.js wird dies aber nach und nach durch das [[/mw|mediaWiki-Objekt]] sowie [[/jQuery#Standard-Module|jQuery]] ersetzt. Der jeweils aktuelle Stand der Einbindung muss überprüft werden. Übergangsweise werden <code>legacy</code>-Funktionen des ResourceLoader verfügbar sein (siehe auch [[mw:ResourceLoader/JavaScript Deprecations#edit.js|mw:]]).

Um historische Skripte nachvollziehen zu können, sind auch veraltete Server-Skripte aufgeführt. Sie sind teilweise noch abrufbar, werden aber nicht zwangsläufig in die Seiten eingebunden.

== Siehe auch ==

* [[../GUI|Skin/GUI]] – Einsatz von JavaScript bei der Seitengestaltung
* [[../Benutzerskripte|Skin/Benutzerskripte]]
* [[:en:Wikipedia:WikiProject User scripts/Guide|User scripts/Guide]] in der englischsprachigen Wikipedia
* [[:en:Help:Wikipedia: The Missing Manual/Customizing Wikipedia/Easier Editing with JavaScript]] in der englischsprachigen Wikipedia
* [[mw:Manual:Interface/JavaScript|JavaScript]] auf [[MediaWiki]]
* [[mw:JavaScript performance|JavaScript performance]] auf [[MediaWiki]]
* [[mw:Manual:Coding conventions/JavaScript|Coding conventions]] auf [[MediaWiki]]
* [[:en:Wikipedia:Gadget #General criteria for Gadgets]] in der englischsprachigen Wikipedia
* [[/Linkbox|Linkbox]] – zum Einfügen in die eigene Benutzerseiten

== Anmerkungen ==
<references>
<ref name="noscript.allowURLBarJS">
Vom [[NoScript]]-AddOn für Firefox wird dies aus Sicherheitsgründen standardmäßig blockiert; die Einstellung <code>noscript.allowURLBarJS</code> muss mittels <code>about:config</code> auf <code>true</code> gesetzt werden.
</ref>
<ref name="FF.urlbar">
Seit Firefox 6 ist die Eingabe von JS-Code in der URL-Adresszeile komplett deaktiviert.
Auch die Option <code>browser.urlbar.filter.javascript</code>
bleibt wirkungslos.
</ref>
<ref name="void">
Mitunter kommt es nach Aktivierung zu seltsamem Verhalten der Seite im Browser, vor allem zu ihrer fast vollständigen Leerung. In diesem Fall ist an die letzte Anweisung anzuhängen: <code>;void(0)</code>
</ref>
</references>
<noinclude>
[[Kategorie:Wikipedia:Technik/Skin/JavaScript| ]]
</noinclude>