CONTENIDO Forum

Hallo zusammen,

mir wurde (als Contenido-Nichtkenner) eine Contenido-Installation der Version 4.8.12 vor die Füße geworfen, die ich auf einem Ubuntu-Server mit PHP7 zum Laufen bringen soll. Allerdings war nicht mal das Kennwort des Benutzers "sysadmin" bekannt. Nun habe ich aufgrund der Doku-Lektüre verstanden, dass Contenido erst in der aktuellen 4.9er-Version unter PHP7 arbeitet. Außerdem habe ich nach Analyse des Datenbank-Dumps irgendwann gefunden, wo das Kennwort des Sysadmins gespeichert ist und habe es geändert. Ich bin nun soweit, dass das System in einer virtuellen Maschine mit PHP5 läuft und ich mich ins Backend einloggen kann. Der Zugriff auf's Frontend klappt nicht, weil es angeblich zu viele Umleitungen gibt - und da vermute ich, dass das Plugin AMR die Ursache ist (installiert in Version 0.5.4).

Unter "Content - AMR" (interessant, nicht unter "Extras") kann ich das Plugin deaktivieren, aber der Zugriff auf's Frontend klappt trotzdem nicht. Ich denke, die Datei .htaccess ist dafür verantwortlich, die von AMR erzeugt worden zu sein scheint. Wenn ich diese lösche, sehe ich im Browser ein Listing aller Dateien und Verzeichnisse im Root-Path, und wenn ich dann z.B. den Ordner CMS anklicke, werde ich automatisch auf die ursprüngliche (Internet-) Adresse der Webpräsenz geleitet - und bleibe damit nicht lokal. Allerdings habe ich keine Ahnung, woher diese Umleitung nun kommt. Wenn AMR deaktiviert ist und es keine .htaccess mehr gibt, dürfte das doch eigentlich nicht passieren, oder?

Nachtrag: soeben stelle ich fest, dass im Backend wohl auch nicht alles funktioniert. Zwar sehe ich unter "Content - Articles" eine Auflistung aller Artikel, aber wenn ich einen anklicke, sehe ich im rechten Fensterbereich keine Ansicht des Artikels - der Bereich bleibt einfach weiß.

Kann da jemand helfen?

Danke und viele Grüße,

fauxxami

Ich gehe mal davon aus, dass du noch in CON 4.8.12 bist und davon redest, ja? Sehr wahrscheinlich stimmen einfach nicht alle Pfadangaben.
Also: unter Administration/Mandanten musst du die für das Frontend korrekten relativen und absoluten Pfade anpassen, hast du das gemacht? Ebenso muss per FTP im Ordner /contenido/includes die config.php ggf. nachbearbeitet werden mit Pfaden und Datenbankzugängen, sofern du nicht das Setup drüber hast laufen lassen.
AMR erstmal ausschalten ist eine gute Idee. Der Aufruf des Frontend müsste dann über www.xxx.de/cms/front_content.php funktionieren.

Unter 4.9 wandert die AMR-Verwaltung dann tatsächlich nach EXTRAS. Jetzt schon vorneweg: WENN du auf die 4.9 willst, dann installiere bitte erstmal die 4.8.20 drüber und spring von dort aus auf die 4.9, die dann allerdings einiges an zusätzlicher Anpassungsarbeit erfordert. Darüber haben wir hier im Forum schon sehr viel erklärt und geschrieben, da müsstest du gute Treffer finden.

homtata hat geschrieben:Ich gehe mal davon aus, dass du noch in CON 4.8.12 bist und davon redest, ja?

Genau so ist es.

homtata hat geschrieben:Sehr wahrscheinlich stimmen einfach nicht alle Pfadangaben. Also: unter Administration/Mandanten musst du die für das Frontend korrekten relativen und absoluten Pfade anpassen, hast du das gemacht?

Das muss ich heute Abend, wenn ich wieder daheim bin, prüfen. Das kann ich so aus dem Gedächtnis nicht sagen. Aber danke für den Hinweis.

homtata hat geschrieben:Ebenso muss per FTP im Ordner /contenido/includes die config.php ggf. nachbearbeitet werden mit Pfaden und Datenbankzugängen, sofern du nicht das Setup drüber hast laufen lassen.

Das habe ich händisch gemacht; in meiner VM habe ich ja direkten Zugriff auf das Dateisystem.

homtata hat geschrieben:AMR erstmal ausschalten ist eine gute Idee. Der Aufruf des Frontend müsste dann über http://www.xxx.de/cms/front_content.php funktionieren.

