Wikipedia Diskussion:Projektneuheiten

Archiv

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte morgens automatisch archiviert, deren jüngster Beitrag mehr als 14 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Fehler in neuer Spezialseite

Spezial:RandomInCategory funktioniert nicht mit Doppelpunkt-Kategorien: Beispiel. δ¹ 22:36, 22. Aug. 2013 (CEST)

Doch, wenn du den vollen Kategorienamen angibst (also mit Namensraum): Spezial:RandomInCategory/Kategorie:Wikipedia:Exzellent. Der Umherirrende 14:47, 23. Aug. 2013 (CEST)

Dann ist das inkonsistent, denn bei Kategorien ohne Doppelpunkt funktioniert es auch so: Autor. δ¹ 21:39, 23. Aug. 2013 (CEST)

Der Fehler ist bekannt und wird behoben: Bug 53239, aber für den Moment hat man eine Umgehungslösung, wenn man den Namensraum mit angibt. Der Umherirrende 22:21, 23. Aug. 2013 (CEST)

CodeEditor und IE8

Das der CodeEditor im IE8 nicht einwandfrei funktioniert, ist wahrscheinlich kein Bug …, aber dann sollte er dort standardmäßig auch deaktiviert werden. Der IE8 zerstört teilweise die Newlines, bei JavaScript ist das nicht (immer) problematisch, bei Lua aber schon eher (wo es auch nicht funktioniert). Ungünstig ist auch, das nach dem deaktivieren trotzdem die Newlines kaputt sind. Ich habe keine Lust auf Bugzilla eine solche Browser-Diskussion zu starten, daher nur hier als kleinen Hinweis. Der Umherirrende 14:59, 23. Aug. 2013 (CEST)

„Wenn keine Bugs auftreten, wird …“ ist gut: modules/ext.codeEditor.js

• Opera 11.10 / Linux: copy fails, paste sometimes crashes
• IE 8.0.6001.18702 / Win XP: some newlines mysteriously removed, corrupting data;
  • insertion point keeps resetting back to the top of the page after a click (arrow keys ok)
• Safari / iPad 4.3 (8F190): renders ok, but can't set focus or scroll vertically. No focus means no typing. :(

Es wäre für uns nicht schwer, beim wgPageContentModel ungleich "wikitext" nach dem Browser zu schauen und im selteneren Fall ungeeigneter Browser zu setzen:

$.cookie( "wikiEditor-0-codeEditor-enabled",
          "0",
          { expires: 365,
            path:    "/" } );
mw.loader.state( "ext.codeEditor", "missing" );

• Die erste Anweisung verhindert per Cookie, dass dies planmäßig automatisch aktiviert ist; ließe sich aber noch anklicken. Den Button kann man aber $....remove().
• Wenn die zweite rechtzeitig wirksam werden sollte, wird das Teil gar nicht erst geladen.

Ohne solche Maßnahmen könnten entsprechende Benutzer ihr persönliches JS/CSS nicht mehr bearbeiten; oder es muss jedem vom Himmel die Erkenntnis fallen, dass man auf klicken muss, um arbeiten zu können. Alternativ ein Gadget für das bail out.

Es ist aber eigentlich serverseitig dafür zu sorgen, dass solche Zusatz-Tools erst dann geladen oder scharf werden, wenn sich der Browser dafür eignet. Davon sehe ich nichts. Prinzipiell ist das Ding soweit hilfreich und im Rahmen der Möglichkeiten ausgereift. Als Opt-in unterstütze ich das ausdrücklich.

• Aber mich stimmt die in diesem Jahr auftretende Attitüde der WMF äußerst nachdenklich, dass hemmungslos jedem zusätzliche Software aufgezwungen wird (und nicht einmal ein Opt-out vorgesehen ist), egal ob sie für ihn sinnvoll ist und überhaupt für seine Technik funktioniert. Dazu zählt IME/ULS für lateinisch verschriftete Projekte, das unselige Trauerspiel um den erst halb fertigen VE und jetzt diese Nummer.
• Der Netzwerkaufwand zum Angucken einer Seite steigt immer weiter, die Ladezeit wird auf langsamen Maschinen spürbar ausgebremst, Wikis sind bald nur noch mit neuester Hardware in schnellen Netzwerken lesbar – aber gleichzeitig plärrt WMF was von Wiki-Zugang auf der Südhalbkugel für technologisch schwache Infrastruktur. Und einfache Bearbeitung der Inhalte mit niedrigschwelliger Software gehört zu den Wiki-Basics; oder war mal eine Grundidee gewesen. Wenn kompliziert, dann serverseitig.

Schönes Wochenende --PerfektesChaos 22:45, 23. Aug. 2013 (CEST)

Information der Benutzer betreffend anstehender Umstellung auf HTTPS

