System-Log: "No active page for page ID" durch Bots

Hallo zusammen,
wir haben hier mehrere große Systeme (unterschiedlicher Contao-Versionen) am laufen. Eines haben alle gemeinsam:
Der System-Log (tl_log) wird geflutet mit "No active page for page ID".

Alles verursacht durch irgendwelche Bots (Yahoo! Slurp, Trident, MetaJobBot, Googlebot, ltx71, DotBot, ...).
Mehrmals pro Minute generieren diese durch teils wahllos zusammengereimte URLs tausende von Log-Einträgen, was dazu führt, dass der System-Log von einem recht wichtigen Tool zu einem fast unbrauchbaren Tool wird.
Jeder Aufruf des System-Logs und jede Filter- bzw. Sortieraktion benötigt eine halbe Ewigkeit.

Gibt es eine Möglichkeit (z.B. mit [botdetection] ) die Aufrufe der Bots aus dem Logging auszuschließen?
Mich interessieren nur Falschaufrufe, die von Menschen erzeugt werden, um z.B. Umleitungen etc. zu setzen. Aber das ist eine Tortur diese von den durch Bots generierten Aufrufen auseinanderzuhalten.

Mein Systemlog beinhaltet derzeit ~328000 Einträge bei Aufbewahrungszeit von 3 Monaten. Mindestens 90% davon sind durch Bots entstandene Einträge.

Viele Grüße

Eine interessante Idee, wobei manchmal die Bots auf wirkliche Fehler hinweisen, die ganz zu killen könnte auch bei einem oder anderem zum Übersehen von Fehlern führen.

Müsste man mal schauen ob man sich in den Log Vorgang einklinken kann und den abbricht.
Der 404 Meldung an den Bot selbst sollte schon bestehen bleiben.

Wenns da ein Hook gibt um das Logging zu manipulieren, dann könnte man eine kleine Erweiterung schreiben die auf Botdetection basiert.
Botdetection selbst ist ja nur die Erkennung.

Zitat:

---

Zitat von BugBuster

Wenns da ein Hook gibt um das Logging zu manipulieren, dann könnte man eine kleine Erweiterung schreiben die auf Botdetection basiert.

---

In der Doku konnte ich auf die schnelle folgendes finden:
- https://docs.contao.org/books/api/ex...dLogEntry.html
bzw. https://github.com/contao/core/blob/....php#L192-L198

Nur leider blicke ich da nicht so richtig durch, ob man damit das Logging manipulieren und ggf. das ausführen des database query unterbinden kann.

Da könnte ich mir spannende und nützliche Einstellmöglichkeiten vorstellen. Z.B. Ab x Einträgen Bots ausfiltern. So läuft die Tabelle nicht voll und man kann trotzdem erst mal eine begrenzte Menge an Logeinträgen durch Bots zulassen. Oder man trennt das noch auf, so dass z.B. jeder Bot eine vorgegebene Anzahl Einträge erzeugen kann, danach wird er ausgefiltert. Wird natürlich beliebig kompliziert ... :rolleyes:

Hmm, schade, der Hook kommt erst, nachdem der Eintrag in die tl_log bereits erledigt ist.
Die PageError404 Klasse die das Logging auslöst bietet auch keine Angriffsmöglichkeit.

Zwei Möglichkeiten.
a) den Hook nehmen und den Eintrag aus der Log wieder löschen wenn von Bot
b) die PageError404 Klasse ersetzen, das geht updatesicher, und das Logging damit bei Bots verhindern.

b) habe ich schon mal gemacht, für meine Anti-SEO Erweiterung. Könnte man da mit einbauen, nur gibts zur Zeit dafür keine Konfiguration.
Entweder mit in die System Einstellungen, oder über Extra Menüpunkt und DCA, also übliche Formulare.
Außerdem wäre es dann keine reine Anti-SEO Erweiterung mehr. Aber die könnte man auch umbenennen :-)
Oder als Add On Erweiterung, die ich dann selber per Hook aufrufe. Alles nette Ideen die mir da grad rumspuken. :cool:

Ich habe zwar keine Lösung, aber wollte nur mitteilen, dass bei mir auch so täglich über den Tag verstreut ca. 30 derartige Einträge drin sind. Ich lösche sowie so öfters manuell den System-Log, so dass der Kram dann auch gleich mit weg ist. Sicherlich ist es etwas nervig.

