[3.80] Übersetzung und translation.phtml weg nach Auto-Update

[robertskiba]

Ich habe heute in meinem Testshop das Update auf die 3.80 gemacht per Auto-Update, um zu testen, ob mittlerweile dieses im Betreff beschriebene Problem gelöst ist.

Leider wird immer noch eine leere wpsg-de_DE.po ins LANG-Verzeichnis geschrieben und das LANG-Verzeichnis und die wichtige Datei translation.phtml werden nicht gesichert und zurückgespielt. (ganz zu schweigen vom User_views, wenn man es noch im Plugin-Ordner hat). Dies zerstört jedem Nutzer, der WPSG mehrsprachig nutzt, die komplette übersetzung, wenn er sie nicht gesichert hat.

EIne Lösung wäre, hier eine entsprechende Routine zu integrieren, die das korrekte kopieren in das wpsg_temp-verzeichnis überprüft und anschließend das korrekte zurückspielen.

Alternativ könnte man das automatische Update per Option deaktivieren, damit nicht z.B. ein Kunde dieses automatisch durchführt.

Bevor gefragt wird: Ich bin bei Hosteurope und habe einen Webspace, der rechtemäßig keinerlei Probleme macht was das kopieren von DAteien durch PHP-Apps angeht, also hakt es irgendwo in eurem Shop.

[maennchen1.de]

Hallo!
Bitte prüfe und nenne uns folgende Kriterien:

1. Welchem Benutzer gehört der Ordner wp-content/plugins/wpshopgermany und wie lauten die Dateiberechtigungen?
2. Welchem Benutzer gehört die Datei wp-content/plugins/wpshopgermany/lib/translation.phtml und wie lauten deren Dateiberechtigungen?
3. Gibt es einen Ordner wp-content/uploads/wpsg_temp/? Wenn ja, wem gehört dieser Ordner und wie lauten dessen Dateiberechtigungen?
4. Wie hast du die alte Version installiert (per FTP/WordPress Backend) und wie die neue?

[MKJ]

Ich kann beides bestätigen. Auch bei mir waren nach dem Update aus dem Backend heraus die .mo Datei und die translation.phtml futsch. Bei mir gehören alle Ordner und Dateien dem SSH-User. Alle haben identische Rechte 775 für Ordner und 644 für Dateien. Bei mir wird WPSG initial fast immer per FTP hochgeladen. Updates mache ich normalerweise auch per FTP, weil es per Backend nicht sicher funktioniert.

Fairerweise muss man sagen, dass fast alle Plugins ohne eigene Mods die Sprachdateien löschen bei einem Update. Es ist daher sinnvoll, einen Override für den Standardordner zu machen. Das folgende Snippet habe ich getestet:

Code: Alles auswählen

