CONTENIDO Forum

Liebe Gemeinde,
nach einem Update von 4.9.12 auf 4.10.0 funktioniert das URL-Rewriting in folgendem Fall nicht korrekt: sobald sich mehrere identische Links auf einer Seite befinden, also z.B. ein Menüpunkt und der gleiche Link wurde nochmals "per Hand" im Contentbereich eingefügt, wird nur ein Link korrekt umgewandelt ("https://www.domainname.de/categorie/dateiname.html"), der andere hat die Form "https://www.domainname.de/index.html". Die Aliase habe ich zurückgesetzt, das ändert nichts.

Infos zum System:
CONTENIDO version 4.10.0
Server operating system Apache
Installed PHP version 7.2.28-he.0
Database server version 5.6.47-87.0-log
PHP database extension mysqli
PHP configuration
memory_limit 256M
upload_max_filesize 32M
post_max_size 32M
max_execution_time 30
max_file_uploads 50
max_input_time 60
sql.safe_mode deactivated
disable_classes nothing disabled
disable_functions syslog
Loaded extensions:
Core, PDFlib, PDO, Phar, Reflection, SPL, SimpleXML, apache2handler, bcmath, bz2, calendar, ctype, curl, date, dba, dom, exif, fileinfo, filter, ftp, gd, geoip, gettext, hash, iconv, imap, intl, ionCube Loader, json, ldap, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_sqlite, posix, pspell, session, shmop, soap, sockets, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, timezonedb, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib

Contenido Errorlog:
kein Eintrag

Provider Errorlog:
[Wed Apr 01 14:06:22 2020] [php7:error] script '/XXX/www/cms/front_content.phpfront_content.php' not found or unable to stat

Für ein Feedback wäre ich sehr dankbar!

Viele Grüße
mikedreissig

Hallo mikedreissig,

leider konnte ich das von dir beschriebene Verhalten nicht reproduzieren. Unter einer CONTENIDO 4.10.1 unter PHP 7.2.6 habe ich im Sitemap-Modul die Sitemap 3 x ausgegeben, und zwar mit klassischen URLs, die 'front_content.php' enthalten. Alle URLs werden korrekt vor der Ausgabe der Seite umschrieben, da ist kein einziger Link fehlerhaft ausgegeben worden.

Im AMR-Plugin gab es zwischen 4.10.0 und 4.10.1 keine Änderungen, die das Problem verursachen könten, meines Wissens waren alle Änderungen nur Kommentare im Code.

Die Funktion mr_buildGeneratedCode() in contenido/plugins/mod_rewrite/includes/functions.mod_rewrite.php macht alle Ersetzungen, wenn im AMR die Option "Bei der Ausgabe des HTML Codes der Seite" bei "Zeitpunkt zum Generieren der URLs" angegeben ist. Dort wird der Gebraucht von der PHP-Funktion preg_replace_callback() gemacht.

Laut der PHP Changelog gab es zwischen PHP 7.2.6 und PHP 7.2.28 nur ein Bugfix wegen den /r Flag und dies wird sowieso nicht verwendet.

Sofern bei dir die Links bei der Ausgabe der Seite umschrieben werden, kannst du dir die Funktion mr_buildGeneratedCode() näher ansehen, was da genau schiefläuft.

Als Alternative kann ich dir empfehlen, alle URLs in Modulen immer mit dem UrlBuilder auszugeben, z. B.: Zum Fehler:

... [Wed Apr 01 14:06:22 2020] [php7:error] script '/XXX/www/cms/front_content.phpfront_content.php' not found or unable to stat...

Kann es sein, dass hier jemand versucht, Requests auf ...domain.com/front_content.phpfront_content.php abzusetzen und der Webserver versucht, das PHP Script front_content.phpfront_content.php auszuführen? Ich würde in den access_logs des Webservers nachschauen, ob solche Requests kommen. Die kann man dann mit entsprechenden Regeln in der .htaccess blocken, siehe .htaccess des AMR-Plugins.

Gruß
xmurrix

