Letzter Kommentar: vor 14 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Gut, dann fange ich mal an. Nachdem die ersten ca. 20 Tests ohne Probleme liefen (durchgängig richtige Bewertung der Weblinkverfügbarkeit), zeigt der Dead Link Finder bei bei einem Einzelnachweis (Nr. 4 bei [1], Link auf wdr.de) einen nicht nummerierten Fehler an, obwohl der Link problemlos aufrufbar ist (probiert mit Firefox und Chrom unter Windows, jeweils aktuellste Version). --Martin Zeise✉18:58, 13. Nov. 2010 (CET)Beantworten
ein seltener Fehler des DeadLinkFindersHallo Martin. Danke für das Feedback. Ich konnte leider den Fehler nicht wieder rekonstruieren. Bei mir lief das Skript problemlos durch und auch in dem Log steht, dass der Test normal verlief. Dennoch glaube ich, ich weiß, was für einen Fehler du meinst. Er sieht in etwa so aus, wie rechts abgebildet , oder? Das ist einer der Fehler, dem ich versuche noch auf die Schliche zu kommen. Ich vermute, es hängt damit zusammen dass der Server nicht schnell genug reagiert, aber eigentlich sollte dann der Fehler XX1 oder XX3 kommen. Sag Bescheid, falls dir so ein Fehler noch mal unterkommt. -- Frog2320:02, 16. Nov. 2010 (CET)Beantworten
Hallo Frog23, danke für deine Antworten. Jetzt weiß ich zumindest, dass das Toll nicht zu 100 % richtige Antworten liefert bzw. liefern kann. Den ersten Fehler oben hast du genau richtig beschrieben. Bei einem Test eben trat die Meldung auch nicht mehr auf, sie ist mir aber doch schon noch ein. zweimal in den letzten Tagen untergekommen. Beim zweiten Fehler verstehe ich deine Zurückhaltung. Das ist zwar unschön, aber wohl nicht zu verhindern. Wenigstens habe ich noch keine Fehler bei einer positiven Bewertung der Linkverfügbarkeit gefunden. Beste Grüße --Martin Zeise✉20:44, 16. Nov. 2010 (CET)Beantworten
Hi zusammen, Ich hatte mit dem Vorläufer (Greasemonkey-Skript) das selbe Problem. Ich hatte mir damals damit beholfen, dass ich einen Timeout von 45 Sec. definiert hatte. Allerdings ist keine Antwort eigentlich ein Zeichen, dass nur ein temporäres Problem vorliegt und damit eigentlich der Link in Ordnung ist. Wenn der Server nicht mehr existieren würde, dann gäbe es eine klare Fehlermeldung. Aus Sicht eines Dead Link Finders könnte man sich tatsächlich überlegen den betreffenden Link eben gerade nicht als fehlerhaft zu markieren.
Ach ja, eine Möglichkeit für gar keine Antwort wäre z. B. eine falsch ausgehandelte MTU auf dem Weg zwischen HeaderProxy und der zu prüfenden Seite. Wenn das passiert, dann bist du (mit Verlaub gesagt) bös am A*sch gekniffen, weil du wahrscheinlich nicht mal eben die MTU von toolserver.org ändern darfst. Das einzige was dir dabei helfen könnte, wäre das auslesen von einem Service wie http://www.downornot.com/ oder ähnlichem.
In diesem Fall ist die Antwort recht einfach. Der Server liefert verschiedene Antworten, abhängig davon, was für einen User Agent bei der Anfrage übermittelt wird. Bei den meisten normalen Browsern funktioniert das, aber bei ungewöhnlichen User Agents, verweigert der Server die Antwort. Für die Anfrage nutze ich einen eigenen User Agent, der klar macht, dass das in Tool ist, das für Wikipedia arbeitet mit einem Link für weitere Infos. Solche Fälle lassen sich leider nicht ausschließen, außer man tut so, als es ein normaler Browser ist, was aber aus meiner Sicht nicht richtig ist. Vielen Dank für dein Feedback. -- Frog2320:04, 16. Nov. 2010 (CET)Beantworten
Bug beim Anschalten des automatischen Modus via Link / Cookies
vector.js:var deadLinkFinder_showOk = true; var deadLinkFinder_showWaitingIcon = true;
Cookies:DeadLinkFinder_alwaysCheck=off
Aktuelle Seite: getestet mit jeweils einer beliebigen Seite je Namensraum. Bug tritt bei jedem Namensraum auf, welcher nicht zur Überprüfung ausgewählt wurde (default = alles außer Artikelnamensraum).
Aktion
Jeweilige Startseite wird neu geladen. Dann klicke ich auf den Link "immer Links überprüfen".
Bug
Jede aktuelle Seite wird überprüft, auch wenn sie nicht Teil des Artikelraums ist!
vector.js:var deadLinkFinder_showOk = true; var deadLinkFinder_showWaitingIcon = true;
Cookies:DeadLinkFinder_alwaysCheck=on
Aktuelle Seite: getestet mit jeweils einer beliebigen Seite je Namensraum. Bug tritt bei jedem Namensraum auf, welcher nicht zur Überprüfung ausgewählt wurde (default = alles außer Artikelnamensraum).
Aktion
Jeweilige Seite wird neu geladen. Jetzt klicke ich auf den Link "keine Links mehr überprüfen".
Bug
Obwohl ja bereits ein Link "Links überprüfen" vorhanden ist (da ja hier nicht automatisch geprüft wird), wird der Link "keine Links mehr überprüfen" durch zwei Links ersetzt, nämlich "Links überprüfen" und "immer Links überprüfen". Dadurch hat man dann zweimal ein und den selben Link "Links überprüfen".
Hallo Federstrich. Ich habe das überprüft und bei mir lief alles korrekt. Das ist also auch einer der Fehler, dem man so schwierig auf die Schliche kommt. Ich vermute, dass der fremde Server nicht richtig reagiert hat, aber es kann auch sein, dass es am HeaderProxy lag. Sag Bescheid, falls so was wieder auftritt. Ich habe auch schon Überlegungen angestellt, ob man im Warte-Icon eine kleine Zahl anzeigen lassen soll, welcher Link gerade überprüft wird und wenn man mit der Maus drüber geht, dann auch den Link und die Gesamtanzahl der Links als title-Tag angezeigt bekommt. Das kann helfen, falls solche Fehler bei Seiten auftreten sollten bei denen es mehr Links gibt und die Frage ist, bei welchem sich der DeadLinkFinder gerade aufgehängt hat. Danke für den Report. -- Frog2312:12, 25. Nov. 2010 (CET)Beantworten
Hallo Frog23. Schon beim Antworten hier (Vorschau anzeigen) kann ich dir sagen, dass der Fehler immer noch auftritt. Auch dein ehemaliges Greasemonkey-Skript hat hier Probleme. Meine modifizierte Version zeigt mir "something went badly wrong". Das bedeutet, dass ich dieses Problem schonmal hatte, sonst wäre diese Fehlermeldung nicht in meinem Code. Damit zumindest mal das Skript weiterläuft, solltest du den kompletten xmlhttpRequest in ein
Konstrukt packen, daher kommt auch meine Fehlermeldung. Im ersten Schuß würde es ja durchaus reichen, dass dein Skript zumindest mal durchläuft und alle Links kontrolliert werden. Wenn dann der eine oder andere Link übrig bleibt, den man vorerst selbst kontrollieren muss, dann ist das auf alle Fälle besser.
Was das die Zahl im Warte-Icon angeht, prinzipiell eine gute Idee, aber ich würde dir raten, das Ziel anders anzugehen. Ich würde dir raten, optional das Ok-Symbol hinter jeden Link zu hängen, der bereits geprüft wurde. Da dein Skirpt durchaus Links kontrolliert, die nicht als externe Links angezeigt werden, kann man sich mit einer Zahl durchaus verzählen. Denke auch an diese Beispiel-Seiten: [2] und [2] da zählt man sich sonst dumm und albern. Viele Grüße, ↑Federstrich¿?¡!»•«16:59, 29. Nov. 2010 (CET)Beantworten
Letzter Kommentar: vor 13 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hi,
wäre es möglich, bei einer Weiterleitung (302 Redirect) optional ein zusätzliches Icon hinter dem Link zu platzieren? Das sollte dann zum Beispiel so aussehen:
Lorem ipsum dolor sit amet, consectetur, adipisci velit ...
Dieses Problem mit deinem Skript zu erkennen wird wahrscheinlich schwierig, daher hätte ich halt erst mal gerne eine kleine optische Warnung, dass man sieht, hier sollte man mal nachschauen.
Vorschlag für die Umsetzung: Optional anschalten ließe sich das ganze mit einer Variable im Skin, z.B.:
var deadLinkFinder_showRedirect = true;
Für das Icon würde ich http://commons.wikimedia.org/w/thumb.php?f=Fairytale%20right%20red.png&width=16px () vorschlagen. Das paßt relativ gut zu den bisherigen Icons, und dir bleibt die Möglichkeit, bei Bedarf noch zwischen einigen verschiedenen Redirects zu unterscheiden, falls sich später herausstellt, das das noch relevant wird. Dazu gibt es nämlich noch passend die Varianten:
Weiterer Ausblick: Möglicherweise könnte man zu einem späteren Zeitpunkt, wenn die Analyse deiner Datenbank mal online geht, da den einen oder anderen Mechanismus ableiten. Eine Variante wäre zum Beispiel der folgende Gedankengang: Wenn es mehr als [Schwellenewert] verschiedene Links gibt, welche auf die selbe URL weitergeleitet werden, dann kann man von einem toten Link ausgehen.
Hallo Federstrich. Das mit dem Weiterleitungssymbol ist eine gute Idee. Allerdings bleibt die Frage wie genau das dann genutzt werden soll. Die Weiterleitungen werden z.Z. vom HeaderProxy übernommen. Eine einfache, aber nicht optimale Möglichkeit wäre die, dass man mit einer solchen Option, wie du sie vorgeschlagen hast, dem HeaderProxy anweist, keinen Weiterleitungen mehr zu folgen und statt dessen den Code (3XX) zurück zu geben. Im Script kann man den dann heraus filtern und entsprechend das Symbol anzeigen lassen. Lieber wäre mir jedoch die Variante, dass der HeaderProxy sehr wohl auch den Weiterleitungen folgt und dem entsprechend auch prüft ob das Weiterleitungsziel noch vorhanden ist und trotzdem zurück gibt, ob es sich um eine Weiterleitung handelt. Dafür müsste man aber die Kommunikation zwischen Skript und Proxy-Server ändern, was folglich auch mehr Arbeit ich. Ich bleibe da auch alle Fälle dran, auch wenn es etwas dauern kann, bis ich dazu kommen. Aber danke für die Idee und auch die Icons passen wunderbar dafür. Viele Grüße -- Frog2312:12, 25. Nov. 2010 (CET)Beantworten
Unabhängig von dem allgemeinen Problem von fehlerhaften automatischen Weiterleitungen und deiner Idee, Weiterleitungen anzeigen zu lassen, habe ich mir mal die Links aus dem benannten Beispiel angeschaut und bemerkt, dass die neue Seite mit den alten Parametern auch funktioniert, also habe ich MerlLinkBot gleich mal einen Auftrag gegeben, die Links zu korrigieren. Dann sind es zumindest schon mal ein paar weniger. -- Frog2313:05, 25. Nov. 2010 (CET)Beantworten
Hallo Frog23. Aha - der Auftrag für MerlLinkBot klingt super, werde ich demnächst gleich selber machen. Was die Weiterleitung angeht, würde ich auf alle Fälle an deiner Stelle die zweite Variante wählen, also die Weiterleitung vom HeaderProxy machen lassen und zusätzlich noch eine Information, dass eine Weiterleitung erfolgte. Dadurch hätte man dann die Option, dass man später in einer weiteren Ausbaustufe noch die oben angesprochenen zusätzliche Tests machen könnte. Viele Grüße, ↑Federstrich¿?¡!»•«18:06, 29. Nov. 2010 (CET)Beantworten
Hallo Federstrich, in der neusten Version habe ich die Weiterleitungen eingebaut. Es war technisch nicht ganz so knifflig wie ich ursprünglich befürchtet hatte. Ich habe mich für den blauen Pfeil entschieden, da dieser neutral ist im Vergleich zu rot (Fehler!) oder grün (alles ok). Ob ein Link eine Weiterleitung ist wird auch in der Datenbank mitgeloggt, sodass bei den Links aus dem Cache, auch die Pfeile angezeigt werden können. Ich hoffe es entspricht deinen Vorstellungen. Sorry, dass ich so lange nicht auf deine Posts eingegangen bin. Ich war in den letzten Monaten sehr beschäftigt. Viele Grüße --Frog2323:32, 13. Mai 2011 (CEST)Beantworten
Letzter Kommentar: vor 13 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, der Abschnitt Ok-Symbol der Doku legt nahe, dass das Ok-Symbol per default nicht ausgeblendet wird und man das ausblenden durch die Zeile var deadLinkFinder_fadeOk = true; in der JavaScript-Seite der Skin einschalten muss. Dies ist momentan nicht so. Man muss das Ausblenden explizit mit der Zeile var deadLinkFinder_fadeOk = false; abschalten. Dabei ist es egal, ob die Links automatisch überprüft werden oder manuell.
Letzter Kommentar: vor 13 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wie gewünscht, melde ich einen Fehler [xx4]. Dieser trat hier als letzter Link bei Weblinks auf. Nachdem Firefox da auch wegen nicht astreinem Sicherheitszertifikat gemeckert hat, habe ich ihn gleich ersetzt.
Viele Grüße, ↑Federstrich¿?¡!»•«11:53, 2. Dez. 2010 (CET)Beantworten
Du hast den Grund für das Problem auch schon gleich mit erwähnt: es liegt an dem fehlerhaften Zertifikat. Da kann ich jetzt nichts ändern. Es wird also auch in Zukunft bei fehlerhaften Zertifikaten der Fehler XX4 auftreten. Ich werde die Dokumentation dahingehend noch anpassen. -- Frog2315:47, 6. Dez. 2010 (CET)Beantworten
Letzter Kommentar: vor 13 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, grad mal eine spontane Idee - wäre es vielleicht eine gute Idee, hinter jedem Link welcher das Achtung-Symbol bekommt auch gleich noch einen Link auf die Spezial:Weblink-Suche zu setzen? Wenn man sich einmal die Mühe gemacht hat, einen toten Link zu ersetzen, dann kann man doch gleich noch nachschauen, ob der selbe Link evtl. noch irgendwo anders verwendet wird.
Beispiel: Dies ist ein toter Link[XX1]
Viele Grüße, ↑Federstrich¿?¡!»•«18:23, 2. Dez. 2010 (CET)Beantworten
Hallo Federstrich, das ist eine gute Idee und ich habe sie auch gleich in die neuster Version des DeadLinkFinders mit eingebaut. Allerdings habe ich dafür kein extra Icon eingebunden, sondern einfach das Warnungssymbol verlinkt. Um das Feature zu nutzen, musst du die Zeile var deadLinkFinder_linkToLinkSearch = true; in die Script-Datei deiner Skin einbauen. Die Dokumentation muss ich dafür noch anpassen. -- Frog2315:47, 6. Dez. 2010 (CET)Beantworten
Ich habe mir den Link mal etwas genauer angeschaut und das ist in der Tat auch etwas kniffliger. Ich vermute, dass der Fehler daher kommt, dass auf dem Zielserver, die URL erst einmal umgeleitet wird und dann am Ende ein Sonderzeichen (ß) im Dateinamen enthält. Mir ist auch vorher schon einmal aufgefallen, dass das Script Probleme mit Umlauten in der Domain hat und vermutlich hängt das zusammen. Auch hier muss ich die Dokumentation noch einmal aktualisieren, damit klar ist, dass das ein bekannter Fehler ist. Vielen Dank für den Hinweis. -- Frog2315:47, 6. Dez. 2010 (CET)Beantworten
Letzter Kommentar: vor 13 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wie gewünscht, melde ich einen Fehler [XX4]. Dieser trat hier als vierter Spiegelstrich bei Gesetzes- und Richtlinientexte, Gesetzgebungsverfahren auf. Der Server liefert (nach sehr langer Zeit) schliesslich 502 Proxy Error.
Das sieht für mich wieder nach einem Time-Out-Problem aus. Gerade hat die Seite auch bei mir richtig geladen, das Script hat jedoch noch den XX4 Code angezeigt, da dieser noch auf dem HeaderProxy gecache war. Bei Gelegenheit muss ich noch eine Möglichkeit schaffen, diesen Cache gezielt bei einzelnen Links zu umgehen, z.B. wenn ein Server wieder erreichbar ist oder so. Trotzdem danke für den Hinweis. -- Frog2315:47, 6. Dez. 2010 (CET)Beantworten
Letzter Kommentar: vor 13 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, ich habe gerade gesehen, dass dein Skript fleissig läuft, wenn ich mir die Versionsgeschichte von einem Artikel anschaue (Beispiel: Versionsgeschichte von „Allgemeines Gleichbehandlungsgesetz“. Da stellt sich mir natürlich die Frage, welche externen Links gibt's denn da zu prüfen?
Ein kompletter Mittschnitt zeigt folgendes:
GET /w/index.php?title=Allgemeines_Gleichbehandlungsgesetz&action=history
GET /w/thumb.php?f=Gnome-emblem-default.svg&width=40px
Erstens, bin ich der Meinung, dass *de.wikipedia.org* Links nun wirklich nicht geprüft werden sollten.
Und zweitens, und das ist viel wichtiger, stelle ich fest, dass nur die blau hinterlegten Versionen, also die „Automatisch gesichteten“ Versionen geprüft werden. Das ist möglicherweise das eigentliche Problem. Ich vergleiche hier mal den HTML-Code von zwei Links:
Das würde bedeuten, dass möglicherweise dein Skript grundsätzlich Links nicht prüft, da ich momentan ausser der Versionsnummer keinen Unterschied im HTML-Code erkennen kann. Falls das so ist, käme das natürlich einem GAU gleich.
Auch hier würde natürlich im ersten Schuss mal helfen, wenn man sich ein kleines Ok-Symbol hinter jedem wirklich geprüftem Link anzeigen lassen könnte.
Hallo Federstrich, in der bereits erwähnten neusten Version des DeadLinkFinders werden die Seiten zur Versionsgeschichte nicht mehr überprüft (genau so wie, die fürs Editieren und Versionsvergleiche). Außerdem werden Links auf Wikipedia selbst (oder viele andere Wikimedia Foundation Projektseiten) nicht mehr überprüft. Das Problem hattest du ja damals schon beschrieben, als du die Weiterentwicklung des Greasemonkeyscripts veröffentlicht hast und seit dem hatte ich es auf meiner Liste, bin jedoch erst jetzt dazu gekommen. Ich habe einmal nachgeschaut, in all den Domains, die ich im ersten Testzeitraum allein überprüft haben, habe die jetzt ausgeschlossenen Domains rund 1/3 aller Abfragen ausgemacht. Jedenfalls sollten mit diesen beiden Maßnahmen, beide deiner Probleme behoben sein.
Der Grund, warum nur die gesichteten Versionen überprüft wurden, ist recht banal. Das Script sucht automatisch nach Links, deren class-Attribute mit "external" anfängt, da damit alle externen Links gekennzeichnet sind. In der Versiongeschicht, wird diese class jedoch auch für Links auf die gesichteten Versionen genommen, also die Links, die überprüft werden, sind nicht die auf die eigentlichen Versionen, sondern die, bei denen steht "automatisch gesichtet" oder "gesichtet von ...". Das sind auch die Links, die den Parameter stableid verwenden, wohingegen die anderen den Link oldid verwenden, was du auch in deinem Mitschnitt bzw. Beispielen sehen kannst. Ich hoffe, es ist jetzt etwas klarer, warum diese Links überprüft wurden. (nur so interessehalber, womit hast du den die Requests mitgeschnitten?)
Hallo Frog23, rund 1/3 aller Abfragen? Vorlage:Smiley/Wartung/shocked Dass das so viel ausmacht hätte ich nicht gedacht! Ach ja - jetzt wo du's sagst, dass mit dem "external" hätte ich ja gleich drauf kommen können, wenn ich hier nicht den falschen Link als HTML-Code ausgeschnitten hätte. Vorlage:Smiley/Wartung/pfeif
Letzter Kommentar: vor 13 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, jetzt habe ich auch den Browsemode geprüft und folgendes festgestellt: Wenn der Browsemode eine Seite mit einem Fehler gefunden hat, dann fehlt der Link keine Links mehr überprüfen bei den Werkzeugen. Ist jetzt nicht so dramatisch, könnte man aber bei Gelegenheit gleich ausbessern. Viele Grüße, Federstrich¿?¡!»•«14:20, 10. Dez. 2010 (CET)Beantworten
Letzter Kommentar: vor 13 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, beim ersten Weblink von Willi Cuno kommt eine Meldung [XX1]. Stutzig gemacht hat mich der Titel der Fehlermeldung, die URL kam mir sehr verdächtig vor. Bei jedem weiteren Versuch steht als Titel nur noch "Could Not Reach Server" da. Die Greasemonkey-Variante hat mit diesem Link kein Problem.
Wenn ich mal versuchsweise einen ähnlichen Link hier einfüge passiert folgendes:
Hallo Federstrich, also ich habe mal kurz nachgeschaut und es scheint ein Fehler des Servers von hagen.de zu sein. Hier ist der komplette Mitschnitt der Header mit der Weiterleitung:
Header Mitschnitt mit Weiterleitung
Request:
GET http://www.hagen.de/content/p_bild.shtml HTTP/1.1
Request:
GET http://www.hagen.de/quickurl/content/p_bild.shtml HTTP/1.1
Response:
HTTP/1.1 302 Found
server: SAP J2EE Engine/7.00
date: Fri, 10 Dec 2010 15:21:37 GMT
content-type: text/plain location: http://www.hagen.de;saplb_*=(J2EE21615400)21615450
content-length: 0
Connection: Keep-Alive
Set-Cookie: saplb_*=(J2EE21615400)21615450; Version=1; Path=/
Von dem anderen Server wird also eine unsaubere Weiterleitungsadresse mitgeliefert und deshalb geht der HeaderProxy in die Knie. Er ist halt nicht so robust wie moderne Browser. Ich bin mir aber nicht sicher, ob ich das tatsächlich reparieren sollte. Ich könnte nach Sonderzeichen suchen (wie z.B. eben jenem Semikolon) und nur bis dort hin die URL auslesen, aber was ein anderer Server die Sonderzeichen in seiner URL nicht richtig codiert? Dann würde ich dort falsche URLs erhalten. Ich glaube ich werde es erst einmal so lassen, oder was meinst du?
Der Grund, warum dieser Fehler übrigens nur beim ersten Mal auftrat, ist der, dass die fehlerhafte URL in der Fehlermeldung nicht mitgeloggt wurde und danach nur noch die gespeicherten Ergebnisse zurück gegeben wurden.
Ich glaube ein ordentliches Analysetool, bei dem man so eine fehlerhafte URL eingeben kann und dann genau angezeigt wird, wo was schief gelaufen ist (unabhängig vom gecacheten Ergebnissen), sollte ich auch noch zur dazu bauen, damit man solche Ungereimtheiten besser finden kann. Und wieder was für die Liste.
Ich habe hier zufällig einen toten Weblink entdeckt, der unter upload.wikimedia.org/wikipedia/de* liegt, ich befürchte mal, dass dieser Link systematisch nicht geprüft wird. Die Weblinksuche ergibt aktuell 807 Verwendungen bei 363 toten Links. Wenn ich da meinen Suchfilter anschmeiße (keine Diskussionsseiten, keine Benutzerseiten, keine *[Aa]rchiv*-Seiten) bleiben immerhin 102 Verwendungen mit ca. 35 toten Links übrig. Ich denke mal, dass wäre Grund genug, diese Links zu überprüfen.
Und - falls ich's noch nicht gesagt habe - ich hätte wirklich gerne einen Option, die mir anzeigt, weilche Links überprüft wurden und welche nicht - also irgendein Icon hinter jeden überprüften und für gut befundenen Link. Damit könnte man deutlich erkennen, welche Links gar nicht überprüft wurden und dadurch erstens mal selber per Hand nachprüfen und zweitens hier einen Verbesserungsvorschlag abgeben.
Hallo Federstrich, die Optionen, sich jeden überprüften Link markieren zu lassen, ist ebenfalls im letzten Update eingebaut. Jetzt kann ein kleines OK-Icon hinter jedem einzelnen Link angezeigt werden, falls der geprüft wurde. Das lässt sich auch wunderbar mit der Anzeige der Weiterleitungen kombinieren. Viele Grüße --Frog2323:40, 13. Mai 2011 (CEST)Beantworten
ich habe mir die beiden Links mal angeschaut, in dem ersten Fall ist das leider ein Problem der Seite http://www.nuernberg.de. Zwar heißt es auf der Fehlerseite, dass die gewünschte Seite nicht mehr existiert, jedoch wird für diese Seite nicht der HTTP-Statuscode 404 mitgeliefert, sondern 200 für OK. Da das Script jedoch nur diese Codes auswertet, sieht es da kein Problem. Was die Umlaute-Domains angeht, so ist mir auch schon aufgefallen, dass die nicht richtig funktionieren (siehe hier). Leider habe ich momentan keine Zeit, mich damit auseinander zu setzten. Daher muss das wohl noch bis Ende März warten, bis ich versuchen kann, mich diesem grundlegenden Problem zu stellen.
So etwas hatte ich mir schon gedacht, zumal es ja bei anderen nuernberg.de-Seiten auch funktioniert, siehe z.B. hier. Vielleicht findest Du ja aber trotzdem noch irgend eine auswertbare Unregelmäßigkeit (z.B. die Weiterleitung von einem PDF-Link auf eine HTML-Seite), um es dann mit einem XX-Code zu markieren. Eine solche Ausweitung der Regeln könnte dann natürlich zu falschen Treffern führen, in Verbindung mit der von Dir geplanten Auflistung toter Links wäre ja aber auch eine Art Whitelist möglich.
Ich hatte diese Seite hier zumindest überflogen, aber wohl übersehen, dass die Umlautdomains schon thematisiert worden waren. Vielleicht könntest Du die Doku mit "Bekannte Fehler" o.ä. ergänzen, bis Du für die Fehlerbehebung Zeit findest?
Nur zur Vollständigkeit: ich habe die Dokumentation (zumindest die deutsche, die englische folgt vermutlich morgen) aktualisiert. Jetzt gibt es ein Absatz für bekannte Fehler und die Variable deadLinkFinder_linkToLinkSearch ist jetzt auch dokumentiert, ebenso wie die neuen Features, die ich heute eingebaut habe. Viele Grüße --Frog2323:46, 13. Mai 2011 (CEST)Beantworten
Hallo IWorld, ich habe das Problem behoben. Danke für den Hinweis. Das Problem war, dass der Proxy-Server bei den Anfragen keinen User-Agent mitgesendet hat, die WikiMedia-Server aber einen UserAgent erwarten, da die Seite sonst nicht ausgeliefert wird. Das ist jetzt behoben. Es kann jedoch sein, dass in den nächsten 24 Stunden noch falsche Ergebnisse aus dem Cache geladen werden. Unabhängig davon werde ich wohl auch die https://secure.wikimedia.org - Domain auf die White-List setzten, d.h. dass Links zu dieser Domain nicht überprüft werden. Alle anderen WM-Domains werden ja auch übersprungen, um den Traffic auf die jeweiligen Server etwas zu limitieren. Viele Grüße --Frog2307:49, 18. Aug. 2011 (CEST)Beantworten
Letzter Kommentar: vor 12 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Aktuell wird mir der Finder nicht angezeigt. Ist das ein allgemeines Problem, oder ist bei mir was faul? Geändert habe ich eigentlich nichts an der Konfiguration. < gruß, --Martin1978☎/±WPVB20:52, 6. Mär. 2012 (CET)Beantworten
Hallo Martin1978, also bei mir sieht alles gut aus. Es kann sein, dass der Cookie abgelaufen ist, der dafür sorgt, dass die Links immer überprüft werden. Einfach mal unter "Werkzeuge" schauen, wenn dort der Eintrag "immer Links überprüfen" erscheint, einfach drauf klicken und dann werden für die nächsten 30 Tage die Links automatisch überprüft. Wenn du dir wirklich sicher bist, dass die Links immer automatisch überprüft werden sollen, unabhängig von dem Cookie, dann einfach die folgende Zeile in die JavaScript-Seite deiner Skin einfügen.
Noch ein Nachtrag, dann habe ich hier aber auch genug gespamt: Das Script läuft wieder, aber ich muss bei jedem aufgerufenen Artikel erst den Cache leeren, damit mir die Links angezeigt werden (Links überprüfen, immer Links überprüfen und Browsemode starten). Das ist zwar nicht wirklich befriedigend, aber es ist ein Workaround, mit dem ich leben kann. Gruß, --Martin1978☎/±WPVB23:23, 6. Mär. 2012 (CET)Beantworten
Letzter Kommentar: vor 12 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Kannst Du – gesteuert durch eine weitere Variable – statt eines OKs für funktionierende Links den Content-Type ausgeben? Hintergund: Ich habe es mit Weblinks zu tun, die dauernd aktualisiert werden. Für den Fall, dass ein Dokument, auf das ich eigentlich verlinken will, nicht mehr verfügbar ist, wird an dessen Stelle eine html-Seite angezeigt. OK im engeren ist der Link also nur dann, wenn kein html-Content kommt. Wäre das viel Aufwand? Anka☺☻Wau!16:19, 15. Jul. 2012 (CEST)Beantworten
Hallo Anka, grundsätzlich ist das möglich. Allerdings ist das keine triviale Sache, da eine Menge Änderungen dafür nötig ist. Momentan ist es um meine Zeit ein wenig knapp bestellt, daher werde ich dafür wohl etwas Zeit brauchen. Aber ich werde mich darum kümmern. Ich melde mich noch mal, wenn es Neuigkeiten gibt. Viele Grüße --Frog23 (Diskussion) 21:29, 16. Jul. 2012 (CEST)Beantworten
Danke. Ist aber nichts, was drängt. Das sind "nur" ca 350 Links und sooo viele ändern sich davon nicht. Wenn die in großen Abständen getestet werden, reicht das. Und ich hab auch ein Verfahren dazu, ist halt nur öde und viel Handarbeit. Anka☺☻Wau!21:34, 16. Jul. 2012 (CEST)Beantworten
Hallo Ninxit, es ist kein Fehler des Scripts, dass der Link als 404 angezeigt wird, sondern von der Seite selbst. Wenn man den Link http://www.siper.ch/de eingibt, liefert die Seite zwar den richtigen Inhalt, aber trotzdem den Fehlercode 404 zurück. Gibt man jedoch http://www.siper.ch/de/ (mit abschließendem /) ein, so wird der Statuscode 200 (also OK) zurückgegeben. Ich habe den Link auf der Seite gerade mal angepasst, dass er nicht mehr als fehlerhafter Link gemeldet wird. Trotzdem vielen Dank, dass du diese vermeintliche Unstimmigkeit gemeldet hast. Viele Grüße --Frog23 (Diskussion) 15:42, 15. Sep. 2012 (CEST)Beantworten
Aha! Danke für die Auskunft (vielleicht solltest Du diese Info in die Skriptbeschreibung einfügen) und auch das hilfreiche Skript. Ein schönes Rest-Wochenende wünscht, Ninxit (Diskussion) 08:54, 16. Sep. 2012 (CEST)Beantworten
Hallo Thoken, vielen Dank für die Reparatur von meinem Script. Ich hatte es noch gar nicht mitbekommen, dass es nicht mehr funktioniert. Jetzt habe ich das Script aktualisiert und auch die Installationsanleitung. Außerdem habe ich noch einige andere Sachen in dem Script aktualisiert. Falls dir noch etwas auffällt, was noch nicht richtig funktioniert, sag kurz Bescheid. Viele Grüße, Frog23 (Diskussion) 18:05, 9. Sep. 2013 (CEST)Beantworten
Dein Script funktionierte, nur das schöne Schloss in der Browser-Adresszeile verschwand.
Könntest du überlegen, eine weitere Klasse Weblinks besonders zu markieren, mit gelbem Pfeil etwa, nämlich Weiterleitungen zu "200 OK"-Seiten, die aber den im Artikel angegebenen Inhalt wahrscheinlich nicht mehr haben? Kandidaten sind Links, deren am Ende geänderte URL zur selben Seite weiterleitet, zB:
Einen Schwung an globalen Variablen zur Konfiguration hatte man vor einigen Jahren noch hinzugefügt. Heutzutage ist das unerwünscht und stört die Übersichtlichkeit im Debugger.
Im wesentlichen würde deine lokale Variable
varDeadLinkFinder={};
zu einer
mw.libs.deadLinkFinder={};
(die man zur Übersichtlichkeit intern mappen kann auf
varDLF=mw.libs.deadLinkFinder;
und sämtliche Benutzeroptionen werden zu
mw.libs.deadLinkFinder.optionXYZ=true;
Deine bisherigen Vorgaben in der Objektdefinition, soweit sie konfigurierbar sein sollen, werden zu einer internen
var defaults = { showUnsupportedProtocol: false, ...
und können mittels der Funktion
DLF = $.extend( defaults, DLF )
zu einer aktuellen Konfiguration gemischt werden.
Danach können sie ebenfalls mit etwas wie
$.extend( config, preset )
zu nichtkonfigurierbaren Optionen gemischt werden.
Wobei es aber schlauer ist, solche internen Angelegenheiten nicht nach außen zu exponieren, sondern dafür interne Variable in einer gekapselten Objektfunktion zu benutzen.
Damit steht alles, was mit dem Teil zu tun hat, in einem einzigen Anwendungsobjekt; und nichts mehr im globalen Namensraum.
Zurzeit bemühst du dich, alles in der einen global sichtbaren Objektvariable unterzubringen, um die Umwelt nicht zu belasten; das kannst du wesentlich einfacher haben, weil du in der gekapselten Pseudo-Funktion ganz normal lokale Variable nutzen kannst. Außerdem sind sie dann nach außen weder sichtbar noch irrtümlich manipulierbar.
Zusätzlich zur JavaScript-Syntax auf einer Benutzerseite, die für viele Autoren eine große Hürde darstellt, gibt es inzwischen auch die Möglichkeit, die Optionen in einem interaktiven Formular bei den Benutzereinstellungen zu speichern: Benutzer:PerfektesChaos/js/preferencesGadgetOptions. Das kann in jedem Wiki genutzt werden.
Die Aktivierung ist außerdem interaktiv möglich über Benutzer:Schnark/js/fliegelflagel, wodurch ebenfalls eine Möglichkeit zur interaktiven Konfiguration von Benutzereinstellungen gegeben ist. Allerdings dann in einer sehr speziellen Form, die nicht auf jedem Wiki-Projekt konfiguriert sein dürfte.
Unsere Technik-Werkstatt steht dir gern zu Rückfragen zur Verfügung, ich kann dir auch eine Neufassung deines Skripts gemäß oben genannter Gesichtspunkte in modernisierteren Formen schreiben.
Zufällig hatte ich bereits vor einem halben Jahr ebenfalls den Plan, defekte URL in der HTML-Seite zu markieren. Wir müssten uns da ein wenig abstimmen, um uns nicht gegenseitig zu zersägen.
Letzter Kommentar: vor 10 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Frog, ich habe die entsprechende mw Zeile des Scripts in meine common.js Seite kopiert, so wie schon einige andere Skripte zuvor. Leider läd er das ganze nicht, so dass unter Werkzeuge der Link zum Überprüfen angezeigt wird. Ich habe auch auf weitere Modi und Einstellmöglichkeiten bisher verzichtet. Cache Löschen und Aktualisieren habe ich schon probiert. Ist das Skript down? Wie ist Dein Status? VG--Maczunk (Diskussion) 17:12, 2. Jul. 2014 (CEST)Beantworten
Hallo Maczunk. Danke für die Info. Ich habe mir das gerade mal angeschaut und weiß aber spontan nicht, was da los ist. Es ist auf jedenfalls ein Fehler bei meinem Tool oder WMFLabs. Ich werde heute und morgen wohl nicht dazu kommen, dem genauer auf dem Grund zu gehen, werde mich aber am Samstag morgen darum kümmern. Ich hoffe das reicht aus.
Keinen Stress, ich bin Erstverwender für Dein Tool und da es ungewöhnlich ist, dass Wikitools nicht funktionieren, wollte ich dich gleich mal informieren. Wenn es wieder online ist, schreibe bitte hier rein, ich behalte die Seite in der Beobachtung. VG--Maczunk (Diskussion) 09:53, 3. Jul. 2014 (CEST)Beantworten
Danke für die Meldung. Dieser Fehler hätte so nicht auftreten dürfen, es ist eine ungünstige Kombination aus einem falsch konfiguriertem Server und einer fehlenden Ausgabe einer Fehlermeldung in meinem Script. Aus irgendeinem Grund gerät mein Tool beim Überprüfen des Links, in eine Endlosschleife aus Weiterleitungen. Im Browser tritt dieser Fehler aber nicht auf. Ich habe es auch mit einem anderen Programm manuell überprüft und auch dort bin ich in eine Schleife geraden (ich habe dafür die Seite https://www.hurl.it/ genutzt, falls du das auch mal überprüfen möchtest). Nach 20 Weiterleitungen hört mein Script eigentlich auf und gibt nur noch den Statuscode für die Weiterleitung (meist 301 oder 302) zurück. In diesem Fall jedoch hat es einfach aufgehört. Das habe ich jetzt behoben und man bekommt zumindest nun eine Fehlermeldung, dass was mit dem Link nicht stimmt, auch wenn es im Browser dann ja wieder zu funktionieren scheint.
@Yoavd: I just checked and for me everything seems to work. Maybe this was a temporary issue? Or maybe the cookie for the automated mode has expired: if you had at some point selected the option "always check links", this is stored in a cookie which has a long but no unlimited time to live. If it expires, you have to click the link for automatically checking all the links again, or select the mode in the settings, see the documentation for Modes of Operation . Maybe this is helps. Let me know if the issue still persists and what exactly happens (do the links appear in the tools menu on the left side? Does the automated checking work, ...). Cheers, Frog23 (Diskussion) 22:25, 10. Feb. 2019 (CET)Beantworten
Hello, the feauture stopped to work a few weeks ago. I did not use the option "always check links" but I used it manually every time that I wanted to check. In the Hebrew wikipedia they gave an assumption that wikipedia has now stricter rules about such scripts and it is not in the "white list" - maybe you could check it? Thanks!--Yoavd (Diskussion) 16:30, 11. Feb. 2019 (CET)Beantworten
Hello again, a friend of mine from the Hebrew wikipedia found the problem at line 376 of your script. it sends the following message:
Access to XMLHttpRequest at 'https://tools.wmflabs.org/deadlinkfinder/headerproxy/get.php?link=http://www.moshkashi.com/' from origin 'https://he.wikipedia.org' has been blocked by CORS policy: Request header field accept-language is not allowed by Access-Control-Allow-Headers in preflight response.
to complete the picture: the workaround i found is to trick dedlinkfinder to not use it, by executing the following line before using the script: window.XDomainRequest=window.XMLHttpRequest;// dirty hack to trick deadlinkfinder. remove as soon as possible (this may provide temporary relief for someone who is reading this for the same reason, until the root issue is resolved). peace - קיפודנחש (Diskussion) 18:10, 14. Feb. 2019 (CET)Beantworten
[XX4]: Bei vielen fremdsprachigen Seiten wird der Fehler [XX4] erkannt, obwohl es mit den Seiten keinerlei Probleme gibt
amet, consectetur, adipisci velit ...
) vorschlagen. Das paßt relativ gut zu den bisherigen Icons, und dir bleibt die Möglichkeit, bei Bedarf noch zwischen einigen verschiedenen Redirects zu unterscheiden, falls sich später herausstellt, das das noch relevant wird. Dazu gibt es nämlich noch passend die Varianten:
)
)
Viele Grüße, ↑Federstrich¿?¡!»•« 01:04, 25. Nov. 2010 (CET)
[XX1] 
Viele Grüße, ↑Federstrich¿?¡!»•« 18:23, 2. Dez. 2010 (CET)
Dass das so viel ausmacht hätte ich nicht gedacht! Ach ja - jetzt wo du's sagst, dass mit dem "external" hätte ich ja gleich drauf kommen können, wenn ich hier nicht den falschen Link als HTML-Code ausgeschnitten hätte. 
