Wikipedia Diskussion:Technik/Skin/Gadgets/watchlistMessage

Diese Seite wird wenig beobachtet.

Änderungswünsche müssen ohnehin auf Wikipedia:Technik/Skin/MediaWiki/Änderungen vorgestellt und erörtert werden.

Neue Angelegenheiten bitte primär dort vorschlagen, oder auf eine neue Angelegenheit hier hinweisen.

Technik-Werkstatt Juli 2022

Übertrag von dort:

Code-Review erbeten: watchlistMessage

Lange geplant als (erstes größeres JS-in-Wiki-)Projekt, nun anlässlich kürzlicher Diskussion auf FZW mal aufgesetzt: Neuschrieb des Codes für die Watchlist-Messages (MediaWiki:Common.js/watchlist.js) auf https://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Hgzh/watchlistMessage.js. Wesentliche Änderungen:

• generelles Update und (hoffentlich) Verbesserung der Robustheit
• Nutzung von LocalStorage anstelle von Cookies
• optionale Zuordnung der Messages zu den CentralNotice-Bannertypen, um auch auf der Beobachtungsliste Hinweise direkt ausblenden zu können, die man auch bei den CentralNotices nicht sehen möchte.

Anmerkung: Das verlinkte Skript enthält noch keine Einschränkung auf die Beobachtungsliste, möglich wäre eine spätere Einbindung als Gadget und Laden dann wie derzeit in MediaWiki:Common.js#L-22 und dort weiter oben für die uploadtools. Gruß, -- hgzh 22:08, 20. Jul. 2022 (CEST)

„LocalStorage anstelle von Cookies“ finde ich grundsätzlich gut.

• Der Gedanke kam mir auch schon mehrfach, in den letzten Tagen oder Wochen wegen WikiCon-Banner + FZW und sonst so seit Jahren.
• Bin aber völlig überlastet, vertrage Hitze nur schlecht und kann meinen vielen Baustellen keine eigenverantwortliche neue Bauruine hinzufügen. Aber wenn du das organisierst, will ich gern beitragen was ich kann.

Ich würde ein generelles per-Wiki-Optionen-Gadget separat von der Anwendung watchlist angehen.

• „enthält noch keine Einschränkung auf die Beobachtungsliste“ liest sich in der Art.
• Dabei ist wichtig, von vornherein erstmal einzuplanen, wie man die Dinger wieder loswird, weil die sonst in einem Jahrzehnt Wiki-Dasein im selben Browser kumulieren und ich habe noch meine Umgebung von 2010. Die Gesamtgröße per Domain ist limitiert.

Ich würde bei „Setzen“ des neuen „Cookies“ die Unixzeit + Haltbarkeit addieren und als Wert des Hash-Map-Objekt-Eintrages verwenden.

• Für watchlist-Message also sowas wie 50 × 86400 Sekunden plus 1713619348.
• Bei jedem Anfassen des per-Wiki-Optionen-Gadget werden alle Storage-Einträge gegen „Jetzt“ geprüft, und wenn kleiner ist dann wird dieser Eintrag eliminiert.
• Ansonsten ist es halt der Eintrag watchlist234 und wenn der einen Eintrag hat, dann ist „Ja“ und wenn kein Eintrag dann „Nein“.
• Die Prüfung ob ID bekannt lässt sich auch zuerst machen und beantworten, und die Frage was veraltet ist später parallel weitermachen. Bringt aber vermutlich keine Optimierung.
• Der Eintrag kann auch immer ein Objekt zugewiesen bekommen, mit beliebigen Komponenten frei wählbar sowie einer Komponente _expiry_ für das Verfallsdatum.
• In en:User:PerfektesChaos/js/remindErrorMessages/d.js ab Repo.first() und in anderen Gadgets habe ich sowas bereits gemacht; in diesem konkreten Fall allerdings für das gesamte Gedächtnis. Irgendwo habe ich das auch für einzelne Einträge aber vergessen wo. Hier wohl reduziert auf Zeitstempel in Minuten und Verfall nach einem Tag.

