Ja verstehe. Aber ich verstehe nicht, warum ich im Adminbereich das Template von EyeCandy auf Honeygrid umstelle und ich dann meine Seite nicht mehr aufrufen kann. Dann anschließend in phpMyAdmin die gm_configuartions ---> mobile_template auf mobileCandy umschreibe und dann das Honeygrid auf einmal funktioniert. Mhh Ebenso wird mir jetzt oben auf der Startseite: Template directory '/var/www/web70/html/html/StyleEdit3/templates/Honeygrid' is not writable angezeigt. Auch wenn ich das Template in den Bearbeitungsmodus lade.
Hallo constantineduardo, deaktiviere bitte das MobileCandy noch im Admin. Der Vorteil eines responsiven Templates ist, dass sich die Darstellung der Größe des genutzten Gerätes anpasst. Vorausgesetzt, dass man alles responsiv umsetzt. (z.B. wenn man irgendwo Bilder in einem Textfeld einfügt). Damit erspart man sich die doppelte Template-Pflege.
Setzte mal bitte im Verzeichnis StyeleEdit3/ templates/ Honeygrid alle Ordner mit allen Unterordnern auf die Schreibrechte 777 ebenso die __temporary_style_config....
Okay, diese waren auf 755. Also für Besitzer berechtigt zu schreiben, nicht für Gruppen und öffentliche Berechtigung.
Tatsache ... ich habe den Ekomi-Code in meinem testshop mal rausgenommen .. und siehe da ... Honeygrid funktioniert
Hallo. Haben endlich einen Testshop eingerichtet. Bekommen zwecks StyleEdit folgende Fehlermeldung: Template directory '/www/htdocs/w0141d87/lern-verlag.de/StyleEdit3/templates/Honeygrid' is not writable Was ist zu tun? Danke und Gruß
Kurzer Einwurf: Es gibt leider keine universell für alle Hoster pauschal richtige Tabelle mit zu setzenden Dateirechten, setzt darum den Ordner StyleEdit3/templates/Honeygrid inklusive allem was darinliegt auf 777, das stimmt meistens. Um das Problem mal ganz kurz ganzheitlich zu umreissen: Klassische Unixrechte in Hostings trennen Dateiberechtigungen für jede Datei und jeden Ordner einzelen zwischen Besitzer, Gruppe und anderen auf. Wir loggen uns mit einen FTP-Benutzer x ein und laden unsere Dateien hoch. Nur: Ist Benutzer x auch der, der den Webserver auf der Maschine betreibt oder ist das vielleicht ein Systembenutzer mit dem Namen www-data? Wenn ersteres zurtrifft sind die Besitzerrechte ziemlich wichtig. Wenn der webserverbetreibende Unixbenutzer aber nicht unser FTP-Nutzer ist, ist der vielleicht in der gleichen Gruppe wie unser FTP-Nutzer x, denn einerbestimmten gehören ja alle unsere Dateien. Wenn das so ist, sind die Gruppenrechte aller Elemente wichtig und die Nutzerrechte zu vernachlässigen. Nur wenn der Webservernutzer auch nicht in der Gruppe ist wie unser FTP-Benutzer, dann muss man die Rechte über die Rechte für "andere" festlegen. Wenn wir jetzt aber einen Hoster aus Fall 1 haben, könnte der das unsicher finden wenn andere alles dürfen (was auch immer das in dessen Konfiguration bedeutet) und die Ausführung des Shops blockieren.Dann dürfen die Rechte für "andere" nicht hoch sein. Was beim einen richtig ist, kann also beim nächsten höchst falsch sein. Es gibt nur eine Menge von Dateirechten die etwas häufiger als andere bei Hostern korrekt ist, die geben wir dann üblicherweise an. Nur behaupten das wäre dann sicher so und dann auch noch für alle verlässlich geht nicht.
Hi Wilken ... du hast vollkommen Recht. Bei uns meckert er, nachdem ich dem erst genannten die Zugriffsrechte auf 777 gesetzt habe, das ich auch noch /www/htdocs/w0141d87/lern-verlag.de/templates/Honeygrid/styles/custom die Zugriffsrechte anpassen soll Weiterhin bringt er (der Shop) jetzt (Zwischenstand, ohne den zweiten Zugriff zu ändern) die Meldung: CSS cache file cannot be created causing slow page speed.
Ja, sobald auch für den custom-Ordner und die enthaltenen Dateien die Rechte stimmen, verschwindet auch die Fehlermeldung .