Geeklog Forums

I want to write a manual on how to write the perfect Plugin. This manual is an adition to the universal plugin which is quite out-dated IMHO.

So the question at first would be: What are the features of a perfect plugin?
When this list is somewhat complete I will add this to the documentation Wiki and maybe release a new universal plugin to make this here much easier for everybody to achieve. Any help of course is appreciated.

I have a list here, please kindly add to it!

1. 100% of all displayed text has to be in the language file or in the database. The name of the plugin (except the folder), all buttons, admin interface, Page titles, Block titles.. everything that not editable through the interface goes to the language file!

2. There has to be a maximum of usage of the plugin API (where applicable):
- Search
- stats
- what's new?
- bb-code ( [plugin:id linktext] to link to the items in the plugin)
- submission

3. All text that is entered has to go through the html & censor filter, and has to have the html/txt chooser

4. All plugin-api functions have to have a possibility to be switched off from withing the plugin or a config file (is there a what's New or not?), and all of them have to set the amount of entries in the same way, as well as the time gap of the what's new block etc etc

5. Each item in the plugin has to have a geeklog standard-ID (makesid) that can be replaced by user-editable text (just like static pages & stories)

6. The plugin has to have a working install, uninstall and upgrade function

7. Each data component has to have full user access rights management for each main item in the database, ideally also a possibility to choose who can see the stats, who can submit, etc etc

8. The size of Text-area-forms should be able to be set from an interface or a config-file.

9. the functions created for the plugin should be named after the plugin to prevent programm errors when two plugins use the same names for functions (Example: function plg_myplugin_deleteitem() )

10. The page title should always be set by the plugin's current content (in other words the title of the current item displayed)

11. Direct Links to main items in the plugins should be called only with one variable in the get-statement (example: /myplugin/index.php?get_id=132444 instead of /myplugin/index.php?get_id=132444&option2=23444)

I wish I could add to your list but it looks like it covers everything I can think of

on a great idea that will help others to develop a new line of Geeklog plugins.

Robert

---

Geeklog Polish Support Team

The universal plugin does need updating badly. Some more suggestions.

1) Configurable install directory

2) All plugin API functions stubbed in and example code given.

3) Further automate the code for install/uninstall/upgrade so the developer only has to fill in arrays.

4) Create some other standard functions like logging.

5) Make different levels of text filtering based on user privileages. e.g. Allow admin to use any html.

6) Standard interface in and out to geeklog filtering routines for all data saved in database. In other words make one call filter html, do html transforms, filter css scripting, sql injections, process links, etc.

I applaud the interest but I wonder if you have read the Plugin Developers Guide. I know it's outdated from a perspective of having documented details on the new API's but Tom and I wrote this over 2 years ago and I really wonder how many times it's actually read or referenced.

Many just dig in but this was written after we struggled and became aware of the details and were self-sufficient. It includes an overview and best practices and details the installer/de-installer. There is alot of information and tips in the guide but it could use a major update for the API's. It's been on my list like many items for the past year

Personally I have the installer and de-installer working for a new plugin in about 10 min. It's the easiest part of developing a plugin.

You may want to extend the best practices. My development style and techiques have changed dramaticaly as well since writting and continue to improve.

---

Geeklog components by PortalParts -- www.portalparts.com

Blaine,

your documentation is nothing to argue about. However, if I am deriving well from my own style of programming and some issues I have seen in the plugins I downloaded, it might be a good Idea to base a plugin much more on a sample application where you have to fill in some variables rather than a manual that you read and then start programming from scratch.

Your documentation is an excellent refference, and I think it should be a part of the code comments inside a nwe universal plugin.

When I wrote "Manual" on the first post I much more meant a guide on important features and guidelines than an in-detail technical refference. For that, I would rather see a sample application than a manual. Having that guide, it would be a model on how to re-build the universal plugin. sorry for beeing so unspecific.

under best practices I would like to see everything that is configurable be so from the UI rather than having to edit the config file, ie, put configuration in the database. I'd like to see that for geeklog as well, but that is simply an impractical wish based on the sheer number of things to configure.... or is it?

but seriously, the user friendly plugin (It seems that is what you're aiming at) should be idiot proof. By that I mean that it shouldn't be assumed that end users know anything at all about how, for example, to properly add an item to an array. Most idiots, on the other hand, can tick a checkbox if given proper instruction.

one major question is if this includes the installation of the plugin.

generally I would like to have 100% of all options. in the database too

yes yes. obviously pre-installation there can be no admin panel in which to tick a box. any configuration directly influencing the installation, e.g., directory structure, needs to be specified in the config file, which I do not suggest getting rid of altogether for this type of reason

But on the same hand, default values should take care of things there once again ensuring that the plugin will function once installed without necessary file editing from the end user.

Another best practice I'd like to see for the sake of idiot end users, of which kind I often am, is effort applied to documentation--not only howto's but also troubleshooting. One should be know enough about his/her app to be able to supply answers for the most common issues that may arise.

Two things I haven't seen mentioned:

1. Support for (Geeklog's version of) URL rewriting


2. Spam filtering (if it allows users to make submissions of one form or another)

bye, Dirk

I was just searching for a post dealing with this issue and came across me offering to update the universal plugin. oops, guess I forgot.

/me goes thru his files for any work done on it...

Knowing what you app can do does not really mean you know what a noob can do wrong with it.

you guys should be happy to hear that in my work to turn all of the core peices into plugins i am also moveing there settings from the config file over to the database. with admin pages (minus settings that cant go in the database like where the database is and how to connect to it hehe

---

glFusion - Technology Fused with Style - www.gllabs.org