fibronic

Yeah, we use WP-Optimize for caching. But we have TranslatePress + WP-Optimize running on four websites with basically the same settings, so I also don’t understand why it works for the other three websites…

I haven’t had time to check out what the option “Force language in custom links” does that tikotot mentioned. But if we also need this option to be enabled, then we’re not there, yet :).

Issue has been resolved. Here’s the solution if you’re interested: https://www.ads-software.com/support/topic/wp-mail-smtp-cannot-connect-to-smtp-server/#post-16363996

Hi Dake,

We had already contacted our hosting provider several times about this and they said that nothing was wrong on their end.
I hadn’t tried configuring a different mailer because I was pretty sure it wouldn’t make a difference. Turns out I was very wrong: emails are now being sent successfully via Sendinblue.

Thank you for your help ??

Kind regards,
Fibronic

Hi Andrei,

How’s it going so far? I assume it might be hard to replicate this issue. Maybe the better option would be to experience the issue yourself by visiting the website. We can also provide you with administrator credentials for any troubleshooting you might want to perform. Is this a good idea?

Kind regards,
Frank

Hi Andrei,

Thanks for picking this up! I look forward to hear about your findings.

While I have your ear: there’s also another topic we created three weeks ago about TranslatePress translating the original English to Dutch, and then saying that the text is still in it’s original English form (while it’s clearly translated to Dutch). Because TranslatePress says it’s still in the original English language, the text is greyed out in the editor.
Perhaps you can help us with this too? Is it possible to go into the database table and change the translations and the original text?

Kind regards,
Frank

• This reply was modified 2 years, 3 months ago by fibronic.

Hi Denis,

Thank you for taking the time to reply.

The WordPress language is set to English as is the default language set in TranslatePress, so to answer your question: yes.

That’s why it’s weird that we get some text in Dutch but TranslatePress says that it’s the original English language. Can you help with that?

• This reply was modified 2 years, 3 months ago by fibronic.

Hi Dragos,

Thanks for taking the time to read and reply to our support request.

I understand what the functionality of this option is and what it does, that’s why we enabled it. But the issue we are having is that all hyperlinks are broken for the default, English version of the page. I will try to explain the issue we are facing as clear and elaborate as possible:

Our website has hyperlinks to other pages within the same website. In our header menu, for example, we have links to other pages. Some of the hyperlinks in our header menu have the following URLs set:
domainname.nl/gallery
domainname.nl/about-us
domainname.nl/contact

Now, like I said before, we enabled the “Use subdirectory for the default language” feature of TranslatePress, and moved the language “Dutch” to the top of the “language list”, because we want visitors of the website to land on the Dutch version of our website by default. This works fine.

This feature adds either /nl/, for Dutch or /en/, for English, to the URL when we navigate to any page. Sticking to the previous header menu example, when we use the header menu to navigate to another page when on the Dutch version of the website. This is what the URLs look like:
old: https://domainname.nl/gallery new: https://domainname.nl/nl/gallery
old: https://domainname.nl/about-us new: https://domainname.nl/nl/about-us
old: https://domainname.nl/contact new: https://domainname.nl/nl/contact

This is exactly what we want and all the URLs work as expected.

For the English version of our website, however, all the URLs are unfortunately broken. Again, sticking to the same example as before. Here’s what the URLs are for the English version of the website:
old: https://domainname.nl/gallery new: https://domainname.nl/en/1
old: https://domainname.nl/about-us new: https://domainname.nl/en/1
old: https://domainname.nl/contact new: https://domainname.nl/en/1

Obviously, all the hyperlinks for the English version of our website now lead to a non-existing page (404).

I’ll give another practical step-by-step example just in case there’s any chance of misunderstanding:
1. We enter the address https://domainname.nl in our browser
2. We end up at https://domainname.nl/nl (because we set the Dutch version as default in TranslatePress.
3. While on the Dutch version of our website, we click on the “Gallery” list item in our header menu.
4. We are navigated to https://domainname.nl/nl/gallery (great)
5. We go back to the homepage https://domainname.nl/nl
6. We click on the language switcher and choose the language: English.
7. We are navigated to https://domainname.nl/en (so far so good)
8. We click on the “Gallery” list item in our header menu.
9. We are navigated to https://domainname.nl/en/1 (not so good)

Any hyperlink we may click while on the English version of our website, we always end up at https://domainname.nl/en/1.