Ein Universal-per-Wiki-Optionen-merken wäre auch für andere Anwendungsfälle nutzbar, etwa die SiteNotice und auch unangemeldet.

Die Bannertypen wären unabhängig von den individuellen Ausblenden-Cookies, weil sie die Message dann immer unterdrücken und nicht ausgeblendet werden müssen.

Tückisch wird FOUC für User ohne aktiviertes JavaScript.

• Ggf. wäre spezielles CSS sinnvoll, das nach ein bis zwei Sekunden ein Banner über die Seitenüberschrift drüberblendet, und was direkt drunter jeweils noch kommt.
• Dann ruckelt es beim Einblenden nicht. Zwei Optionen anbieten: Dauerhaft Ausblenden, oder erstmal nur jetzt.
• Wer JavaScript hat, bei dem wird innerhalb dieser Sekunde das hinterlegte Wunschkonzert geprüft, und dann ggf. das Dings komplett unsichtbar gemacht.

Neben LocalStorage gäbe es noch unabhängig von Endgerät und einzelnem Browser die Möglichkeit, das auf dem Server am Benutzerkonto zu hinterlegen, Dann wird das aber (wie auch Cookies) bei jedem Seitenaufbau übers Netz geschickt und es wäre noch mehr mit Bytes zu geizen. Auch kein anonymes SiteNotice möglich.

Den BETA-Code gucke ich mir in einer der kommenden Nächte genauer an, wenn ich aus dem Backofen wieder rauskrabbele.

VG --PerfektesChaos 01:01, 21. Jul. 2022 (CEST)

Die Idee, das unabhängig von der Beobachtungliste aufzuziehen, kam mir auch, hatte ich dann aber erstmal verworfen, weil ich mir ob der Anwendungsfälle unsicher bin: Brauchen wir irgendwelche Banner auf irgendwelchen anderen Seiten außer der Beo? Es sind ja ohnehin nur wenige Anwendungsfälle und die Sitenotice gibt es schon. Man müsste das Skript auch immerzu laden und nicht nur auf einer speziellen Seite. Bei nur einer Zielseite ist auch das Aufräumen des LocalStorage schnell gemacht, dann werden einfach alle IDs rausgekickt, die nicht mehr auf der Seite angetroffen werden.

Ohne aktiviertes JS wird derzeit einfach das Banner angezeigt, ohne Ausblenden-Knopf etc. Der FOUC passiert eher andersrum, das schon bemängelte kurze Aufblitzen des Banners, aber da muss entschieden werden, ob man das auch Nicht-JS-Benutzern anbieten will oder nicht.

Lass dir ruhig etwas Zeit mit dem Angucken, ich hab grad erst mw.user.options gefunden, muss das also gar nicht, wie bisher, über die API machen. Dann wird das ganze Ding noch bissl einfacher. -- hgzh 10:41, 21. Jul. 2022 (CEST)

--PerfektesChaos 21:39, 21. Jul. 2022 (CEST)

• Performance ist unkritisch. MW schickt Tausende von Zeilen los, da kommt es auf einige sinnvolle optimierte Statements nicht an.
• Es gibt vielfache Anwendungen für LocalStorage-Optionen, siehe folgende Abschnitte.

VG --PerfektesChaos 21:39, 21. Jul. 2022 (CEST)

siteOptions

Dieses Gadget könnte ich kurzfristig aus vorhandenen Funktionen zusammenbauen; habe ich in einem Dutzend Benutzerskripte stecken und stehe im Stoff.

• Erste Frage ist, wie man die Dinger wieder loswird, weil die sonst auf ewig kumulieren. Brauchen also eingebaute Selbstzerstörung, sprich Verfallsdatum.
• Können zu jedem Schlüsselwort ein Objekt mit beliebigen Infos hinterlegen, in dem auch das Verfallsdatum mitläuft.
• hidden default für alle.
• Nach Laden initialisiert es sich, indem das LocalStorage der siteOptions abgefragt wird.
  • Wenn noch nicht vorhanden dann wird leeres Objekt generiert und gespeichert.
  • Wenn Speicherung fehlschlägt dann in diesem Browser zurzeit nicht möglich.
  • Es werden alle Komponenten geprüft ob Verfallsdatum überschritten.
  • Wenn sich was ändert wird das jetzt hinterlegt.
  • Am Ende der Initialisierung gibt es ein Objekt aller Einträge oder einen Passiv-Status, und es wird auf mw.hook() gewartet.
