Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#49132 closed enhancement (wontfix)

Remove translation files when a plugin no longer exists

Reported by: audrasjb's profile audrasjb Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: has-patch
Focuses: Cc:

Description (last modified by audrasjb)

That would be nice to remove existing translation files when a plugin is manually deleted (by FTP or whatever).

Plugins translation files are already removed when the plugin is deleted with WordPress Admin, but still exist when the plugin is manually deleted by FTP or so.

To reproduce the issue:

  1. Activate a plugin which is translated into your website language (other than en_US)
  2. Delete the plugin folder (by FTP or whatever)
  3. Problem: the translation files still exists in wp-content/languages/plugins folder

If you delete the plugin with WP Admin Plugins screen, the translation files are actually deleted.

Thanks @wpchannel who indirectly raised the issue in WP French Slack team and @sebastienserre for his contribution.

Attachments (1)

49132.diff (1.7 KB) - added by audrasjb 5 years ago.
First, let's do that for plugins. If the plugin doesn’t exists anymore, silently remove the related language files

Download all attachments as: .zip

Change History (11)

@audrasjb
5 years ago

First, let's do that for plugins. If the plugin doesn’t exists anymore, silently remove the related language files

#2 @audrasjb
5 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

#3 @audrasjb
5 years ago

Hmm. For plugins, I used the existing validate_active_plugins function.

Since we don't have any corresponding function for themes, I'm wondering if we should rather limit this ticket to plugin translation files, first. Any thoughts on this?

#4 @audrasjb
5 years ago

  • Description modified (diff)

#5 @audrasjb
5 years ago

  • Description modified (diff)
  • Summary changed from Remove translation files when a plugin or a theme no longer exists to Remove translation files when a plugin no longer exists

Removing references to Themes in this ticket as there is nothing similar to validate_active_plugins to perform the theme translation files removal.

Theme translation files removal should be handled in another dedicated ticket as it would include further investigation on themes deactivation/removal actions.

#6 follow-up: @ocean90
5 years ago

  • Keywords dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Thanks for the ticket and the patch! This doesn't sound feasible though.

  • If someone is deleting files directly they should know what they are doing and are responsible for deleting all associated files. This may be custom directories in the uploads directory, or, in this case, translation files.
  • A plugin may only be temporary not available due to a misconfiguration. There is no indication if a deletion was initiated by a user unlike it's the case for #29860.
  • validate_active_plugins() doesn't delete broken plugins, it only deactivates them thus deleting something shouldn't be part of this function.
  • Neither options or other data is deleted when a broken plugin is detected.
  • There's no harm in having the files still on server if someone has forgotten to delete them.

Therefore I'm going to close this as wontfix.

#7 in reply to: ↑ 6 @audrasjb
5 years ago

I understand your points, thank you I appreciate the detailed answer.

However, I'd like to have discuss some points to be sure we'll take the best option.

Replying to ocean90:

If someone is deleting files directly they should know what they are doing and are responsible for deleting all associated files. This may be custom directories in the uploads directory, or, in this case, translation files.

I'd say they could also assume that translations related to deleted plugin would be deleted as well, since it's actually the case when they delete the plugin in WP-Admin. In my opinion, there is a small inconsistency here. It doesn't hurt very much (except we keep files that are not used anymore in the installation), but it's still an inconsistency, and to be honest I don't think we should make our decision based on the statement that users have to delete those file by themselves :)

  • A plugin may only be temporary not available due to a misconfiguration. There is no indication if a deletion was initiated by a user unlike it's the case for #29860.

I understand this point and I share your thoughts, but this is why I added a test on plugin_not_found error code. Do you think it's not sufficient to consider the plugin has been deleted?

Translation files deletion doesn't hurt as a translation update will be available if the plugin is put back in place.

  • validate_active_plugins() doesn't delete broken plugins, it only deactivates them thus deleting something shouldn't be part of this function.

Yes you're right, so maybe it would be better to add a specific function to delete translations, outside of validate_active_plugins?

  • Neither options or other data is deleted when a broken plugin is detected.

I kindly disagree on this point, as validate_active_plugins use deactivate_plugins function which removes the plugin from active_plugins site option. So the plugin data is actually deleted from the plugin option, isn't it?

  • There's no harm in having the files still on server if someone has forgotten to delete them.

I also disagree on this point, as it's always nice to remove unused and useless files.
Once again, if it's a temporary deletion and the plugin is put back in place, a translation update will be available, so there is no harm to delete translation files when there a plugin isn't available anymore.

  • Therefore I'm going to close this as wontfix.

I'd like to keep it open to give some time to discuss the above points.
But be sure I'll be happy to close it after some discussion! Thanks for your comprehension @ocean90 :-)

#8 @ayeshrajans
5 years ago

When debugging fatal errors, I have seen people just taking off the plugin directory outside to see if it brings the site back to life.

If we expect users to remove the plugin directory without proper uninstallation, I think we should expect they will put it back too. If we proactively delete the language files, we have to copy them to languages directory when placed back as well.

I agree with points raised by @ocean90 - it is an edge case that has no serious impact, and it is something we can't reliably work around either.

#9 @knutsp
5 years ago

I kindly disagree on this point, as validate_active_plugins use deactivate_plugins function which removes the plugin from active_plugins site option. So the plugin data is actually deleted from the plugin option, isn't it?

No. Plugin data can be anything in the database, a db table or several options. Such may only be removed by the plugin itself, executed from the uninstall_$plugin or it's own uninstall.php file.

I can understand the wish to clean up unnecessary files, but deleting language files should only happen when properly deleting (uninstalling) a plugin. A cleanup of either files, options or db tables that has become obsolete because of file deletion outside WordPress admin should be plugin territory.

Do not assume all language files in wp-content/languages folder is downloaded from wp.org since translation plugins optionally put their (source and compiled) files there (but warn that they can be overwritten by language packs, and they may or may not keep a backup).

A recommended way to check is a plugin is causing an error is to temporarily rename it. If no one visits the Plugins screen in that time, these plugins are not even deactivated (just not loaded).

#10 @audrasjb
5 years ago

Fair enough. Some points look really legit to me.
Let's keep it closed.
Thanks for sharing your thoughts.

Note: See TracTickets for help on using tickets.