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.