Benutzer Diskussion:Frog23/Dead Link Finder/de

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Fehlalarm bei Heiner Geißler

[Quelltext bearbeiten]

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 DeadLinkFinders
Hallo 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. -- Frog23 20: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.
Viele Grüße, Federstrich¿?¡!»•« 21:55, 16. Nov. 2010 (CET)Beantworten

Fehlalarm bei Henschel-Werke

[Quelltext bearbeiten]

In dieser Version wird der Weblink auf The Henschel Tiger Factory als Forbidden markiert, ist bei mir aber problemlos abrufbar. --Martin Zeise 13:59, 14. Nov. 2010 (CET)Beantworten

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. -- Frog23 20:04, 16. Nov. 2010 (CET)Beantworten
[Quelltext bearbeiten]
Startzustand
  • System: OS=WinXP Browser=Firefox 3.6.12 Skin=vector
  • 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!

Viele Grüße, Federstrich¿?¡!»•« 20:22, 17. Nov. 2010 (CET)Beantworten


Danke für den Bericht. Der Fehler ist behoben. Siehe Benutzer:Frog23/Dead_Link_Finder/Updates. -- Frog23 12:12, 25. Nov. 2010 (CET)Beantworten


[Quelltext bearbeiten]
Startzustand
  • System: OS=WinXP Browser=Firefox 3.6.12 Skin=vector
  • 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".

Viele Grüße, Federstrich¿?¡!»•« 20:41, 17. Nov. 2010 (CET)Beantworten


Dieser Bug hängt ja eng mit dem darüber zusammen. Also habe ich mich gleich um beide gekümmert. -- Frog23 12:12, 25. Nov. 2010 (CET)Beantworten


Bug: Skript hängt sich auf und prüft nicht weiter

[Quelltext bearbeiten]

Hi, hier mal was besonders feines! Ich habe diesen Link: http://1000-jahr-feier.de/Portaldata/2/Resources/sponsoren/images/frankenbrunnen_slogan_170.gif hier entdeckt. Irgendwie hängt sich das Skript dabei auf, das spinning wheel läuft endlos.

Viele Grüße, Federstrich¿?¡!»•« 23:57, 17. Nov. 2010 (CET)Beantworten

Der Vollständigkeit halber hier auch noch die technischen Daten eingefügt, obwohl ich befürchte, dass sie nicht viel beim debuggen helfen werden:
Viele Grüße, Federstrich¿?¡!»•« 18:35, 24. Nov. 2010 (CET)Beantworten


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. -- Frog23 12: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
try( ... } catch(err){ ... something went badly wrong ... }
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

RFC: Weiterleitungen optional anzeigen

[Quelltext bearbeiten]

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 302 Redirect amet, consectetur, adipisci velit ...

Begründung: Ich bin auf der Seite Sweet November beim ersten Einzelnachweis nur zufällig darauf gestossen, dass der Link http://www.filmevonabisz.de/filmsuche.cfm?wert=515134&sucheNach=titel weitergeleitet wird auf http://www.zweitausendeins.de/filmlexikon/ und damit als Einzelnachweis natürlich unbrauchbar ist. Eine Weblinksuche ergibt, dass es ca. 1000 Links in der deutschen Wikipedia gibt, die wahrscheinlich alle auf die selbe Seite weitergeleitet werden.

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 (302 Redirect) 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.

Viele Grüße, Federstrich¿?¡!»•« 18:04, 24. Nov. 2010 (CET)Beantworten


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 -- Frog23 12: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. -- Frog23 13: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 --Frog23 23:32, 13. Mai 2011 (CEST)Beantworten

Bug: Ausblenden des Ok-Symbols

[Quelltext bearbeiten]

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.

  • System: OS=WinXP Browser=Firefox 3.6.12 Skin=vector

Ist wohl am einfachsten zu beheben, indem man die Doku anpasst. ein lächelnder SmileyVorlage:Smiley/Wartung/:-)  Viele Grüße, Federstrich¿?¡!»•« 01:04, 25. Nov. 2010 (CET)Beantworten