P.S.: Du kannst mir auch die generierte HTML-Seite schicken, bevor die URLs umschrieben werden und ich schaue mir das mal an...

Hallo xmurrix,

erstmal vielen Dank für Deine ausführliche Antwort!

Dieser Tipp hat die Lösung gebracht:
Ich habe bisher immer alle Menüpunktverlinkungen nach diesem Schema angelegt
und hatte bis 4.9.12 keine Probleme damit. Dann muss ich wohl jetzt alle Verlinkungen umarbeiten.

Nochmals danke, und ich habe den Betreff meines Beitrags entsprechend korrigiert.

Viel Grüße
mikedreissig

Da hätte ich doch glatt noch mal eine Verständnisfrage. Bisher habe ich es immer so gehandhabt, dass Links wie in Vor-AMR-Zeiten im Quellcode stehen: Eigentlich musste ich mich auch nie um irgendwas sonst kümmern. AMR hat solche Links zuverlässig umgewandelt. Jetzt bin ich gerade am zweiten Projekt, wo das nicht mehr geht. Ehe ich diesen Threat wiedergefunden habe, hatte ich erfolgreich folgendes probiert: Das ging, hat aber zu anderen (funktionierenden) URLs geführt. (Es tauchten die Artikel-Aliasse in der URL auf.)
Jetzt kann ich natürlich in allen Projekten sicherheitshalber die URLs umbimmsen. Aber es fühlt sich schon so an, als würde da irgendwas in im AMR-Plugin nicht mehr sauber laufen, was immer problemlos lief und jetzt dann und wann zickt.
Und jetzt die Verständnisfrage: Sollte AMR meine oldstyle-Links nicht eigentlich auch fehlerfrei umwandeln können?
Grüße!
Bodil

Naja, wenn nur idcat vorhanden ist, woher soll AMR wissen, welcher Artikel gemeint ist? Man kann ja in einer Kategorie theoretisch beliebig viele Artikel reinsetzen und nur einer ist der Startartikel. Der wird immer angezeigt, wenn nur die Kategorie (idcat) aufgerufen wurd. Fehlt der Startartikel, gibts Fehlermeldung, weil dann ist kein Artikel für diese Kategorie ausgewählt.

Wenn idart und idcat im Link sind, fehlt immer noch die Sprache und der Client.
Beim Client ist es problemloser, weil man sich ja bereits in einem Client befindet, nämlich der, in dem die Webseite mit den Links ist.
Aber welche Sprache?
Falls ordentlich synchronisiert wurde, ist die idcat und idart in jeder Sprache nochmal vorhanden.
Ich glaube, da gibt es noch idcatlang und idartlang, die sich auf die Sprache beziehen.
Wobei ich denke, dass es keine idcatartlang gibt. Aber wer weiß das schon so genau.

Hallo bodil,

das AMR-Plugin kann zwar auch nur mit der Kategorie ID die URLs generieren aber besser ist immer die Verwendung der Artikel ID, die eindeutig ist.

Wenn URLs nur die Kategorie ID enthalten und die AMR-Option "Artikelname immer an die URLs anhängen (auch bei URLs zu Kategorien)" deaktiviert ist, kann das zu Problemen führen, daher empfehle ich immer den Artikelnamen an die URL anzuhängen, inkl. der aktivierten Option "Dateiendung am Ende der URL".

Der Grund ist folgendes:
In einem Projekt kann es vorkommen, dass es eine Kategorie "foo" gibt, das einen Artikel "bar" enthält.
Zugleich ist es möglich, dass eine Kategorie "foo" existiert, die wiederum eine Unterkategorie "bar" hat.

Wenn nun ein Request mit der URL "/foo/bar" ankommt, kann das AMR-Plugin nicht entscheiden, ob den Artikel "bar" in der Kategorie "foo" zeigen soll oder den Startartikel im Kategorienbaum "foo > bar".

Es kann aber auch an den AMR-Einstellungen liegen, genauso gut kann es ein Fehler sein. Man müsste also prüfen, warum die URLs nicht korrekt generiert werden.

Gruß
xmurrix