• mw.hook( "siteOptions.feasible" ).fire( callback )
  • Antwort: true wenn LocalStorage in diesem Browser möglich.
• mw.hook( "siteOptions.fetch" ).fire( obj )
  • obj ist Objekt mit der Kennung sign und Callback-Funktion.
  • Antwort: Objekt zum Eintrag sign oder sonst null.
• mw.hook( "siteOptions.fill" ).fire( obj )
  • Objekt wird übergeben mit Kennung _sign_ und Haltbarkeit _minutes_ und Payload.
• Bei Abspeicherung wird Haltbarkeit _minutes_ zum date addiert.
  • Wenn _minutes_ fehlt oder kleinergleich Null dann 1440 und wenn größer 500000 dann Obergrenze.
• Bei Abfrage wird auf Gültigkeit geprüft, ob
  • Komponente ein object ist
  • und nicht null
  • und _minutes_ vom Typ number enthält
  • und _minutes_ kleiner als date in Minuten ist,
  • und wenn irgendwas davon nicht zutrifft dann wird diese Komponente eliminiert.
• Wenn Zugriff auf das siteOptions fehlschlägt, JSON.parse() fehlschlägt, Resultat kein object oder null ist dann Löschung und Reset.

VG --PerfektesChaos 21:39, 21. Jul. 2022 (CEST)

Inzwischen erste Implementierung als localUserOptions verfügbar. Kann im Testbetrieb verwendet werden. VG --PerfektesChaos 15:43, 31. Jul. 2022 (CEST)

restoreCookies

Aufgabe: Cookies aller Art des Wikis über Löschung aller Cookies retten.

• Browser schließen, Laptop-Deckel zu – löscht für viele alle Cookies.
• Ist auch sinnvoll; habe ich bei meinen Nicht-Wiki-Browsern ebenfalls so konfiguriert.
• Dann müssen alle Banner erneut weggeklickt werden.
• SiteNotice, CentralNotice, ULS/IME Sprach- und Schrifteinstellungen, diverse Merker für Ein/Ausklappen.
• Prozedur:
  • Wenn bestimmtes Cookie nicht definiert dann frage siteOptions.
    • Wenn dort definiert dann stelle Cookie mit bisherigem Wert wieder her.
  • Wenn aber definiert dann schicke an siteOptions zwecks Abspeicherung.
• Kleines Problemchen: CentralNotice verwendet wohl viele; müsste der Gesamt-Cookie-String mit Pattern geflöht werden zwecks Abspeicherung.

VG --PerfektesChaos 21:39, 21. Jul. 2022 (CEST)

Cookies & LocalStorage

Fachliche Infos:

• Cookies gehen in allen Browsern und sind seit letztem Jahrhundert definiert.
• LocalStorage sind technisch in etwa 99,8 % der marktgängigen Browser implementiert.
• Sicherheitswerkzeuge blockieren LocalStorage aus Domains ohne Whitelist, weil sich hier Tracking-Infos hinterlegen lassen, die ein konventionelles Cookie-Reset überstehen.
• Browser mit Privacy-Bewusstsein bieten das wohl heute oder bald als konfigurierbare Option an.
• LocalStorage hat Größen-Limits, gern 5 MB für alle Subdomains einer Domain, und das wird von MediaWiki öfter mal bis zum Anschlag ausgelutscht.
• Cookies werden bei jedem Seitenabruf an den Server übertragen und erhöhen dadurch den Traffic. Sie sollten heutzutage nur dann an den Server geschickt werden, wenn dieser damit auch was anfangen kann. Die Maximalgröße ist eiiiiigentlich limitiert. Deshalb wurde ja Web Storage eingeführt. Weil aber sehr robust sind Cookies weiterhin sehr gebräuchlich, um lokale Zustände zu hinterlegen.

