Vorsicht mit Contao CMS UPDATE auf 3.5.16 ...

**Spooky** · 22.09.2016, 12:42

Notfalls manuell herunterladen und installieren.

**sperelec** · 22.09.2016, 13:24

Zitat von Spooky

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...

**Spooky** · 22.09.2016, 13:26

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.

**Der Astronaut** · 22.09.2016, 18:09

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...

**Spooky** · 22.09.2016, 18:14

Ich glaube nichts davon ist die Lösung

**pretty-cool** · 07.10.2016, 10:30

Wurde der Fehler eigentlich mit dem Update auf 3.5.17 behoben?

**Spooky** · 07.10.2016, 10:39

Zitat von pretty-cool

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

**Cranker** · 10.10.2016, 11:17

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.

Zitat von Spooky

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.

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?

**Spooky** · 10.10.2016, 11:19

Zitat von Cranker

und der Firefox Debugger meldet auch nichts.

Was genau meinst du damit? Hast du die einzelnen Requests analysiert?

**Cranker** · 10.10.2016, 11:23

Was kann ich denn da analysieren?
Unter "Netzwerkanalyse -> XHR" steht nichts...

**Spooky** · 10.10.2016, 11:25

Das heißt die Requests werden nicht mal abgesetzt? Ist ein JavaScript Fehler vorhanden?

**Cranker** · 10.10.2016, 11:32

~~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()

Code:

Laden von gemischten aktiven Inhalten "http://www.domain.de/" wurde blockiert.[Weitere Informationen -> https://developer.mozilla.org/en-US/.../Mixed_content]

Kann es damit zusammenhängen?

**Cranker** · 11.10.2016, 16:12

Hat sonst noch jemand das Problem, das sich der Suchindex nicht aufbauen lässt?
Oder besser noch: Eine Lösung dafür? ;-)

**Spooky** · 11.10.2016, 16:15

Zitat von Cranker

Doch etwas habe ich gefunden:

Code:

getAttributeNode() sollte nicht mehr verwendet werden. Verwenden Sie stattdessen getAttribute().

Code:

…

Das ist egal, das ist nur eine Warning.

Zitat von Cranker

Code:

Laden von gemischten aktiven Inhalten "http://www.domain.de/" wurde blockiert.[Weitere Informationen -> https://developer.mozilla.org/en-US/.../Mixed_content]

Kann es damit zusammenhängen?

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.

**Cranker** · 11.10.2016, 16:42

Zitat von Spooky

[...] oder die Seiten sind nicht für HTTPS in der Seitenstruktur konfiguriert [...]

Was kann oder muss ich denn dort konfigurieren?

Ich rufe das Backend auf jeden Fall über HTTPS auf und alle Seiten liegen unter der gleichen Domain.
Daran kann es also nicht liegen...

**Spooky** · 11.10.2016, 16:43

Zitat von Cranker

Ich rufe das Backend auf jeden Fall über HTTPS auf

Dann musst du in der Seitenstruktur HTTPS für die Sitemap aktivieren - dann wird auch HTTPS für das Aufbauen des Suchindex verwendet.

**Cranker** · 11.10.2016, 17:02

Manche Dinge können so einfach sein :-)
Herzlichen Dank, das war genau der Haken der gefehlt hat.

**Silent-Bob** · 17.11.2016, 13:31

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

**Spooky** · 17.11.2016, 13:57

Teste das nochmal im abgesicherten Modus von Contao. Das kann eigentlich nur an einer Extension liegen. Denn der pid Wert wird eigentlich direkt aus

PHP-Code:


global $objPage;

… $objPage->id …

übernommen. Es wäre aber denkbar, dass irgendeine Extension, aus welchem Grund auch immer, bspw.

PHP-Code:


global $objPage;

$objPage->id = …;

oder

PHP-Code:


$GLOBALS['objPage']->id = …;

macht.

**Silent-Bob** · 18.11.2016, 13:30

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.

**Spooky** · 18.11.2016, 13:40

Ja tatsächlich. Die entsprechende Stelle ist https://github.com/BugBuster1701/vis...rsTag.php#L677

@BugBuster ich nehme an du arbeitest bereits dran?

**BugBuster** · 18.11.2016, 14:04

Sagen wir mal, heute noch. Noch bin ich auf Arbeit.

https://github.com/BugBuster1701/visitors/issues/211

**BugBuster** · 18.11.2016, 17:14

Version 3.7.4 von Visitors sollte das hoffentlich beheben.
Gerade für Composer und im ER2 veröffentlicht.

**Silent-Bob** · 18.11.2016, 18:12

Tausend Dank, BugBuster! Nach dem Update gibt es keine Fehlermeldungen mehr auf den Nachrichtenseiten.

**BugBuster** · 18.11.2016, 18:27

Ü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.

**gm-team** · 01.12.2016, 14:21

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.

**Spooky** · 01.12.2016, 14:22

Verwendest du die Extension visitors oder cookiebar?

**gm-team** · 01.12.2016, 14:38

Ja stimmt - Cookiebar tatsächlich - habe ich aber vorher im Test deaktiviert. Kann die Ärger machen wenn ich sie wieder aktiviere?

**Spooky** · 01.12.2016, 14:45

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

**gm-team** · 01.12.2016, 15:25

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.

**gm-team** · 02.12.2016, 14:20

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.

**Spooky** · 02.12.2016, 15:09

Zitat von gm-team

Contao 3.5.18
contao-legacy/cookiebar 1.1.1.9007

Wie schon erwähnt musst du auf Contao 3.5.19 aktualisieren und auf cookiebar 1.1.2 und davor (und vorsichtshalber danach auch) den Suchindex löschen. Darüberhinaus solltest du nicht contao-legacy/cookiebar verwenden, sondern codefog/contao-cookiebar.

**sperelec** · 04.12.2016, 16:25

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...

**gm-team** · 05.12.2016, 16:35

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:

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].

1. sieht es mir so aus als würde Composer denken ich bin noch Version 3.5.16?
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 Versionsinfo

Code:

>=1.1.2.0,<1.2-dev

in roter Schrift.
Cookiebar wird im Frontend (auch nach leeren des Cache) angezeigt.

**Spooky** · 05.12.2016, 16:38

Du hast cookiebar nun zwei mal in der composer.json drin. Einmal mit

Code:

codefog/contao-cookiebar

und einmal mit

Code:

contao-legacy/cookiebar

und 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.

**gm-team** · 05.12.2016, 16:49

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?

**Spooky** · 05.12.2016, 16:50

Zitat von gm-team

Check sagt aber "alles ok". Kann da trotzdem etwas schiefgelaufen sein?

Also die Validierung beanstandet keine Dateien?

Zitat von gm-team

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?

Ich denke da ist jetzt alles ok, wenn die Paket Aktualisierung erfolgreich durchlaufen konnte. Poste trotzdem mal deine gesamte /composer/composer.json.

**gm-team** · 05.12.2016, 17:08

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:

Code:

Version

Eine Contao 3.5.19-Installation wurde gefunden.

Fehlende Dateien

.htaccess.default
Ihre Installation ist nicht aktuell.

Und hier meine composer.json:

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"
        }
    }
}

**Spooky** · 05.12.2016, 17:21

Sieht nun alles korrekt aus. Einige deiner contao-legacy Pakete haben aber native Pakete. Die sollten dir in der Paketverwaltung eigentlich auch angezeigt werden.