Tja, das klappte bisher noch nicht - aber wie gesagt, heute Abend probiere ich es weiter.

homtata hat geschrieben:Unter 4.9 wandert die AMR-Verwaltung dann tatsächlich nach EXTRAS. Jetzt schon vorneweg: WENN du auf die 4.9 willst, dann installiere bitte erstmal die 4.8.20 drüber und spring von dort aus auf die 4.9, die dann allerdings einiges an zusätzlicher Anpassungsarbeit erfordert. Darüber haben wir hier im Forum schon sehr viel erklärt und geschrieben, da müsstest du gute Treffer finden.

Also: den von dir vorgeschlagenen Weg über 4.8.20 nach 4.9.12 bin ich bereits gegangen. Erst in 4.8.20 konnte ich die Spracheinstellungen so bearbeiten, dass der Upgrade-Vorgang letztlich geklappt hat. Sobald ich in der 4.9er-Version jedoch AMR deinstalliere (so wie ich es verstanden habe, brauche ich dort die Version 1.0.0, die mir ja auch in der Plugin-Liste angeboten wird), so funktioniert nach Logout/Login der Kopfbereich des Backends nicht mehr. Für mich ist das alles sehr verwirrend, zumal sich ja auch von 4.8 zu 4.9 an der Struktur der Konfig-Dateien einiges geändert hat. Wenn ich dann den alten Datenbank-Stand wieder einspiele (also den Stand, den ich vor der Deinstallation von AMR hatte), so klappt zumindest das Login wieder.

Wenn man keine Ahnung vom betreffenden CMS hat, sollte man vielleicht lieber die Finger davon lassen, aber nun hat mich der Ehrgeiz gepackt ...

Viele Grüße,

fauxxami

Ja, das ist ein steiniger Weg LOL
EIN Problem mit dem AMR könnte aus folgendem Umstand rühren: Bis 4.8.18 (einschließlich) war das AMR separat als Plugin zu installieren mit eigener Setuproutine, bevor es direkter in Contenido integriert wurde (ab 4.8.20). Daher wäre es ratsam, VOR dem Update auf 4.8.20 das Plugin komplett zu deinstallieren:
http://www.domain.de/contenido/plugins/ ... nstall.php (oder so ähnlich). Dann mit den Logindaten anmelden, auf der Sonderseite das Plugin deinstallieren.
Danach ist die Installation "sauber". Beim Update auf 4.8.20 kannst du während des Setups das AMR einfach mal NICHT mitinstallieren, ist egal.
Nach dem Upgrade auf 4.9.x ist das AMR dann wieder mit installierbar und mit drin.
Hintergrund: in etlichen Datenbanktabellen landen doppelte Einträge für AMR, wenn die alte Version nicht deinstalliert wird. Das ist der vermutliche Grund dafür, dass dein Backendheader spinnt.

homtata hat geschrieben:Daher wäre es ratsam, VOR dem Update auf 4.8.20 das Plugin komplett zu deinstallieren:

Das sollte man sogar unbedingt tun.

Das ist der vermutliche Grund dafür, dass dein Backendheader spinnt.

Man kann in der Tabelle con_nav_sub nachschauen, ob es dort einen Eintrag mit idnavs='10100' gibt, der in der Spalte dann navigation/content/mod_rewrite/ lautet.
Den müsste man in der 4.8.20 manuell löschen, wenn man verpasst hat, das AMR vorher zu deinstallieren.
In der Subnavigation bis 4.8.20 war das AMR im Content angesiedelt aber bei 4.8.20 ist es unter Extra.
Folglich findet man in 4.8.20 die gültigen Einträge dann in navigation/extra/mod_rewrite/

Wenn man Glück hat, ist in der Tabelle con_plugins noch das alte Plugin enthalten, dort stehen die Install-SQL als auch Uninstall-SQL.
In etwa so könnte es aussehen:

Code: Alles auswählen

DELETE FROM con_nav_sub WHERE idnavs='10100';
DELETE FROM con_frame_files WHERE idframefile='10104';
DELETE FROM con_frame_files WHERE idframefile='10103';
DELETE FROM con_files WHERE idfile='10104';
DELETE FROM con_files WHERE idfile='10103';
DELETE FROM con_area WHERE idarea='10100';
DELETE FROM con_plugins WHERE idplugin='1';

Wenn man in diese Tabellen schaut, wird man feststellen (im Falle man hat bei 4.8.20 AMR mit installiert), dass es mod_rewrite Einträge auch mit jeweils anderen IDs gibt.
Diese auf keinen Fall anfassen, das sind dann die neuen und gültigen Einträge.