I hope it’s clear what the issue is now. Again: any help will be greatly appreciated.

Kind regards,
Frank

Hi Harshad,

I have still problems with Wp-optimze, the issue is still going on. Can you please help me again with new solutions.

Kind regards,

Fibronic -Yunus

Hi Harshad,

The issue was resolved by uninstalling both Updraftplus and WP-Optimize and reinstalling them. Not sure if the Updraftplus deinstallation and reinstallation had anything to do with it, though.

Kind regards,

Frank

Hi Harshad,

Thanks for the reply. We have tried that many times. Also disabling and re-enabling the plugin doesn’t help. Files are being cached because you can see how many files are cached and how large the cache is.

Kind regards,

Frank

Hi George,

Thanks for all the effort you’ve put in! I fixed it by playing around with the Astra Footer builder Design section. I picked a background image for both of the sections of the Primary footer section and then deleted them again. That seems to have done the trick.
The weird thing is that when I edited the settings there were no images set. Maybe whenever the background image was removed, it didn’t process the change somewhere on the backend of the site.

Kind regards,

Frank

Hi @bsfherman
Yes, that is corrected. We used the Starter Templates — Elementor, WordPress & Beaver Builder Templates. The plugin is no longer installed so I can’t see exactly which template it was. It was called something like “Sierra National Park” and it had a big picture of an elephant on the home page.

Hi @gappiah
Thanks! That’s a great step forward. If you don’t mind me asking: how did you get to this conclusion? Did you just inspect the page and searched for the image name?
Do you know what would be the best way to resolve this? Do we need to make a change to a database entry?

Thanks to both of you!

Kind regards,

Frank

Hi Herman,

Our website is trying to load an image that isn’t there anymore. This increases the load time of all of the frontend webpages significantly. This is the Google Inspect reponse header:

General
Request URL: https://roodbolevenementen.nl/wp-content/uploads/2018/11/bg-10-free-img.jpg
Request Method: GET
Status Code: 404
Remote Address: 20.105.216.1:443
Referrer Policy: strict-origin-when-cross-origin
Response Headers
cache-control: must-revalidate, no-cache, max-age=0
content-encoding: gzip
content-type: text/html; charset=UTF-8
date: Tue, 15 Mar 2022 10:45:53 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://roodbolevenementen.nl/wp-json/&gt;; rel=”https://api.w.org/&#8221;
server: nginx/1.14.2
x-powered-by: PHP/8.0.11
Request Headers
:authority: roodbolevenementen.nl
:method: GET
:path: /wp-content/uploads/2018/11/bg-10-free-img.jpg
:scheme: https
accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl-NL;q=0.8,nl;q=0.7
cookie: wordpress_test_cookie=WP%20Cookie%20check; ARRAffinity=7bb81a2218562f014bc0f51eb0d63115484ded253a94ea773a560d355a3735c0; ARRAffinitySameSite=7bb81a2218562f014bc0f51eb0d63115484ded253a94ea773a560d355a3735c0; wp_lang=en_US
referer: https://roodbolevenementen.nl/
sec-ch-ua: ” Not A;Brand”;v=”99″, “Chromium”;v=”99″, “Google Chrome”;v=”99″
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: “Windows”
sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36

Is this useful information?

Kind regards,
Frank

• This reply was modified 2 years, 8 months ago by fibronic.
• This reply was modified 2 years, 8 months ago by fibronic.

Hi Andrei,

Thank you for the reply.
I would like to try out the first option you mentioned. However, I can’t find where to deactivate the floating language switcher, and I also don’t know how to remove the language switcher from the menu, or which menu that should be. Can you please guide me?

Thanks!

Kind regards,

Frank

Hi George,

Thanks for the reply. I can give u the URL, but the problem is that it’s not displaying the root issue. Because of TranslatePress it throws a HTTP 302 response, instead of the 404 response. The website also has minify enabled, which also alters the HTTP response. In order for you to see the real problem, I would have to disable both TranslatePress and WP Optimize’s minify, and because it’s a production website, I’m not so keen on that.

What I would rather do is disable both plugins and then copy all of the Google Chrome Inspect information. Is that a valid alternative, and if so, what would you like me to capture?

Also, it doesn’t only occur on a single page, it occurs on all the frontend pages and not on the admin pages.

Thanks, again.
Frank