Hi,

wollte mich hier mal dranhängen. Hatte heute gerade so einen Fall - innerhalb von 4 Wochen waren ca. 60.000 Einträge aufgelaufen. Das sind im Schnitt also 2.000 pro Tag.

Wäre mir nicht aufgefallen, wenn es nicht ein Problem mit dem Einloggen ins BackEnd gegeben hätte. In den errors stand etwas von

... PHP Fatal error: Uncaught exception 'Exception' with message 'Query error: Duplicate entry '60757' for key 'PRIMARY' (INSERT INTO tl_log (tstamp, source, action, username, text, func, ip, browser) ...

so dass ich mir die tl-log über PhpMyAdmin ansah und die vielen Einträge sah. Welchen Zusammenhang es da genau gibt, verstehe ich nicht, aber ich habe die tl_log geleert und danach klappte das Einloggen wieder. Vorher habe ich mir eine Kopie als CSV gezogen - sie ist voll von Bot-Einträgen.

Ab Contao 4.2.1 gibt es diese Meldungen nun nicht mehr: https://github.com/contao/core-bundle/pull/525

Hm, gut zu wissen.

Aber was kann ich bei diesem Problem bei einer 3er-Version tun?

Nach einem genaueren Blick in die sehr gut gefüllten error-Logs hat es gestern im Laufe des Tages zunächst Fehler der Art gegeben (jeweils gehäuft, aber in der Reihenfolge...):

User (Datenbank) already has more than 'max_user_connections' active connections ..
Uncaught exception 'Exception' with message 'Too many connections' ...
PHP Warning: mysql_connect(): Connection refused in ...

Und ab da war wohl etwas mit einigen IDs in der tl_log verquer, so dass nicht mehr geschrieben werden konnte (was dazu führte, dass man sich auch nicht einloggen konnte). So meine Interpretation.

Habe auch in die error-Logs der letzten Wochen/ Monate geschaut. Auch hier kam die Warnung mit "max_user_connections" und "too many connections" vor. Die normalen Traffic-Zahlen der Website sind nicht so, dass sie das ausgelöst haben könnten.

Für mich sieht es so aus, als wenn die vielen Bots, die bei jedem Besuch massenhaft Einträge in der tl_log hinterlassen, die Datenbank überlasten und gestern das erste mal dadurch einen "Schaden" angerichtet haben.

Kann ich die "No active page"-Protokolle irgendwie deaktivieren?

Grüße
Pipkin

Ich würde die Bots ja gar nicht erst auf den Server lassen. Dann machen Sie auch keine Einträge.

Ah, danke! Auf die Idee bin ich noch gar nicht gekommen.

Welcher Weg ist dafür besser: die IPs Stück für Stück herausfriemeln und per htaccess verbieten ... oder müssten die Provider dazu etwas bereit stellen (Domainfactory)?

Oder was anderes?

Als Anregung mag beispielsweise https://perishablepress.com/6g/ dienen.

Wow! ;-)

Ich sehe schon, ein (für mich) unerwartet komplexes Thema. Das werde ich mir mal reinziehen, scheint ja immer wichtiger zu werden.

Tausend Dank!

Hi nochmal ...

Ich bin auf der Suche nach englischsprachigen Fachartikeln, die gut erklären, worum es sich beim Traffic durch Bots handelt.

Der Website-Betreiber ist der Meinung, dass der Hoster etwas gegen die Bots tun muss. Er will weder updaten noch etwas installieren lassen, dass die Bots draußen hält.

... einmal mit Profis arbeiten ...

:rolleyes:

https://perishablepress.com/6g/ et al.

Danke ;-)

Über diese Seite haben wir auch schon miteinander diskutiert. Der Mensch vertritt die Meinung, dass der Serverbetreiber diese Vorkehrungen treffen müsste. Er glaubt, es handele sich dabei um DDOS-Attacken - gegen die der Serverbetreiber ja auch vorgehen müsse. Daher suchte ich nach etwas, was mehr "basic" ist... so eine Art "was ist was: Robots". Aber inzwischen denke ich, dass er es gar nicht verstehen will ...

