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.

Author Posts
May 3, 2019 at 5:06 pm

Kim Gamez

We have had an issue for over a year now where randomly our /shop page in English (default language) will load without any shop products appearing. The translated page /tienda works as expected.

I have not been able to replicate any sort of behavior to cause this to happen but it for sure happens without anyone being logged in or editing from the backend. When this happens I am able to get the shop back by visiting the /shop page and clicking "edit page" from the admin bar (this option is not available when the system recognizes the shop page as the product archive page ). flushing the rewrites basically is all that it takes to get it back. So deactivating plugins to check would fix the issue but really did not provide any help to what was causing it.

I have tried to diagnose this issue without much success as it is not something I can replicate by taking any set steps. But the staging site is currently displaying the issue. The last time it did happen I was able to debug some things while on a chat with Woocommerce support and was able to determine that while the shop is down nothing unexpected is happening with Woocommerce itself.

I was able to pull a dump of the Database and was able to check what exactly is changing when the shop is down compared to when the shop is up. The reason the shop is not showing is because somehow the rewrite rules are getting flushed (maybe a cronjob?) and the translated shop base is getting stored instead of the default base. Below is what I am seeing in the rewrite rules.

SHOP WORKS
shop/?$ index.php?post_type=product
shop/feed/(feed|rdf|rss|rss2|atom)/?$ index.php?post_type=product&feed=$matches[1]
shop/(feed|rdf|rss|rss2|atom)/?$ index.php?post_type=product&feed=$matches[1]
shop/page/([0-9]{1,})/?$ index.php?post_type=product&paged=$matches[1]

MYSTERY THING HAPPENS AND SHOP DOES NOT WORK IN ENGLISH
tienda/?$ index.php?post_type=product
tienda/feed/(feed|rdf|rss|rss2|atom)/?$ index.php?post_type=product&feed=$matches[1]
tienda/(feed|rdf|rss|rss2|atom)/?$ index.php?post_type=product&feed=$matches[1]
tienda/page/([0-9]{1,})/?$ index.php?post_type=product&paged=$matches[1]

Really need your help fixing this as I am losing potential sales as i am not ever aware when the shop goes down. My team and I have become quite parinoid with checking the shop to make sure it is up but would really like to get to the bottom of the issue as it has been happening for some time.

I have been through every post in the forum as well as on other github/stackoverflow issues I could find related to this type of thing and could not come up with a reason or solution on my own.

May 4, 2019 at 8:43 am #3739559

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

Thank you for contacting WPML support!

I have tried to diagnose this issue without much success as it is not something I can replicate by taking any set steps

I'm afraid that this may be a problem for our debugging team as well. There are some things to try though:

We have had an issue for over a year now where randomly our /shop page in English (default language) will load without any shop products appearing.

When this happens and if you deactivate WPML (English being default language, the broken shop should be visible) and all its plugins, it is also the case - is the shop page still broken?

But when you say this:

The reason the shop is not showing is because somehow the rewrite rules are getting flushed (maybe a cronjob?)

And this:

flushing the rewrites basically is all that it takes to get it back

I am wondering whether something like this would work in your case?
hidden link

Or perhaps consult our Contractors - https://wpml.org/contractors/ - and ask for a quote to create a cron job that would always flush permalink that they look like:

 
shop/?$ index.php?post_type=product
shop/feed/(feed|rdf|rss|rss2|atom)/?$ index.php?post_type=product&feed=$matches[1]
shop/(feed|rdf|rss|rss2|atom)/?$ index.php?post_type=product&feed=$matches[1]
shop/page/([0-9]{1,})/?$ index.php?post_type=product&paged=$matches[1]

Perhaps something like this would work - let me know if otherwise.

Regards,
Bruno Kos

May 6, 2019 at 12:54 pm #3748607

Kim Gamez

When this happens and if you deactivate WPML (English being default language, the broken shop should be visible) and all its plugins, it is also the case - is the shop page still broken?

Yes the shop page is still broken and the rewrite rules are still set to the translated page slug.

I would really like someone to look into the issue rather than try to bandaid it. I could write a script to flush rewrites every hour but my worry is that this will just cause more harm than good as it is already a cron job that is flushing the rerwrites that causes the issue. I could end up just killing the shop in the default language every hour. Can you ask one of your devs if it is possible to just hard code the rewrites for the shop and the Spanish version on "init" to stop this from happening rather then run a cron job to flush them.

If I understood your plugin better I could likely diagnose the issue further but I do not have the time and have paid close to $300 for an expert to help with these issues. Sorry if that comes off as pissy but i have another support thread that has been open for almost 8 months.

