Important Plugin Question

Something in the back of my mind is setting off a soft, distant warning buzzer about the plugins: the lack of controlling their execution order. I mentioned this to Travis in passing regarding the manager, and he agreed as well. I can see Plugins really taking off and sometime in the not so distant future having to redo the way they work later to add in order execution...

Travis pointed out what sounds to me like an outstanding idea regarding the plugins. Based on his initial research, he *thinks* it would give us everything that plugins allow now (tapping into system events all over the place), but acutally would require less overhead and allow us to control the order of plugin execution, and be 100% compatible with the way they work now. And they'd be compatible with a lot of existing WordPress plugins, too, which would be a killer marketing point as well.

To cut to the chase: http://codex.wordpress.org/Plugin_API

:?: Raymond/Travis, am I thinking crazy here again or is this a viable idea?

Well, the actual code isn't directly portable to Tattoo, but the way it works is.

Obviously, the WP solution is a lot more mature than the Tattoo version which I like. It's also smarter about execution and how things plugin, which reduces overhead.

And, of course, while we might want to take some of WP's events as our own, it would be quite simple to use Raymond's list as the actual hooks.

If anyone is interested, it wouldn't take any time at all for me to write the code to implement Raymond's system events using the WP model. We could then try it out and see what everyone thinks.

TS

If it's no big time-consuming deal it'd be cool to see WP methods with Raymond's events.

Something in the back of my mind is setting off a soft, distant warning buzzer about the plugins: the lack of controlling their execution order. I mentioned this to Travis in passing regarding the manager, and he agreed as well. I can see Plugins really taking off and sometime in the not so distant future having to redo the way they work later to add in order execution...

execution order is on the todo list. you be able to change the execution order of a plugin on an event-by-event basis

Travis pointed out what sounds to me like an outstanding idea regarding the plugins. Based on his initial research, he *thinks* it would give us everything that plugins allow now (tapping into system events all over the place), but acutally would require less overhead and allow us to control the order of plugin execution, and be 100% compatible with the way they work now. And they'd be compatible with a lot of existing WordPress plugins, too, which would be a killer marketing point as well.

To cut to the chase: http://codex.wordpress.org/Plugin_API

:?: Raymond/Travis, am I thinking crazy here again or is this a viable idea?

You can always add more system-events. But would think that using an event to filter the page title and other to filter the content is a watse of resource.

It's better to have one event that is able to pass the entire document to the plugin for it to modify it's content

The questin is still open though that if a "Wordpress" clone plugin model could be quickly implemented now, and that offers lower overhead and the execution order, while maintaining compatibility with the current plugin methods, where's the harm in that?

I'd venture to say none; in fact, I'd venture to say it would be a big draw. A lot of people use Word Press, certainly a significant multiple more than MODx and Etomite combined to say the least. As such, they rightfully have some mindshare of perception of the way things should be done. If we could effectively "drop in" a boatload of plugins (even if they seem to be overly resource consuming), then all the better on our ultimate quest to get MODx out there as a viable solution.