Naja, wer ist denn der Serverbetreiber, und wofür wird der bezahlt? Das kann ja entweder jemand mit einer physischen Maschine sein, oder jemand, der mir ein wenig Webspace gibt. Obendrein mag es die Einstellung geben, entweder alles zu blocken was da primär nicht hingehört (aber wer definiert das?) oder alternativ sich am Listing auf mittelöstlichen Malwareschleudern zu erfreuen - mithin: es liegt im Auge des Betrachters, und insofern muss man das sicher auch immer an individuelle Bedürfnisse anpassen.

Mein Sohn war mal sehr sauer, als ich ihm den Versuch, sein Taschengeld aufzubessern, indem er klickbait- und botanziehende Werbeblogs auf einem von mir zur Verfügung gestellten Serverspace durch massive Blocklisten vereitelte - das war so der Klassiker, bei dem ich als Betreiberin nach allen Regeln der Kunst gehandelt habe und er (der Quasi-Kunde) das gar nicht wollte. Vielleicht erzählst Du Deinem Kunden mal so eine Geschichte?

Hehe ;-)

Es handelt sich um ein Shared-Hosting-Paket bei Domainfactory für rd. 25 Flocken im Monat - und für das viele Geld kann man ja einiges erwarten ;-)
:mad: :p :rolleyes:

Manchmal würde ich den Leuten gern gleich zu Beginn einen Realitätscheck verkaufen ...

Moin,

nach einiger Zeit Beobachtung und manueller Pflege der "G6 Firewall" suche ich nach anderen Lösungen.

Denn ich habe jetzt eine Zeit lang die "schlimmsten" IP-Adressen nach und nach gesammelt und in die htaccess eingetragen (innerhalb der "G6 Firewall"), habe das Problem allerdings noch nicht im Griff.

Zu tun habe ich es
a) mit Bots, die inhaltlich harmlose Anfragen stellen, davon aber so viele in so kurzer Zeit, dass regelmäßig (alle paar Tage) die Datenbank in die Knie geht
b) mit offensichtlich bösartigen Anfragen (Suchen nach wp-login.php), die vielseitiger sind, aber nicht so aggressiv und daher mir eigentlich egal.

Mein Problem ist a. Binnen von Minuten werden hunderte von identischen Not-Found-Einträgen verursacht, wenn die Datenbank nicht mehr kann landen entsprechende Fehler in der error.log-Datei des Servers. Da ist es dann eigentlich schon "zu spät", denn die Website ist währenddessen mal wieder nicht erreichbar. Der letzte Vorfall dieser Art dauerte immerhin 7 Minuten. D.h. 7 Minuten lang kamen so viele Anfragen, dass sie nicht abgearbeitet werden konnten.

(Mir ist klar, dass es ab der 4er-Version keine 404-Errors mehr in die Datenbank geschrieben werden. Hilft mir aber jetzt nicht weiter ;-) )

Hat jemand einen Rat?

Kann ich das Mitloggen manuell ausknipsen? Es muss auch nicht updatesicher sein ...

@ ToNoma, wie hast Du das Problem bei Dir gelöst?

Vor einiger Zeit hatte ich mir das mal angesehen und ermittelt, dass man es sogar Update-Sicher entfernen könnte. Allerdings wurde das damals dann doch nicht finanziert.

Ich bin mir auch nicht zu 100% sicher, ob das für mich tatsächlich die Lösung wäre.

Heute wurde die Datenbank auch wieder abgeschossen, zwei mal, jeweils für ein paar Minuten. Ich fische dann immer die IP heraus und setze sie zu den geblockten, aber nächstes mal ist es dann eine andere...

Ich weiß auch nicht, wo ich eine anständige Blacklist herbekommen kann.

Und was ich auch nicht weiß: würden diese "Angriffe" die Datenbank auch dann lahmlegen, wenn keine Einträge geschrieben werden? Denn "reagieren" muss das System ja auch so, auch wenn die Vorgänge dann nicht so rechenintensiv sind.

Naja, du müsstest einfach herausfinden, was genau deine Datenbank lahmlegt. Also welche Queries.

Das ist leider nicht immer einfach herauszufinden.

Beispiel 1, heute, zwischen 10:53 und 10:56 wurden 49 Einträge in die error.log-Datei des Servers geschrieben. Wie diese und ähnliche Meldungen (alle mit "connection refused" und unterschiedlichen Zeilen der Mysql.php):

PHP Warning: mysql_connect(): Connection refused in ... system/modules/core/library/Contao/Database/Mysql.php on line 54

