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
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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).
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).
Vorlage:Überschriftensimulation 4
Jeweilige Seite wird neu geladen. Jetzt klicke ich auf den Link "keine Links mehr überprüfen".
Vorlage:Überschriftensimulation 4
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 14 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
Bug: Ausblenden des Ok-Symbols
Letzter Kommentar: vor 14 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.
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 14 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 LinkVorlage:(XX1Vorlage:)
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 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wie gewünscht, melde ich einen Fehler Vorlage:(XX4Vorlage:). 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
Ein Fall, zwei Fehler: Versionsgeschichte
Letzter Kommentar: vor 14 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 14 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 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, beim ersten Weblink von Willi Cuno kommt eine Meldung Vorlage:(XX1Vorlage:). 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
zwei Probleme
Letzter Kommentar: vor 14 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Frog23, ich verwende das Tool jetzt schon einige Wochen, dabei sind mir folgende zwei Punkte aufgefallen:
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
Ich bekomme es nicht zum Laufen
Letzter Kommentar: vor 13 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
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)
Vorlage:(XX1Vorlage:) 
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. 
