spontiflex

In order to implement an effective workaround, I added Javascript to my http-responses (by using the well-known plugin “Simple Custom CSS and JS”).

Each time when a webbrowser receives an http-response from my wordpress, then the script checks whether the url corresponds to one of the paywalled wp-pages. If yes then
‘?timestamp=’ + (new Date()).getTime() is added to the url and the browser reloads the page anew.

(Then the content of the testing browser disappears for a very short moment. Furthermore web-address field of the browser-tab shows the new url then, i. e. the old one enhanced by a dummy-param, which is obviously unique at each page-load.)

And indeed: When a paywalled wp-page is loaded, then the webserver treats the url of the (respectively) 2nd http-request as a new one, whereas wordpress doesn’t pay attention to the unknown query parameter. (Seems that mod_rewrite, or equivalent of mod_rewrite at nginx, doesn’t filter it out.)

The http-response is not served by some network level cache anymore then, and concerned wordpress-php-scripts are executed anew then, actually. This is evident, because after some user has finshed their payment process, a _different_ restricted-content-message is given as a response – it’s a different one then, because i changed it at another browser in the middle of the user’s payment process.

I’m sure, you won’t be surprised that this is my issue now: Why doesn’t the post-for-pay plugin switch to the behind-paywall-content, although php-scripts are obviously/evidently executed anew after successful payment process?

Preconditions and postconditions of my tests are still the same: I remove website-data (cookies, etc.) from testing browser before each test. Furthermore I start each test having a clean list of wordpress-users and a clean list of woocommerce-orders at the monitoring browser, where I’m logged in as an admin user. Payment process creates a wordpress-user, corresponding session-cookie at testing-browser and a complete order as ever.

Would be great if you could help us to solve this issue and find the cause of this unexpected behaviour.

• This reply was modified 5 years, 7 months ago by spontiflex.

Well, I contacted the ionos support yesterday, and today i got the answer to my problem: It isn’t possible for me to control or deactivate their webserver-cache, because we subscribed to a shared-hosting product. Support recommends an upgrade to a dedicated-hosting-product, which costs almost 10 times as much. Now I’m waiting for my principal to decide, how we will go further on.