[geeklog-devel] we don't need to maintain the plugin's upgrade function

[Joe Mucchiello]

Then what was the point of making them plugins? Some of them use to 
just exist in the core.

Dirk has expressed hope that someone will take over control of some 
of them. Part of that I assumed included decoupling their release 
from the core. But as long as those plugins are inseparable from the 
core, who is going to come along and take control of them?

Finally, when I finish the calendar bounty, it will be released 
independently of Geeklog. And frankly I'm haven't said "I'll take 
over calendar" because I don't want to be tied to GL releases. This 
is a big step backwards away from giving those plugins separate life.

That said, I think SPAM-X and staticpages should be moved into core. 
I doubt anyone actually disables those from the plugin admin screen. 
Polls, links and calendar I can see being disabled. But not those 
two. OTOH, I'd love to see story/article support moved into a plugin. 
With forum and mediagallery having support for taking over index.php, 
I can imagine a site where the story code should be disabled. Right 
now, you can't remove stories from the what's new block and a few 
other places. Also there is so much special code for story that would 
just go away. (I'm talking about stuff like if ($type == 'story') { 
$ret = do this } else { $ret = PLG_callsomething($type); })

   Joe

At 03:28 AM 3/20/2008, Michael Jervis wrote:
>Just roughly, but, in what scenario would you need the upgrade
>function that isn't covered by the Geeklog installer for a currently
>bundled plugin?
>
>I don't have them installed, I don't need the upgrade.
>I have them installed, they are upgraded by the install.
>
>They aren't released separately, so there is no need for the
>individual upgrade function unless we make a plugin release
>independantly to the main software.
>
>Or have I lost the plot?
>
>On Wed, Mar 19, 2008 at 8:16 PM, Joe Mucchiello <joe at throwingdice.com> wrote:
> > At 05:12 PM 3/17/2008, Dirk Haun wrote:
> >  >Log Message:
> >  >Plugins are updated by the install script, so we don't need to
> >  >maintain the plugin's upgrade function
> >
> >  What? Why not disable editing them in the plugin menu too? I thought
> >  you were planning to decouple the plugins from the core tarball.
> >  That's where I thought the PEAR deployment stuff was headed. This is
> >  a serious blow toward PEAR delivery ever working with selectable plugins.
> >
> >  Okay, I read back a few days and see you did discuss this. But the
> >  reason those functions were hard to maintain was because the
> >  installer cheats. If you can maintain the upgrade_linksplugin
> >  function in install.php why can't you move that functionality to
> >  links/functions.inc and call plugin_upgrade_links instead?
> >
> >  Too late now I suppose.
> >

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com