Trailing Slash Not Being Forced When Accessing Homepage of Chosen Language

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.

This topic contains 8 replies, has 2 voices.

Last updated by Lynn Okulanis 4 years, 7 months ago.

Assisted by: Bruno.

Author	Posts
March 30, 2020 at 11:33 pm #5799689
Lynn Okulanis	CDN: Cloudflare HOST: KINSTA PHP: Version 7.2 WordPress: Version 5.3.2 WPML Multilingual CMS: Version 4.3.10 Yoast Premium: Version 13.3 ISSUE: When accessing the homepage of the following languages: hidden link hidden link The trailing slash is NOT being forced. Yoast is correctly rendering the URLs with the trailing slash in the HREFLANG. This is resulting in 2 different URLs that are being crawled for these homepages which, of course, is causing issues with duplicate content in SEO reviews. I've done a LOT of Googling and the only thing I've seen is "the trailing slash is automatically added" by WPML. Unfortunately, it's not on these websites. Any assistance would be greatly appreciated.
March 31, 2020 at 10:34 pm #5808209
Bruno	Thank you for contacting us. I tested this in my testing environment, but I was unable to replicate this problem. Please as a test, could you disable all non-WPML plugins, switch to the default theme and see if the problem persists? If the problem is fixed, please, enable the plugins one by one to see if there is any compatibility problem between these plugins. Thank you.
April 1, 2020 at 2:45 pm #5814557
Lynn Okulanis	OK .. I went ahead and performed those requirement in my STAGING environment. Used the Twenty-Nineteen WP Theme. Deactivated ALL plugins except the WPML plugins that we have installed (see below). And we still have the same issue. No forced trailing slash ("/") in the URL. URL: hidden link site_url(): hidden link home_url(): hidden link Database Name: ******************** Table Prefix: wp_ WordPress Version: 5.3.2 Web Server: ..................... nginx/1.17.5 PHP: ............................ 7.2.17-1+ubuntu16.04.1+deb.sury.org+3 WP Memory Limit: ................ 40M PHP Time Limit: ................. 300 Blocked External HTTP Requests: None fsockopen: ...................... Enabled OpenSSL: ........................ OpenSSL 1.1.1b 26 Feb 2019 cURL: ........................... Enabled Enable SSL verification setting: No Opcache Enabled: ................ Enabled MySQL: ................... 5.5.5-10.2.25-MariaDB-10.2.25+maria~xenial ext/mysqli: .............. yes WP Locale: ............... en_US DB Charset: .............. utf8 Debug Mode: ... No Debug Log: .... No Debug Display: Yes Script Debug: No PHP Error Log: WP Max Upload Size: 128 MB PHP Post Max Size: 128 MB Compatibility Mode: .... Yes Delay Between Requests: 0 WP_HOME: ....... Not defined WP_SITEURL: .... Not defined WP_CONTENT_URL: hidden link WP_CONTENT_DIR: ****************** WP_PLUGIN_DIR: ****************** WP_PLUGIN_URL: hidden link Media Files: .......... 1,761 Number of Image Sizes: 7 Active Theme Name: Twenty Nineteen Active Theme Folder: ********************/wp-content/themes/twentynineteen Active Plugins - WPML Multilingual CMS (v4.3.10) by OnTheGoSystems - WPML Media (v2.5.5) by OnTheGoSystems - WPML Sticky Links (v1.5.1) by OnTheGoSystems - WPML String Translation (v3.0.8) by OnTheGoSystems - WPML Translation Management (v2.9.5) by OnTheGoSystems Must-Use Plugins - Kinsta Must-use Plugins (v2.3.1) by Kinsta Team
April 2, 2020 at 2:26 pm #5823733
Lynn Okulanis	Hi Bruno .. have you been able to review the results of the testing you asked me to perform?
April 2, 2020 at 3:34 pm #5824433
Bruno	Hi, Sorry for the delay. Yes, I saw your message above. This may be happening through your server (Nginx). Perhaps your server has some configuration to redirect URLs without trailing slash. Using the Apache server, even without WPML enabled, WordPress by default redirects URLs without the "/" to add it to the URL. That is, this is not only the behavior of WPML but also of WordPress itself. You may need to configure Nginx or a redirect plugin to redirect to the URL with "/". Thank you.
April 2, 2020 at 6:26 pm #5825969
Lynn Okulanis	Well .. it would appear to me that WordPress' trailing slash functionality on its permalinks is working just fine for this application: This URL: hidden link Renders automatically like this: hidden link Just as this URL: hidden link Renders like this: hidden link And this URL: hidden link Renders like this: hidden link As mentioned in the original issue: this is specific to the homepages for each alternate language: hidden link hidden link So, I don't see how nginx is causing any issues there? If it was an nginx or WordPress issue, would these errors not be persistent in EVERY instance a URL is rendered? Additionally, the other 40+ websites we manage (all hosted on KINSTA) don't seem to have this issue. But, as a show of good faith, I have contacted KINSTA and provided their support team a link to this ticket for review. I am waiting for their response now. If they provide a solution I will supply it here.
April 2, 2020 at 6:57 pm #5826095
Lynn Okulanis	So .. to avoid delaying this any longer, I asked the support folks at KINSTA to place a 301 REDIRECT on the nginx server for the following URLs: hidden link hidden link .. so that they render appropriately and to prevent any SEO crawlers from crawling the URLs without the slash (as they are being rendered by WPML). The downside to this is, if it's ever again required to move this application to a different server within KINSTA (as has been the case in the past), the nginx config file on that new server will need to be edited to reflect this change. So, I would consider this matter resolved via 3rd party workaround.
April 2, 2020 at 7:03 pm #5826097
Bruno	If you want I can try to test your site in our testing environment as well. Just let me know so I can apply for credentials. Another option, instead of using some configuration in Nginx, you can use a plugin to do this redirection. Thank you.
April 2, 2020 at 7:05 pm #5826101
Lynn Okulanis	My issue is now resolved courtesy of a 3rd party workaround - a redirect placed into the config file of the nginx server.