function wpse159536_override_mofile_path( $mofile, $domain ){
    if( 'other_plugin' == $domain ){
         $mofile = WP_LANG_DIR . '/plugins/' . basename( $mofile );
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'wpse159536_override_mofile_path', 10, 2 );
function wpse159536_override_mofile_path( $mofile, $domain ){
    if( 'other_plugin' == $domain ){
         $mofile = WP_LANG_DIR . '/plugins/' . basename( $mofile );
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'wpse159536_override_mofile_path', 10, 2 );

Wenn man nun die Sprachdateien in wp-content/languages/plugins legt und die .mo Datei im Plugin löscht, klappt alles. Das gilt allerdings nicht für die translation.phtml. Wofür ist die eigentlich?

[robertskiba]

Die translation.phtml ist äußerst wichtig, damit selbstdefinierte Strings für Übersetzungsprogramme übersetzbar werden. Sobald du z.B. die Shop-Infos aktualisierst, werden die Shop-Infos in dieser Datei als String gespeichert und sind ab dann für Übersetungsprogramme (z.b. POEDIT) zu finden. Nur mithilfe dieser Datei lassen sich 100% von WPSG in eine andere Sprache übersetzen.

Es wäre aber sehr hilfreich, wenn es eine verlässliche Rücksicherung aller Dateien (inklusive des oft noch benötigten USERVIEWS-VZs) zurück in den Plugin-Ordner geben würde. Andere Plugins schaffen dass doch auch. Es handelt sich doch "nur" um einfache hin-undher-kopiervorgänge.

[MKJ]

Danke für die Erklärung!

Es wäre aber sehr hilfreich, wenn es eine verlässliche Rücksicherung aller Dateien (inklusive des oft noch benötigten USERVIEWS-VZs) zurück in den Plugin-Ordner geben würde. Andere Plugins schaffen dass doch auch. Es handelt sich doch "nur" um einfache hin-undher-kopiervorgänge.

Das stimmt so nicht ganz. Anpassungen im Pluginordner werden von den meisten Plugins bei einem Update überschrieben und nicht zurück gespielt. Deshalb gehen manche Entwickler einen anderen Weg und weisen die User an, die Anpassungen extern abzulegen (z.B. Satollo Newsletter). Das wird bei WPSG mit den user_views auch gemacht. Dort sollte auch die translation.phtml liegen. Optimalerweise könnten dort dann auch gleich die Sprachdateien untergebracht werden, dann ist Ruhe im Karton.

Bei einem Premium Plugin darf man das eigentlich schon erwarten. Obwohl ich kein Anfänger bin, ist mir relativ später klar geworden, warum das kombinierte Update per FTP und Backend immer Probleme gemacht hat. Von normalen Anwendern ist das bei weitem zu viel verlangt. Ein Problem kann das Übersetzen per Codestyling Localization werden. Ich denke, es wäre das beste, wenn mit der Installation die kompletten (leeren!) user_views gleich auch angelegt würden. Dort würden dann zunächst nur die Sprachdateien liegen. Die sollten sich dann per Codestyling auch übersetzen lassen. Wenn ich das richtig sehe, müsste doch nur dieser Part geändert werden:

Code: Alles auswählen

public function wp_load() { load_plugin_textdomain('wpsg', false, dirname( plugin_basename( __FILE__ ) ).'/../lang/');

Das könnte man doch problemlos auf die user_views modifizieren. Oder spricht etwas dagegen?

[robertskiba]

Absolut richtig! Der hauptgrund, warum ich z.B. in meinem Testshop noch die User_views im Plugin-Ordner habe, ist die Übersetzung.

Leider funktioniert bei mir seit Wordpress 3.2 Codestyling nicht mehr und ich verwende seitdem Loco-Translate, was auch sehr gut funktioniert, wenn auch minimal anders als Codestyling. Ich habe schonmal den Entwickler von Loco angesprochen, ob man nicht vielleicht zusätzliche Ordner pro Plugin definieren kann, in denen nach Übersetzungen gesucht wird. Dann wäre nämlich alles perfekt. Wenn man dann auch noch den Ordner für die Übersetzungsdateien definieren könnte, bräuchte niemand mehr veränderbare Dateien im Plugin-Folder.

[maennchen1.de]

Die po und mo Dateien müssen IMHO zwingend im WordPress Ordner liegen, damit WordPress diese finden kann. Man kann sie leider nicht einfach irgendwohin kopieren.
Genauso die translation.phtml. Die muss ebenfalls im Plugin-Ordner liegen, damit die Übersetzungsplugins diese zuordnen können.

[robertskiba]

Na also, damit sagst du ja im Grunde selbst, dass da was passieren muss.

Wie wäre es denn mit einer Backup-Funktion, die diese Dateien vor dem Update sichert ins Upload-Verzeichnis und dann zurückspielt?

[MKJ]

Super cooler Tipp!! Loco-Translate ist ziemlich gut. Du kannst dort auch angeben, wo die Sprachdatei erzeugt werden soll: im Plugin-Ordner oder im globalen Ordner. Läuft einwandfrei. Bei einem Update müsste man dann eventuell nur die neue .mo Datei im Plugin löschen, weil die wohl Priorität hat. Schade, dass man nicht sieht, in welcher Datei der jeweilige String liegt. Das war schön bei Codestyling Localization.

[MKJ]

Die po und mo Dateien müssen IMHO zwingend im WordPress Ordner liegen, damit WordPress diese finden kann. Man kann sie leider nicht einfach irgendwohin kopieren

Nee, wie kommst Du darauf? WordPress bringt doch selbst einen Order mit dafür. Ich habe das gerade getestet. Läuft einwandfrei auch ohne die Mod in der functions.php. Wenn in dem Ordner etwas drin ist, wird es auch genommen. Ich meine, dass man über die load_textdomain den Ordner beliebig festlegen kann. Habe ich aber nicht getestet.

[maennchen1.de]

Wie wäre es denn mit einer Backup-Funktion, die diese Dateien vor dem Update sichert ins Upload-Verzeichnis und dann zurückspielt?

Diese Funktion gibt es seit Version 3.0. Warum Sie bei dir nicht funktioniert, versuche ich ja mit meinen Fragen heraus zu bekommen. Aber dann musst du auch darauf antworten.

Wenn in dem Ordner etwas drin ist, wird es auch genommen.

Genauso wie es gelöscht wird, wenn du ein WordPress Update machst

[robertskiba]

Ich hab das mal gerade getestet.

Also das Verzeicnis WPSG_TEMP im Uploadsordner hat die Berechtigung 750 und ist leer.

Die Translations.phtml wird mit berechtigung 640 erstellt, wenn sie nicht existierte.

Alle anderen Dateien sind auf 755 gesetzt (z.B.die Lang-Files).

Alle Dateien, ob frisch erstellt oder reinkopiert, werden alle mit den vollen Berechtigungen des Webserver-Users erstellt.

[maennchen1.de]

Die einzelnen Berechtigungen in Zahlen haben keinen Wert, wenn du nicht den Benutzer dazu nennst.
Die erste Zahl steht für den Benutzer. Das kann zum Beispiel der Webserver sein, oder der FTP-Benutzer.
Jetzt kann aber auch der FTP Benutzer der Gruppe angehören, die dem Webserver gehört (oder umgedreht). Dann ist die zweite Zahl ausschlaggebend.

Hallo!
Bitte prüfe und nenne uns folgende Kriterien:

1. Welchem Benutzer gehört der Ordner wp-content/plugins/wpshopgermany und wie lauten die Dateiberechtigungen?
2. Welchem Benutzer gehört die Datei wp-content/plugins/wpshopgermany/lib/translation.phtml und wie lauten deren Dateiberechtigungen?
3. Gibt es einen Ordner wp-content/uploads/wpsg_temp/? Wenn ja, wem gehört dieser Ordner und wie lauten dessen Dateiberechtigungen?
4. Wie hast du die alte Version installiert (per FTP/WordPress Backend) und wie die neue?

[robertskiba]

Ich hab doch geschrieben, dass bei Hosteurope so wie bei vielen alle lese- und Schreibvorgänge mit dem Webserver-Benutzer durchgeführt werden und es somit nur einen einzigen Benutzer gibt. Selbst bei Zugriff per FTP kann man im Backend des PRoviders wählen, ob diese mit extra FTP-USEr-Berechtigungen oder als Webserver-User geschrieben werden sollen. Hier ist alles komplett einheitlich. Es gibt sozusagen nur einen Benutzer.


Die erste Zahl steht übrigens immer für den Owner, die zweite für die Gruppe und die dritte für alle anderen. Die dritte Berechtigung ist wichtig. Bei PHP reicht es, wenn diese auf Read steht, um eine Datei wegzukopieren, oder??

[maennchen1.de]

Ich dachte es geht für beide unkomplizierter, indem du einfach

• Benutzername, 755

schreibst. Das ist eineindeutig und lässt keinen Interpretationsspielraum. Aber gern frage ich weiter, bis die Punkte für mich beantwortet sind:
Wie hast du die alte Version installiert (per FTP/WordPress Backend) und wie die neue?

Ich weiß, dass du dich in der Materie auskennst. Um so einfacher ist es doch, einfache Antworten zu geben, oder?

Bei den Berechtigungen ist jede Zahl wichtig. Hier ein paar Grundfakten (für alle anderen):
http://wpshopgermany.maennchen1.de/2015 ... via-chmod/