How to write decent plugin: discussion

WP 2.8 gives to many of us an out of memory. Yes, there is a solution, increase the memory limit, but… I see that many plugins are NOT written in a way to save memory, database and processor resources.

I want write out a list of such NOT GOOD practices:

– Merge in the main plugin file the HTML and logic used in the option panel. WordPress loads all main plugin files on EACH page request. There is a hook to load the options panel when it is used by the blog owner and its code che be stored in a separate file.

– Init and activation are not the same thing. “init” hook called by WP when it loads the plugins has to be used to initialize the plugin (on EACH request) to work for that request. “activation” is a hook WP call when one activates the plugin from the plugin management system. Creation of table on databasae, directories and so on is a task to add to the activation process, not to the init process.

– Always load the text domain. Text domain are used to translate the options panel. Why load it every time the plugin is loaded. Separating the plugin code from the options panel code give a way to load the text domain only when really needed.

– Not use the is_admin() function. is_admin() is a function returning a boolean value to know if whe are or not in the admin pages. Many times plugins do different things when in the admin context or in the public context. With this function we can avoid to register hook, do queries, read file and so on which are not useful on current context.

– Save plugin options separately. WP has the wonderful functions get_option() and update_option() which can store options giving them a name. Those function can store arrays too! It’s better to store all plugin options in an associative array and save them under a SINGLE option name. This saves a lot of queries.

Other?

[ Signature moderated. ]