#0 (...)/system/modules/core/library/Contao/Database.php(73): Contao\Database\Mysql->connect()
#1 (...)/system/modules/core/library/Contao/Database.php(157): Contao\Database->__construct(Array)
#2 [internal function]: Contao\Database::getInstance()
#3 (...)/system/modules/core/library/Contao/System.php(124): call_user_func(Array)
#4 (...)/system/modules/core/library/Contao/User.php(85): Contao\System->import('Database')
#5 (...)/system/modules/core/classes/FrontendUser.php(70): Contao\User->__construct()
#6 (...)/system/modules/core/library/Contao/User.php(147): Contao\FrontendUser->__construct()
#7 (...)/system/cache/config/config.php(1238): Contao\User::getInstance()
#8 (...)/system/modules/core/library/Contao/Config.php(130): include('/kunden/446546_...')
#9 (...)/system/modules/core/library/Contao/Config.php(108): Contao\Config->initialize()
#10 (...)/system/initialize.php(162): Contao\Config::getInstance()
#11 (...)/index.php(16): require('(...)_...')
#12 {main}

In diesem Zeitfenster gibt es - logischerweise - keine Einträge in Contaos tl_log, da die Datenbank ja gestört war. Interessant sind dann immer die unmittelbar davor oder danach aufgelaufenen 404-Fehler. In diesem Fall gibt es aber genau davor oder danach keine. Die Fehler haben alle einen Abstand von mehreren Minuten und sind aus unterschiedlichen Quellen/ IP-Adressen, so dass ich sie nicht genau zuordnen kann.


2. Beispiel, was wesentlich klarer zu "greifen" ist:
Von einer IP-Adresse, die ich inzwischen geblockt habe, kamen Anfragen zu immer derselben URL, die mit einem "server-status?auto" endete. Der "Browser" war "libwww-perl/6.04". Inzwischen habe ich gelesen, dass ich auch gezielt Anfragen von diesen Pearl-Scripten blocken kann und werde das auch asap tun.
Diese Quelle erzeugte allein am Karfreitag einen Serverausfall von 7 Minuten, umrahmt von 1.400 404-Einträgen, die jeweils zum Start und Ende einer "Attacke" noch protokolliert wurden.



3. Beispiel, heute 12:49 bis 12:55 Uhr

[18-Apr-2017 12:49:31 Europe/Berlin]
PHP Warning: mysql_query(): MySQL server has gone away in (...) /system/modules/core/library/Contao/Database/Mysql/Statement.php on line 74
#0 [internal function]: __error(2, 'mysql_query(): ...', '(...)_...', 74, Array)
#1 (...)/system/modules/core/library/Contao/Database/Mysql/Statement.php(74): mysql_query('SELECT * FROM t...', Resource id #36)
#2 (...)/system/modules/core/library/Contao/Database/Statement.php(291): Contao\Database\Mysql\Statement->execute_query()
#3 (...)/system/modules/core/library/Contao/Database/Statement.php(262): Contao\Database\Statement->query()
#4 (...)/system/modules/core/library/Contao/Model.php(944): Contao\Database\Statement->execute('14')
#5 (...)/system/modules/core/library/Contao/Model.php(660): Contao\Model::find(Array)
#6(...)/system/modules/dlh_googlemaps/classes/Googlemap.php(62): Contao\Model::findByPk('14')
#7 (...)/system/modules/dlh_googlemaps/elements/ContentMap.php(79): delahaye\googlemaps\Googlemap::getMapData('14', 'html5', Array)
#8 (...)/system/modules/core/elements/ContentElement.php(165): delahaye\googlemaps\ContentMap->compile()
#9 (...)/system/modules/dlh_googlemaps/elements/ContentMap.php(53): Contao\ContentElement->generate()
#10 (...)/system/modules/core/library/Contao/Controller.php(469): delahaye\googlemaps\ContentMap->generate()
#11 (...)/system/modules/core/modules/ModuleArticle.php(187): Contao\Controller::getContentElement(Object(Contao \ContentModel), 'main')
#12 (...)/system/modules/core/modules/Module.php(154): Contao\ModuleArticle->compile()
#13 (...)/system/modules/core/modules/ModuleArticle.php(50): Contao\Module->generate()
#14 (...)/system/modules/core/library/Contao/Controller.php(405): Contao\ModuleArticle->generate(false)
#15 (...)/system/modules/core/library/Contao/Controller.php(269): Contao\Controller::getArticle(Object(Contao\Articl eModel), true, false, 'main')
#16 (...)/system/modules/core/pages/PageRegular.php(129): Contao\Controller::getFrontendModule('0', 'main')
#17 (...)/system/modules/core/controllers/FrontendIndex.php(250): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#18 (...)/index.php(20): Contao\FrontendIndex->run()
#19 {main}