The real issue is that at some point a rewrite is triggered and the system thinks that the product_base is the translated base and not the default base. I am not sure if it is in the core WPML, String Translation, or WooCommerce Multilingual. I also know that this has been an issue in the past and updates where made to fix the issue. I know that my issue is likely not exactly the same but should be similar.

I really would like to know that our shop will be up and active as long as the server is up. As of right now we constantly have to load the /shop page to see if it is up.

May 6, 2019 at 2:35 pm #3749993

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

Can you ask one of your devs if it is possible to just hard code the rewrites for the shop and the Spanish version on "init" to stop this from happening rather then run a cron job to flush them.

I am sorry but that does not go like this - we have a very strict procedures on how something gets implemented into WPML or its addons (just as it is the case for any other software).

You could suggest this as a feature though:
https://wpml.org/suggest-a-new-feature-for-wpml/

The main problem here is that we don't know the trigger for this, so if I send this to our 2nd tier for further inspection, they will ask how can we reproduce and they will not be able to do much about this.

How about this scenario - when the issue happens, create a Duplicator package and tell me so that I can download a broken version? Perhaps checking that version by our 2nd tier would shed some light on this.

Regards,
Bruno Kos

May 6, 2019 at 3:09 pm #3750283

Kim Gamez

Bruno,

Sorry if what I wrote was confusing. I was not suggesting that your team implement those hard coded rewrites into the plugin but rather ask if they think it would be OK if I added it to my site. From the research I have done it seems that have rewrites for both /shop and /tienda being set to a product archive will work but wanted your guys take on that be fore implementing.

I completely understand not being able to debug much without being able to reproduce. The staging site url I have sent is in the broken state. I was just thinking that a dev that works with your system on a daily basis might be able to help pin point the actual issue.

Please note that disabling any plugin that flushes rewrites will fix the issue as well as visiting the "edit page" link for the shop will also flush the rewrites for some reason (not sure why this happens might be WooCommerce). So they will want to use Adminr or something similar to pull the database before updating or causing the rewrites to flush.

If you make the next message private I will give the Basic Auth username and password as well as the admin login.

May 7, 2019 at 11:50 am #3757465

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

I've asked our developers about this and here is the response:

""""""""""""""""""""""""""""
Could it be related to this?

https://wpml.org/errata/htaccess-is-rewritten-with-language-folder/

You can confirm by checking .htaccess when the error pops up.

This bug keeps popping up with 3rd party plugins that flush_rewrite_rules() in the frontend while you are in a secondary language. Its bad practice to flush_rewrite_rules() on init and they should be flushed on plugin activation or theme switch instead.

Read about usage here: https://codex.wordpress.org/Function_Reference/flush_rewrite_rules

The problem is finding the 3rd party plugin.
""""""""""""""""""""""""""""

Regards,
Bruno Kos

May 7, 2019 at 5:53 pm #3761043

Kim Gamez

The server is not running Apache but Ngnix so I do not have an .htaccess file.

As for finding the 3rd party plugin I have done a GREP search for flush_rewrite_rules and have every instance of flush_rewrite_rules. There were a total of 5 plugins that even have the function in their files and 4 of them are either your plugins or plugins you are compatible with the last one is a woo add-on that only calls the function on activation.

I will list the plugins below as well as where the flush_rewrite_rules can be found along with how the function is called. I put a (*) next to the ones I believe could possibly be triggering the issue.

Yoast SEO - https://wpml.org/plugin/yoast-seo/

  • wordpress-seo/wp-seo-main.php line 190 - On activation schedule_flush called from class-rewrite.php
  • wordpress-seo/wp-seo-main.php line 226 - Fires on deactivation
  • wordpress-seo/admin/class-admin.php line 129 - Only fires when using the strip category feature
  • wordpress-seo/inc/class-upgrade.php line 167 - Runs on plugin upgrade and fires on 'shutdown' action so runs just before PHP shuts down execution
  • wordpress-seo/inc/class-rewrite.php line 48 - fires on 'init' runs on 'shutdown' action so runs just before PHP shuts down execution

---

Gravity Forms - https://wpml.org/plugin/gravity-forms/

  • gravityfroms/gravityforms.php line 549 - Runs on deactivation
  • gravityfroms/includes/webapi/webapi.php line 178 - only fires if using v! of the api

---

