Notfalls manuell herunterladen und installieren.
Notfalls manuell herunterladen und installieren.
Bedanke mich für die Hilfe!
Ich habe nun über die Einstellungen dafür gesorgt das auch "inkompatible" Erweiterungen angezeigt werden.
Sodann konnte ich Version 1.6.2 installieren und meine Seite sieht wieder aus wie meine Seite...
Mein letzter Punkt aus der Liste (3) ist als einziger noch ungeklärt. Was ich bisher dazu gelesen habe erschließt
sich mir nicht wirklich...
Lade dir dieses Template herunter: https://gist.github.com/fritzmg/81acff5ed269f3281ee1 (wie schon mehrmals erwähnt)
Gib es in deinen /templates Ordner und lasse dann den Suchindex nochmal neu aufbauen. Beobachte ob sich dann zumindest "farblich" mehr tut . Wenn nicht, befolge die Instruktionen aus diesem Post.
Ich glaube das Problem mit der Fehlermeldung nach dem Update auf 3.5.17 gelöst zu haben. Zumindest habe ich seit der letzten Fehlermeldung gestern keine weitere erhalten. Was habe ich gemacht? Gute Frage... Die genaue Lösung kann ich nicht bestimmen, aber es wird eine der nachfolgenden Aktionen gewesen sein müssen:
Einmal habe ich die htaccess bearbeitet. Dort hatte ich folgende Zeilen auskommentiert:
URL-Rewriting (ohne HTML-Suffix)
Code:RewriteCond %{REQUEST_FILENAME} !\.(htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|mp4|webm|ogv|mp3|ogg|oga|eot|otf|tt[cf]|woff2?|svgz?|pdf|gz|eps|zip|html|phpx)$ #RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* index.php [L]
Für Referer-Spam:
Code:#RewriteCond %{HTTP_REFERER} ^http(s)?://(www.)?.*example1\.com [NC,OR] #RewriteCond %{HTTP_REFERER} ^http(s)?://(www.)?.*example2\.com [NC,OR] #RewriteCond %{HTTP_REFERER} ^http(s)?://(www.)?.*example3\.com [NC] #RewriteRule ^(.*)$ – [F,L]
Bilder-Klau:
Code:#RewriteCond %{HTTP_REFERER} !^$ #RewriteCond %{HTTP_REFERER} !^http(s)*://(.*\.)?example1\.com(/.*)?$ [NC] #RewriteCond %{HTTP_REFERER} !^http(s)*://(.*\.)?example2\.com(/.*)?$ [NC] #RewriteCond %{HTTP_REFERER} !^http(s)*://(.*\.)?example3\.com(/.*)?$ [NC] #RewriteRule .+\.(gif|jpg|png|jpeg|pdf)$ - [F]
Dann hatte ich noch das Template für Piwik-Analytics zwischen den Fingern. Dieses hatte ich an das aktuelle von Contao mitgelieferte Template angepasst.
Was davon jetzt genau die Lösung war, weiß ich nicht und mir fehlt momentan leider die Zeit zum Testen. Aber vielleicht hilft mein Post ja trotzdem irgendwie, irgendwem...
Ich glaube nichts davon ist die Lösung
Wurde der Fehler eigentlich mit dem Update auf 3.5.17 behoben?
Welcher Fehler genau? Der Fehler der auftritt, wenn du von einer früheren Contao Version auf 3.5.10 oder später aktualisierst, ohne vorher den Suchindex zu leeren, wurde (und wird wahrscheinlich) nie behoben. Siehe dazu: https://github.com/contao/core/issues/8320
Hallo,
ich habe ebenfalls eine Website von 3.5.15 auf 3.5.17 upgedatet ohne vorher den Index zu löschen.
Beim löschen der Datenbankspalte gab es eine Fehlermeldung, welche aber nach einem Weg über das Install-Tool verschwunden ist und ich die Spalte über "Datenbank aktualisieren" entfernen konnte.
Allerdings kann ich den Suchindex nicht neu aufbauen!
Gleiches Phänomen wie schon weiter oben beschrieben:
Es erscheint die Meldung "Bitte warten Sie, während der Suchindex neu aufgebaut wird.", das Rädchen daneben dreht sich und es passiert nichts.
Die Meldungen werden nicht grün, es werden keine Inhalte in die Datenbank geschrieben.
Auch das habe ich gemacht. Die Ansicht hat sich durch das Template (einfach nur in den "/templates" Ordner legen - Richtig?) aber nicht verändert und der Firefox Debugger meldet auch nichts.
"Daten bereinigen" und ein nochmaliger Versuch den Suchindex aufzubauen bringt ach nichts.
Die Tabelle "tl_search" über phpMyAdmin zu löschen bringt auch nichts, die ist ja schon leer...
Gibt es sonst noch etwas das ich versuchen kann um den Suchindex wieder aufzubauen?
Das heißt die Requests werden nicht mal abgesetzt? Ist ein JavaScript Fehler vorhanden?
Nein, nichts.
Doch etwas habe ich gefunden:
Code:getAttributeNode() sollte nicht mehr verwendet werden. Verwenden Sie stattdessen getAttribute().Code:this.Request<.send() i/i<() Request<.initialize/this.send() i[t]() i/i<() <anonym> forEach() forEach() .each() <anonym> .fireEvent/<() forEach() forEach() .each() .fireEvent() h()Kann es damit zusammenhängen?Code:Laden von gemischten aktiven Inhalten "http://www.domain.de/" wurde blockiert.[Weitere Informationen -> https://developer.mozilla.org/en-US/.../Mixed_content]
Das ist egal, das ist nur eine Warning.
Ja, da ist das Problem. Scheinbar lässt du Seiten indizieren, die entweder auf einer anderer Domain liegen als der Domain über die du dich in das Backend eingeloggt hast, oder die Seiten sind nicht für HTTPS in der Seitenstruktur konfiguriert und du hast dich über HTTPS in das Backend eingelogged.
Ich möchte das ursprüngliche Thema noch einmal aufgreifen, da das Problem bei mir selbst mit Version 3.5.19 leider noch nicht behoben ist. Allerdings sind nur Seiten aus dem Nachrichten-Bereich betroffen, die mittels Nachrichtenleser generiert werden und dann einen "Duplicate entry"-Fehler in der tl_search-Tabelle erzeugen.
Ich habe die Datei /system/modules/core/library/Contao/Search.php einmal analysiert, da er nicht auftritt, sobald ich im Backend eingeloggt bin. Dabei ist mir aufgefallen, dass die Variable $arrSet['pid'] bei einem normalen Besucher seltsamerweise die ID des Nachrichten-Beitrags selbst enthält und nicht, wie es korrekt wäre, die der Seite, die den Nachrichtenleser als Modul eingebunden hat. Daher wird die bereits existierende Seite in der Datenbank-Abfrage auch nicht gefunden und der Fehler generiert, da die Hash-Werte natürlich übereinstimmen.
Kann das evtl. jemand reproduzieren!?
Gruß Tim
Teste das nochmal im abgesicherten Modus von Contao. Das kann eigentlich nur an einer Extension liegen. Denn der pid Wert wird eigentlich direkt ausübernommen. Es wäre aber denkbar, dass irgendeine Extension, aus welchem Grund auch immer, bspw.PHP-Code:
global $objPage;
… $objPage->id …
oderPHP-Code:
global $objPage;
$objPage->id = …;
macht.PHP-Code:
$GLOBALS['objPage']->id = …;
Hallo Spooky, vielen Dank für deine schnelle Antwort! An den abgesicherten Modus hatte ich gar nicht mehr gedacht. Anschließend habe ich alle Erweiterungen nacheinander einzeln abgeschaltet.
Du hattest recht, es liegt bei mir an einer Erweiterung. Offentlichtlich überschreibt der Besucherzähler [visitors] bei Nachrichtenseiten die ID der eigentlichen Seite mit der des Nachrichteneintrags. Das erklärt auch, warum das Problem nicht auftritt, sobald man im Backend eingeloggt ist und der Besucherzähler nicht greift. Ich werde BugBuster diesbzgl. mal eine Mail schreiben.
Ja tatsächlich. Die entsprechende Stelle ist https://github.com/BugBuster1701/vis...rsTag.php#L677
@BugBuster ich nehme an du arbeitest bereits dran?
Sagen wir mal, heute noch. Noch bin ich auf Arbeit.
https://github.com/BugBuster1701/visitors/issues/211
Geändert von BugBuster (18.11.2016 um 14:13 Uhr)
Grüße, BugBuster"view source" is your guide.Danke an alle Amazon Wunschlisten Erfüller
Version 3.7.4 von Visitors sollte das hoffentlich beheben.
Gerade für Composer und im ER2 veröffentlicht.
Grüße, BugBuster"view source" is your guide.Danke an alle Amazon Wunschlisten Erfüller
Tausend Dank, BugBuster! Nach dem Update gibt es keine Fehlermeldungen mehr auf den Nachrichtenseiten.
Übrigens, wenn die Fehlerseiten direkt im Frontend kommen, dann ist das so bei den Einstellungen im Backend eingestellt worden.
Normalerweise kommen die Meldungen nur in der Contao error.log.
Grüße, BugBuster"view source" is your guide.Danke an alle Amazon Wunschlisten Erfüller
Hallo,
hatte auch das Problem - höchstwahrscheinlich nach Update von 3.1x (genaue Version nicht mehr sicher) via Easy Update auf 3.5.18
Nachdem ich den Suchindex via Systemwartung geleert und neu aufgebaut habe scheint das Problem nicht mehr aufzutreten. Habe Browsercache geleert und alle Seiten durchgesehen.
Nun meine Frage: Muss ich mir Sorgen machen dass das bei meinen Besuchern aus irgendwelchen Gründen trotzdem noch angezeigt könnte? Bzw wenn ich etwas im Contao mache dass es dann wieder auftritt?
Und könnte es sein dass es bei Kunden nach wie vor sichtbar ist welche ihren Browsercache nicht geleert haben?
Vielen Dank.
Verwendest du die Extension visitors oder cookiebar?
Ja stimmt - Cookiebar tatsächlich - habe ich aber vorher im Test deaktiviert. Kann die Ärger machen wenn ich sie wieder aktiviere?
Nein, du musst die cookiebar Extension einfach auf die neueste Version aktualisieren und danach den Suchindex löschen. Siehe https://github.com/codefog/contao-cookiebar/issues/21
Alles klar - habe das gemacht und die Cookiebar wieder aktiviert. Sieht gut aus.
Auch nachdem ich auf "Verstanden" geklickt und aktualisiert habe, passt es.
Vielen Dank für die Hilfe.
Nun taucht die Meldung leider doch wieder auf.
Ich kann leider nicht mit Sicherheit sagen ob jemand etwas im Backend gemacht hat, da mehrere Personen Zugriff haben.
Wenn jemand etwas gemacht hat, dann aber nur rein redaktionelle Tätigkeiten.
Contao 3.5.18
contao-legacy/cookiebar 1.1.1.9007
In der DB sehe ich in der Tabelle tl_search tatsächlich mehrere Seiten welche zweimal vorkommen, jeweils mit der gleichen pid, jedoch unterschiedlicher id.
Ich nehme an daher rührt die Fehlermeldung?
Habe jetzt mal die Fehlermeldungen in den Einstellungen deaktiviert da wir gerade großen Ansturm auf der Website haben.
Kann man so - klar nur als Zwischenlösung - sicher gehen dass die Meldung auch wirklich niemand sieht? Denn die Meldung zerstört das mobile Layout.
Vielen Dank.
Hallo Spooky,
ich bedanke mich für den Lösungsvorschlag mit dem Häkchen bei "HTTPS in Sitemaps" in der Seitenstruktur.
Wie schrieb ein andere User schon zuvor: "Manchmal kann es so einfach sein"...
Mein Problemsammelsurium ist damit abgearbeitet. Ich denke meine Lehre für die Zukunft ist, dass ich
nicht mehr mehrere Fehler zusammen in eine Anfrage packen werde... Denn das macht es unübersichtlich.
Tschüss...
Vielen dank, habe inzwischen vernommen dass es eine 3.5.19 Version gibt wo das gefixt wurde.
Habe jetzt gemacht was du gesagt hast:
- Suchindex geleert
- Contao (via easyupdate) auf 3.5.19 gebracht
- codefog/contao-cookiebar
Doch genau beim letzten Schritt habe ich ein Problem, Composer schreibt:
1. sieht es mir so aus als würde Composer denken ich bin noch Version 3.5.16?Code:Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 - The requested package contao/core (locked at 3.5.16, required as 3.5.19) is satisfiable by contao/core[3.5.16] but these conflict with your requirements or minimum-stability. Problem 2 - don't install codefog/contao-cookiebar 1.1.2|remove contao-legacy/cookiebar 1.1.1.9007 - don't install codefog/contao-cookiebar 1.1.2|don't install contao-legacy/cookiebar 1.1.1.9007 - don't install codefog/contao-cookiebar 1.1.2|don't install contao-legacy/cookiebar 1.1.1.9007 - don't install codefog/contao-cookiebar 1.1.2|don't install contao-legacy/cookiebar 1.1.1.9007 - Installation request for codefog/contao-cookiebar >=1.1.2.0,<1.2-dev -> satisfiable by codefog/contao-cookiebar[1.1.2]. - Installation request for contao-legacy/cookiebar (locked at 1.1.1.9007) -> satisfiable by contao-legacy/cookiebar[1.1.1.9007].
2. habe ich bereits contao-legacy/cookiebar deinstalliert, es erscheint auch nicht mehr in der Liste. Auch den Composer Cache habe ich geleert sowie Systemwartung durchgeführt.
Weiß jemand was ich machen kann? Ich kann dazu gerne ein eigenes Thema aufmachen falls das besser ist.
EDIT: Die Installation scheint zumindest geklappt zu haben, jedoch bleibt die Versionsinfoin roter Schrift.Code:>=1.1.2.0,<1.2-dev
Cookiebar wird im Frontend (auch nach leeren des Cache) angezeigt.
Geändert von gm-team (05.12.2016 um 16:42 Uhr)
Du hast cookiebar nun zwei mal in der composer.json drin. Einmal mitund einmal mitCode:codefog/contao-cookiebarund letzteres hast du auf eine fixe Version gelocked. Den contao-legacy Eintrag solltest du entfernen. Darüberhinaus ist vielleicht das Update auf Contao 3.5.19 nicht ganz geglückt. Validiere deine Contao Installation mit dem Contao Check.Code:contao-legacy/cookiebar
Als mich das Update in die install.php leitete, bekam ich zuerst einige Fehlermeldungen ala "cannot find ... classloader". Hab ich jetzt leider nicht gespeichert.
Bei erneutem Aufruf kam ich normal ins Installtool und konnte die DB updaten.
Check sagt aber "alles ok". Kann da trotzdem etwas schiefgelaufen sein?
Ja habe mich vorher schon gewundert warum in der composer.json noch immer contao-legacy drin ist.
Nur jetzt dürfte er es bei erneutem Installationsversuch tatsächlich gelöscht haben - ist nicht mehr drin.
Jedoch in der composer.lock schon noch - sollte ich das da rauslöschen?
Sorry ich dachte es genügt wenn ich nur den check aufrufe und mir da gleich eventuelle Fehler angezeigt werden.
Habe jetzt die Installation prüfen lassen, folgendes Ergebnis:
Und hier meine composer.json:Code:Version Eine Contao 3.5.19-Installation wurde gefunden. Fehlende Dateien .htaccess.default Ihre Installation ist nicht aktuell.
Code:{ "name": "local/website", "description": "A local website project", "type": "project", "license": "proprietary", "require": { "bugbuster/dlstats": ">=3.9.2.1,<3.10-dev", "codefog/contao-cookiebar": ">=1.1.2.0,<1.2-dev", "contao-community-alliance/composer-client": "~0.12", "contao-legacy/backupdb": ">=3.2.2.9016,<3.3-dev", "contao-legacy/clipboard": ">=2.0.3.9008,<2.1-dev", "contao-legacy/cron": ">=3.3.3.9004,<3.4-dev", "contao-legacy/dk_mmenu": ">=1.5.1.9007,<1.6-dev", "contao-legacy/dma_elementgenerator": ">=1.0.1.9003,<1.1-dev", "contao-legacy/easyupdate3": ">=3.3.3.9006,<3.4-dev", "contao-legacy/flexslider": ">=1.4.3.9004,<1.5-dev", "contao-legacy/googleanalytics": ">=1.4.0.9012,<1.5-dev", "contao-legacy/newsmetatitle": ">=2.0.0.9004,<2.1-dev", "contao-legacy/simple_news_urls": ">=2.0.3.9005,<2.1-dev", "fritzmg/contao-sharebuttons": ">=1.3.1.0,<1.4-dev", "lionel/superfish": ">=3.2.0.0,<3.3-dev" }, "prefer-stable": true, "minimum-stability": "dev", "config": { "preferred-install": "dist", "cache-dir": "cache", "component-dir": "../assets/components" }, "repositories": [ { "type": "composer", "url": "https://legacy-packages-via.contao-community-alliance.org/" }, { "type": "composer", "url": "https?://legacy-packages-via.contao-community-alliance.org", "allow_ssl_downgrade": false }, { "type": "artifact", "url": "packages" } ], "extra": { "contao": { "migrated": "done" } } }
Sieht nun alles korrekt aus. Einige deiner contao-legacy Pakete haben aber native Pakete. Die sollten dir in der Paketverwaltung eigentlich auch angezeigt werden.
Super danke für's drübersehen.
Ja, die anderen werden mir in der Paketverwaltung angezeigt.
Aktive Benutzer in diesem Thema: 2 (Registrierte Benutzer: 0, Gäste: 2)
Lesezeichen