If your trial doesn't work, send me a private post to give you another link to enter the staging site
The thing is I'm using WP Tiger (in my host's cpanel) to create staging and it could be possible thta you had to enter through WP Tiger to enter staging backoffice.
thanks
Carlos
I can observe and confirm the issue on the staging server, and that has helped me track down where in the plugin code base the redirection occurs, but I can't follow exactly what happens (I don't know what all the values of the variables are) without stepping through the code execution as the code runs.
I can only do that locally, not on the staging server. You said something about a plugin that would permit the form to work on an unregistered development site?
Do you have more details about how I can do that?
While checking to see if we had any internal tickets about anything related I see that we had one previous report about this same issue, from you.
1/I don't really understand what you mean by "I don't know what are all the values of the variables are without going through code execution during code execution?"
If you succeed to reproduce the issue on staging, why can't you see the variables during code execution?
If, to fix this, you need to test orders on the production site itself, then I allow you to do so: you can run test commands (in debug mode) to see these variables.
The important thing is above all to NOT use the troubleshoot in WPML page / cleanup section on the production site at the risk of breaking something. But, on the other hand, you can do it / test it on the staging one to see if, by chance, it could resolve the 404 error. Please tell me what it is.
2/ the membership plugin that I use PrivateContent (hidden link) is coupled with Woocommerce. The addon I told you about allows PrivateContent to work on staging (without a license or checked domain) and it is already installed on the staging (plugin named: dike-targeted-bypass-for-domain). It only allows you not to check the domain. So unfortunately, this won't change anything in your "search for variables" problem.
3/ old internal tickets: The problem encountered at the time was resolved because the thank you page appeared in FR during a FR order, following an update of WPML and PrivateContent. And it worked for 2 years.
Last point which seems important to me: when this issue occurred after the latest WPML update (12 days ago), I checked the WPML strings and I realized that half a dozen variables (strings) were inverted between FR and EN. So I swapped them (using wpml strings feature) thinking that might help things. This is why the 404 error appeared. Previously, there was only the problem of changing languages during FR order process!
This is why I am telling you about the possibility of resolving this missing URL problem (404) using the troubleshoot in WPML page / cleanup section. I have never used it myself but, in the past, one of your support colleagues (for another subject) carried out a troubleshoot on this section which resolved the problem. What do you think ? Could this be of any use in our situation?
Regarding the strings you updated, I can't locate any strings that look relevant to the problem.
Without being able to step through the code execution I can't identify exactly why this is going wrong, and without knowing that I can't comment on whether trouble-shooting steps or updating string translations might fix it.
And I can only step through the code execution on a local version of the site.
I copied and installed the plugin you referred to, but it doesn't help, it appears to only work on sub-domains of wptiger.fr.
At this stage I can't do any more without being able to test the plugin, specifically the form submission workflow, on my localhost.
Could you please contact the plugin author to see how that would be possible?
Nigel,
I asked PrivateContent author but I'm not sure he will allow us to bypass his plugin outside of wt-tiger sub-domain.
So, can you consider testing orders on production site itself and see variables involved? I don't think you're damaging it by doing that? Am I wrong?
Carlos
I simply can't test on an external site, I need to have the code running on my local site to be able to inspect the code as it executes.
Let's see what he says. It seems he collaborated in the past.
If he is reluctant to facilitate my working on the site I'll have to pass this to our compatibility team and they can make a more formal request from WPML.
Here's the answer of PrivateContent plugin's author :
"here some infos to troubleshoot:
1. if you are using my last plugin version (which is the case), the ajax calls are now performed on the WordPress Ajax endpoint.
2. During the registration phase, the "wc_get_checkout_url()" function is called (is a WooCommerce function)
3. On successful checkout, I get the page ID you set in the Premium Plans settings ("Successful order redirect" field) and pass it through the WPML functions to get the translated page ID.
NB: if you didn't set any custom landing page, the redirect is performed by WooCommerce
To clarify the PrivateContent plugin behavior (on point 3):
3. On successful checkout, PrivateContent get the page ID I set in the Premium Plans settings ("Successful order redirect" field) => see enclosed screenshot .... and pass it through the WPML functions to get the translated page ID.
Please tell me if these information help you to understand the situation
Thanks
Carlos
Hi Nigel
the author of PrivateContent plugin sent me a script(.zip) to unlock ane enable you to test from your local clone.
here's his message:
Nevermind, is faster to give you a timed unlock!
Just give WPML the attached package to be installed in the localhost website
Can you send me a private link/form where I can send you this .zip?
Thanks for your appreciated help
Carlos
The topic ‘[Closed] Since last WPML update, WC order (in second language) malfunctions (error 404’ is closed to new replies.
