An interesting message from PP dev list. I strongly agree with Brett R. Edgar. Extending of PP is a hell... PP needs remodel of entire architecture, of course not focusing the idea about lightweight and very easy to use PM environment.
Brett R. Edgar
Fri, 14 Nov 2008 07:50:48 -0800
Perhaps we need to re-think this whole plugin system. I've so far discovered
the following two issues:
1) The ApplicationLogs filters logs from uninstalled plugins by getting the
object manager class name as a lower-case string and then checking to see if
a plugin by that name exists.
I discovered this while trying to create a "Time" plugin incorporating all
the TimeTracker code. However, the object manager for application logs from
that plugin is called ProjectTimes. Now, I've worked around this relatively
easily by adding a column to the plugins table called 'log_providers' and
asking the plugin's init.php script for a list of those.
2) Public files and images. This is a major deficiency in the current plugin
architecture. The plugin can't provide any static content without writing
outside the /application/plugins/ directory structure. Allowing a plugin to
do so would violate the principle of isolating plugins from each other. It
would also make plugins harder to add and remove completely.
I discovered this because the "Wiki" plugin creates application logs, which
when displayed on the dashboard tries to show an image in the left-hand
column of the log entry. The wiki plugin can't distribute an image for every
possible theme, though, and it would have to install that image outside of
its plugin directory. Both of these situations are unacceptable. I can't
solve this problem because the sequence of functions called (image_url() ->
get_image_url() -> get_public_url()) makes it hard to check if a file exists
and provide another default location if it doesn't. And that is not even
mentioning the configuration headache installing PP would incur in getting
Apache to serve public files out of another directory in addition to
So does anyone have any thoughts on how to solve these two issues? Can
anyone think of any further issues like this that we may encounter? I'm sure
as we create more plugins we are going to run into more issues like this. We
may not be able to anticipate all of them until we encounter them, which
means we need a lot more people contributing test plugins.
My initial fear is that adding proper plugin support to the system is going
to require so many changes that it would be better to completely
re-architect ProjectPier. Plugins need to be pushed into the Env classes,
not some hack-job add-on. A plugin system's needs are low-level enough that
they should be part of the *core* application. The same goes for extensible
Plugins are making me very sad today.