Barn2 Plugin Support

Hi, Johan (@johan_walter).

Thanks for your reply. Yes, manually copying a plugin’s .mo and .po translation files to /wp-content/languages/plugins should allow its translations to work.

You will also need to disable the notices/warnings as mentioned.

Best regards,
Edge

Hi, @psykonevro and @ezequielb.

Update: For info, translations are broken in WordPress core itself right now, and this affects numerous plugins other than our own. This is due to what’s mentioned at?https://make.www.ads-software.com/core/2024/11/19/wordpress-6-7-1-release-schedule/?:

Translations not being applied properly (#62337)

Translations worked prior to WordPress 6.7. Our suggestions in the meantime are to:

• Roll back to WordPress 6.6.2?and wait. The easiest way to do this is to restore the backup/version of your website prior to updating to WordPress 6.7. Otherwise, I suggest that you get in touch with your website’s web hosting provider, who can assist you with this best.
• Manually copy translations.

If you’re familiar with the steps, or have a developer who can perform them for you, our developers have provided the following example:

Let’s take WPO for example and assume the site is using Spanish as language.

• Navigate to?wp-content/plugins/woocommerce-product-options/languages/
• Copy the the 2 files that end with the suffix?es_ES?. They have different extensions –?.mo?and?.po
• Navigate to?wp-content/languages/plugins?– create the folder if it doesn’t exist.
• Paste the files.

Once done, translations will start working again, but you may see notices/warnings. To disable this from being displayed, see: https://developer.woocommerce.com/2024/11/11/developer-advisory-translation-loading-changes-in-wordpress-6-7/

I hope this makes sense and helps in the meantime. Please let me know how it goes, and if you have any questions.

Best regards,
Edge

Hi, Johan. (@johan_walter).

Thanks for getting in touch! We are aware of the translations issue you’re experiencing with?WooCommerce Product Tabs, which occurred after updating to WordPress 6.7, and appears to persist in WordPress 6.7.1.

For info, translations are broken in WordPress core itself right now, and this affects numerous plugins other than our own. This is due to what’s mentioned at https://make.www.ads-software.com/core/2024/11/19/wordpress-6-7-1-release-schedule/ :

Translations not being applied properly (#62337)

You are correct – Translations worked prior to WordPress 6.7. Our suggestions in the meantime are to:

• Roll back to WordPress 6.6.2?and wait. The easiest way to do this is to restore the backup/version of your website prior to updating to WordPress 6.7. Otherwise, I suggest that you get in touch with your website’s web hosting provider, who can assist you with this best.
• Manually copy translations.

If you’re familiar with the steps, or have a developer who can perform them for you, our developers have provided the following example:

Let’s take WPO for example and assume the site is using Spanish as language.

• Navigate to?wp-content/plugins/woocommerce-product-options/languages/
• Copy the the 2 files that end with the suffix?es_ES?. They have different extensions –?.mo?and?.po
• Navigate to?wp-content/languages/plugins?– create the folder if it doesn’t exist.
• Paste the files.

Once done, translations will start working again, but you may see notices/warnings. To disable this from being displayed, see: https://developer.woocommerce.com/2024/11/11/developer-advisory-translation-loading-changes-in-wordpress-6-7/

I hope this makes sense and helps. Please let me know how it goes, and if you have any questions.

Best regards,
Edge

Hi again, @psykonevro and @ezequielb.

Our developers have replicated the issue and are aware of it, and will work on a fix to be included in the next release. I will keep you updated.

For info, this issue also occurs in other plugins and is not isolated to Posts Table with Search & Sort. i.e. A similar notice is displayed for the TranslatePress – Multilingual plugin even when Posts Table with Search & Sort is deactivated. You can see the discussion about this issue at https://core.trac.www.ads-software.com/ticket/62462, where WordPress is considering to revert this in version 6.7.1 and wait for 6.8 to introduce a more robust mechanism to handle early text domain loading.

I hope this helps explain the issue. Let me know if there’s anything else that we may assist you with in the meantime.

Best regards,
Edge

Hi, @ezequielb and @psykonevro.

Thanks for your replies. I really appreciate the supplemental info.

I see what you mean, and am able to replicate the issue on a test site that uses WP 6.7 and the default Twenty Twenty-Four theme, and with only Posts Table with Search & Sort 1.4.6 and the TranslatePress – Multilingual 2.8.9 plugins active. I set the Site Language to Fran?ais, and the notice that you mentioned displays in the front-end posts table page (screenshot: https://share.zight.com/bLuvW17A).

I am relaying the details to our developers for review and to investigate further, and will let you know as soon as we have new information.

Thank you for telling us about this, and I’m very sorry for the inconvenience.

Best regards,
Edge

Hi there,

Thanks for your reply and update.?I’m glad I could help!

Please let me know if there’s anything else that we may assist you with.

Best regards,
Nikki

Hi, @idris-draig.

Thanks for getting in touch and for using Posts Table with Search & Sort. I understand you’ve used our other free plugin, Easy Post Types and Fields, to create a custom post type on your website which appears to have a name/slug conflict with an existing post type. Such an issue could indeed be quite tricky!

Please could you email me at [email protected] to send temporary admin login details for your WordPress website (login page URL, admin username and password) and I’ll investigate further.

Alternatively, you can send a secure login link (also to [email protected]) by installing the free Temporary Login Without Password plugin.

You can also send us the credentials to your website via a support request from our dedicated Support Center. This is usually for our premium/paid plugins, albeit the issue you’re experiencing can be resolved quicker by having temporary wp-admin access to your website, which you can send privately as described above.

Many thanks,
Edge

Hi, @psykonevro.

Thanks for the reminder! As mentioned and thanks to your initial report, our developers are aware of the issue and will include a fix in the next release of the plugin now that WordPress 6.7 has been published.

I will let you know as soon as the next version is available.

Best regards,
Edge

Hi there,

Thanks for your quick reply and the helpful information. I appreciate you sharing the link to the document library page.

To further troubleshoot the conflict, could you please try the following:

-Disable Other Plugins: Temporarily deactivate all plugins except for Document Library Lite.
-Switch to Storefront Theme: Switch your active theme to Storefront.
-Test Previous Version: Install the previous version of Document Library Lite and see if the issue persists.

Please let me know if any of these steps resolve the issue.

Thanks,
Nikki

Hi,

Thanks for your suggestion. This is a great feature request, and we appreciate your feedback. We’ll consider this for future updates as we continue to improve our plugins. In the meantime, I’m sorry this isn’t possible.

Please let us know if you have any other questions.

Nikki

Hi there,

Thank you for using Document Library Lite. We apologize for the delay in responding to your query.

To better assist you, please share the link to the specific page where you’re encountering the issue. Additionally, please ensure that you’re using the most recent version of the plugin and that it’s active on your site.

We appreciate your patience and understanding.

Best regards,

Nikki

Hi?@altalena?,

Thank you for the reply and the images. They are helpful. Looks like everything is in order. For the next steps we can try and for more flexibility troubleshooting, please get in touch with us through our Support Center (https://barn2.com/support-center/). I look forward to hearing from you. – Carl

Hi @altalena ,

Thank you for the comment. I’d be glad to help you.

I tested this on my end and I’m not able to replicate the issue – https://share.zight.com/X6uj10zb. The bullet points are visible. Can I have the URL of the product page where I can see the issue? Can you also try the same HTML code on the description part (or anywhere else that accepts and displays HTML code) of the product and see if the bullet points will be displayed? Please also send a screenshot of the HTML code you are using.

I look forward to hearing from you. Let me know if you have more questions.

Carl

Hi again, JCV (@psykonevro).

Thank you for your patience. The current target for the WordPress 6.7 release is November 12, 2024. We test each version of our plugins against upcoming releases, especially major ones, before release.

Our developers are now aware of the issue you reported, and will include a fix to address it in the next version of the plugin, once WP 6.7 is published.

Please let me know if you have any more questions. I will mark this topic as resolved for now.

Best regards,
Edge

Hi, JCV (@psykonevro).

Thanks for getting in touch, and for using our plugin. I understand you’ve tested the current version 1.4.6 with the upcoming WP 6.7 release (currently in beta), and are reporting the mentioned notice thrown if load_plugin_textdomain()?is not loaded in “init” hook.

I am relaying the details of your concern to our developers for review and to investigate further. I or another member of our team will let you know as soon as we have new information.

Thank you for telling us about this. In the meantime, please let me know if there’s anything else that we may assist you with.

Best regards,
Edge