Vermutlich gibt es auf dem Server im mod_rewrite Verzeichnis dann noch alte Dateien, die man unter anderem am Datum erkennt, aber auch z.B. eine install.sql, die z.B. noch in das Content Menü installieren will.

Code: Alles auswählen

INSERT INTO con_nav_sub VALUES ('10100', '1', '10100', '0', 'mod_rewrite/xml/;navigation/content/mod_rewrite', '1');

Darin sieht man wieder den Zusammenhang zwischen den Daten in der DB und dem Uninstall-SQL.
Sollte man auf eine 4.8.12 einfach nur das 4.8.20 mit dem Plugin AMR darüber installiert haben, befinden sich wahrscheinlich noch so einige Dateien im mod_rewrite Verzeichnis, die zum alten Plugin gehören und sich quasi nur noch durch das Datum unterscheiden lassen.

Und, alle Angaben ohne Gewähr.

Es könnte bei anderen Installation vielleicht anders sein.

Hallo zusammen!

Leider brauche ich nun doch einmal Hilfe: nachdem ich nun durch meine verschiedenen Aktualisierungsversuche selber nicht mehr durchgestiegen bin, bin ich auf den Ausgangszustand (Version 4.8.12) zurückgegangen und habe diese Version so angepasst, dass sie in meiner lokalen Arbeitsumgebung funktioniert. Das heißt:

Login ins Backend funktioniert
Artikel etc. werden in der Bearbeitungsansicht angezeigt
AMR ist noch installiert und aktiviert (mit deaktiviertem AMR funktioniert das Backend auch nur noch zur Hälfte)
Frontend wird trotz aller lokalen Anpassungen nicht angezeigt (der direkte Aufruf von cms/front_content.php wird nach wie vor auf die usprüngliche Webadresse umgeleitet)

In der Datenbank habe ich tatsächlich in "con_plugins" unter "uninstall" diesen Eintrag gefunden:

Code: Alles auswählen

DELETE FROM con_nav_sub WHERE idnavs='10100';
DELETE FROM con_frame_files WHERE idframefile='10104';
DELETE FROM con_frame_files WHERE idframefile='10103';
DELETE FROM con_files WHERE idfile='10104';
DELETE FROM con_files WHERE idfile='10103';
DELETE FROM con_area WHERE idarea='10100';
DELETE FROM con_plugins WHERE idplugin='1';

Ist AMR mit der Ausführung dieser Zeilen in der Datenbank dann tatsächlich gelöscht? Oder müssen noch Dateien entsorgt werden?

Mein Ziel ist es, eine "saubere" 4.8.12 ohne AMR zu haben, von der aus ich dann via 4.8.20 zu 4.9.12 kommen kann.

Ergänzung: Soeben habe ich in der Tabelle "con_art_lang" eine Umleitung auf die Willkommens-Seite gefunden - nach dem Löschen dieses Eintrags funktioniert nun auch das Frontend zumindest dann, wenn man cms/front_content.php direkt aufruft.

Euch allen ein frohes neues Jahr,

fauxxami

Als erstes solltest du die 4.8er richtig ans laufen bekommen.
Prüfe hier zuerst, ob der Startartikel eine Weiterleitung enthält, diese nimmst du dann ggf. raus.
Dann gehst du in das Verzeichnis, in dem die gesamte Webseite drin liegt, und benennst .htacccess in .htaccess_old um.
Am besten in der DB dann nochmal die DB-Tabelle con_code leeren (NICHT löschen... nur Truncate ausführen!)

Dann sollte das Frontend funktionieren - wenn es nur an dem AMR lag.
Es kann natürlich auch sein, das deine neue DB utf-8 als Standard verwendet, was die weißen Seiten im Article-Bereich erklären könnte (aber nicht muss, die Ursachen können vielfältig sein.... 1. Anlaufstelle: errorlog.txt von Contenido... 2. Anlaufstelle Webserverlogs).

Wenn du da bist, das alles in der aktuellen Version sauber läuft, schiebst du das Upgrade auf 4.8.20 drüber (das ist noch unproblematisch und sollte Reibungslos funktionieren).

Einiges mehr zu beachten ist bei den Sprung von 4.8 auf 4.9

Hallo fauxxami,
um deine Frage bzgl. des SQL-Statements noch kurz zu beantworten: ja, das kannst du ausführen (am besten hast du zuvor im Contenido-Backend AMR deaktiviert). Danach sind die Einträge weg, die auch die Setup-Routine kicken würde. Dann noch wie von rethus vorgeschlagen die htaccess umbenennen (die brauchst du später nach dem Upgrade auf die 4.9.x wieder, wenn du AMR aktivierst).
Du kannst auch noch den Unterordner /contenido/plugins/mod_rewrite löschen (vorher aber sicherheitshalber Backup, wer weiss).