Gut aufgepasst! Das ist natürlich ein Fehler. Ich habe die Dokumentation auch gleich angepasst. Vielen Dank! -- Frog23 12:12, 25. Nov. 2010 (CET)Beantworten
[Quelltext bearbeiten]

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. -- Frog23 15:47, 6. Dez. 2010 (CET)Beantworten
[Quelltext bearbeiten]

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 Could Not Reach Server this.is.a.dead.link.com [XX1] Spezial:Weblink-Suche http://this_is_a_dead_link.com/at/some/weird/path.html 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. -- Frog23 15:47, 6. Dez. 2010 (CET)Beantworten
Hallo Frog23, eingebaut, getestet und für gut befunden! Klasse, danke dir! Viele Grüße, [3]Federstrich¿?¡!»•« 21:25, 7. Dez. 2010 (CET)Beantworten

Fehlalarm [404]

[Quelltext bearbeiten]

Hi, hier wird ein [404]-Fehler angezeigt, obwohl das pdf ohne Probleme geladen werden kann. Viele Grüße, Federstrich¿?¡!»•« 19:12, 2. 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. -- Frog23 15:47, 6. Dez. 2010 (CET)Beantworten

Meldung [XX4] bei Allgemeines Gleichbehandlungsgesetz

[Quelltext bearbeiten]

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.

Viele Grüße, Federstrich¿?¡!»•« 17:05, 5. Dez. 2010 (CET)Beantworten

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. -- Frog23 15:47, 6. Dez. 2010 (CET)Beantworten

Ein Fall, zwei Fehler: Versionsgeschichte

[Quelltext bearbeiten]

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?

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:

Geprüft:

<a xmlns="http://www.w3.org/1999/xhtml" title="Allgemeines Gleichbehandlungsgesetz" href="/w/index.php?title=Allgemeines_Gleichbehandlungsgesetz&oldid=68395681">2009-12-24T22:08:32</a>

Ungeprüft:

<a xmlns="http://www.w3.org/1999/xhtml" title="Allgemeines Gleichbehandlungsgesetz" href="/w/index.php?title=Allgemeines_Gleichbehandlungsgesetz&oldid=68394875">2009-12-24T21:16:20</a>

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.

Viele Grüße, Federstrich¿?¡!»•« 18:42, 5. Dez. 2010 (CET)Beantworten

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?)
Viele Grüße -- Frog23 15:47, 6. Dez. 2010 (CET)Beantworten
Hallo Frog23, rund 1/3 aller Abfragen? ein SmileysymbolVorlage: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. ein SmileysymbolVorlage:Smiley/Wartung/pfeif 
Die Mitschnitte stammen übrigens von LiveHTTPHeaders Version 0.16 (Homepage auf livehttpheaders.mozdev.org).
Vielen Dank für die schnelle Umsetzung! Viele Grüße, Federstrich¿?¡!»•« 21:00, 7. Dez. 2010 (CET)Beantworten

Bug bei Browsemode

[Quelltext bearbeiten]

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

Danke für den Hinweis. Da kümmere ich mich beim nächsten Update drum, da es ja keine kritische Sache ist. Viele Grüße -- Frog23 16:52, 10. Dez. 2010 (CET)Beantworten
Den Fehler habe ich auch im letzten Update korrigiert. --Frog23 23:35, 13. Mai 2011 (CEST)Beantworten

Fehlalarm [XX1] bei Willi Cuno

[Quelltext bearbeiten]

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:

Ich gebe mal eine wilde Vermutung ab: Das könnte mit den Cookies des Servers zusammenhängen, dieser liefert bei mir:

Cookie: saplb_*=(J2EE21615400)21615451; JSESSIONID=(J2EE21615400)ID0957311051DB10394289559402567604End

und der * im Cookienamen ist doch recht ungewöhnlich. Wahrscheinlich zerschießt der dir irgendwas im HeaderProxy.

Vielleicht liegts aber auch an der doppelten Weiterleitung. Wenn ich versuche, den Link direkt aufzurufen, dann bekomme ich folgendes:

Viele Grüße, Federstrich¿?¡!»•« 15:12, 10. Dez. 2010 (CET)Beantworten

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:
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.
Danke für deine wachsamen Augen. Viele Grüße -- Frog23 16:50, 10. Dez. 2010 (CET)Beantworten
[Quelltext bearbeiten]

Hi, da bin ich wieder im neuen Jahr ein SmileysymbolVorlage:Smiley/Wartung/cool 

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.

Viele Grüße, Federstrich¿?¡!»•« 01:54, 5. Jan. 2011 (CET)Beantworten

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 --Frog23 23:40, 13. Mai 2011 (CEST)Beantworten

zwei Probleme

[Quelltext bearbeiten]

Hallo Frog23,
ich verwende das Tool jetzt schon einige Wochen, dabei sind mir folgende zwei Punkte aufgefallen:

