Plugin Advanced Mod Rewrite für Contenido 4.8.x

[xmurrix]

...
ich habe festgestellt, das der Editor nicht mehr richtig funktioniert.
Beim Abspeichern oder zwischenspeichern braucht er ewig lange und kommt zu keinem Ende. 99% ist Ende Gelände

Obwohl er nach ungefähr 3 bis 4% alles gespeichert hat. Bricht man dannach nämlich ab, ist der bearbeitete Text da.

Schalte ich mod rewrite ab, ist er wieder schnell.

Ok, das Problem lag an den nicht ganz korrekten RewriteRules in der .htaccess. Deine .htaccess für das MR Plugin liegt im Ordner /cms drin. Die RewriteBase ist zwar /cms aber die RewriteRules dürfen keine cms/ enthalten, also anstatt

Code: Alles auswählen

RewriteRule ^cms/upload/.*$ - [L]
RewriteRule ^cms/test/.*$ - [L]
RewriteRule ^cms/index_controller.php.*$ - [L]
RewriteRule ^cms/front_content.php.*$ - [L]

muss es folgendermaßen sein:

Code: Alles auswählen

RewriteRule ^upload/.*$ - [L]
RewriteRule ^test/.*$ - [L]
RewriteRule ^index_controller.php.*$ - [L]
RewriteRule ^front_content.php.*$ - [L]

Bei dir wurde der Request an front_content.php beim Editieren an index_controller.php übergeben. Der hat versucht, die ankommende URL aufzudröseln, weil MR aktiviert ist. Das hat zu einem Fehler geführt, die Weiterleitung zur Fehlerseite hat nicht geklappt, was auch noch einen dauer-Redirect ausgelöst hat - daher der ewige Ladebalken im IE7. FF ist da etwas auskunftsfreudiger und bringt eine genauere Meldung.

Die .htaccess in /cms habe ich angepasst, jetzt sollte es funktionieren.

Gruß
xmurrix

[apicalart]

Herrschaften, das ist ein Entwickler auf den kann unser Forum stolz sein ( ohne jetzt emergence oder Herrn B oder Dodger77 auszuklammern und die, die ich vergessen habe und sich angesprochen fühlen ). Ein Grund warum wir unseren Kunden Contenido auf wärmste empfehlen.

Tschuldigung, das ich mich hab gehen lassen, aber musste mal sein

[morgenstern]

Hi xmurrix

Habe bei meiner Seite noch was in die front_content.php einbauen müssen.
Ich arbeite mit der guten alten Download liste von Stese um MP3 und Videos anzubieten.

Schon in der "Originial" Stese Version hatte ich Probleme mit dem "Allowed memory size exhausted"

Kleine Files mit 2-3 MB funktionieren einwandfrei.
Grössere ab ca. 4,5 MB war das Memory voll.

Ich habe in der front_content.php folgendes eingebaut (ca. Linie 970:)

Original:

Code: Alles auswählen

			ob_start();
        	eval ("?>\n".$code."\n<?php\n");
			$htmlCode = ob_get_contents();
			ob_end_clean();

			// process CEC Hook to do some preparations before output
            $htmlCode = CEC_Hook::execute('Contenido.Frontend.HTMLCodeOutput', $htmlCode);

			// print output
			echo $htmlCode;

Anpassung:

Code: Alles auswählen

			ob_start();
        	eval ("?>\n".$code."\n<?php\n");
			$htmlCode = ob_get_contents();
			ob_end_clean();

      if  (strlen ($htmlCode) < 1000000) //morgenstern skip code (files) larger 1mb
          {
			// process CEC Hook to do some preparations before output
            $htmlCode = CEC_Hook::execute('Contenido.Frontend.HTMLCodeOutput', $htmlCode);
          }

			// print output
			echo $htmlCode;

Downloads von 7.5mb funktionieren so.
Kann das irgend an einem anderen Ort Probleme machen, oder ist das aus deiner Sicht i.O ?
... es macht ja keinen Sinn MP3's und Videos nach irgenwelchen URLS abzusuchen....

[xmurrix]

...Ich habe in der front_content.php folgendes eingebaut (ca. Linie 970:)
...
Anpassung:

