Beiträge mit dem Tag ‘domainfactory’

WordPress Domainfactory-Dateirechte-Problem endgültig gelöst

6. April 2009

Vor einiger Zeit habe ich ein WordPress Plugin geschrieben, dass die Dateirechte beim Upload einer Datei ändert. Dies war nötig, da mein Webhoster Domainfactory eine Webserver-Konfiguration benutzte, die Probleme beim WordPress Upload machte (gemeint ist hier natürlich eine eigene WordPress Installation und nicht die, die Domainfactory selbst anbietet). Anfang Februar berichtete ich von einer möglichen Lösung des Problems die das Plugin überflüssig macht. Nach gut zwei Monaten des testens lässt sich definitiv sagen: das Problem ist gelöst! Mit der beschrieben Lösung werden die Dateirechte einwandfrei gesetzt. Ich werde deshalb die weitere Entwicklung an meinem Plugin “Change Uploaded File Permissions” ab sofort einstellen.

Hier noch einmal die Vorgehensweise bei Problemen mit dem Dateiupload:

Allem Anschein nach hat sich diese Problematik aber nun erledigt und die Dateirechte können auch auf “normalem” Wege einwandfrei gesetzt werden. Alles was wann dafür tun muss, ist dem Ordner “uploads” (zu finden unterhalb von wp-content) die Rechte “750″ zu geben. Mit dieser Einstellung erhalten alle *neuen* Dateien und Ordner unterhalb von “uploads” die richtigen Rechte, so dass reibungslos damit gearbeitet werden kann. Bei mir reichte dies allerdings nicht aus, und ich musste auch allen Ordnern unterhalb von “uploads” die Rechte “750″ geben. Danach funktionierte alles aber reibungslos. Wenn man keine Bilder oder Dateien in alte Artikel einfügen will, sollte es also ausreichen dem Ordner “uploads” und dem aktuellen Jahresordner die Rechte “750″ zu geben (sofern man Monats- und Jahresbasierte Strukturen verwendet).

Lösung für Domainfactory-Dateirechte-Problem gefunden?

6. Februar 2009

Seit September 2007 kümmert sich mein Plugin “Change Uploaded File Permissions” um das Setzen der richtigen Dateirechte bei Dateien und Bildern, was insbesondere beim Webhoster Domainfactory nötig ist. Die Problematik war Domainfactory bekannt und nur durch ein manuelles Eingreifen in den WordPress-Core zu beheben. Genau an dieser Stelle setze das Plugin ein und machte einen solchen Eingriff bei jedem WordPress Update überflüssig.

Allem Anschein nach hat sich diese Problematik aber nun erledigt und die Dateirechte können auch auf “normalem” Wege einwandfrei gesetzt werden. Alles was wann dafür tun muss, ist dem Ordner “uploads” (zu finden unterhalb von wp-content) die Rechte “750″ zu geben. Mit dieser Einstellung erhalten alle *neuen* Dateien und Ordner unterhalb von “uploads” die richtigen Rechte, so dass reibungslos damit gearbeitet werden kann. Bei mir reichte dies allerdings nicht aus, und ich musste auch allen Ordnern unterhalb von “uploads” die Rechte “750″ geben. Danach funktionierte alles aber reibungslos. Wenn man keine Bilder oder Dateien in alte Artikel einfügen will, sollte es also ausreichen dem Ordner “uploads” und dem aktuellen Jahresordner die Rechte “750″ zu geben (sofern man Monats- und Jahresbasierte Strukturen verwendet).

Ich werde mein Plugin vorerst hier deaktivieren und das Ganze weiter testen. Es sieht aber so aus, als wenn das Plugin nicht mehr benötigt wird.

Siehe auch: Domainfactory Forum.

Wie der alte Webhoster wieder der Neue wurde

28. Januar 2009

Im Oktober letzten Jahres habe ich, wie berichtet, meinem langjährigem Webhoster Domainfactory den Rücken gekehrt um bei HostEurope eines neues zu Hause für meine Domains zu finden. In einem vServer wollte ich zukünftige nicht nur meine Domains, sondern auch das Hosting unterbringen. Die Einrichtung dauerte zwar etwas lange, aber angesichts des Preis/Leistungsverhältnis war es mir das wert. Obwohl es sich um ein recht leistungsstarkes, wenn auch nur virtuelles System, handelte, war ich mit der Performanz von Beginn an nicht richtig glücklich. Shared Hosting war in Bezug auf die Antwortzeiten eindeutig schneller. Da es sich aber im Rahmen hielt, konnte ich damit leben. Anfang Dezember viel dann der vServer zum ersten Mal komplett aus. Weder über SSH, noch über die bereitgestellte Virtuozzo-Anwendung war ein Zugriff möglich. Nachdem ich Hosteurope über den Umstand informiert hatte, wurde der vServer innerhalb von 24 Stunden neu gestartet. Grund des Ausfalls: Die Virtualisierung hatte sich “aufgehängt”. Aufgrund der schnellen Reaktionszeit und der Tatsache das der vServer wieder lief, legte ich diesen Vorfall in der Kategorie “kann ja mal passieren” ab. Unglücklicherweise wiederholte sich der Vorfall Ende Dezember und Anfang Januar. Beide Male wurde der Server innerhalb von 24 Stunden neu gestartet. Allerdings hat Hosteurope bis heute keinen Grund für den letzten Ausfall gefunden. In Verbindung mit der Tatsache, dass die Antwortzeiten mittlerweile jenseits von Gut und Böse lagen, war dies für mich das Zeichen dem Thema vServer ein für alle mal den Rücken zu kehren. Denn vor Hosteurope hatte ich mir schon die vServer von 1&1 sowie united hoster angesehen. Hier waren die Antwortzeiten aber so hoch, dass ich gar nicht erst damit angefangen habe, meine Domains umzuziehen.