VG --PerfektesChaos 21:39, 21. Jul. 2022 (CEST)

Systemnachricht

Ich würde die zukünftig wie folgt aufbauen:

<div data-sign="WikiCon2022LastCall"
     data-type="event"
     data-minutes="1440"
     class="watchlist-message noscript"
     style="background:#DEFFDE; border:1px solid #BBBBBB; color:#000000; font-size:110%; margin:.3em 0; padding:.5em;">
<div>
Dingenskirchen
</div>
</div>

1. Wenn im Dokument ein nicht-leeres-content Banner-Feld vorkommt, dann schau dir die data-Attribute an.
2. Wenn data-type eine nicht-leere Zeichenkette dann frage mw.user.options nach der zusammengebauten preference für CentralNotice.
3. Wenn data-type nicht generell ausgeblendet dann frage data-sign in siteOptions an ob auszublenden.
4. Wenn eins von beiden Ausblenden sagt dann .hide() das Dingens, bzw. mache es nicht aktiv sichtbar.
5. Andernfalls rüste es mit zwei Buttons am LTR-rechten Rand aus:
   • klein, rot, auf dieser Seite ausblenden.
   • Aktion, blau, Text Erledigt, bewirkt persistente Ausblendung.
6. Blauer Button nur dann wenn auch LocalStorage in diesem Browser möglich und data-sign nicht leer.
   • Blauer Button .click() das prefixed data-sign in siteOptions hinterlegt, mit ggf. vorhandenen data-minutes.
7. CSS-Transition mit etwa zwei Sekunden Vorlaufzeit, damit die Dienstwege abgelaufen werden können, falls sich keine bessere Lösung ergäbe.
8. Gering-transparente Überblendung der Seitenüberschrift und des Gedöns ganz oben in der Seite. Deshalb kein nachträgliches Ruckeln.
9. Nicht-JS-Darstellung halt konventionell, nicht wegklickbar, eingeschoben, mit CSS-Geruckel. Demzufolge wäre statisch in MediaWiki:Watchlist-summary bei Nicht-JS zu belassen aber das Element zu detach() und Mobil-Desktop-alle weiter oben im body-content zu verankern.
   • Mit .noscript müsste das gehen: Bleibt für ohne JS sichtbar. Mit JS wird das Element statisch frühzeitig ausgeblendet, und falls kein Ausblendungswunsch festgestellt wurde, kann es per detach() herausgelöst und weiter oben überdeckend wieder eingefügt werden, und zum Schluss sichtbar geschaltet.

VG --PerfektesChaos 21:39, 21. Jul. 2022 (CEST)

Danke schonmal, ich schau mir alles die Tage an. -- hgzh 07:58, 28. Jul. 2022 (CEST)

Drüber nachgedacht:

• Transition mit Überblendung müsste sich möglicherweise immer für alle machen lassen. Aber tricky, wegen Rennen gegen FOUC.
• Bekommen dann alle non-JS. Kein Geruckel.
• Mit JS gibt es dann eine Sekunde Zeit, um die Bedingungen zu prüfen.
• Wenn „Gelesen“ vermerkt, dann Element aus dem DOM löschen. Wenn nicht, dann wie non-JS.
• Anders als zunächst umseitig vermerkt, kein default hidden sondern Opt-Out. Wer immer alle Nachrichten sehen möchte, bekommt sie dann halt immer und kein Angebot zum Ausblenden. Wer nie Nachrichten sehen möchte, kann display:none in sein CSS schreiben und umseitiges JS deaktivieren.
• Mit localUserOptions gibt es die Möglichkeit zweier Ausblende-Buttons:
  1. Button mit roter Schrift auf weißem Grund; „Diese Nachricht nicht mehr anzeigen“ unten rechts drunter.
  2. Setzt erfolgreiches mw.hook("localUserOptions.feasible") voraus; wenn dies nicht dann Kästchen mit × oben rechts. Weil dann kein LocalStorage für diese Konfiguration.

VG --PerfektesChaos 16:11, 31. Jul. 2022 (CEST)