Ansonsten funktioniert es super, danke dafür! --Buffty Pinnwand 22:08, 9. Jan. 2011 (CET)Beantworten

Hallo Buffy,
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.
Vielen Dank für dein Feedback. -- Frog23 07:40, 10. Jan. 2011 (CET)Beantworten
Hallo Frog23, danke für die Antwort.
  • 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?
Noch eine Ergänzung: bei den Updates wird eine Variable deadLinkFinder_linkToLinkSearch erwähnt, die aber noch nicht dokumentiert ist. --Buffty Pinnwand 13:08, 10. Jan. 2011 (CET) nicht zu verwechseln mit einer Vampirjägerin... :-PBeantworten
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 --Frog23 23:46, 13. Mai 2011 (CEST)Beantworten

Ich bekomme es nicht zum Laufen

[Quelltext bearbeiten]

Könnte bitte mal jemand über meine monobook.js schauen (steht ziemlich oben)? Ich bekomme dieses sehr nützliche Tool einfach nicht zum Laufen: Firefox 5, Windows XP Pro. Danke, --Martin1978 /± 10:15, 27. Jul. 2011 (CEST)Beantworten

Nach einer Nacht geht es jetzt doch... lol --Martin1978 /± 16:44, 28. Jul. 2011 (CEST)Beantworten

https-Version

[Quelltext bearbeiten]

Die HTTPS-Version von Wikimedia meldet der Finder als Error 403. Bitte fixen. --IWorld@ 21:19, 17. Aug. 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 --Frog23 07:49, 18. Aug. 2011 (CEST)Beantworten

Fehler

[Quelltext bearbeiten]

Derzeit kann DeadLinkFinder keine Icons darstellen. Liegt wohl an der Umstellung der Thumbs. Kannst du das fixen? --IWorld@ 16:36, 2. Mär. 2012 (CET)Beantworten

Vielen Dank für den Hinweis. Die Icons werden jetzt wieder richtig angezeigt. Einfach die Seite (ohne Cache) neu laden und dann klappt es wieder. --Frog23 (Diskussion) 11:51, 3. Mär. 2012 (CET)Beantworten
Danke! --IWorld@ 19:03, 23. Mär. 2012 (CET)Beantworten

Läuft nicht

[Quelltext bearbeiten]

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 /± WPVB 20: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.
var deadLinkFinder_runAlways = true;
Genauere Details zu den Einstellungen und die Begründung, warum das so ist, findest du hier Benutzer:Frog23/Dead_Link_Finder/de#Operationsmodi
Ich hoffe das hilft dir weiter. Falls es immer noch Probleme gibt, melde dich und ich werde dann noch mal genauer nachforschen. Bis dann --Frog23 (Diskussion) 22:10, 6. Mär. 2012 (CET)Beantworten
Mir werden die Links gar nicht mehr angezeigt (Links überprüfen sowie immer Links überprüfen). Das hätte ich auch gleich schreiben können... Gruß, --Martin1978 /± WPVB 22:22, 6. Mär. 2012 (CET)Beantworten
Ich habe jetzt mal die letzten 4 Änderungen an meiner js zurückgesetzt und es geht wieder. Jetzt mache ich mich auf die Fehlersuche. Gruß, --Martin1978 /± WPVB 22:25, 6. Mär. 2012 (CET)Beantworten
Läuft alles wieder! Wo der Fehler genau lag, kann ich nicht genau feststellen. LG, --Martin1978 /± WPVB 22:31, 6. Mär. 2012 (CET)Beantworten
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 /± WPVB 23:23, 6. Mär. 2012 (CET)Beantworten

Bug bei Weiterleitungen mit Leerzeichen

[Quelltext bearbeiten]

Dieser Link http://www.europarl.europa.eu/meps/de/28386.html führt zu einer Weiterleitung mit dem Code 303 (See Other) mit dem Locaction Header:

Location: /meps/de/28386/Jan Jerzy_KUAAKOWSKI.html;jsessionid=B86DDAB18BA074CE878C30C37A8676B5.node1.

Der HeaderProxy versucht aber auf http://www.europarl.europa.eu/meps/de/28386/Jan zuzugreifen, was zu einem 404 Fehler führt. Ich werde mich bei Gelegenheit darum kümmern.

--Frog23 (Diskussion) 19:08, 24. Apr. 2012 (CEST)Beantworten

Content-Type

[Quelltext bearbeiten]

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

Fehler bei Daniele Ganser