In zwei bis drei Tagen steht eine Umstellung von Anmeldeprozeduren und weiterem auf HTTPS an; darüber sollten die Benutzer per sitenotice und/oder watchlistnotice informiert werden; mit Verweis auf Hilfe:Secure Server.

Liebe Grüße --PerfektesChaos 20:55, 26. Aug. 2013 (CEST)

Gemischte Inhalte

Was mir auffällt: die Wikipedia wird zwar via HTTPS ausgeliefert, aber anscheinend nicht komplett. Der Firefox "hat unsichere Inhalte blockiert" und weist mich via Icon in der Adresszeile, dass es "gemischte Inhalte". Auf der zugehörigen Hilfe-Seite [1] steht: „Wenn jedoch die aktuell besuchte HTTPS-Seite auch HTTP-Inhalte enthält, kann der HTTP-Anteil von Angreifern gelesen oder modifiziert werden, obwohl die Seite über HTTPS aufgerufen wurde. Wenn eine HTTPS-Seite HTTP-Inhalt enthält, nennen wir diesen Inhalt „gemischt“. Die Seite, die Sie besuchen, ist nur teilweise verschlüsselt und obwohl sie sicher erscheint, ist sie es nicht.“ Das ist ha sicher nicht im Sinne des Erfinders, oder? Kann man das abstellen? --emha ^d|^b 09:56, 29. Aug. 2013 (CEST)

Kommt vermutlich daher, dass Du in Deinem common.js/monobook.js/vector.js/etc. Sachen per http einbindest. --Krd 10:02, 29. Aug. 2013 (CEST)

Dito. mein verdacht ist Benutzer:Emha/monobook.js oder ähnliches. -- southpark 10:04, 29. Aug. 2013 (CEST)

+1

Infos:

• Seit 2011 sind alle gepflegten Ressourcen auf protokoll-relative Links umgestellt worden.
• Für in Wiki-Texten vorkommende Links wird notfalls automatisch umgestellt auf das richtige Protokoll.

Nur Programmierung in JS (und CSS) käme für veraltete (weil nicht protokoll-relative) Links in Frage.

Siehe Hilfe:Secure Server #Hinweise für die Praxis.

Das document.write und includePage ist auch bös veraltet; siehe Wikipedia:Technik/Skin/JS/Obsolet #Einbindungen.

LG --PerfektesChaos 10:37, 29. Aug. 2013 (CEST)

Danke für die Hinweise - schön, wenn man selbst 'schuld' ist, dann lässt sich sowas am schnellsten beheben :) Grüße, --emha ^d|^b 11:13, 29. Aug. 2013 (CEST)

HTTPS und Sitzungmanager vom Firefox

Hallo. Ich habe vorhin meine gestrige Sitzung im Firefox aufgerufen, nachdem ich mich in der Esperantowikipedia angemeldet hatte. Allerdings blieb ich trotzdem in der deutschen und den beiden sorbischen Wikipedien unangemeldet. Ich habe mir daraufhin mal das Dateiformat der Sitzung angeschaut. Dort stehen alle Adressen noch mit HTTP drin. Das läßt sich aber sehr einfach beheben.

• Ich habe die Sitzung, die im Firefoxprofilordner rumliegt, in meinem Commander kopiert.
  • Falls etwas schief geht, kann man dann nochmal anfangen.
• Und dann alle Adresseinträge für die Wikipedien per Suchen und Ersetzen auf HTTPS geändert.
  • Aber bitte aufpassen, daß alles was nicht zur Wikipedia gehört bei HTTP bleiben sollte.

Jetzt klappt die Anmeldung wieder überall wie gewohnt, wenn man sich in einer der Sprachversionen anmeldet und dann die Sitzung lädt. --Tlustulimu (Diskussion) 13:44, 29. Aug. 2013 (CEST)

Caching-Verhalten

Wurde mit der Umstellung auf Zwangs-HTTPS was am Caching geändert? Wenn ich von einem Artikel aus einen externen Link aufrufe und dann zurückgehe, wurde die Seite früher nicht neu geladen - jetzt ist das schon der Fall. Der HTTP-Header sagt auch "Cache-Control: no-cache". Ich weiß nur nicht, wie das vorher war. Oder ist das normales Browser-Verhalten bei HTTPS? Insgesamt verlangsamt das meine Arbeit schon merklich... --APPER\^☺☹ 23:00, 29. Aug. 2013 (CEST)

Es gibt nur beim IE eine uralte Einstellung, nach der man https-Seiten vom Caching ausschließen könne; dann würdest du aber keinen HTTP-Header "Cache-Control: no-cache" sehen, weil Privatangelegenheit des Browsers.

Ich bin seit mehreren Jahren auf https, und das Caching ist eigentlich ganz normal.

