New plugin architecture patch

Ok,
First off there is a comma in your sql, which is causing an error at installation:

When I removed the comma after default '' (Line 147) it installed ok.

Next, for some reason there were two copied of the same code in each of your files, which was causing 'class already been declared' errors.
At first I thought this was me accidentally patching it too many times (I'm new to patching), but when I look in the patch file I see:

Again, I don't know much about patches, so this might be normal....

I went through most of the files, and deleted the duplicate code.
I went to the admin tab and tried to enable the links plugin, and get this error:

Apart from the above, it looks promising :)

EDIT:
Ok, I changed the table column name from title to name - That solved the plugins' failed to activate error

Now it says plugins' activated, but with an error flash, and the radio button for Project links is set at deactivated.
However, it has created the db table pp_project_links but the project tabs (forms etc.) are not hidden.

Thanks for the feedback Alex. Fixes from above have been applied and new FULL patch uploaded. For some reason TortoiseSVN insists on creating doubles of some files.

Thanks. The supplied patch is meant as a starting point to get the discussion moving on where to place hooks throughout the code. So far, as a proof of concept, I have only placed hooks in the menu areas of PP. Hooks could very well be placed in the permissions config area of PP etc.

The sample plugin does have user protection to make sure that only members of the owner company or an administrator can create, update or delete while all project members can view links associated with the project.

I found from writing the sample that it was more involved than writing for something like Wordpress and probably more like writing for Mambo/Joomla, in that the plugin files were spread across multiple existing folders (i.e. controllers, models, views). In presenting this plugin framework as a starting point, maybe we can move toward an easier structure for plugin writers to write for. This could be an uploader and unpacker that distributes files to their correct locations or maybe some mods that would allow each plugin to maintain all files in their plugin folder and allow PP to pick up whats needed in each folder.

Not sure what the way to go is and I am sure I know much less about the framework than others here but lets get talking.

Just curious if you're part of the development mailing list or might come chat in the IRC channel.

Moved this to the list thread.

Just to give credit where credit is due, most of the work in this patch is still activeingredient's work. I prefixed the name of the patch above with cgonzlaez to indicate that the patch is his update to activeingredient's patch.

So, activeingredient, a gigantic thank you to you for getting the ball rolling on this.

Another update to the plugin system. Unfortunately, I'll bet that this patch still has tabs ('\t') in it instead of spaces. My apologies to andypost. I'll have to figure out Emacs...

This patch further refines the plugin system, moving all plugin files under a single directory. This patch also supersedes the permissions patch in Issue 1183. Permissions are integral to a full-featured plugin system, and this patch includes a working permissions system. As such, this is a large patch with many new files and many one and two line changes in existing files.

This patch also includes all necessary code to install a fresh PP database, and upgrade an existing PP database through the http://pp_server/install and http://pp_server/upgrade URLs. For the purposes of this patch, it calls the "new" version of ProjectPier 0.8.1. If this patch is approved, I'm assuming it will be integrated into 0.8.5. The upgrade script class implementing these changes is "QuinceUpgradeScript", following in alphabetical order (and nomenclature) from the two existing upgrade scripts.

I've updated my initial documentation regarding the changes and attached it to this message. I've also attached the updated Wiki plugin, which uses the new directory structure and implements basic per-project permissions.

As before, the Wiki plugin is really a .tar.gz file. Rename it and then untar it into the pp_root/applications/plugins/ directory.

In #14 WikiController.class.php

line 231 //$page->setTagsFromCSV();
line 312 //$page->setTagsFromCSV($data['tags']);

In form there's not tags - notice-exception

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 /public/.

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.

Plugins are making me very sad today.

Attached is a more complete plugin and permissions patch. I've verified that it applies cleanly to SVN revision 177 and that a new install can proceed from there. In addition, there is an upgrade script (QuinceUpgradeScript.php) to take things from a flavor of 0.8.0 to what I call 0.8.1.

Obviously this patch needs review, comments, and updates before it would be ready to commit. That said, we are using in production with a plugin specific to a segment of our business.

I installed the wiki plugin from post #14 and it seems to be working fine with the patch from post #20.

Thanks TheWalrus.

It would be nice to know where this patch, as well as all of these various patches, stand in relation to upcoming releases of PP.

It is rather frustrating to have to download 5-7 different patches of which there are various incarnations from the forums to cobble together a non-standard install.

Accepted into 0.8.6 including wiki plugin. Superb work!