nikdow

Thanks for the helpful information, however we are using a PY script to update, not PHP.

You have the correct version in the /trunk/readme.txt, and the wordpress plugin developer guidelines say:

Put your code files directly in the trunk/ directory of your repository. Whenever you release a new version, tag that release by copying the current trunk revision to a new subdirectory of the tags/ directory.

If you do the above, the file in the tags/ directory will have the correct version number.

Here’s what our PY script finds:
⬆ Updating megamenu: 3.4.1 → 3.5
✅ Updated: /home/lamp/wordpress/plugins/megamenu

So it looks like you are copying the files to tags/ then after that you are updating the readme.txt in trunk, which is the wrong way around.

Anyhow it’s still a great plugin and we can put up with downloading it every 12 hours, thanks for you attention to this request.

Thanks for your response.

Our script already gets the correct stable tag from the WP API but we have to compare that to the installed plugin, which we install from the tag, not from trunk. The installed plugin references an incorrect version number and that is the only way the script can determine the version of the installed plugin on our server.

We can’t install from trunk because some plugins have pre-release tags which we obviously don’t want to automatically install.

99% of plugins do this correctly, I’m afraid that only a couple that we use are not updating the stable tag in the readme that is included with the installed plugin code.

successful run today, plugins are updating again, thanks.

Thanks, I had tried that approach and succeed in unhooking the function and writing my own but hadn’t succeeded in getting it working on the live server. I’ll try that again, and post the code here if I can get it to work.

the function that WC calls is apache_get_modules which isn’t present in PHP-FPM

Found the problem. Some years ago, while we were still using Paypal, it was necessary to suppress the WC order button. The Paypal plugin had code to do this but was not always successful. So we put this in the theme:

add_filter( ‘woocommerce_order_button_html’, ‘replace_order_button_html’, 10, 2 );
function replace_order_button_html( $order_button ) {
return ”;
}

Since then we switched to the eway payment gateway, so this filter would have been redundant since then.

A WC update must have changed the behaviour of this filter, causing our problem. Removing the filter fixed the problem.

Thanks for suggestions. I ran the conflict test by disabling all plugins (even Jetpack) except for:
WooCommerce
woocommerce-gateway-eway

plugins update every 12 hours via a cron job that runs via a user that is not apache.

Paypal was turned on for testing and is disabled again now as it showed the same symptoms, nothing happens. Normally Paypal loads up an iframe. No JS errors.

I tried loading up the previous version of eWay plugin but no change is visible. Screen shot of missing payment fields is at
https://www.cbdweb.net/wp-content/www.cbdweb.net/uploads/2024/03/wceway.png

I’ve now restored to the current version of eWay plugin.

This is hard to debug because there is nothing in any log that gives a clue. eWay have responded but haven’t got any clues.