[geeklog-devel] [Fwd: Re: Redesign the Plugin "Editor"]

[Randy Kolenko]

Aside from the dig against Socnet, Joe's point is valid.

During our last revamp of our Nexpro plugins, we introduced a very simple-to-code dependency check in the installation routine and returned the dependency information in an error message.  This way we could have dependencies on many other plugins and never have to worry about installing something without other mechanisms being present.

For the last revision of our apps, reception from the GL community at large was tepid at best -- but the approach is all there for everyone to see.

We noted issues with the current GL plugin system where the plugin would not be able to raise errors with Geeklog during the installation.  We noted this in the devel list a few times.  So we had to adhere to what Geeklog would allow us to do, and thus we simply had to rely on the error.log file to spit out dependency information.

That being said, it's a VERY short step from what we've implemented already to showing those dependencies and having an install routine blocked by the UI.  So don't re-invent the wheel when most of it has already been created.



From: Joe Mucchiello [mailto:jmucchiello at yahoo.com] 
Sent: Sunday, January 16, 2011 12:10 AM
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] [Fwd: Re: Redesign the Plugin "Editor"]


"Rouslan Placella" <rouslan at placella.com> wrote:
>Couldn't that information go into a "info" tooltip? Or if it needs to be
>changed, it could go directly into the list of plugins.

Do you really think "This plugin requires the social networing plugin active in order to work" is the kind of information that belongs in a tooltip? Last summer everyone was all up about making plugins that were built off the socnet plugin (where ever that is). Well, knowing that if you deactivate the socnet plugin it will affect other plugins doesn't sound like something that goes in a tooltip. Adding this information to the main plugin list doesn't sound good either. 

What is the motivation to remove the editor screen? Are you going to remove the topic editor too? It's kind of sparse. I just think it would confusing to have some admin screens that lead to editors and some that are edited in place.

>The oldest entry in the bugtracker that I can see is from 2008...
There was a big crash in 2008. They are older.

>> Geeklog needs that much more than it needs pretty admin screens.
>Why?
Because only admins see pretty admin screens. Making pretty admin screens benefits one or two people per geeklog installation and usually only during their first few weeks of installation: how often to admins go to the plugin screen really? User facing screens getting beautified helps every user at every geeklog installation.

The plugin load order fix is as simple as adding a pi_order field to the plugin table. Stealing the up/down arrow interface from the blocks admin screen and changing the spot where the plugins are initially loaded so that it uses the new order field when it loads the plugin list. The request is at least as old as Geeklog 1.3.x. And the old bug tracker had a patch lost in the above crash. If you can get it into core, more power to you.

  Joe