[18-Apr-2017 12:49:31 Europe/Berlin]
PHP Warning: mysql_query(): Error reading result set's header in (...) /system/modules/core/library/Contao/Database/Mysql/Statement.php on line 74

.. has gone away, connection refused etc...

Leider weder davor noch danach irgendwelche verdächtigen 404-Einträge in der tl_log.

Ich bin wirklich ratlos, was ich - nimmt man nur den Fall von 12:55 Uhr heute - tun kann. Hat das am Ende nur manchmal was mit den Bots zu tun und manchmal nicht? ...

Ja schon klar, aber der Hoster müsste herausfinden können warum die Verbindung zum MySQL Server abbricht bzw. zu welchem Zeitpunkt der MySQL Server crashed.

Habe den heute bereits kontaktiert...

Inzwischen suche ich mal weiter nach einer adäquadten Bot-Blacklist...

Nochmal ne andere Frage...

Ich versuche gerade, zusätzlich noch bestimmte Ausdrücke zu blocken. Z.B. so:

# Block via Query String
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (ausdruck|nocheinausdruck) [NC]
RewriteRule (.*) - [F,L]
</IfModule>

Ich hatte jetzt erwartet, URLs wie (meine-website.com/ausdruck.html) geblockt werden und nicht auf der 404-Seite landen. Das tun sie aber trotzdem, und es entsteht auch ein Datenbankeintrag.