Code: Alles auswählen

			ob_start();
        	eval ("?>\n".$code."\n<?php\n");
			$htmlCode = ob_get_contents();
			ob_end_clean();

      if  (strlen ($htmlCode) < 1000000) //morgenstern skip code (files) larger 1mb
          {
			// process CEC Hook to do some preparations before output
            $htmlCode = CEC_Hook::execute('Contenido.Frontend.HTMLCodeOutput', $htmlCode);
          }

			// print output
			echo $htmlCode;

Downloads von 7.5mb funktionieren so...

Das ist ein guter Ansatz, um Ausgaben, die nicht HTML enthalten, von der Verarabeitung des MR Plugins auszuschließen. Besser wäre es, wenn man erkennen könnte, ob die Ausgabe HTML ist oder nicht um dann darauf zu reagieren.

Es ist zwar unwahrscheinlich, dass eine HTML-Seite meht als 1000000 Bytes hat, dennoch wäre das möglich.

Eventuell könnte man das in die Konfiguration des Plugins einbauen, z. B. durch Angabe der Artikelids die vom Umschreiben ausgeschlossen werden sollen. Idealerweise sollte eine nicht HTML-Ausgabe überhaupt nicht im Ausgabepuffer landen, bei einem 50 MB Download wären dann 50 MB im Speicher, das sollte nicht sein.

Gruß
xmurrix

[Supporter]

Hallo xmurrix

Ich verwende in einer 4.8.7er mit MR Plugin das Modul Fotoalbum von OmaWetterwax.

Dieses Modul arbeitet mit einer "externen" Datei die sich picture.php schimpft und die Bilder über diese Datei in der Modulausgabe über ein iframe ausgibt.

Jedoch wird seit der 4.8.7er ein "Illegal Call!" ausgegeben, kann es an Deinem Modrewrite liegen oder an einem SecurityFix von Contenido?

Wenn Du Zeit und Lust hast würde ich Dir die Zugangsdaten zu dem System zukommen lassen, sodass Du einen Blick darauf werfen kannst.

Hier zumindest einmal der Link zum Modul: http://forum.contenido.org/viewtopic.ph ... =fotoalbum

[BagHira]

Jedoch wird seit der 4.8.7er ein "Illegal Call!" ausgegeben, kann es an Deinem Modrewrite liegen oder an einem SecurityFix von Contenido?

Versuch doch mal in deine .htaccess folgende Zeile einzufügen:

Code: Alles auswählen

RewriteRule ^PfadZurDatei/picture.php.*$ - [L]

Möglicherweise hilft das?

[xmurrix]

...Jedoch wird seit der 4.8.7er ein "Illegal Call!" ausgegeben, kann es an Deinem Modrewrite liegen oder an einem SecurityFix von Contenido?

Wenn Du Zeit und Lust hast würde ich Dir die Zugangsdaten zu dem System zukommen lassen, sodass Du einen Blick darauf werfen kannst...

Hallo,

du kannst die Weiterleitung der Requests auf die picture.php zum index_controller.php in der .htaccess, wie BagHira es im vorherigen Post beschrieben hat, ausschließen. Da du ein "Illegal Call" bekommst, ist das wohl schon gemacht...

Um das Problem mit "Illegal Call" zu beheben, musst du noch am Anfang der picture.php folgende Zeilen einfügen:

Code: Alles auswählen

<?php

if (!defined("CON_FRAMEWORK")) {
    define("CON_FRAMEWORK", true);
}

// include security class and check request variables
include_once ('../contenido/classes/class.security.php');
Contenido_Security::checkRequests();

include_once ("config.php");

So wird ab Contenido 4.8.7 ein aufgerufenes Script (front_content.php, dbfs.php, usw.) immer initialisiert, das ist das neue Securitypackage um es dem Hackerpack zu erschweren

Gruß
xmurrix

[Supporter]

So wird ab Contenido 4.8.7 ein aufgerufenes Script (front_content.php, dbfs.php, usw.) immer initialisiert, das ist das neue Securitypackage um es dem Hackerpack zu erschweren :-)

Du meintest sicherlich die russische Scriptkiddie Mafia ;)

[Supporter]

Hallo Zusammen

Da ich ModRewrite in allen meiner Installationen verwende, hier ein paar Tipps zur Konfiguration (Zusammenfassung mit xmurrix Hinweisen).

ModRewrite ist geeignet für den Einsatz bei Standalone Mandanten, also Systemen mit nur einem Mandanten, aber auch für Installationen mit mehreren Mandanten.

