WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

.html statt .php

<< < (3/5) > >>

Stefek:
@Chio

hehe. Du meinst, dann wäre es kein Geheimtipp mehr.
Mode hat nichts mit Rarität oder Exclusivität zu tun.


 :-D
Schönen Gruß,
Stefek

Waldschwein:
Hallo!

Nö, ich glaube einfach chio meint damit, das ganze Endungszeug ist Unfug... Ob da jetzt php, html gar nichts oder magdichnet da steht ist dem Normaluser eh wurscht, und den, den es interessiert weiß sowieso dass dort php stehen sollte.

Gruß Michael
 

chio:
Danke, Michael!
Du verstehst mich ;-)

Ich habs gerade mal probiert, auf einer jungfäulichen Domain.

Probleme:
Wenn ich jeden Zugriff auf eine html-Seite auf .php umleite, funktioniert zb der FCK-Editor nicht mehr; also alle Module, die html-Seiten haben. Weil ja die entsprechenden php-Seiten nicht vorhanden sind. Einige Module enthalten ja zb ein help.html - die müsste man alle umbenennen.

Wenn ich .html-Seiten durch den Parser schicke, könnte es Probleme geben, wenn diese zb tatsächlich php-code (oder auch nur  <?xml...> in der DTD haben.

Eine Lösung ist, dass ich die entsprechende .htaccess _nur_ im pages-Verzeichnis habe, und alles andere (diverse html-Seiten, die zb per iframe reinkommen) woanders. Aber das sollte man ohnehin nicht machen: Im pages-Verzeichnis noch andere Seiten haben.

Übrigens: Wenn ich als Extension .html angebe (unter Optionen) funktioniert im WB 2.7 Backend die Ansicht der Seiten (pages/modify.php -> "Ansehen") nicht mehr: Es ist ein überflüssiger Slash nach dem .html

So, und jetzt geh ich auf ein Bier. 8-)

chio:
Jepp....
Ich will es gar nicht "Bug" nennen... ist ja etwas verzwickt, die Sache; daher nur um zu zeigen, welcher Art die Probleme sein können:

Wenn ich als Extension .html angebe (was ich tun muss, damit auch im Menü .html steht) legt WB die Access-Files (=die Daten im pages-Verzeichnis) ebenso als .html an.

Das ist an sich korrekt. Aber damit fällt die Variante RewriteRule ^(.*).html$ $1.php [L] raus. Die einzige Lösung ist: Die Daten von Hand wieder umbenennen. Oder Variante 1: html parsen.

---------------------------------------
<edit>
Mit der Kraft der 5 Biere habe ich jetzt folgendes herausgefunden:

die entsprechende .htaccess MUSS in das pages-Verzeichnis. Überall sonst ist sie fehl am Platz.
Dann ist die Frage: Was mit der /index.php, was mit der Suche. Knifflig.

Man muss das von Anfang an machen; nachträglich wird es sehr schwierig. Normalerweise werden die access-Files als .php angelegt. Wenn ich die Extension ändere, werden sie als .html angelegt - aber ältere NICHT korrigiert. Ich muss also alle alten access-files umbenennen. Wohl von Hand.
Ein schneller Weg aus der Misere fällt mir momentan nicht ein, ist ja ein "logisches" Problem ("was denn jetzt").

ruebenwurzel:
Hallo,

muss jetzt auch mal noch kurz meinen senf dazugeben.

1.) Das festlegen der Dateiendung muss und soll in allen WB Versionen (auch in 2.7) vor dem Anlegen der ersten Seite passieren. Ein nachträgliches Ändern war und wird auch mit nachträglichen Handarbeiten im /pages Verzeichnis verbunden sein.

2.) Problematisch sind noch einige Module und Templates. Dort ist an verschiedenen stellen fälschlicherweise die Variable PAGE_EXTENSION verwendet und umgekehrt sind einige Sachen auf php hardgecoded, die variabel sein sollen. z.B. In Templates bei den Anmeldungen und suchmasken muss es immer auf die search.php oder login.php verweisen, die entsprechenden html Dateien gibt es nicht.

3.) Das ganze funktioniert nur mit der .htaccess die im Paket drin ist und darf nicht die rewrite geschichte enthalten. Ob die .htaccess nur in der root, nur im pages Verzeichnis oder in beidem stehen muss, muss ich auch nochmal testen. Bei mir funktionierte es mit nur im root Verzeichnis ohne Probleme.

4.) Bei der Entwicklung von WB 2.7 wurde der Wert darauf gelegt, dass von Seiten der WB Core-Files diese Geschichte fehlerfrei läuft (können dennoch einige bugs drin sein, muss und soll ja vor dem Final noch getestet werden). Wie das ganze dann auf Seiten umzusetzen ist, was es nocvh für Möglichkeiten gibt (mod_rewrite), welche Probleme auftauchen können (Module, templates) und was bei nachträglichen Änderungen zu beachten sein wird (inkl SEO) das haben wir uns vorgenommen auf den Hilfeseiten ausführlich zu dokumentieren.

Gruß
Matthias

Navigation

[0] Message Index

[#] Next page

[*] Previous page