You should tell me to read the instructions!!!!
I am being guilty of something I tell others of for. ... laziness!
On 4 Jun 2008, at 06:11AM, deliciousdays wrote:
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
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
