Frog CMS - Lets get Plugins up to scratch

This post doesn't exist anymore!

Lets get Plugins up to scratch

11 posts, 8 voices

Feb 16, 2009 08:34 eoghanobrien 23 posts	One thing I’ve noticed about plugins with Frog is that they all seem to have their own UI with their own icons etc. What I’d like to see is: 1. a pre-decided icon set to be used across all plugins [approved/disapproved] 2. a pre-decided layout for tables, lists, headings, links, buttons etc [approved/disapproved] 3. some kind of code quality assurances [approved/dissaproved] 4. proper testing before a plugin is released as stable [stable/untested] I think if we subdivided the Contributed Plugins page with stable/approved, stable/disapproved, untested/approved, untested/disapproved we could give plugin developers a hope of keeping up with demands and trying out new innovations without the guilt of releasing a sub-standard plugin. Anyone agree?

Feb 16, 2009 12:13 Martijn (mvdkleijn) 651 posts	while I agree some of this would be nice… some concerns I have: who is going to do these quality tests? who decides what is good quality code and what is not? what if a developer decides to provide a different layout for something? (do we punish them? ;-) this approach leaves little room for developers who don’t have a lot of experience but do have willingness to help out. Apart from those concerns, I personally feel that anyone who wants a certain plugin should write it themselves or be glad there is someone out there that’s willing to do it for free. My personal estimate is that I’ve donated roughly (probably more) € 14.400,- euros in hours worked to the Frog project over the last 2-3 months. I don’t do that because someone on the forum wants feature this or feature that… I do it because its fun for me. And an occasional thank you. One thing I personally will never do is approve or disapprove plugins. That stifles innovation and developer’s willingness to help out the community by writing a plugin and releasing it for everyone to use. Mind you… all this is just my personal opinion. You can ignore it completely if you want. :-) by the way: where do I send the bill for 14.400 euros? ;-)

Feb 16, 2009 14:36 ricks 486 posts	i’m with martijn. i don’t favor anything that would discourage contributions. but, eoghanobrien, if you want to put your seal of approval on certain plugins that you test or that comply with standards you come up with, that’s a good idea too. i don’t think the seal of approval necessarily needs to come directly from “team frog”

Feb 16, 2009 15:25 eoghanobrien 23 posts	Okay I didn’t mean to come off as elitist but I think I may have. I’m not saying that even my code would be up to scratch just that if we had some standard to work towards it would help everyone that uses Frog and any of its plugins aswell as Plugin developers themselves. who is going to do these tests? Good point I naturally assumed the people involved in the core without thinking about the time it would take them, I apologise who decides what is good quality code and what is not? I thought this would be a community decision to get a basic standard with the correct hooks for styles for a basic plugin UI, obviously more complex plugins will require a more complex UI which would also be my answer to your third point this approach leaves little room for developers who don’t have a lot of experience but do have willingness to help out. i’m not trying to stop people from developing plugins, if anything its the opposite, for me anyway a basic standard for a plugin would give me the confidence that I’m not releasing crapware to people, I have a plugin I’m working on at the moment for SMS Updates via Clickatell which I’m thinking about releasing for public consumption but I wouldn’t feel confident releasing it until I get worthy of the Frog system (ie simple to use through thought in UI design) One thing I personally will never do is approve or disapprove plugins. That stifles innovation and developer’s willingness to help out the community by writing a plugin and releasing it for everyone to use. I only said Approve/Disapprove for lack of better phrasing but I do agree with you on that, I don’t want to block creativity in any way, I’m really just looking to maintain the quality of the core code in other parts, similar to the way other open source CMS, such as Drupal do (if only it wasn’t so convoluted) Anyway, I was just suggesting a means for maintaining the good start frog has already made. Thanks for the input, you made me think about it a bit more. Eoghan

Feb 17, 2009 05:20 Martijn (mvdkleijn) 651 posts	I understand what you’re trying to do and appreciate that I may have come off a little more irritated than intended. :-) for me anyway a basic standard for a plugin would give me the confidence that I’m not releasing crapware to people My guess is people won’t mind if its not perfect as long as you clearly tell them that. And it should always be clear whether or not the plugin is still under development or not. Also, in Frog 0.9.5 I’ve introduced a “skeleton” plugin which attempts to showcase some functionality and tries to steer people into a “standard” for development. I’m really just looking to maintain the quality of the core code in other parts Agreed, this is important. This is the main reason why (if I have anything to say about it) the plugin api provides or will provide functionality so developers don’t need to touch the core. Two examples: Events will probably be expanded upon even further A new set of getAllSettings() and setAllSettings()