Schreibe ich das falsch (abgeguckt hier: https://perishablepress.com/block-bad-bots/) oder sind meine Erwartungen falsch?

Eine neue Beobachtung:
Einige Seitenaufrufe erzeugen einen 404-Eintrag, obwohl der Aufruf zur gewünschten Seite führt. Und zwar bei mehrsprachigen Seiten dann, wenn man die Sprache nicht mit in die URL mit eingibt.

Beispiel:

meinedomain.com/zielseite.html

führt automatisch zu

meinedomain.com/en/zielseite.html

Parallel wird ein 404-Eintrag in die tl_log geschrieben.

Wieso? :eek:

(Edit mit einem Redirect 301 Eintrag in der htaccess entsteht kein 404-Eintrag mehr. Irgendwie dachte ich, dass hierfür keine Redirects nötig wären...?)

meinedomain.com/en/zielseite.html existiert auch tatsächlich? Wie lautet der genau System Log Eintrag? Wie lautet der genaue Link zu dieser Seite?

Ich muss die Domain leider anonymisieren.

No active page for page ID "", host "meinedomain.com" and languages "de, en-US, en" (http://meinedomain.com/zielseite.html)

Wenn ich jetzt quasi http://meinedomain.com/zielseite.html in den Browser eingebe, wird das "/en/" automatisch hinzugefügt:http://meinedomain.com/zielseite.html. Die Seite existiert und kann auch normal über die Navigation angesteuert werden, dann ist das "en" ja automatisch schon dabei.

Das ist generell immer so, wenn ich das "en" im Pfad weglasse, also nicht nur bei einer Seite. So erklären sich einige der vielen 404-Einträge. Die Website war zuvor einsprachig und hat den Sprachzusatz in der URL erst bekommen, als sie schon in div. Suchmaschinen ohne /en/ indiziert war. Etliche Crawler rennen da stündlich durch und suchen nach Pfaden ohne "en".

Ich guck mal, ob ich das auch mit anderen Installationen reproduzieren kann.

Das beantwortet nicht meine Frage. Existiert die Seite nun oder nicht? Wenn nicht, ist es klar, dass da ein 404 kommt.

? Dann bin ich wohl zu blöd für die Frage...

Zitat:

---

Die Seite existiert und kann auch normal über die Navigation angesteuert werden, dann ist das "en" ja automatisch schon dabei.

---

http://meinedomain.com/en/zielseite.html <- existiert, steht auch genau so in der XML-Sitemap.

/en/ ist dabei kein Unterverzeichnis sondern das von Contao automatisch zugesetzte Sprachkürzel. Sprache ist Englisch. Fallback ist Englisch.

Wenn man das Sprachkürzel bei der URL weglässt, setzt Contao das Sprachkürzel automatisch dazu. Man landet auf der existierenden Seite.

Ja, wenn http://meinedomain.com/en/zielseite.html existiert dann ist es komisch, dass dafür ein 404 Eintrag erzeugt wird.

Hier schreibt nochmal zu diesem Thema eine PHP-Nichtfachfrau. Was kann ich nun tun?
Ich habe seit geraumer Zeit in der System-Log ebenfalls "No active page for page ID ...", die entweder auf geänderte (aus Versehen ein Umlaut gewesen) oder gelöschte Seiten/Arikel, aber auch neuerdings ganz normale aktive Seiten hinweisen, die sich ganz normal aufrufen lassen. Hinzu kommen Event-Seiten, die nicht veröffentlich werden. Zu Beginn hat mich das nicht weiter gestört. Aber jetzt bin ich doch verwirrt und möchte das ändern, da es zu o.g. "Überlauf" führen kann und außerdem nervt es langsam aber sicher!
Wie kann ich dem begegnen?

Freue mich auf Antwort.

Zitat:

---

Zitat von Monic49

aber auch neuerdings ganz normale aktive Seiten hinweisen, die sich ganz normal aufrufen lassen.

---

Wie lautet der komplette Log Eintrag dazu? Ohne Zensur.

Hallo Monic49,

die Events sind dann sicher in der Sitemap erlaubt eingestellt und werden dann auch an die sitemap.xml-Datei weitergegeben. Hier dann auf den Seiten, wo das Listen- und das Lesermodul eingebunden ist, die Option für die Anzeige in der Sitemap auf ”Nie anzeigen” einstellen.

Für geänderte Seiten und -aliase hilft in der Regel das Anlegen eines 301-Redirects in der .htaccess-Datei im Root von Contao.

[2017-04-24 11:35] No active page for page ID "presse", host "meine domain.de" and languages "" (http:/meine Domain.de/presse.html) - diesen Seite gibt es nicht mehr.
[2017-04-24 05:11] No active page for page ID "Le_Laudi", host "meine domain.de" and languages "" (http://meine domain.de/Le_Laudi.html) - diese Seite gibt es, aber aufrufbar nur über Menü, da ist richtiger Weise der Seitenalias: le-laudi.html.
Tsss alles vor x-Zeiten geänderte Sachen.


Sitemap habe ich nicht eingebaut. Ich schau mal... Danke für die Tipps

Du hast die Domains zensiert. Poste die Meldung aus dem Log so wie sie ist, ohne Änderung. Darüberhinaus verstehe ich nicht, was du hier meinst:

Zitat:

---

Zitat von Monic49

[2017-04-24 05:11] No active page for page ID "Le_Laudi", host "meine domain.de" and languages "" (http://meine domain.de/Le_Laudi.html) - diese Seite gibt es, aber aufrufbar nur über Menü, da ist richtiger Weise der Seitenalias: le-laudi.html.

---

Inzwischen habe ich in Systemwartung alle caches gelöscht und da ist nun bei neustart ins Backend alles weg. Aber fürs nächste mal:
Ich kann dir nur das gleiche nochmal aufzeigen
[2017-04-24 11:35] No active page for page ID "presse", host "singakademie-ffo.de" and languages "" (http:/singakademie-ffo.de/presse.html) - diesen Seite gibt es nicht mehr.
[2017-04-24 05:11] No active page for page ID "Le_Laudi", host "singakademie-ffo.de" and languages "" (http:/singakademie-ffo.de/Le_Laudi.html) - diese Seite gibt es, aber aufrufbar nur über Menü, da ist richtiger Weise der Seitenalias: http://singakademie-ffo.de/le-laudi.html - mittlerweile https://singakademie-ffo.de/le-laudi.html

viele Grüße
Monic49

Verstehe ich nicht, aus dem Aufruf mit Le_Laudi wird doch die Seite .../Le_Laudi.html aufgerufen. .../le-laudi.html ist doch was ganz anderes (Du musst mit Maschinenaugen gucken :-)

Außerdem ist als Sprache immer "" angegeben, d.h. der Aufruf bringt keine Sprache mit und dafür gibt es bei Contao nur die Fallback-Sprache. Wahrscheinlich wurde auch dorthin weitergeleitet und trotzdem ein Log-Eintrag gespeichert, sofern es sich um eine vorhandene Seite handelt.

Zitat:

---

Zitat von Monic49

Inzwischen habe ich in Systemwartung alle caches gelöscht und da ist nun bei neustart ins Backend alles weg. Aber fürs nächste mal:
Ich kann dir nur das gleiche nochmal aufzeigen
[2017-04-24 11:35] No active page for page ID "presse", host "singakademie-ffo.de" and languages "" (http:/singakademie-ffo.de/presse.html) - diesen Seite gibt es nicht mehr.
[2017-04-24 05:11] No active page for page ID "Le_Laudi", host "singakademie-ffo.de" and languages "" (http:/singakademie-ffo.de/Le_Laudi.html) - diese Seite gibt es, aber aufrufbar nur über Menü, da ist richtiger Weise der Seitenalias: http://singakademie-ffo.de/le-laudi.html - mittlerweile https://singakademie-ffo.de/le-laudi.html

viele Grüße
Monic49

---

Die Seite http://singakademie-ffo.de/Le_Laudi.html existiert nicht, daher kommt es auch zu diesem System Log Eintrag.

Ja habe schon alles richtig erkannt. Aber warum erscheint diese Ausschrift? Lag das nur am cache, den ich nicht sofort nach Änderung löschte? Ich muss halt mehr aufpassen.
Mit der Sprache liege ich im Klinsch: Sprache im "ersten" Startpunkt: de und Haken in Sprachen-Fallback kann ich nur eintragen. Ich nutze nur deutsche Sprache.


Ich danke euch.

Zitat:

---

Zitat von Monic49

Ja habe schon alles richtig erkannt. Aber warum erscheint diese Ausschrift?

---

Wenn zu irgendeinem Zeitpunkt die URL http://singakademie-ffo.de/Le_Laudi.html angezeigt war, dann wird sie auch irgendwann mal durch irgendwen aufgerufen. Und wenn unter dieser URL dann tatsächlich nichts zu finden ist, kommt es zu diesem System Log Eintrag.

Zitat:

---

Zitat von Monic49

Mit der Sprache liege ich im Klinsch: Sprache im "ersten" Startpunkt: de und Haken in Sprachen-Fallback kann ich nur eintragen. Ich nutze nur deutsche Sprache.

---

Was genau meinst du?

Danke für die Antwort und einem besseren Verstehen der System-Log-Einträge. Es sind gerade wieder neue Einträge erschienen von html-Aufrufen der wahrscheinlich geänderten Website (arbeite mitlerweile mit anderem Theme)
[2017-04-24 15:02] No active page for page ID "geschichte", host "singakademie-ffo.de" and languages "de, en-US, en" (https://singakademie-ffo.de/geschichte.html)
und da ist auch der Spracheneintrag vorhanden.

Die Seite https://singakademie-ffo.de/geschichte.html existiert nicht, daher kommt es auch zu diesem System Log Eintrag.

Was meinst du mit der Sprache?

Stimmt, es gibt da nur https://singakademie-ffo.de/geschichte-220.html

Hi Monic49,

wenn man bei Dir über das Menü auf die Seite "Geschichte" geht, steht in der URL das hier:
https://singakademie-ffo.de/geschichte-220.html

Vielleicht lautete die URL früher einmal so:
https://singakademie-ffo.de/geschichte.html
So wurde sie dann auch in Suchmaschinen gespeichert. Klickt nun jemand auf den Link, entsteht die Fehlermeldung, da die Seite inzwischen umbenannt wurde.

Du kannst nun die Seite wieder "geschichte" nennen, dann stimmen die Links wieder.
Wenn nun aber in der Zwischenzeit Google & Co den neuen Link ebenfalls in den Index aufgenommen haben (und in ihren tw. hartnäckigen Cache), kehrt sich das Problem um: dann klickt jemand auf geschichte-220.html und bekommt ein Not-Found.

Ich würde mit 301 Redirects in der htaccess arbeiten. Kennst Du Dich damit ein bißchen aus?

ja aber wer ruft die denn auf? Robots?

Ich habe bis zu 4 (jetzt noch 3) "Startpunkte einer Website" aber nur in der ersten kann ich Sprachenfallback eintragen. Aber das ist wohl ok so.

Danke- hat sich jetzt überschnitten.

Nein kenne mich nur wenig mit htaccess aus. Leider :-(

Robots oder Menschen ... über Suchmaschinen oder auch Bookmarks?

Sprachenfallback kann es nur eins geben, korrekt. Würde die Häkchen bei den Startpunkten, die nicht das Fallback sind, rausnehmen.

Nachtrag: ist die Website überhaupt mehrsprachig? ich sehe da gar keinen Sprachumschalter...

Schau dir deine Seitenaliase alle nochmal an, da sind noch andere dabei, die hinten noch eine Zahl (id?) dranhängen haben. Falls das nicht so gewollt ist, würde ich die zur Sicherheit notieren und dann möglichst schnell ändern. Dann nötigenfalls in der .htaccess auf die neuen Aliase umschreiben.

Zitat:

---

Zitat von Monic49

ja aber wer ruft die denn auf? Robots?

---

Das siehst du (mehr oder weniger) in den Details des System Log Eintrags.

Vielen Dank euch allen.
Wie sieht denn das in der .htaccess für "Geschichte" zum Beispiel aus?
Für Änderungen wird es wohl zu spät sein- ist ja schon ein Dreivierteljahr so drinnen und dann kommt der Umkehrschluss.

Mehrsprachigkeit ist nur für später vorgesehen. Dann wird es erst spannend.

@ Monic
Wozu dienen dann die verschiedenen Seitenbäume, die Du hast?

Zur htaccess lies Dir am besten erstmal die Basics an - und mache in Backup Deiner htaccess.
Z.B. hier https://wiki.selfhtml.org/wiki/Webserver/mod_rewrite
Oder suche hier im Forum mal...

Ein 301 Eintrag für den o.g. Fall würde z.B. so aussehen

Redirect 301 /geschichte.html https://singakademie-ffo.de/geschichte-220.html




@ wen es interessiert
Ich konnte "mein Problem" jetzt an anderen Installationen reproduzieren - 3.4.x Installationen und 3.5.x Installationen:
Wenn eine existierende Seite ohne Sprachkürzel im Browser aufgerufen wird, ergänzt das System das Sprachkürzel automatisch und man landet auf der gewünschten Seite. Parallel - und das ist das Problem - entsteht ein 404-Error-Eintrag in der Datenbank.

Ich werde jetzt als Notlösung für alle URLs Redirects schreiben, wobei mir natürlich dennoch interessieren würde, ob es einen "guten Grund" gibt, warum sich das so verhält. Ich habe leider nirgendwo die 3.5.26 am Start, habe in in den Changelogs allerdings dazu nichts gesehen (und hoffentlich nicht übersehen), so dass ich davon ausgehe, dass es auch in der 3.5.26 noch so ist.

Für alle mit dem gleichen Problem:
So sieht mein Ergebnis aus am Beispiel "Geschichte" und es funktioniert:

Redirect 301 /geschichte.html https://singakademie-ffo.de/geschichte-220.html

Herzlichen Dank an alle!

Danke auch dir pipkin, du warst eine Sec. schneller :-)

Achso die Seitenbäume: habe ich für jede Mitgliedergruppe, in die sie sich auch extra einloggen, also gesperrt sind für die Öffentlichkeit. So läuft das ganz gut.

Zitat:

---

Zitat von pipkin

@ wen es interessiert
Ich konnte "mein Problem" jetzt an anderen Installationen reproduzieren - 3.4.x Installationen und 3.5.x Installationen:
Wenn eine existierende Seite ohne Sprachkürzel im Browser aufgerufen wird, ergänzt das System das Sprachkürzel automatisch und man landet auf der gewünschten Seite. Parallel - und das ist das Problem - entsteht ein 404-Error-Eintrag in der Datenbank.

---

Das kann ich nicht bestätigen. Wenn ich http://example.org/foo.html eingebe werde ich auf http://example.org/en/foo.html weitergeleitet. Im System Log steht dann auch

Zitat:

---

No active page for page ID "", host "example.org" and languages "en, en-GB, de-AT, de" (http://example.org/en/foo.html)

---

wenn es die Seite mit dem Alias "foo" nicht im englischen Seitenbaum gibt.

Ich habe contao 3.5.18. Alles funktioniert . Aber unter system-log bekomme ich auch dauernd diese Fehlermeldug: No active page for page ID "18"
Kann ich einfach die Job-Dateien löschen?