Support » Plugin: Loco Translate » Translation files aren’t loaded via symlink outside wordpress project directory

  • Resolved juslintek

    (@juslintek)


    Problem is when I use symlinks to outside project directory files are not detected. Why? is there fix for that?

    P.S. Directory still belongs to same user php-fpm is on.

    • This topic was modified 5 years, 1 month ago by juslintek.
Viewing 15 replies - 1 through 15 (of 16 total)
  • Plugin Author Tim W

    (@timwhitlock)

    Files are not detected in what situation exactly?

    You say “Translation files aren’t loaded”. Where are they located? What part of the system is doing the loading?

    Please provide steps to reproduce and test.

    Thread Starter juslintek

    (@juslintek)

    Steps:
    1. Install core wordpress using wp-cli or by downloading
    2. Install demo database
    3. Go to activated theme directory and move languages dir to below public_html, basically outside webroot directory. In my case:
    core setup: /home/user/current/web/app/themes/twentynineteen
    language dir: /home/user/shared/web/app/themes/twentynineteen/languages
    4. ln -s /home/user/shared/web/app/themes/twentynineteen/languages /home/user/current/web/app/themes/twentynineteen
    5. Add extra languages to wordpress setup
    6. Install Greek language for the theme. I think this is one of the supported languages at least theme description lists it:

    Arabic
    Chinese
    Cyrillic
    Devanagari
    Greek
    Gujarati
    Hebrew
    Japanese
    Korean
    Thai

    7. Go to theme translation via Loco Translate and you’ll see no languages and files listed.

    Or you can do it otherwise fist install languages them move languages directory to symlink destination directory.

    Basically I’m deploying project with mina deployment script and I can create symlinks to files which are translated or modified on production, so its basically translations. And if I copy content from symlink to languages2 directory remove symlink and mv languages2 languages, it starts to show them again.

    • This reply was modified 5 years, 1 month ago by juslintek.
    • This reply was modified 5 years, 1 month ago by juslintek.
    Plugin Author Tim W

    (@timwhitlock)

    Before I go ahead and set all this up…

    Language files should not be installed under the theme. i.e. themes/twentynineteen/languages is a legacy location no longer included in WordPress downloads. Installed language packs will be found at: languages/themes/twentynineteen-*

    Does this change anything? Do you get the same results when you symlink the installed languages directory?

    Thread Starter juslintek

    (@juslintek)

    But what if I would like to VCS languages? Whats the strategy for languages Version Control? I’ll move translations there. I think it doesn’t matter where languages are located after this:

    
    load_theme_textdomain('my_textdomain', get_template_directory() . '/languages');
    

    is used inside after_setup_theme, action hook callback.

    • This reply was modified 5 years, 1 month ago by juslintek.
    • This reply was modified 5 years, 1 month ago by juslintek.
    Plugin Author Tim W

    (@timwhitlock)

    I can’t offer advice on that part. load_theme_textdomain is part of WordPress. I’m trying to establishing if there’s a bug in my plugin, regarding your point no.7 above.

    It’s possible that the file listing isn’t symlink safe, so I’ll look at that shortly. However, it would save me some time if you could eliminate the fact that the themes/twentynineteen/languages would not be expected to contain any files after a language install.

    Thread Starter juslintek

    (@juslintek)

    the languages directory should contain translation files.

    Okay, so lets say just move whole wp-content/languages directory via symlink to parallel shared directory. As well I will try to adjust my code accordingly, that it would use new updated localization directory structure.

    • This reply was modified 5 years, 1 month ago by juslintek.
    • This reply was modified 5 years, 1 month ago by juslintek.
    Plugin Author Tim W

    (@timwhitlock)

    I’ve tested this. From a clean WordPress install, I installed Greek translations.

    With the original folder structure (under /site) I have:

    /site/wp-content/languages/themes/twentynineteen-el.mo

    So as mentioned previously, nothing under themes/twentynineteen/languages as is normal.

    Then I move the whole global languages directory to a shared location and symlink it into the site, as you suggest:

    mv /site/wp-content/languages /shared/languages
    ln -s /shared/languages /site/wp-content/languages

    Then I go into Loco Translate dashboard and see warnings that /shared/languages is outside my open_basedir. So I fix that in my PHP config and restart server.

    After this, file listings and translation loading all works as expected.

    Plugin Author Tim W

    (@timwhitlock)

    As for your original report –

    Translation files aren’t loaded via symlink outside wordpress project directory

    – I’m unable to reproduce this.

    Perhaps you have the open_basedir issue too. Or perhaps some other file permission problem. All I can say is that Loco Translate can pull file listings from the normal registered paths as long as PHP can see the files.

    Thread Starter juslintek

    (@juslintek)

    @timwhitlock no, because I do same with uploads directory and cache directory and its working, its loco translate problem specifically, its just not loading languages on interface, while translations themselves are picked up by wordpress itself. Seems like you’re not using official WordPress FileSystem class to CRUD po, mo, pot files. P.S. I use no openbase dir restrictions as its not shared hosting.

    • This reply was modified 5 years, 1 month ago by juslintek.
    • This reply was modified 5 years, 1 month ago by juslintek. Reason: Forgot to mention openbase_dir restriction is not enabled
    Plugin Author Tim W

    (@timwhitlock)

    FileSystem abstraction isn’t necessary for reading files. WordPress itself doesn’t even use these classes for file listings.

    You are also comparing the reading of files to the reading of directories. WordPress loading MO files for a given path is not equivalent to Loco Translate finding them inside your folders.

    Let’s get back to reproducing why the file listings are failing …

    Loco Translate deliberately avoids following symlinks in some situations (security reasons; avoiding infinite loops; avoiding scanning your entire server). It’s possible this applies in your case, but it shouldn’t apply to the official file locations like the languages directory. This measure is only taken when searching for additional files in non-standard locations.

    In trying to reproduce your setup, clearly something is different. We started talking about a folder under your theme (themes/twentynineteen/languages) and are now talking about symlinking the entire wp-content/languages directory. Can you please show me your current setup and which points along the path are symlinked?

    Thread Starter juslintek

    (@juslintek)

    @timwhitlock, okay my current setup uses symlinked directory specified by this function:
    Add this to after_theme_setup hooks callback in functions.php of twentynineteen:

    
    load_theme_textdomain('tudosobresites', get_template_directory() . '/languages');
    

    So you can just add this function to twentynineteen and move its language files from wp-content/languages/themes/twentynineteen* to wp-content/themes/twentynineteen/languages and then run this bash script to rename language files accordingly. Go to default wp ABSPATH directory and:

    
    parallel_dir=$(realpath ../shared/wp-content/themes/twentynineteen/languages)
    theme_dir=$(pwd)/wp-content/themes/twentynineteen
    mkdir -p $paralel_dir
    cp -rf wp-content/languages/themes/twentynineteen* $parallel_dir
    cd $parallel_dir
    for file in $(ls *.po *.mo); do mv $file $(echo $file | cut -d'-' -f2); done;
    cd $theme_dir
    ln -s $parallel_dir languages
    

    And try it now.

    P.S. I’ve currently change my CI environment just to copy language files on deployment from previous release to the current to avoid all that symlink stuff.

    If this doesn’t work then guess its because I’m using bedrock then.

    • This reply was modified 5 years, 1 month ago by juslintek.
    Plugin Author Tim W

    (@timwhitlock)

    OK, I’ve got it.

    The issue is that when finding a file with no text domain prefix the path is checked to see if it is under the theme directory. Code here.

    I could potentially fix that, but it’s a real edge case. Each folder in the path would have to be checked until one is found to be linked into the sub tree. Considering this folder location is deprecated, I’m not super keen to do that work.

    I strongly recommend you don’t use folders under the theme to hold your translation files. As suggested earlier I suggest symlinking the global languages directory.

    If you must use the theme folder, I suggest symlinking the entire theme rather than just its languages directory.

    Thread Starter juslintek

    (@juslintek)

    Okay I’ll do the rework.

    Plugin Author Tim W

    (@timwhitlock)

    I’ve added a fix for this in the dev branch.

    The file finder still follows symlinks, but this code checks if the file was originally under the theme.

    Thread Starter juslintek

    (@juslintek)

    Thanx for the change, maybe it will be implemented in the future. But one way or another I think custom language directories should be considered. 🙂 Because I might save them in ABSPATH or even above public_html path. So people could access them lets say from more then one service. 🙂

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Translation files aren’t loaded via symlink outside wordpress project directory’ is closed to new replies.