For the time being I simply offer users of cforms the option to store
all customized files (CSS, fonts, images) in a separate folder, e.g.
plugins/
cforms/ <-- plugin folder
cforms-custom/ <-- custom folder
Of course this is optional. Not a perfect way, but one that works well.
***
deliciousdays.com / cforms <http://www.deliciousdays.com/cforms-plugin>
DD32 wrote:
On Wed, 04 Jun 2008 14:41:18 +1000, Jacob Santos
<[EMAIL PROTECTED]> wrote:
Might be time to revive the upgrade script idea (or am I thinking of
plugin data discussion). Might be useful to have a file called
upgrade.php (or whatever) which is called within the context of a class
which gives it access to control the flow of the upgrade.
A combination i think :)
Dan Milward wrote:
Hi Dion,
Thanks for the email.
If you could come up with a few hooks then that would be awesome. I'm
asking because we create plugins and I think it would be useful - the
problem we are having right now is that people can add additional php
files to our plugin to extend the core features.
Theres a few plugins which did that, At least one has moved to storing
user content outside of the plugins folder.
So when the update the plugin from WordPress extend they loose their
work. If we were making a new plugin from scratch then this wouldn't
be a problem and we would do it differently but because we already
have lots of users I'm not sure we can do it.
A few items that come to mind:
* Is what happens if the plugin is deactivated when the user upgrades?
* What happens to current people who upgrade to the new plugin
(before the deletion handling is added to your plugin)
* The user will need to move their custom data before doing the
upgrade, so the user is going to need to move the data regardless.
* The plugin upgrader likes to install plugins into a folder based on
their WordPress.org slug, Many older installations do not have this
format, Which increased the complexity required by the upgrader, so a
simpler approach was chosen to smooth out the directory names.
The main reason the updater simply deleted everything, Was, What is
user data? What is plugin data? It has to be assumed its all plugin
data, The current generation of plugins were *not* going to be able to
take advantage of any hooks to filter it, In a way, It forces plugins
to seperate user and program data.
However, Future plugins *will* be able to take care of it, So.. Thats
a good enough reason i guess for something to happen, but how many
plugins/users are going to benifit from it?
Its not going to be a change which makes it into 2.5, It'll be a 2.6
item( Whoa, Thats due in about a months time:
http://wordpress.org/about/roadmap/ ).. I was hoping to avoid changing
the updater code until morphing in a plugin installer.
I'm still going to suggest moving user data outside of the plugin data
folder though..
As an interim what we're going to try and do is just disable auto
updates from happening but allow people to manually download updates
and do it themselves. For powerful plugins I think this would be
extremely cool.
I agree that there'll be some plugins which could take use of it, But
i still do not think there'll be a great use for it.
As an intrim, My suggestion is to filter the pre_option_update or
whatever it is to remove the download link from the update option,
That'll have the effect of notifying that there is a update available,
but as it will not have a URL to download the zip from, It'll not
offer to automatically upgrade it.
Ciao,
Dan
DD32 wrote:
It is not currently possible to hook in to make changes to what
is/isnt deleted.
The plugin directory the files are stored in are often not the same
as the plugin's slug, In order to keep simpler code, all plugins are
stored into a folder based on their slug and the old plugin removed.
If you have made changes to the core plugin, Consider submitting them
as patches back to the author, or forking the plugn(at least for
yourself = modify the plugin name and url)
If the plugin stores files into its plugin folder, Consider asking
the plugin maintainer to store the data outside of the plugins
folder, Or in the database if its small enough. This has the benefit
of also keeping the plugins folder manageable.
It may be possible in 2.6 to filter what is/isnt
deleted/removed/modified/etc, There have been 1 or 2 requests for it
so far since 2.5 release :). I'm working on some changes which'll
affect the upgraders code, so i may well try and write a few hooks or
something in, But as it is, there is no list of files which you cna
filter, it just says "Delete that folder and any files in it, i dont
care what the files are, just get rid of them"
Cheers,
Dion
On Wed, 04 Jun 2008 10:52:24 +1000, Dan Milward <[EMAIL PROTECTED]>
wrote:
Hi Guys,
How do we add custom code to the plugin updating system to preserve
files that people may have added to the plugin directory.
Because by default it looks like it deletes the plugin directory and
replaces the all the files with the updated version - in the process
deleting any changes.
Ciao,
Dan
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
