Closed meyway closed 3 years ago
wisydb
commented
5 years ago Ich habe anscheinend nicht überall "help wanted" ergänzt. Wo es bei neuen Punkten nicht auftaucht eher ignorieren. Dort wo jmd. das machen soll, soll die Aufgabe auch ausführlicher beschrieben sein, wie hier.
svenkaemper
commented
5 years ago Ausführlicher beschreiben kann nie schaden… 😉
svenkaemper
commented
5 years ago @wisydb Man muss die Linkprüfung ja nicht auf das Menü beschränken. Wir würden hier eine Art "Site-Crawler" vorschlagen, der jeweils das komplette Portal nach „fehlerhaften“ Links absucht und diese z.B. im Administrationsbereich auflistet. Für den speziellen Fall der Navigation könnte ich mir dann eher eine Einstellung vorstellen, mit der man „leere“ Menüeinträge automatisch ausblenden kann und sie aber dann auch wieder sieht, sobald der Crawler wieder Inhalte findet. Es wird ja wohl kaum jemand ständig seine Menüstruktur anpassen, nur weil es temporär mal gerade keine Kurse zu einem verlinkten Thema gibt?
debagel
commented
3 years ago Wenn technisch möglich würde ich hier Svens Vorschlag so aufnehmen das ich eine Klasse zu Menüpunkten ohne Treffer hinzufüge so das jedes Portal diese Punkte dann über CSS ausblenden kann oder auch nicht.
meyway
commented
3 years ago Danke, das wäre auf jedenfall sinnvoll, wie Du schreibst, eine CSS-"ist leer"-Klasse zum Ausblenden. Und wie gesagt: dort wo "keyword" oder "thema" hinterlegt sind kann man einfach den Searcher prüfen lassen, ob Ergebnisse vorliegen - nur bei "sonstigen Links" müsste man die URL aufrufen.
Ein Komplett-Site-Crawler würde dennoch die Unterscheidung zwischen Menüs und sonstigen Links benötigen. Es ist eine andere, komplexe Aufgabe. Die Anzahl der Links im Portal beträgt z.B. in HH > 200.000. Das dauert Stunden bis es durchläuft, müsste also permanent laufen, wenn es mehrere Portale machen (und es düften ja nicht mehr als 5-10 Links gleichzeitig aufgerufen werden, um den Server nicht zu belasten). Jedenfalls, wenn der Crawler wirklich "dumm" crawlt. Etwas anderes ist es, alle Links in allen DB-Feldern rauszuholen. Aber auch das ist wahrscheinlich komplex und nicht zwingend erfolgt daraus ein verwertbares Ergebnis: wenn der Anbieter falsche Links in seine Kursbeschreibung schreibt, kann man nur Schulterzucken, weil die Anbieter ja eh regelmäßig gebeten werden zu aktualsieren und bei großen Importen muss man würde dann der manuell korrigierte Link ggf. wieder überschrieben. Denke ich...
debagel
commented
3 years ago Der aktuelle Stand im DEV-Branch ist testbar. Ich habe die WISY_MENUCHECK_CLASS hinzugefügt. Die kann zb. über /menucheck?all aufgerufen werden und überprüft dann pro Aufruf alle Links in einem Portal (das seit längstem nicht mehr aktualisierte aktive Portal). Das Ergebnis der Prüfung wird ausgegeben und im Admin-Bereich des jeweiligen Portals unter den Einstellungen in "Einstellungen Hinweise" ausgegeben.
Dafür habe ich das Feld "einstellungen_hinweise" im Table "Portale" hinzugefügt (siehe admin/config/db.sql und db.inc.php). In der Framework Klasse habe ich den 'menucheck' Aufruf hinzugefügt.
Meine Vorstellung ist, das das Skript regelmäßig aufgerufen wird so das im Laufe eines Tage alle Portale einmal durchgeprüft werden. Ich kann das Limit auf 1 Portal pro Aufruf aber auch gerne ändern, kann nur nicht einschätzen wie hoch die Last pro Portal ist. Lokal habe ich es nur mit 3 angelegten Portalen und wenigen Links getestet.
wisydb
commented
3 years ago Aus Tests (vgl. E-Mail):
Zu ignorieren bzw. Startseite aufrufen, URL besteht aus: "/", "search", "#", "javascript:[...]"
Relative Links als absolute Links testen, sonst werden diese nicht getestet (unknown menu type): Insb. auch wenn mit "/" beginnend. Domain dafür kann z.B. die erste sein im "domains"-Feld der "portale"-Tabelle. Dazu erst als "https" probieren dann zur Not "http" - man könnte auch Portaleinstellung "https = ..." auslesen, ob an, aber letzteres wahrscheinlich unnötig umständlich.
Glossarseiten:
debagel
commented
3 years ago Die option "portal" ermöglicht es jetzt ein spezifisches Portal zu überprüfen, zb. "?portal=12345". Obige Testergebnisse habe ich jetzt weitestgehend berücksichtigt.
wisydb
commented
3 years ago Danke. Es funktioniert jetzt... Haken wir also erst mal ab.
Es ist in den seo-Zweig auch bereits gemerged (eigener commit) und im Wiki-Log.
Ich habe noch ein paar Ergänzungen vorgenommen, weil es sonst noch zu viele falsch-positive gab - aber v.a. neues, was ich noch nicht geschickt / bemerkt hatte. Es fällt eben erst beim Testen auf: die Sonderfälle von den Sonderfällen... Das mit dem "Portal"-Beschränkungsparameter ist da recht sinnvoll für's Testen.
Noch ergänzt:
Ich fand es schwierig, dass das date_modified nach der Prüfung aktualisiert wurde, weil es so aussieht, als ob alte Portale plötzlich von alten Benutzern gerade aktualisiert wurde. Aber ich sehe auch ein, dass man das Datum zur Ermittlung der letzten Änderung usw. braucht, wenn man keine neuen Felder nur für diese Funktion anlegen will. Also habe ich in allen WISY-Systemen einen zusätzlichen Benutzer angelegt (namens "Automatische Menü-Prüfung"), dessen ID in der admin/config/codes.inc.php hinterlegt ist (also installationsabhängig) und mit dem das Update dann gespeichert wird, so dass man sieht, es war kein "echtes Update". Aus dem gleichen Grund wird nun das Journal oben ergänzt (war keine Anforderung, aber finde ich aktuell sinnvoller).
Weitere Ausnahme: Ich habe mich gewundert, warum manch gemeldetes 0-Ergebnis aber Ergebnisse liefert => dies stammte dann manchmal aus dem Umstand, dass bei 0 Ergebnissen autom. auf Volltextsuche weitergeleitet wird => Prüfung, ob Einstellung "intellisearch.fulltext" = 1 oder 2 => dann pauschalen Hinweis über der Menü-Rückmeldung, dass dem so ist.
Neben "q"-Parameter auch "qs" berücksichtigt, weil absolute Links meist aus dem Browserkopiert sind nach Suchfeldeingabe => qs=... . Außerdem als den Querystring als geparster String, weil q= bzw. qs= öfters nicht am Anfang stehen.
Formalkram aus Merge mit Zweig (utf8 in Browseroutput + GET-Parameter von woanders)
Es ist jetzt gut benutzbar finde ich. Jedes Portal kommt ca. 1x / Monat dran (= alle 4h eines).
Ziel ist:
1.) Eine tägliche Überprüfung aller Menüpunkte in allen Portal zu schaffen, d.h. ob Menüpunkte mind. 1 Ergebnis liefern. Entweder über Frontendcrawl oder unter Verwendung des Menürenderers zur Prüfung.
2.) Das Ergebnis sollte dann idealerweise in ein neues Feld in der Tabelle "portale" geschrieben werden. Dieses wird dann (nur lesbar) in der Portale-Maske angezeigt, so dass die Redakteure eine entsprechende Übersicht haben und Menüpunkte entweder anpassen oder entscheiden können, dass nur vorübergehend keine Kurse zu den jeweiligen Menüpunkten vorhanden sind.
Die hauptsächliche Arbeit steckt dabei natürlich in Punkt 1.