Ben

Hello @doublezed2,

I apologize for the late reply and thank you for your help. I’m afraid that this is not possible due to the following error being displayed, despite being logged in as an administrator:

Unfortunately, you are not authorised to access this page.

Kind Regards
Ben

Hello Maybellyne,

thank you very much for you feedback. We’ve proceeded with the upgrade and everything is working smoothly.

Thank you & Kind Regards
Ben

Hi @hjogiupdraftplus

Absolutely, you deserve more than the 5 available stars.

The upgrade to MySQL-Client Version 8.0 was successful, and no issues were found in our setup.

Kind Regards
Ben

• This reply was modified 5 months, 2 weeks ago by Ben.

Hi @hjogiupdraftplus,

thank you very much for your quick and helpful reply. I’ll confidently proceed with the update.

Thanks & Kind Regards
Ben

Hello again,

thank you very much for your quick and helpful reply!

You’re absolutely right, I’ve mistakenly copied the current minimum required WordPress 3.0.1 by the plugin instead of the plugin version 1.4.7

I’ll confidently proceed with the update.

Thanks & Kind Regards
Ben

@missveronicatv

Great, thank you for reproducing and posting the issue report on GitHub.

I’ve subscribed to the new issue in case I can be of any help.

Dear Ashley,

I encountered this exact issue where the htaccess file also got corrupted for one of my client’s websites after updating the plugin to version 5.1.8.

Fortunately, I was able to resolve the issue by using a backup copy of the htaccess file that was created prior to the update (stored in the directory /wp-content/aiowps_backups).

If you would like to investigate further, I can provide you with the corrupted htaccess file for analysis. Please let me know if you have an email address that I can use to send it privately.

Thank you for your attention to this matter.

Best regards,
Ben

Thank you, Fernando, for your competent and friendly support. I appreciate you taking the time and effort to help investigate the issue.

To summarize for any potential readers who may be experiencing the same issue:

The problem was resolved by adding the translation files wpsl-de_DE.po and wpsl-de_DE.mo to the directory /wp-content/languages/wp-store-locator, as described in the article on translations.

In case the changes don’t immediately appear, like in my case, it’s helpful to temporarily disable the cache by activating debugging mode in the tools section of the plugin settings.

Hi Fernando,

I just wanted to let you know that I’ve submitted a ticket through the form provided in the link.

Thank you for your help.

Hi Fernando, nice to hear from you! ??

yes, I had tried that yesterday and again just now because I had read it in a different support post related to translation issues.

I’m afraid the issue persists, and the data provided by the “hours” variable still appears in English instead of German.

Interestingly but maybe unrelated, the function wpsl_get_weekdays() used in the custom listing template returns the weekdays in German.

@dkotter Great, I will confidently proceed with the update and let you know in case any issues arise.

Thanks a lot for your quick help and feedback!

Yes, it appears that the plugin currently doesn’t meet the legal requirements in Germany. I’ve opened an issue in on GitHub.

Thanks for the clarification, I will be making use of a workaround until this update gets released.

My goal is to add the capability to use the export plugin from a specific user role, which will then allow this role to export a custom post type including all their corresponding ACF fields.

I found a workaround to enable access to the plugin with a specific role but I was forced to customize the core functionality of the WP All Export plugin, which isn’t the correct way this should be handled, as it will no longer allow me to update the plugin without overriding my code.

• This reply was modified 7 years, 2 months ago by Ben.

I’ve followed the steps in the link provided above & updated to version 3.0.1.

The issue on the cart page has been resolved.

Thanks for your help Mike!

Yes, unfortunately the problem occurred yesterday after Woocommerce v3.0 update.

Kindly see the screenshots below.
https://unsee.cc/putogire/

With the “Sold individually” checked, the quantity field on the product page should not be visible, and on the cart the quantity input should be disabled (same as the one sent in your previous screenshot).

EDIT:

Adding the code below to my functions file resolved the problem on the cart page.
However now “Sold Individually” is set for all products by default, and on the product page the quantity field is still visible until the variation is changed. The field completely disappears when changing to a different product variant.

add_filter( 'woocommerce_is_sold_individually', '__return_true' );

EDIT 2:

The value for the ‘_sold_individually’ row of the given product within the database seems to be updating fine.

https://unsee.cc/zipenoba/

EDIT 3:

I’ve rolled back the “variation-add-to-cart.php” template file from v3.0 back to v2.5, and the quantity field is no longer visible on the single product page.

https://www.diffchecker.com/e1F1O6hn

A solution for the cart has not been found yet without applying the filter mentioned in edit 1.

Let me know if you require any additional information.