Ich beschloss meinen vServer auf ein Hosting-Paket von HostEurope umzuziehen. Dies lies sich auch schnell und mit wenigen Schritten über das Kundenmenü erledigen. Innerhalb weniger Minuten stand mit das neue Paket zur Verfügung. Auch meine Domain (zunächst erstmal eine um es zu testen) war schnell umgezogen. Dummerweise hatte das Ganze einen Haken: WordPress funktionierte nicht einwandfrei. Zunächst war es nicht möglich Plugins automatisch zu aktualisieren. Nach ein bisschen googeln fanden sich glücklicherweise einige Anleitungen, wie sich dieses Problem beheben lies. Allerdings war es jetzt nur möglich Plugins zu aktualisieren, wenn man einen FTP-Account angibt, Änderungen am WordPress-Core vornimmt, sowie dem kompletten Plugin-Verzeichnis die Unix-Rechte 777 zuweist. Ein, sagen wir mal, ungünstiger Umstand. Als dann aber auch das editieren der Plugins über das Backend nicht ohne Änderung der Rechte möglich war, wurde mir klar, dass WordPress auf diesem Hosting-Paket immer nur mit “fummeln” funktionieren würde.

So fasste ich Anfang der Woche die Entscheidung wieder zu Domainfactory zurück zu kehren. Auch wenn ich mit dem Preis/Leistungsverhältnis nicht zufrieden bin und es mit Sicherheit auch noch andere Webhoster gibt, so weiß ich doch, das all die Kleinigkeiten die einem das Leben beim Webhosting leichter machen, bei Domainfactory funktionieren. Da ein Domainumzug heute keine Woche mehr dauert, schreibe ich diesen Beitrag bereits auf dem alten bzw. neuen Webhoster.

HostEurope kann ich nach wie vor weiterempfehlen. Es sei denn, man möchte WordPress auf einem Hosting-Paket betreiben. Auch einen vServer möchte ich nicht komplett schwarz malen. Die Erfahrungen die ich damit gesammelt habe zeigen aber, dass es einen großen Unterschied macht, was man dort betreiben will. Wenn es nur HTML-Seiten sein sind, und mit viel Traffic zu rechnen ist, haben vServer-Systeme durchaus ihre Existenzberechtigung. Was PHP-MySQL-Anwendung angeht sind solche Systeme meiner Meinung nach aber nicht Leistungsstark genug. Es sei denn man mietet sich ein System mit entsprechender Rechenpower. Dann kann man allerdings auch gleich zu einem dedizierten Server greifen.

Adieu Domainfactory

11. Oktober 2008

Nachdem ich nun gute 6 Jahre Kunde bei Domainfactory war, habe in den letzten Tagen meine Domains bei einem anderen Hoster untergebracht. Und obwohl ich die schlimmsten Befürchtungen hatte, verlief der Umzug von gut einem Dutzend Domains, div. Datenbanken und div. Blogs äußerst reibungslos. Auch der manchmal recht holprige KK-Antrag verlief ohne Probleme.

Bis gerade funktionierte allerdings der RSS-Feed nicht und mein Blog hat mitunter noch ein paar Performance-Problemen, aber auch hier bin ich zuversichtlich dies in Kürze in den Griff zu bekommen.

Der Grund, warum ich Domainfactory den Rücken kehre lässt sich eigentlich in einem Wort ausdrücken: Tarife. Die Tarif-Struktur bei Domainfactory hat mMn in den letzten Jahren einen Rückschritt gemacht. Allen voran ist hier die Limitierung von Domains zu nennen. War es früher noch möglich (gerade in den mittleren Tarifen) eine unlimitierte Anzahl von Domains in ein Paket zu legen, wird diese Anzahl seit einiger Zeit begrenzt. Hat man nun eine Vielzahl von Domains, so muss man u.U. in einen wesentlich teureren Tarif wechseln, nur um eine hohe Anzahl von erlaubten Domains zu ermöglichen.

Dies war allerdings nur ein Grund (wenn auch der ausschlaggebenste), der zur Kündigung geführt hat.