Wenn ich mich recht entsinne, gibt es bei statischen Seiten mit /wiki/ Caching-Infos, und ein no-cache etc. bei /w/index.php und Spezialseiten. Muss ich mal wieder drauf achten.

Vielleicht nur ein temporäres Problem, und irgendwie umstellungsbedingte Absicht aus irgendwelchen Gründen.

LG --PerfektesChaos 00:02, 30. Aug. 2013 (CEST)

Das Verhalten ist eindeutig anders. Wenn ich früher einen Artikel bearbeitet habe und dann beim Speichern eine Fehlermeldung vom Server kam, konnte ich einfach zurückgehen und erneut speichern. Jetzt sind die Änderungen weg... Sorry, so macht die Mitarbeit hier gleichmal wieder weniger Spaß, juchu. --APPER\^☺☹ 16:43, 30. Aug. 2013 (CEST)

Ah, ich seh grad, dass ich das in den Einstellungen deaktivieren kann. Gut. --APPER\^☺☹ 16:45, 30. Aug. 2013 (CEST)

Bei mir ist es genau so, liegt aber am Browser. Opera ermöglicht in den Benutzereinstellungen, die serverseitige Cache-Vorgabe zu ignorieren und Seiten immer aus dem Cache zu laden. Bei https-Seiten wird diese Einstellung allerdings von Opera ignoriert. -- TZorn 18:29, 30. Aug. 2013 (CEST)

Ich bin schon seit Monaten auf https: Über die Firefox-Extension HTTPSEverywhere. Habe keine Probleme mit dem Caching. Wenn ich eine Bearbeitung (durch einen Fehler) verlasse und die Browser-Rück-Taste klicke, werden mir meine Bearbeitungen im Bearbeitungsfenster angezeigt. Aber irgendeinen Unterschied zu dir muss es geben *grübel* — Raymond ^Disk. 19:08, 30. Aug. 2013 (CEST)

Bei mir gibt es auch keine Cache-Probleme. Bearbeiten -> Vorschau -> Browser-Rück führt wieder zum Bearbeiten-Fenster mit meinen Änderungen -> nochmal Browser-Rück führt wieder zum Artikel. Alles sofort da ohne jedes Neuladen. Achja: FF 22.0 ohne irgendwelche umgestellten Einstellungen, falls das hilft. --Stepro (Diskussion) 21:52, 30. Aug. 2013 (CEST)

Danke für eure Kommentare. Das Problem besteht mit Firefox und Chrome nicht, jedoch mit Opera (Opera <15). Das Problem ist das mitgesendete "must-revalidate" im Cache-Control-HTTP-Header. "no-cache" nehm ich zurück, da hab ich mich wohl verguckt. Opera behandelt "must-revalidate" im https-Umfeld strenger und lädt auch in der History die Seite neu - im Gegensatz zu Chrome oder Firefox. Nun kann man sich über die korrekte Interpretation der Absätze 13.13 und 14.9.4 der HTTP-Spezifikation streiten, aber ich halte "must-revalidate" in diesem Fall für übertrieben. Egal, ich deaktiviere HTTPS einfach zunächst - Opera 12 stirbt ja leider sowieso :/ --APPER\^☺☹ 23:49, 30. Aug. 2013 (CEST)

Wikipedia:Umfragen/Technische Wünsche

Zur Info: Wikipedia:Umfragen/Technische Wünsche. — Raymond ^Disk. 21:02, 1. Sep. 2013 (CEST)

Echo

Ist die Einführung auch hier geplant? In der en-WP sind die Notifications seit einer Weile aktiviert und IMO sehr praktisch. --Leyo 11:50, 3. Sep. 2013 (CEST)

[2] (v.a. die Checklist beachten, ich glaube, da hat man aus den Fehlern bei VisualEditor gelernt) --Filzstift ✏ 11:55, 3. Sep. 2013 (CEST)

Wollen wir darum wetten, wie groß der Protestschrei sein wird, dass es mit Echo keinen Kackbalken mehr gibt, gerade im Hinblick auf solche Fälle? --Schnark 12:29, 3. Sep. 2013 (CEST)

@Schnark: Wurde wohl zur optischen Backward Compatibility nachgerüstet; im Sinne der Kinderkrankheiten.

• Es ist vermutlich das Häkchen bei „⧼echo-pref-new-message-indicator⧽“ in der Benutzereinstellung, womit der traditionelle Modus für die eigene Disku zusätzlich hergestellt wird.
• Ich habe den Haken grad reingemacht; schreibe mir doch mal jemand anders was auf en:User talk:PerfektesChaos zum aktuellen Stand.
• Vor ein paar Monaten war das eine verkleinerte Form des traditionellen Balkens gewesen. Das Design ist per CSS voll anpassbar, bis hin zur traditionellen Erscheinungsbild.

LG --PerfektesChaos 12:50, 3. Sep. 2013 (CEST)