WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: chio on February 20, 2008, 12:54:34 AM
-
Vielleicht für den einen oder anderen interessant:
seite.html statt seite.php
http://www.beesign.com/WebsiteBaker/pages/posts/endungsfrage-seite.php-oder-seite.html27.php
PS: Man darf die WB eigene Kommentar-Funktion nutzen ;-)
-
Hallo,
für diejenigen, die WB auf einem Apache Webserver betreiben und das Modul Modrewrite zur Verfügung haben reicht es eine .htaccess Datei mit folgendem Inhalt in das Wurzelverzeichnis von WB zu legen:
RewriteEngine on
RewriteRule ^(.*).html$ $1.php [L]
So machen wir das auf start.WebsiteBaker. org :-)
Gruss Christian
-
Ja, aber darum gehts ja gar nicht.
Viel mehr: Warum sollte man? Wenn es funktioniert bringt es nichts, wenn nicht: Ärger.
Oder gibt es einen vernünftigen Grund dafür, den ich nicht kenne?
-
Hallo!
Ja, ich denke der Grund wird die Neuerung (Bugfix o.ä.) der Art wie Endungen in 2.7 übermittelt werden. Denn dort wird auch eine htaccess (natürlich vorerst nutzlos) mitgeliefert. Soweit ich es verstanden habe. :-P Aber irgendwie ist...
Ja gut, dort heißt der Inhalt der htaccess:
AddType application/x-httpd-php .html
Gruß Michael
-
Hallo,
ich stimme vom Grundsatz her Chio voll zu. Es gibt eigentlich nicht wirklich einen Grund die Endung von .php auf .html zu ändern. Dennoch denke ich sollten wir für diejenigen, die aus welchen Gründen auch immer, dieses Feature nutzen wollen es anbieten. Und WB 2.7 wird die erste Version sein, in der dies auch wirklich geht, zumindest mit den Core Modulen. Viele andere Module müssen da noch angepasst werden. Denke wir werden das auf der Hilfeseite auch beschreiben, wie man es machen kann. Als Einleitungstext, könnte ich mir ganz gut den Text von Chio vorstellen (falls wir den nutzen dürfen :-D), dannach dann die Schilderung der beiden möglichen Szenarien, die beide nur dort funktionieren wo .htaccess Dateien laufen, und am Schluss noch den Hinweis mit den eventuell notwendigen Änderungen in Modulen.
1.) die wesentlich elegantere Lösung mit mod_rewrite von doc
2.) die etwas umständlichere Lösung mit geparsten html Dateien.
Vielleicht sollte man in der htaccess.txt von WB 2.7 beide varianten einbauen und mit entsprechenden kommentaren versehen.
Matthias
-
Ja, die mod_rewrite - Lösung ist eleganter und sicherer, hat aber einen Nachteil:
Die Seiten sind sowohl unter .html als auch unter .php erreichbar. Also uU. doppelt.
Szenario:
Ich habe meine Seiten als .php und die sind auch so in SuMas gelistet. Möglicherweise habe ich auch Deeplinks auf einzelne Seiten.
Dann stelle ich auf .html um:
Mit einem Schlag verdopple ich die ganze Site; jede Seite ist sowohl als .php als auch als .html erreichbar.
Jetzt hat Google ein Problem: Welche soll er listen?: Die alten .php - oder die neuen .html ? Beide sicher nicht; kann gut sein: Keine. Aus. Hängt davon ab, wieviele doppelte ich habe (Löcher, Deeplinks usw...)
Bei der anderen Variante (geparste html Dateien) habe ich dieses Problem nicht, weil die php-Seiten weg sind (und einen Fehler liefern). Dafür ist wieder genau das das Problem.
Die einzige Variante, wo eine Umstellung Sinn machen würde, wäre:
Ich habe eine statische Site und stelle sie auf WB um, will aber die DeepLinks bzw gute Suma-Listung nicht verlieren. Das ist aber eine eher theoretische Möglichkeit, weil es in der Praxis kaum gelingen wird, die URLs 1:1 beizubehalten. Hier muss also trotzdem wieder die htaccess ran: 301er Weiterleitungen. Und damit ist es auch schon wieder egal.
-
Das stimmt völlig.
Ein bestehendes Projekt von der *.php auf die *.html Endung umzupolen würd ich lassen.
Interessant wird das neue Feature sein, wenn man ein von Grund auf neues Projekt beginnt.
Ob es aus SEO-Sicht wirklich für die Listungen der SuMas relevant ist, weiß ich nicht wirklich und wage ich fast zu bezweifeln (lasse mich aber mit gut fundierten Argumenten gerne vom Gegenteil überzeugen).
Stefek
-
Ob es aus SEO-Sicht wirklich für die Listungen der SuMas relevant ist, weiß ich nicht wirklich und wage ich fast zu bezweifeln
Warum sollte es irgendeinen Einfluss haben? Der http-Header (nicht zu verwechseln mit dem <html><head>!) zeigt ohnehin, dass das eine php-Seite ist. Egal ob Extension .html oder .php
Und wahrscheinlich hat mittlerweile auch das (statisch/dynamisch) für sich gesehen relativ wenig Einfluss aufs Ranking.
Als modern gilt derzeit übrigens, die Extension _ganz_ wegzulassen.
-
Als modern gilt derzeit übrigens, die Extension _ganz_ wegzulassen.
Hört sich gut an.
Kannst Du einen Realisierungsvorsch lag machen?
Wie könnte man es ausführen?
Würd mich über eine kleine Info freuen.
Stefek
-
Wenn du es von mir erfährst ist es sicher schon nicht mehr modern.
Mach einfach php.
;-)
-
@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
-
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
-
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-)
-
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").
-
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
-
So wie es aussieht, sollte es reichen wenn die entsprechende .htaccess im pages verzeichnis ist. Es sind ja auch nur diese betroffen.
Eventuell hat ja der eine oder andere zusätzliche .html - Seiten auf der Domain, und diese per menuLink verbunden, da kann das ganz schön Ärger machen, wenn die alle geparst werden.
SEO-mäßig muss man immer darauf achten, dass man keine doppelten Seiten bekommt. Das wäre im Prinzip schon domain.de/ und domain.de/index.php = verschiedene URLs, gleicher Inhalt. Soweit hat Google keine Probleme mit sowas, aber wenns viele doppelte Seiten werden, kann das gefährlich sein.
WB verlinkt an sich ja immer auf /, nie auf /index.php - von daher also kein Problem. Da man das /index.php ohnehin nie sieht, wäre der Kosmetik genüge getan, nur die Seiten im pages-Verzeichnis auf .html zu rewriten.
(Es geht ohnehin nur um kosmetische Gründe)
Was ein Aufwand für die (vermeintliche) Schönheit...
-
3.) Das ganze funktioniert nur mit der .htaccess die im Paket drin ist und darf nicht die rewrite geschichte enthalten.
Hallo,
Opera (9.25) wollte bei der aktivierten .htaccess die .html nicht mehr anzeigen, sondern bot den Download an. "application" mag er nücht. Der IE sperrte sich gegen Editor "no input spec..." Werd's bei Gelegenheit, erst muß ich noch die mitgelieferten css w3c-valide machen, noch einmal in Ruhe testen.
Gruß, Hans J. G.
Edit 16:49Uhr:
Mein Serverlog zeigt mir, daß bei diesem "Ausprobieren" ein 1,2MB Logfile generiert wurde.
Das war vermutlich der Augenblick, wo der IE mit dem Editor einen Ausflug in's Nirwana machte.
(server error 304)
-
Seltsam,
ich habe ganz normal Content-Type: text/html im http-header.
Das ist wohl eine Frage der Server-Konfiguration.
-
Hallo,
für mich ein weiterer Grund, warum man einfach bei php bleiben sollte :-)
Gruss Christian
-
Hallo,
entscheidend ist was hinten rauskommt: Das ist HTML
Der Core und das "Drumherum", also alles für die Ausführung und Umsetzung, halt php (gut, weiss sowieso jeder :-))
So ist es der Gedanke und die Möglichkeit richtig, daß man die Einstellungsmöglich keit für den Output (Ext.) hat.
Es braucht keine Diskussion um das warum oder wofür, sondern nur den Gedanken, daß man beides sinnvollerweise auseinanderhält.
Es bleibt zu prüfen und zu testen, ob bei unterschiedlichen Servervoraussetzung en und -konfigurationen das Zusammenspiel noch funktioniert. Schau'n 'mer mal.
Gruß, Hans J. G.
p.s. Bei meinem ersten Versuch wurde noch "etwas" von einer drüberliegenden htaccess vererbt. Es wird, wie schon gesagt, weitere Tests mit etwas mehr Ruhe geben, damit hausgemachte Fehler nicht das Ergebnis versauen.
Eines schon mal voraus: Die Entscheidung, sich noch vor dem Anlegen der ersten Seite -falls das wirklich EINE Fehlerquelle werden kann- für das ein oder andere entscheiden zu müssen, halte ich für ein potentielles Riskio. Abgesehen vom möglichen Ärgenernis, bedeutet es möglicherweise Probleme bei der Übertragung und Migration. Es gibt aber hier wohl erfahrene WBler, die hierzu genaueres sagen können. Ich arbeite und teste erst seit ein paar Wochen mit WB.
Edit: Noch was vergessen. Na ja, es ist noch ein wenig früh.
Im Prinzip muß JEDE Ext. funktionieren, also nicht nur xxx.html, sondern auch xxx.huehnerbein, wenn's dem Server vorher "gesagt" wird.
-
Ja, theoretisch muss jede Extension funktionieren, letztlich ist alles html. Aber da kann ich mir gleich statt den Fingernägeln die Finger abschneiden.
Habe gerade eine kleine Umfrage (unter Internet-Laien) gemacht: die Extension ist jedem so ziemlich egal. Google ist sie auch egal, also: warum der Stress damit.
Einen kleinen Grund FÜR .html habe ich gefunden:
Ich habe mich entschieden, die Seiten auf "brachial" zu cachen = fix als Dateien (.html) rauszuschreiben. Vorteil: Es gibt ein Sicherheitsnetz für den Kunden, was er macht ist nicht sofort online, sondern erst mit Klick auf "veröffentlichen". Nachteil: kein Gästebuch oÄ, weil das funktioniert nur mit festen Seiten.
Der Vorteil dabei von .html: Ich kann jederzeit die Verzeichnisse tauschen (=Caching ausschalten), etwa wenn ich doch ein Gästebuch haben will. Die URLs ändern sich dabei nicht.
-
Mir geht's tatsächlich nur darum, daß bei beliebiger Extension der Admin, Redakteur oder sonstige Berchtigte ohne Fehlermeldung ihre Arbeit fortsetzen können; egal zu welchen Zeitpunkt die an der Extension "drehen". Sonst kann man diese Möglichkeit im Admin-Interface ja direkt rausschmeißen.
Zusätzliche Verrenkungen mit Cache und Extra-Parser will ich mir und WebsiteBaker nicht antun.
Wenn ich ein flexibles Extra-Klasse-Redaktionssystem haben will, nehme ich mir z.B. AWF mit Staging, Version management, viele Export-Funktionen usw.
Aber leider läuft AWF nicht auf jedem einfachen Webspace, und hier ist WebsiteBaker (2,7) einfach Klasse, das klappt, und dann auch noch die Bedienungsfreundlic hkeit. Mittlerweile bin ich begeistert und "meine" ersten Anwender sind angetan, da sie schnell "durchblicken". Aber "veränderte" Einstellungen, wie die Sache mit der Extension, dürfen nicht zum GAU werden.
Gruß, Hans J. G.
Edit: WB 2.7 ist jetzt als Testplattform installiert
Den ersten Tip kann man auch schon sehen.
http://huehnerbein.visuelle-kommunikation.de/