Trotz der Kritik, würde ich aber weiterhin meine Empfehlung für Domainfactory aussprechen. In Punkto Preis/Leistung und vor allem in Punkto Service habe ich bisher keinen besseren Web-Hoster gefunden. Manchmal sind es Kleinigkeiten (z.B. .htacces-Feature, Nameserver-Einstellungen) mit denen sich Domainfactory von anderen Hostern absetzt. Was die Tarife angeht sollte man allerdings genauer hinsehen und vergleichen.

Domainfactory und WordPress 2.5 Dateirechte [4. UPDATE]

19. März 2008

Bei der kommenden Version 2.5 von WordPress hat sich (wie dem ein oder anderen bekannt) einiges im Adminbereich geändert. Nicht nur die Optik hat einen neuen Anstrich bekommen, sondern auch technisch wurde einiges überarbeitet. Davon betroffen ist auch das Hochladen von Dateien. Beim Upload von Bildern werden z.B. zwei Thumbnails (klein und mittel) erstellt. Das “tolle” darin ist, dass bei einer frischen Installation von WordPress 2.5 (RC1) bei meinem Webhoster der Wahl Domainfactory, keine der drei Dateien die richtigen Rechte erhält, so dass man damit arbeiten kann, sprich, diese aufgerufen werden können. Auch bei anderen Dateien (Dokumente, Audio oder Video) werden die Dateirechte falsch gesetzt. Das Problem ist bekannt.

Ich habe versucht mein Plugin für die WordPress 2.5 anzupassen. Das Problem daran ist aber, dass das Erstellen der Thumbnails *nach* dem eigentlich Upload durchgeführt wird. Damit ist der Zugriff über ein Plugin während des Upload-Vorgangs unmöglich. Überall dort, wo nur eine Datei auf dem Webspace ankommt, als nach dem Upload nichts mehr mit der Datei gemacht wird, kann man die Dateirechte noch via Plugin ändern. Das ist aber nur ein kleiner Trost.

Auch wenn ich sehr gerne an dem Plugin rumprogrammiere, frage ich mich, wieso dieses Problem überhaupt auftritt. Ein generelles Problem mit dem Setzen der Dateirechte durch WordPress liegt m.M.n nicht vor, sonst würde das Problem überall auftreten und nicht nur bei Domainfactory. Mich würde wirkliche interessieren warum ausgerechnet diese eine Funktion in WordPress so mit dem Webspace von Domainfactory kollidiert.

So wie ich das im Moment sehe, ist eine eigene Installation von WordPress 2.5 auf Webspace von Domainfactory, nur mit manuellem eingreifen (via FTP) nach jedem Upload nutzbar.

[UPDATE]
Lese gerade bei momworx, dass das Problem wohl dann auftritt, wenn der “Apache als CGI-Modul” läuft. Ich vermute mal, dass hier wohl eher PHP als CGI-Modul gemeint ist. Dann müsste das Problem aber viel häufiger auftreten.

[2. UPDATE]
Habe gerade einmal ohne mein Plugin mit modifizierter /wp-admin/includes/file.php ein Bild hoch geladen. Gleiches Problem: die Rechte des Originalbildes werden geändert, nicht aber die der Thumbnails.

[3. UPDATE]
Nachdem ich mir die zuständigen Dateien angesehen habe, bin ich doch tatsächlich auf die richtige Funktion gestoßen. Deshalb hier mein Workaround für das Aktualisieren der Dateireche bei WordPress 2.5.

Änderungen in der Datei wp-admin/includes/file.php

Suchen nach

// Set correct file permissions
$stat = stat( dirname( $new_file ));
$perms = $stat['mode'] & 0000666;
@ chmod( $new_file, $perms );

Und wie folgt erweitern

// Set correct file permissions
$stat = stat( dirname( $new_file ));
$perms = $stat['mode'] & 0000666;
@ chmod( $new_file, $perms );
chmod ($new_file,0640);

Damit sind dann schon einmal die Dateirechte der Originaldatei geändert.

Änderungen in der Datei wp-admin/includes/image.php

Suche nach

// fetch additional metadata from exif/iptc
$image_meta = wp_read_image_metadata( $file );
if ($image_meta)
$metadata['image_meta'] = $image_meta;

Und direkt darunter folgenden Code anfügen

$thumbs = explode (".",$file);
foreach (glob($thumbs[0]."*") as $currentfile) {
chmod ($currentfile,0640);
}

Erläuterung: da (aufgrund der im Dateiname eingefügten Dimensionen) nicht bekannt ist, welchen Dateiname die Thumbs haben, schneiden wir als erstes die Dateiendung mit explode ab. Danach suchen wir mit der PHP-Funktion glob nach allen Dateien mit dem übergeben Dateiname (ohne Endung) und ändern die Dateirechte.

Nutzung auf eigene Gefahr!

Mal sehen, ob ich das irgendwie in mein Plugin bekomme. Bei jeder neuen WordPress Version im Code rumzufummeln finde ich nämlich ziemlich albern.

[4. UPDATE]
Da ich jetzt wusste, wo ich suchen muss konnte ich das Ganze auch in mein Plugin integrieren. Das hat zwar nochmal ein bisschen Zeit gekostet, aber jetzt funktioniert das Ändern auch automatisch in WordPress 2.5. Siehe hier.