[geeklog-devel] RFC: Plugin migration
devel at portalparts.com
Tue Jan 13 23:15:01 EST 2009
I have updated my local CVS and am trying to free up my time to test the
plugin install out and explore it further before commenting but it sure
Without really getting into the code and working thru a few examples, I
am thinking it would be best to migrate and then call upgrade. If there
are any new settings for the upgrade, they need to be based on the post
Dirk Haun wrote:
> I'm still interested in any feedback from plugin authors regarding the
> plugin auto install in Geeklog 1.6 
> In the meantime, here's a somewhat related topic: Migration of plugins.
> In 1.6, we now have that nifty Migration option in the install script
> (the other part of Matt's GSoC project). That's what you use when your
> site moves to another server. It also handles path changes, URL
> changes, provides warnings about missing files and plugins, etc.
> When your site's URL changed during the migration, it will also update
> most of the content now. What's missing are the plugins.
> So the obvious idea would be to have a PLG_migrate call that informs
> plugins about the migration and gives them a chance to update paths
> and URLs where needed.
> However, the migration can also perform database updates. Which raises
> the question: What comes first? PLG_upgrade or PLG_migrate?
> Alternatively, we could call PLG_upgrade for the migration case (with
> a flag indicating that a migration is underway) and let the plugins
> figure out the proper order themselves. The downside of this approach
> is that it would call PLG_upgrade in cases where the plugin doesn't
> need to be upgraded, which could confuse some plugins.
> To summarize the options:
> 1) PLG_upgrade first, then PLG_migrate
> 2) PLG_migrate first, then PLG_upgrade
> 3) PLG_upgrade($mode = 'migration')
> bye, Dirk
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
More information about the geeklog-devel