Wie oben beschrieben, hattest du mit Sicherheit eine Weiterleitung im Startartikel. Die ist durch deinen Eingriff in der Datenbank jetzt weg (obwohl man die besser nicht in der DB, sondern in Contenido entfernt); du findest diese jeweils in den Eigenschaften eines Artikels - dort gibt es ein separates Feld dafür. Außerdem sieht das Artikelicon anders aus, wenn für den Artikel eine Weiterleitung eingerichtet ist, da kannst du das schneller erkennen.

Hallo zusammen!

Ich habe das Gefühl, dank eurer Geduld mit mir (vielen Dank dafür!) kurz vor dem Ziel zu sein:

in der Version 4.8.12 ist es mir durch Ausführen der SQL-Anweisungen gelungen, AMR sauber zu deinstallieren
nach dem Löschen der .htaccess liefen Back- und Frontend einwandfrei
danach habe ich 4.8.20 drüberinstalliert (immer noch ohne AMR), Spracheinstellungen aktualisiert, alles lief
dann habe ich 4.9.12 drüberinstalliert, AMR installiert und aktiviert (neue .htaccess wurde erzeugt)

Nun läuft das Backend (fast) reibungslos, das Frontend allerdings nicht. Im Backend wird mir die Artikelübersicht angezeigt, und Eigenschaften der Artikel kann ich ansehen (und z.B. sehen, dass die Weiterleitung im Startartikel tatsächlich weg ist), aber die Artikelvorschau funktioniert nicht. Diese wird mir genauso wenig angezeigt wie die Artikel im Frontend. Ich meine, alle Hinweise von https://docs.contenido.org/display/COND ... .8+auf+4.9 beachtet zu haben, aber irgendwo scheint doch noch eine Kleinigkeit zu fehlen. In der errorlog.txt findet sich ein Hinweis:

Code: Alles auswählen

Error: Can't include /var/www/stiftung/contenido/classes/Contenido_FrontendNavigation/Contenido_FrontendNavigation_Breadcrumb.class.php in /var/www/stiftung/contenido/includes/functions.general.php on line 1477

In der Tat exisitiert das Verzeichnis "Contenido_FrontendNavigation" überhaupt nicht (mehr).

Viele Grüße,

fauxxami

So, nun kommst du an die eigentlich Nuss: die Module laufen aufgrund geänderter Api-Aufrufe nicht mehr so wie bisher. Die musst du nun entweder anpassen oder tauschen (z.B. empfiehlt es sich, die Navigationsmodule gegen die im setup-Ordner vorhandenen Module zu tauschen; andere Module sind easy updatebar). Dazu musst du dich jetzt ein bisschen einlesen hier, was zu tun ist.

Übersicht zu grundsätzlichen Änderungen:
https://docs.contenido.org/display/COND ... .8+and+4.9

Tool "Codeanalyzer":
http://www.contenido.org/deutsch/techni ... index.html

Bei falschem Modulcode bricht die Ausgabe der Seite meist komplett ab. Anhand der Abbruchstelle im HTML-Code kannst du in etwa nachvollziehen, bei welchem Folgemodul es klemmt.

Ergänzend zu homtata's Posting hier einige Hinweise zu deinem Problem und das weitere Vorgehen nach dem Upgrade.

Den 1. Schritt hast du schon erfolgreich gemeistert... Logs im Auge behalten.
2. Schritt - Debugging in Contenido aktivieren (data/config/production/config.misc... hier schlage ich vor, folgendes zu aktivieren:

$cfg['debug']['codeoutput']
$cfg['php_settings']['display_errors']

(Nicht vergessen, beim Go-Live wieder zu deaktivieren!!)

Diese optionen spucken error-meldungen im FE aus, und zeigen zudem ne Textarea mit ungeparsten PHP-Code (daher ggf. den Parameter $cfg['debug']['codeoutput'] in nem If-Schachteln :

Code: Alles auswählen

 if($_GET['superAdmin']) $cfg['debug']['codeoutput']=true;

Nur kurz zu deinem obigen Fehler... "Can't include" bedeutet, das die Datei nicht vorhanden ist, und daher nicht includiert werden kann. Nimm ggf. erstmal das BreadCrumb-Modul aus deinen Templates, oder fange dort an, deine Module zu mergen/fixen.

CONTENIDO Forum

Problem mit AMR-Plugin

Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin

Re: Problem mit AMR-Plugin