Exclude files and folders from automatic plugin upgrade

[alexrabe]

The new unistall feature #5625 is a great addon and I would like to suggest to implement a other feature for the upgrade procedure. The problem :

Some files (CSS, addon flash files, config settings, etc.) are stored in a plugin folder, during every automatic upgrade procedure these files will be removed as they are not included in the core plugin. The user must reupload them always again. I don't like to seperate these files outside the main plugin folder because they are part of the plugin.

The possible solution :
A hook or file (upgrade.php) defines files and folder which will be saved in a temp folder and will be copied back to plugin after upgrade. If there is any interesting and agreement from the core dev team, I can work on a first patch.

[Viper007Bond]

-1

User content should not be stored in the plugins directory plus this would not allow plugin authors to remove no longer used files that could possibly be a security risk as WordPress would keep them even if they were removed from the plugin.

[ionfish]

-1

WordPress shouldn't have core facilities included to hack around poor plugin design. User content should be stored elsewhere in WP_CONTENT_DIR, and configuration should be stored in the database.

[alexrabe]

I don't see here any security risk, because the uninstall routine should remove all files.Also I don't like to store plugin related files outside the plugin dir, except media files (videos, images etc) which I never store inside the plugin folder. Let me give you three examples :

a) Plugin related CSS files : In my plugin NextGEN Gallery I store the custom CSS files for the gallery design. Of course they can be added to the theme folder, but the user must copy thoses files or edit the style.css when they change the theme. When you remove the plugin you can forgot then to remove the css files. The same happend if you add a new font for the watermark function.

b) Adding of additional resources/files : In my plugin NextGEN Gallery and wordTube (see aslo Viper' Video Quicktags) I include a flash player for images or videos. This flash player is not part of the plugin GPL license and in the past I didn't include this flash player, so that the user must upload the file one time and agree to the creative commons license from the author. Since the automatic upgrade I include this into the repo because it's annoying to reupload the file after each upgrad. In my opinion it's a bad plugin design if I store it outside...

c) Special path constant : In a very seldom case it should be needed to add a custom path to a php file. Yes, all settings should be stored in the database, but if you move the wp-content dir outside the classic path structure I need the path to wp-load.php. I planned to stored this path constant in my plugin dir.

[Viper007Bond]

Replying to alexrabe:

I don't see here any security risk, because the uninstall routine should remove all files.

I missed that your suggestion is that only files defined via a filter would not be removed. I thought all non-plugin files would be kept meaning a plugin author couldn't remove no longer used files.

Still though, I think it's bad practice to store user modified content in a plugin folder.

[DD32]

Since someone asked me to comment:

• I do not support non-plugin files in the plugin folder, I see it as bad practice
• I said in a previous ticket I'd look into putting a filter on it, However never got back to the ticket (and now cant find it); IMHO its more trouble than its worth for the small ammount of uses it'd receive - That and the trouble of upgrading non-auto-installed(ie;. non-upgraded, or non-plugin-install(2.7))) plugins having different directories than their slugs makes it a slightly messy issue
• Yes, You might need to enter a custom path, However, Your plugin should only include other items on an init hook at which the DB is loaded, and any options are loaded, So store it there. Except in the case of Caching plugins, where you need to have a custom configuration file created anyway, So store it in a file in wp-content/ (WP-Cache 2 does that)
• If you have non-plugin files which are UserData, then store them in a user adta folder, Not your plugins data folder, Its not hard to tell users to upload their custom data to WP_CONTENT_DIR/GREF-Data/, and its not hard for your plugin to save them there in preference to your plugins folder

• -1 overall, But if someone else feels like its a good idea and actually wants to spend their time to do it, Go ahead, But i'm not really interested in writing a patch i feel is rather useless to the vast majority, and only useful to a small handful of plugins (The email asked me if i'd write a patch up for it -- I dont think they've got anything to do with this ticket, so no finger pointing & theres my reasoning :))

[alexrabe]

Ok, 3:0 against my idea. Thanks for your comments, so it's my personal problem to find a way around...

[santosj]

Well, there /are/ filters that you can test for that will allow you to move the files out of the directory and then when you're plugin is activated, move them back in. I think the best person to handle this would be the plugin developer and not WordPress. The reason is that there would be many, many bugs and feature requests asking for more that WordPress does that the plugin should be doing.

[bueltge]

I think this is not a personal problem. Thsi in the future a problem of WordPress and the users of WordPress. Most plugins will be bigger and more informations, not interest for the live install. wp.org is a SVn vor developer and a platform for contriubutors, please respect all requirements.

[alexrabe]

Just for the statistic :
Issue is extensively discussed in ​wp-hackers

Don't see here any chance to convince the core team. For me the ticket could closed again.

[Denis-de-Bernardy]

closing... I store stuff in WP_CONTENT_DIR all the time, and it works quite nice as long as the folder is writable.