WooCommerce - https://wpml.org/plugin/woocommerce-2/
Uses do_action( 'woocommerce_flush_rewrite_rules' ) to trigger actions for flushing rewrites. It uses the option 'woocommerce_queue_flush_rewrite_rules' inside the function maybe_flush_rewrite_rules() to check if it should fire a flush after post type registration via 'init'

  • woocommerce/includes/class-wc-install.php ( do_action( 'woocommerce_flush_rewrite_rules' ) ) line 249 - if version upgrade queues the rewrites to be flushed
  • woocommerce/includes/wc-core-functions.php ( do_action( 'woocommerce_flush_rewrite_rules' ) ) line 981 - fires if the shop page or any child page of the shop page is being edited
  • (*)woocommerce/includes/admin/class-wc-admin-settings.php line 83 - On admin settings saved it updates the option 'woocommerce_queue_flush_rewrite_rules' to 'yes'
  • (*)woocommerce/includes/wc-attribute-functions.php line 612 - schedules a cron job to fire 'woocommerce_flush_rewrite_rules'
  • (*)woocommerce/includes/wc-attribute-functions.php line 702 - schedules a cron job to fire 'woocommerce_flush_rewrite_rules'
  • woocommerce/includes/api/v1/class-wc-rest-product-attributes-controller.php line 584 - schedules a cron job to fire 'woocommerce_flush_rewrite_rules' but has been depricated since 3.2.0 and is not actually called from anywhere
  • woocommerce/includes/api/legacy/v3/class-wc-api-products.php lines 2578,2665,2728 - Fires when a product attribute is created, edited, or deleted via the api

---

WooCommerce Multilingual

  • woocommerce-multilingual/inc/class-wcml-upgrade.php line 322 - fires on upgrade to version 3.5.4
  • woocommerce-multilingual/inc/class-wcml-endpoints-legacy.php line 135 - this should not be firing as WPML_Endpoints_Support_Factory exsits
  • woocommerce-multilingual/inc/class-wcml-endpoints-legacy.php line 74 - this is just used on install to flash the rewrites

---

Woocommerce Product Feeds

  • woocommerce-product-feeds/woocommerce-gpf.php line 199 - Only fires on plugin activation

I am not sure what other info I can give you guys before you will dig into figuring out the issue. I know that this issue happens randomly without admin access needed so I have marked the files I think my be causing the trigger with the (*) but like I have said before I do not understand how your plugins handle the switch and why the translated slug is replacing the default product_base when these rewrites are triggered.

If you guys could please stop pointing to other 3rd party plugins and help me figure this bug out I would really appreciate it.

May 8, 2019 at 8:32 am #3764571

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

Can you provide me with access to your staging site and create a database dump possibly (or a full Duplicator package, so that our 2nd tier can investigate further)? I see credentials in the first message, however, these seem to be behind the password?

I have marked your next reply private so you can safely add this information.

Regards,
Bruno Kos

May 8, 2019 at 12:33 pm #3766685

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

Another thing - when the issue happens, can you create a Duplicator package and tell me so that I can download a broken version?

Regards,
Bruno Kos

May 8, 2019 at 12:57 pm
May 8, 2019 at 1:35 pm
May 8, 2019 at 6:48 pm #3770083

Kim Gamez

Bruno,
The migration failed. It looked to have all of the files and db tables ready and migrating last i checked but just got the email that it failed. Now when I attempted again it gets hung up on Validating Details...

Last time I attempted this it also stopped in the very beginning and blogvault alerted me that the site was behind basic auth and it needed the username and password. I had to fill out all of the information over again but for blogvault. This time that did not happen.

May 9, 2019 at 7:00 am #3773475

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

Last time I attempted this it also stopped in the very beginning and blogvault alerted me that the site was behind basic auth and it needed the username and password.

Does it have to perhaps with the site auth used to even access the site - CW plugin not being able to penetrate through? It doesn't seem like that anything has moved - hidden link, so as if the migration has not started at all.

but just got the email that it failed

Is there any useful information in this email related to why it failed?

Let me know what do you think we should try next - I could create a new CW site, perhaps it would help. However, this database you send me, is this for the broken version?

Regards,
Bruno Kos

May 9, 2019 at 12:52 pm #3776237

Kim Gamez

I have disabled the Basic Auth for now and I am going to retry the migration. The DB I sent over is an export from the broken site.

May 9, 2019 at 12:54 pm #3776249

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

The DB I sent over is an export from the broken site.

Can you perhaps zip the WordPress files in the same way then? Exclude uploads and leave only WP isntallation, themes and plugins. Let me know if that's more convenient for you.

Regards,
Bruno Kos