Einzelmandant
Mandant liegt im Verzeichnis "/root/cms/"

Wird nur ein Mandant im System installiert, so müssen nach der Installation des Plugins keine Änderungen vorgenommen werden.

Die .htaccess liegt dann also im Rootverzeichnis der Installation und der Pfad zum Mandanten auf dem Server sowie in der .htaccess muss wie folgt aussehen:

Code: Alles auswählen

RewriteBase /cms

Einzelmandant
Mandant liegt im Verzeichnis "/root/"

In diesem Fall muss in der .htaccess der RewriteBase wie folgt abgeändert werden:

Code: Alles auswählen

RewriteBase /

Mehrmandanten
Mandant liegt im Verzeichnis "/root/mandant/"

Diese Konfiguration ist wahrscheinlich eher etwas für versierte, da diese etwas komplizierter ist und Fehler nicht so schnell gefunden werden.

Normalerweise ist bei einer Mehrmandanteninstallation das Ziel, das Backend über eine separate Domain zu administrieren. Dies kann zum einen echte Domain wie zum Beispiel http://www.contenidobackend.de, aber zum anderen auch eine Subdomain sein, wie zum Beispiel http://contenidobackend.contenidowebsite.de.

Bei dieser Installationsvariante werden also die Domains, jeweils in das entsprechende Verzeichnis der Contenidoinstallation "Geroutet", dies erfolgt bei 1und1, aber auch bei vielen anderen, direkt über die Webhostingverwaltung.

Hier ein Beispiel von meinen Projekten:

Backend
Domain: http://www.contenidobackend.de
Serverpfad: /root/contenido/

Frontend Mandant 1
Domain: http://www.contenido-mandant-1.de
Serverpfad: /root/contenido-mandant-1/

Frontend Mandant 2
Domain: http://www.contenido-mandant-2.de
Serverpfad: /root/contenido-mandant-2/

In diesem Fall liegt eine .htaccess Datei mit folgenden Angaben im Rootverzeichnis:

Code: Alles auswählen

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Diese Angaben in der .htaccess sind erforderlich ab der Version 4.8.7 und höher wenn bei 1und1, Strato, PureTec oder Schlund und Partner gehostet wird!

Bei HostEurope wird PHP5 beispielsweise im KIS aktiviert, in diesem Fall entfällt die .htaccess im Rootverzeichnis!
Über Erfahrungswerte zur Konfiguration bei anderen Webhostern verfüge ich nicht.

Anschließend bekommen die Mandanten jewiels noch eine .htaccess verpasst, welche direkt in das Mandantenverzeichnis gelegt wird. Hier ist wieder auf den RewriteBase zu achten, der in diesem Fall wie folgt aussehen muss:

Code: Alles auswählen

RewriteBase /

Nämlich ganz einfach deshalb, weil die Domain direkt in das Mandantenverzeichnis zeigt.

Am besten nimmt man immer die aktuelle .htaccess Datei aus dem Installerpaket des Plugins, pass sich diese an und lädt diese separat auf den Server, so bleibt man immer aktuell.

@xmurrix: Wenn Du Verbesserungsvorschläge hast dann immer her damit - ist ja schließlich schon spät (früh)...

[xmurrix]

Morgen,

erstmal vielen Dank für die Zusammenfassung der Hinweise und Tipps für das MR Plugin, das kann für Viele aus der Community sehr hilfreich sein.

Ich mach mal im Startbeitrag gleich einen Verweis darauf.

Gruß
xmurrix

[Tbird]

Guten Morgen!

Ich habe eine 4.6.15-Installation auf 4.8.7 geupdatet (alles prima!), das aktuelle MR-Plugin installiert und der Mandanten-Pfad ist das Webroot (also nicht cms/)
Ich habe soweit alle Pfade angepaßt und es läuft auch bis auf die "Kleinigkeit", dass irgendwas mit der Weiterleitung nicht paßt.

Die Startseite des Mandanten wird angezeigt, aber die URL sieht dann so aus:
www.domain.de//home/
(Doppelslash)

Alle Links auf der Seite werden meiner Meinung nach korrekt ge-re-writet, aber ich komme immer nur auf der Startseite mit obiger Url raus..?