Feb 17, 2009 11:24 eoghanobrien 23 posts	Kind of off topic but in relation to the plugin API is it possible to change or overwrite any part of the Page class such as the markup for breadcrumbs without touching the core. Is there any new observer events with 0.9.5?

Feb 20, 2009 03:34 DavidCOG 96 posts	I think providing a comment facility for plugins would solve a lot of this. The comments could be a source of reviews, bug reports and tips. Alternatively, make it mandatory to provide a URL with each plugin for a suppport thread on the forum. That doesn’t mean the developer has to provide support, but it gives a central point for users to get give / get support. P.S. I like the idea of standarised icons. Maybe the Tango icons ?

Feb 20, 2009 10:53 moser 36 posts	I think the people making plugins for frog have done a wonderful job. Every plugin they support so far has been definitely up to snuff for me

Feb 21, 2009 03:49 Andy 257 posts	My thoughts are that people should be allowed to release what they want – if new developers can learn form existing plugins and workout their best practice that is enough – a mandatory URL is incredibly unfair and most serious developers are around to check out the forums any way. If you keep a track of where you downloaded the plugin (or follow the contributed-plugins link) I’ve never seen any problem directly contacting a developer with an issue. Again, with standardised icons, it is not difficult to pick your own icons for a project and simply replace the images on the server with the ones you want if the license allows… On a more positive note, I totally agree that in an ideal world everyone will have the same amount of programming quality standards and think that issues that come about because of errors in code or structure will be ironed out as we go – we’re not on a version 1 release yet so we’re all on the same journey and changes to the core are having minor affects on plugins which make the short term development a little difficult (emphasise little) but long term there are some amazing features that Frog will allow that no other CMS can provide out the box. And at the end of the day, if you really need something to be built on Frog to a high standard, instead of expecting it for free, we should either build it ourselves or pay an experienced programmer to do it for us. My tuppence…

Feb 21, 2009 07:01 Martijn (mvdkleijn) 651 posts	The complete list of observer events in 0.9.5 RC 1 is: Observer::notify('page_not_found'); Observer::notify('comment_after_edit', $comment); Observer::notify('comment_after_delete', $comment); Observer::notify('comment_after_approve', $comment); Observer::notify('comment_after_unapprove', $comment); Observer::notify('comment_after_add', $comment); Observer::notify('view_backend_list_plugin', $plugin_name, $plugin); Observer::notify('plugin_after_enable', $plugin); Observer::notify('plugin_after_disable', $plugin); Observer::notify('user_after_add', $user->name); Observer::notify('user_after_edit', $user->name); Observer::notify('user_after_delete', $user->name); Observer::notify('admin_login_success', $data['username']); Observer::notify('admin_login_failed', $data['username']); Observer::notify('admin_after_logout', $username); Observer::notify('snippet_after_add', $snippet); Observer::notify('snippet_after_edit', $snippet); Observer::notify('snippet_after_delete', $snippet); Observer::notify('page_add_after_save', $page); Observer::notify('part_edit_after_save', $part); Observer::notify('page_edit_after_save', $page); Observer::notify('page_delete', $page); Observer::notify('layout_after_add', $layout); Observer::notify('layout_after_edit', $layout); Observer::notify('layout_after_edit', $layout); Observer::notify('page_requested', $_SERVER['QUERY_STRING']); Observer::notify('page_found', $page); Observer::notify('view_page_edit_tabs', $page); Observer::notify('view_page_edit_plugins', $page); Observer::notify('view_page_edit_popup'); I’ll update the documentation page once 0.9.5 final is out.

Feb 25, 2009 10:21 sc00t3r 8 posts	If anyone is interested, I’ve been testing 0.9.5 RC1 and I’ve posted some of my findings against the relevant threads within the forums. Here’s my post list so far (for what it’s worth): http://forum.madebyfrog.com/user/569/posts One the whole, Frog CMS is robust enough for me to seriously consider if for my next client project. I plan on moving away from my “bespoke” home-grown CMS and adopting Frog CMS as the norm, whilst contributing any “improvements” or updates back into the community. On the subject of icons, I found that if I don’t like something, I just go ahead and change it. That’s the beauty of Open Source. Bye for now, from another Frog convert.

Feb 26, 2009 07:41 tuupola 291 posts	i’m with martijn. i don’t favor anything that would discourage contributions. I agree. The result is the same as jQuery has. Huge amount of plugins. 80% of them are crap but the 20% are excellent. The ones which are great get the most users and become de-facto standard. For new users the only problems might be how to find the good ones.