Updates for other translations are broken

[G3ronim0]

Hello, once GravityView has been installed and activated, all plugins translations updates are saved in WP_LANG_DIR/BLOG_ID.

The problem is located in the gravitykit/foundation vendor, in the TranslationsPress_Updater.php file. The conditional in the modify_upgrader_package_options( $options ) function is incorrect. You first need to check that it's a plugin and then that the slug matches.

At the same time, I don't understand the interest in changing the destination of language files.

Regards, Jérôme CTO @TranslationsPress.

[mrcasual]

@G3ronim0, could you clarify what you mean by "broken"? For example, are they not downloading, or are you receiving an error message? We'll review and test the modify_upgrader_package_options function in the meantime.

Regarding the location, all translations are stored in the wp-content/languages/plugins/<current blog ID> folder. This setup supports automatic cleanup of translation files on both regular sites and multisite networks. When you deactivate any of our products, we automatically remove the translation files. However, since the translation files are named the same and product X can be installed on sites Y and Z, deactivating the product on site Y would also remove the translations on site Z. As such, we store translations in subfolders specific to each blog ID to prevent that from happening.

[G3ronim0]

@mrcasual The whole process works searching for updates, downloads and uninstallations. But the fact that translations are stored in wp-content/languages/plugins/1 for a single installation is not good. Translations don't work because WP searches for them in wp-content/languages/plugins

To test on WordPress (not multisite), if the languages were installed before GravityView was activated, remove them manually so that the update is available. Then, when you perform the update, it will be downloaded into directory 1 and will not work in the interface.

[mrcasual]

@G3ronim0, I was able to reproduce the issue. Indeed, the logical operator used in the conditional check within the modify_upgrader_package_options() method causes the custom translations path to be returned. This path should only be used for GravityKit products. We will fix this in the next scheduled update; thank you! Please let me know if you need a custom build in the meantime.

[G3ronim0]

@mrcasual Great, thank you for your responsiveness. Looking forward to the next update.

Regards

[mrcasual]

Fixed in 001babf. Build file.