Ich denke das hat was mit dem Pfad zu tun... weil nicht in cms/ sondern Webroot, sodass der eine Slash "zu viel" ist.

Wenn ich das MR-Plugin deaktiviere läuft alles einwandfrei.

Gruß aus Chemnitz und schönen Tag!

[xmurrix]

Morgen,

...Die Startseite des Mandanten wird angezeigt, aber die URL sieht dann so aus:
www.domain.de//home/
(Doppelslash)...

überprüfe doch mal folgende Einstellungen:

1. Advanced Mod Rewrite Einstellungen im Backend:
Pfad zur .htaccess Datei aus Sicht des Web-Browsers sollte "/" sein.

2. In der .htaccess ist die Angabe von RewriteBase nicht nötig, ansonsten muss es RewriteBase "/" sein.

Eigentlich sollte das nicht möglich sein. Wenn in der .htaccess etwas falsch angegeben wird, quitiert Apache gleich mit einem Fehler. Doppelt vorkommende Slashes werden vom Plugin beim Erstellen der URLs korrigiert.

...Alle Links auf der Seite werden meiner Meinung nach korrekt ge-re-writet, aber ich komme immer nur auf der Startseite mit obiger Url raus..?...

Werden die Links der Seiten also ohne das doppelte Slash ausgegeben, ist das richtig?

Kannst du die .htaccess und die Einstellungen des Plugins posten?

Gruß
xmurrix

[Tbird]

Also wenn ich die Rewrite-Base entferne bekomme ich einen 500-Fehler.

Code: Alles auswählen

#AddHandler php-cgi .php .php4

# php5-switch for 1und1
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php 

<IfModule mod_rewrite.c>
RewriteEngine on

# Specify a base URL-path for the rules
# -------------------------------------
RewriteBase /

# Exclude some files and directories from rewriting
# -------------------------------------------------
RewriteRule ^usage/.*$ - [L]
RewriteRule ^contenido/.*$ - [L]
RewriteRule ^setup/.*$ - [L]
RewriteRule ^upload/.*$ - [L]
RewriteRule ^test/.*$ - [L]
RewriteRule ^index_controller.php.*$ - [L]
RewriteRule ^front_content.php.*$ - [L]
# enable following line if you want to run the plugin test
#RewriteRule ^mr_test.php.*$ - [L]


# Catch some common exploits in query string to get rid of them
# NOTE: Conditions to prevent protocolls (ftp, http[s]) in query string could be a
#       disadvantage in some cases
# --------------------------------------------------------------------------------
RewriteCond %{QUERY_STRING} contenido_path=.*$  [NC,OR]
RewriteCond %{QUERY_STRING} cfg\[path\]=.*$  [NC,OR]
RewriteCond %{QUERY_STRING} _PHPLIB\[libdir\]=.*$  [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} ftp://.*$  [NC,OR] 
RewriteCond %{QUERY_STRING} http[s]*://.*$ [NC] 
RewriteRule ^.* - [F,L]  # all matching conditions from above will end in nirvana


# One RewriteRule to rule them all
# --------------------------------
RewriteRule !\.(js|ico|gif|jpg|jpeg|png|css|pdf|swf)$ index_controller.php [NC,QSA,L]

</IfModule>

[xmurrix]

Also wenn ich die Rewrite-Base entferne bekomme ich einen 500-Fehler...

Also die Konfiguration und die .htaccess machen einen guten Eindruck.

Warum du aber einen Fehler beim Entfernen von RewriteBase bekommst, ist mir schleierhaft, eigentlich sollte die "/" automatisch die RewriteBase sein, ohne dass man das explizit angibt. Ist der Apache vom Provider konfiguriert oder habt ihr das selber gemacht?

Ich vermute, dass die VirtualHost-Konfiguration in der httpd.conf oder das Apache mod_rewrite Modul das Problem verursacht, eher sogar Apache mod_rewrite.

Gruß
xmurrix

[Tbird]

Die Konfiguration kommt von 1und1 - und habe ich höchstwahrscheinlich kein Einfluß drauf, ist ein Homepage-Server.

Genau die RewriteBase muß sein sonst -> 500.

Das Mod-Rewrite scheint ja auch zu funktionieren, die Links auf der Seite werden ja korrekt ausgeliefert.

Hier einfach mal der Link zu dem Projekt: www.visit-world.com

Vielen Dank @ xmurrix