WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
WebsiteBaker 2.8.2 RC5 Tests
NorHei:
--- Quote ---Leider ist das auch nach der Installation nicht klar, da es so seltsame Programme wie z.B. FileZilla gibt, mit denen sich Rechte jederzeit nachträglich ändern lassen.
--- End quote ---
Äh, eben nicht unbedingt habe hier PHP als Apachemodul laufen das heist Dateien die von WB angelegt werden laufen unter unter einem anderen Benutzer als die per FTP eingespielten.
Da ist es dann garnicht so einfach mal die Rechte wieder zu ändern.
Vielleicht mal auf einem Server testen auf dem PHP als Apachemodul läuft.
Was ich nicht verstehe ist das dem pages Verzeichniss die Rechte entzogen wurden, denn nach der Installation wahren sie ja wohl gesetzt. Ich verstehe einfach nicht den Sinn warum man das machen sollte.
DarkViper:
--- Quote from: NorHei on January 18, 2011, 09:59:29 PM ---Vielleicht mal auf einem Server testen auf dem PHP als Apachemodul läuft.
--- End quote ---
Das Problem ist leider allzugut bekannt.... aber es wird daran gearbeitet.. ;-)
--- Quote from: NorHei on January 18, 2011, 09:59:29 PM ---Was ich nicht verstehe ist das dem pages Verzeichniss die Rechte entzogen wurden, denn nach der Installation wahren sie ja wohl gesetzt. Ich verstehe einfach nicht den Sinn warum man das machen sollte.
--- End quote ---
Dem /pages/ wurden keine Rechte entzogen, es wurde nur in die DocumentRoot 'verlegt'. Verschiedene Admins haben eben lieber Links wie http://example.com/startseite.php anstatt http://example.com/pages/startseite.php.
Normalerweise kein Problem, solange der Provider bei einem unter apache2modul laufenden Server dem www-run nicht die Schreibrechte für DocumentRoot entzieht.
Bei derartiger Konfiguration gibt es nur 2 Möglichkeiten:
* einen Webspace nehmen, der diese Probleme nicht bereitet... bzw. auf fast/CGI umschalten
* jedes Unterverzeichnis in DocumentRoot erst mal per FTP anlegen und passende Rechte vergeben, bevor www-run da was reinschreiben kann.
ruebenwurzel:
Hallo,
--- Quote from: DarkViper on January 18, 2011, 10:39:34 PM ---Bei derartiger Konfiguration gibt es nur 2 Möglichkeiten:
* einen Webspace nehmen, der diese Probleme nicht bereitet... bzw. auf fast/CGI umschalten
* jedes Unterverzeichnis in DocumentRoot erst mal per FTP anlegen und passende Rechte vergeben, bevor www-run da was reinschreiben kann.
--- End quote ---
Hätte da noch eine dritte Variante anzubieten. Bin auch bei einem Provider (allinkl) bei dem Apache als Modul läuft. Dennoch ist es da recht einfach Seiten ins "root" zu bekommen ohne in Konflikt mit den Rechten zu kommen. WB wird einfach in ein Unterverzeichnis des Server-roots gelegt (z.B. in das Verzeichnis "wb"), in der Konfiguration zu diesem Webspace (bei allinkl die KAS-Oberfläche) ändert man den Zeiger auf die Domäne dann auf dieses Verzeichnis. Fertig.
Matthias
P.S.
Kann auch angewendet werden wenn man parallel zu einer alten Seite eine neue mit WB anlegen will. Da kann man die alten Seiten unverändert lassen, die neuen WB Seiten in einem Unterverzeichnis komplett fertig machen und am Tag X dann einfach den Zeiger und (bei WB 2.8.x) in der config.php den Pfad ändern und alles ist gut.
HANS 0:
- LightTPD (win32)
- MySQL 5.1.35
- PHP 5.3.4
- WB RC5
Bitte Direktzugriff (Client) auf modules/admin.php unterbinden.
(für'n richtigen Satz hab' ich i.M. keine Zeit )
NorHei:
Das mit dem Verschieben der /pages in Webroot war mir so noch nicht bekannt, das mit den Unterverzeichnissen scheint mir da ne gute Lösung wenn man keinen eigenen Server nutzt.
Zumal man ja von Seiten Websitebakers keinen Einfluss auf diese Schreibrechte hat.
Dann währe es wohl tatsächlich besser nur das aktuelle Verzeichniss zu überprüfen in das geschrieben werden soll, und beim Verschieben eben wieder prüfen kann ich am Zielort schreiben.
Den nicht bei jedem Hoster hat man eine der drei Optionen um im Webroot Schreibrechte zu bekommen.
Zusätzlich beugt das Überprüfen beim Verschieben auch gleich Manipulationen vor bei denen vielleicht etwas wohin verschoben wird wo es nicht hingehört.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version