Support » Plugin: WP Media folders » WPML compatibility

  • We have a issue when moving a file in Media Folder. The url in _wp_attached_file does not update for the 2nd language.

    subcatalog/picture.jpg <– _wp_attached_file value for primary language
    picture.jpg <– _wp_attached_file value for secondary language

    Are your plugin supposed to be compatible with WPML? …and if not, would it be possible for you to provide us some information on where code should be modified to make it update both _wp_attached_file language entries?

    If you even only could point us in the right direction on how to solve this it would be very appreciated!

    Thanks in advance!

Viewing 15 replies - 1 through 15 (of 16 total)
  • Plugin Author dbarrere



    There is no particular integration with WPML and it should work out of the box.

    What image are you talking about, the featured image or another one?

    Best regards

    When we add a image to a virtual folder in “Media Folder” library the image appears in the correct folder for the primary language, but for secondary language the image appears in the root folder.

    This is because the image-url for some reason doesn’t update for the 2nd language entries in DB.

    You should only have one _wp_attached_file meta per file.

    Once you add an image WP Media Folder add this image to two different “virtual” folders, but you still have only one actual file.

    When you move this file in to another virtual folder, WP Media Folders will move the actual file based on the latest folder the file is moved into.
    Let me explain a bit more, if you are on the media manager with the english language and move the file to the folder “My Stories/Children” the actual file will be in the folder “My Stories/Children”.
    Then you change the language to French in the WP media manager, you move the file to the folder “Mes histoires/Enfants”, the actual file will be moved from the folder “My Stories/Children” to the folder “Mes histoires/Enfants”

    When we add a image to a virtual folder in “Media Folder” library the image appears in the correct folder for the primary language, but for secondary language the image appears in the root folder.

    You are refering to “virtual” folders here right?
    This is the default behavior, when you upload a file directly to a folder in on language selected WP Media Folder will add this file to the folder you want, but the plugin has no idea which is the translated version of this folder, so it put it on the root folder.
    WP Media FolderS only deals with actual folder based on a hook triggered by WP Media Folders.

    The url in _wp_attached_file does not update for the 2nd language.

    In my opinion you’re dealing with two different attachments, you can check in your database the wp_postmeta table where you see the difference in the _wp_attached_file column, you should see that the post_id column value should be different. If it’s the case, it means that you have uploaded the image twice and you’re dealing with two different attachements.

    Please let me know.

    Best regards

    • This reply was modified 1 year, 2 months ago by JoomUnited.
    • This reply was modified 1 year, 2 months ago by JoomUnited.

    We made another test like following:
    1. In default language only; we create new virtual folder.
    2. In default language only; we upload a image to this new virtual folder.
    We 100% surely did NOT upload this image twice!

    After this we have 2 _wp_attached_file entries for this new image.
    One for primary language with correct image path (folder/image.jpg)
    One for secondary language with image path to root (image.jpg)
    We have only 1 actual file on disk, in the same path as _wp_attached_file holds for primary language (folder/image.jpg).

    In Media Library for the secondary language we have the virtual folder “/folder/”, but it’s empty. For the secondary language we find the image.jpg in the root.

    If we assign the image from virtual path “folder/image.jpg” to a product for primary language, it does not display for the secondary language.

    What procedure do we need to do to make the image appear on front-end for both languages?

    Here below is the problem described by the developer who is helping us with this and who has spent much more time on this issue than myself.

    Let me explain our situation.

    We don’t have virtual folders in different languages. All our real folders are in our Main language.
    We agree that the real file on the website is only one.
    But there are several posts which are related to this file.

    Part I. WPML

    When we upload an image to your virtual folder in Main language for our website (in your example it was English), WPML Media add-on creates posts (post_type = ‘attachment’ and post_mime_type = ‘image/jpeg’) for EACH languages on the website and creates relations between them in the wp_icl_translations table.

    For each of these posts in the wp_postmeta table there is must be a path to the real image on the website (‘_wp_attached_file’ = ‘customfolder/image1’). But this path is specified only for the message in the main language. For the post in the other languages path is ‘image1’, without ‘customfolder’.
    Also your plugin adds to virtual folders structure only one post in Main language.

    For example:
    We uplouded an image to the virtual folder ‘customfolder’. And WPML create two posts with IDs 31773 and 31774 in two languages.
    But your plugin changes path only for one post in main language.

    in the DB we can see following:
    31773 [term_taxonomy_id]
    but post with ID 31774 was not added to this term_taxonomy_id.
    it explains why it displays in the root folder.

    postmeta table
    31773 ‘_wp_attached_file’ = ‘customfolder/image1’
    31774 ‘_wp_attached_file’ = ‘image1’

    Part II. Products with images

    For example:
    We created a product in main language with ID 31780 and added to it a featured image in the same language 31773. In the DB we can see following:

    31780 ‘_thumbnail_id’ = 31773

    Then we created a translation of this product and it was created with ID 31781.

    in the DB we can see following:
    31780 ‘_thumbnail_id’ = 31773 => post in Main language
    31781 ‘_thumbnail_id’ = 31774 => post in Second language

    The WPML plugin knows about image translation and set it as a thumbnail to the product translation.

    So…. We have a situation when the translation of product is related to the translation images in which set path to the root folder but there is not our real image file.
    For this translated image we can’t regenerate thumbnails because there is not a real file too.
    AND we can’t see an image on the single product page for product in Second Language.

    Could you consider our problem and add the plugin following behavior:

    1.When your plugin updates ‘_wp_attached_file’ for the image in main language, please check following:
    are there in the wp_icl_translations table ids of posts in different languages? and update ‘_wp_attached_file’ for all of them.
    It will fix regeneration thumbnails process and display

    2.Set virtual forder taxonomy for all of these posts in the wp3_term_relationships table.
    It will fix displaying images in the correct folders for different languages.

    Thank in advance.

    Plugin Author dbarrere



    The plugin has been tested with the version 3.6 of Wpml.
    This could be why we don’t have the same behavior.
    I have asked the Wpml team if they can provide me a free version to check this issue.
    Once I have it I’ll make a try.

    Best regards

    Plugin Author dbarrere


    I have kindly received a version from WPML team to make my tests and I have then be able to reproduce the issue.
    They have added the media translation feature between the version 3.6 and the latest one. That’s why I did not see the issue.
    The solution you developer has provided is right.
    I’ll try to provide a fix before the end of the week.

    Best regards.

    That sounds great!

    Sorry to stress you, but do you have a new time frame on the fix?
    (we are ready to go live with our site as soon as this is solved)


    Plugin Author dbarrere



    I have started working on this issue.
    Unfortunately it’s more difficult than I thought.

    Basically, the solution I have would work for general cases, but it doesn’t work as soon as the images have been edited through the WordPress Media Editor.
    I’m looking for a good solution.
    I’ll keep you informed about the progress.

    Best regards

    Would it be possible for you to send us the plugin with the fix for general cases?
    We wont use the Media Editor, and this way we can launch the shop.

    Plugin Author dbarrere


    I have made big improvements. There is no more media editor issues.
    I want to make some more tests to be sure it won’t break anything.
    I’ll push it to a SVN branch where you’ll be able to test it.
    It should be done by the end of the day.

    Plugin Author dbarrere


    You can download the development version here
    It should work with the media editor too.
    Please let me know how it works on your end.

    Thank you!
    Initial testing on local looks promising. Will do more extensive testing tomorrow/Monday and getting back here with results!

    In the work of testing we encountered another issue/bug.

    When we move an image from a virtual folder to another, there is a query which runs for what it seems forever. If we move multiple images at once this causes our server to respond that there are to many database connections.

    The query which runs look like this:
    SELECT meta_id,meta_value FROM wp3_postmeta WHERE meta_value REGEXP ‘s:[0-9]+:”.(https\://dev\.ourdomain\.com/wp\-content/uploads/brands/filename\-150×150\.jpg|/brands/filename\-150×150\.jpg).”;’

    We don’t think this ongoing query is even necessary since our image virtual path is already changed and the image is displayed in the correct virtual folder in both languages directly after drag-and-drop.

    We’re not sure what purpose this query has, but is it possible for you/us to disable it?

    It seems we finally got most of it working, I’ll get back here with a more detailed description shortly!

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘WPML compatibility’ is closed to new replies.