[Quelltext bearbeiten]

Hallo Frog 23, der erste Link in den Einzelnachweisen wird als 404 angezeigt, obwohl die Seite vorhanden ist. Gruß, Ninxit (Diskussion) 07:53, 14. Sep. 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

fix für https

[Quelltext bearbeiten]

Den Import von script-languages.js mit http habe ich in User:Thoken/deadlinkfinder/ korrigiert. Gruß, Thoken (Diskussion) 11:50, 8. Sep. 2013 (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:
http://www.ftd.de/politik/international/:missbrauchsskandal-auch-bei-regensburger-domspatzen/50084130.html
http://www.ftd.de/politik/international/:missbrauchsskandal-auch-bei-regensburger-domspatzen/a2b4n5m6
In diesem Paper ist ein ausgefeilteres Verfahren beschrieben. Der Erfolg hinge davon ab, ob es gelingt, falsch-positive selten einzufangen. --Thoken (Diskussion) 11:50, 12. Sep. 2013 (CEST)Beantworten

2014, und JavaScript

[Quelltext bearbeiten]

Hallo,

dein Tool wird uns 2014 gute Dienste leisten: es steht eine größere Aktion zum Fixen defekter Weblinks an.

Das eingesetzte JavaScript bräuchte allerdings eine größere Modernisierung. Gern helfe ich dir dabei.

var DeadLinkFinder = {};
zu einer
mw.libs.deadLinkFinder = {};
(die man zur Übersichtlichkeit intern mappen kann auf
var DLF = 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.
  • Außerdem sollte die ganze Angelegenheit gekapselt werden; siehe beispielsweise Benutzer:PerfektesChaos/js/defekterWeblinkBotVorlage/d.js
    • 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.
  • Kennst du eigentlich schon die Möglichkeiten von jQuery?

So, das war ein Überfall; viel zu lesen; aber es hat erstmal keine Eile – liebe Grüße erstmal --PerfektesChaos 22:49, 22. Jan. 2014 (CET)Beantworten

Skript funktioniert nicht?

[Quelltext bearbeiten]

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.
Viele Grüße, --Frog23 (Diskussion) 08:40, 3. Jul. 2014 (CEST)Beantworten
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
So, das Problem ist jetzt behoben und es sollte wieder alles funktionieren. Danke noch mal für die Meldung. --Frog23 (Diskussion) 10:45, 5. Jul. 2014 (CEST)Beantworten
Läuft alles super - Danke auch Dir VG--Maczunk (Diskussion) 12:26, 5. Jul. 2014 (CEST)Beantworten

XX5

[Quelltext bearbeiten]

Hallo, das script hat bei Johann Mühlmann bei diesem Weblink den Fehler XX5 gezeigt. Grüße, Victor Schmidt Was auf dem Herzen? 18:06, 20. Sep. 2017 (CEST)Beantworten

Hallo Victor Schmidt,
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.
Ich hoffe das hilft dir weiter. Vielen Dank noch mal und viele Grüße, --Frog23 (Diskussion) 22:25, 20. Sep. 2017 (CEST)Beantworten

Ich habe noch einen...

[Quelltext bearbeiten]

Auf Tina Haim-Wentscher hat dein Script bei diesem Weblink den Fehler XX5 ausgegeben. Ich habe den Weblink dann manuell im Browser aufgerufen, er war nicht tot. Grüße, Victor Schmidt Was auf dem Herzen? 17:59, 28. Okt. 2017 (CEST)Beantworten

Der Nächste

[Quelltext bearbeiten]

Auf Berlin Bei diesem Weblink kam XX4 Victor Schmidt Was auf dem Herzen? 15:59, 22. Aug. 2018 (CEST)Beantworten

[Quelltext bearbeiten]

Hello! I used your script successfully many times for a long time, but now it stopped working. Could you check why? Thanks! --Yoavd (Diskussion) 09:43, 10. Feb. 2019 (CET)Beantworten

@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.

Many thanks to user קיפודנחש [4]. --Yoavd (Diskussion) 22:49, 12. Feb. 2019 (CET)Beantworten

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

[Quelltext bearbeiten]

Hallo @Frog23, bei vielen fremdsprachigen Seiten tritt der Fehler [XX4] auf, obwohl es mit den Seiten keinerlei Probleme gibt. Siehe u.a. Die Abenteuer des Robin Hood#Einzelnachweise LG Dwain 14:53, 4. Jan. 2023 (CET)Beantworten