This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: 

This topic contains 18 replies, has 2 voices.

Last updated by Bruno Kos 2 months, 3 weeks ago.

Assigned support staff: Bruno Kos.

Author Posts
June 21, 2019 at 11:59 am

arjanO

Please check: Translations not in sync after changes, images break!? (part 2)
It took some time to get it sorted out, but we finally lifted the last 40MB limit. That didn't solve this issue.

I am trying to: translate the page

Link to a page where the issue can be seen: hidden link

I expected to see: the original images

Instead, I got: a few broken images and I can't correct them

June 21, 2019 at 12:00 pm #4066901

arjanO

Part 2: https://wpml.org/forums/topic/translations-not-in-sync-after-changes-images-break-part-2/
Part 1: https://wpml.org/forums/topic/translations-not-in-sync-after-changes-images-break/

June 24, 2019 at 10:24 am #4076425

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

Thank you for contacting WPML support!

I've checked translation editor - it seems like that all the URLs are properly translated, but for some reason it is pulling them from the wrong URLs on translated pages. These URLs would be something like:
hidden link
hidden link
(you can check all these URLs by inspecting these elements in the chrome console, or perhaps by checking 404 urls since all of these are broken in fact).

I'm not entirely sure where these URLs are coming from (they are not within the string translation table) or where have they been used for the first time, getting them stored here. Perhaps the correct translation is within database directly somewhere, but to the wrong one is showing in the string translation table for some reason.

One of the ideas that may not be the nicest solution of all, but will work, is to upload these files with the same file names directly into the wp-content/uploads/2018/10/ folder. This can be done using FTP access for example. By doing this, we will get these images in place, since this URLs are registered in translated pages.

Other than that, we would need to most likely escalated this to our 2nd tier so that they can investigate this further, check database, etc., but I think that my suggested workaround would be the fastest and easiest for us to handle at this point.

We are unable to delete these strings individually from string translation table, because they belong to a string translation package (data for translations stored by WPML).

Let me know what you think and which approach would you like us to go with!

Regards,
Bruno Kos

June 29, 2019 at 8:43 pm #4112859

arjanO

I'm glad you have a good view on the problem. Yes the workaround could work but... it keeps happening. So if I completely remove the images within WordPress, upload them again and set them again, the wrong URL's pop-up again. The client is updating the website without knowledge of FTP. So this is a problem that needs a proper fix. Please escalate.

July 1, 2019 at 8:31 am #4116629

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

Yes the workaround could work but... it keeps happening.

Can you tell me if only the homepage is affected, or are there other pages where wrong image URLs in translation show up?

Just to make sure - this is how I reproduce this?
- Open homepage in the original language
- add "Afbeelding" element
- open translation and translate image URL (or simply copy it)
- the URL will appear incorrect - not the ones from translation editor

If not, can you give me more detailed steps or any other information that me and 2nd tier will benefit from?

Also, can you install Duplicator plugin and create package so that I can try this on my localhost and possibly escalate further to 2nd tier?

https://wpml.org/faq/provide-supporters-copy-site/

Once you create packages, you don't need to upload them to some external service - I will download them directly from the website.

Regards,
Bruno Kos

July 7, 2019 at 6:33 pm #4158089

arjanO

Duplicator isn't able to copy the site. We tried that on the previous thread. We have to work on live I'm affraid.

The route I have taken is to backup the English textst. Remove the English page. Create the translation again in WPML. Put back the English texts and meanwhile irritate myself with the fact that I can already see the images are not working. We haven't seen this behavior on any other pages.

July 8, 2019 at 7:27 am #4159543

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

Duplicator isn't able to copy the site. We tried that on the previous thread.

What about BackupBuddy? I see that you have it installed and that you even created a package already 9 months ago, so I assume that it is working? Can you try creating package once again so that I can download the latest version and restore it on my localhost?

Regards,
Bruno Kos

July 12, 2019 at 5:20 pm #4200671

arjanO

Hi Bruno,

BackupBuddy can't handle it. I have a complete backup package from the host ready for you. How can I send you FTP details?

July 15, 2019 at 9:53 am #4209379

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

Can you tell me you tried moving the site to our Cloudways server before? If not, we can try this method. Can you tell me how big is the site (approximate value)?

Let me know and I will set up everything for you.

Regards,
Bruno Kos

July 22, 2019 at 8:01 am #4254587

arjanO

The site is about 12GB in size. I am currently at a remote site with limited 4G connectivity. It would take me a few days to move it over FTP.

July 22, 2019 at 9:24 am #4255421

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

Would you like me to try to create a duplicator package myself? I will try to exclude as more files is possible and even try client-side kickoff option which seems to be solving many package creation issues.

Regards,
Bruno Kos

July 22, 2019 at 9:28 am #4255469

arjanO

Yes you may

July 22, 2019 at 12:46 pm #4257415

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

I was able to create a duplicator package. There was one other site within the root folder and I also excluded several backups, along with all the media files. The package is now about 100 MB. I have asked our 2nd tier for an opinion, I will get back to you once I will have questions or news.

Regards,
Bruno Kos

July 22, 2019 at 2:01 pm #4258257

arjanO

Thanks for the update. For me it's hard to guess what you do and do not want in your package.

Looking forward to a resolution.

July 25, 2019 at 8:03 am #4280447

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+02:00)

Hi,

I apologize for not responding earlier. We have been investigating this issue and from what I see, the URLs get changed upon upload into the site and not during the translation. Specifically during the upload into the page builder. They all get the following URL format:

hidden link
hidden link
hidden link

etc.

I've uploaded an image named placeholder.jpg, however it was not there at all. It ended up as home.10.jpg. Can you tell me if you noticed this behavior before - original URLs being overwritten when adding image element into Divi builder on the home page?

Therefore, I deactivated all the plugins, leaving only WPML active. I see that the site has plugins such as Divi Hacks or Albricht, so I am assuming that some of these are changing this behavior. Maybe it is not a bug - maybe this is expected for some of these plugins, that the URLs for the homepage change into the above-described pattern?

Can you tell me if you can do the same on your site - try deactivating all the plugins and try adding new images into the page builder, checking give the original URLs will change? Or perhaps checking that Divi Hack plug-in if it has an option which does this?

Let me know!

Regards,
Bruno Kos