Posts Tagged ‘wordpress plugins structure’

WordPress Plugins – Developer’s Dream

February 1st, 2010 by Keith from shrewdies | No Comments | Filed in Function
I searched for WordPress Plugins that would help me apply structure to my own efforts.

A scary journey, but now the nightmare is over.

Now I can dream happily of a bright WordPress development future.

But, there is no time to dream. Not even time to hack together a pretty picture to decorate this article. I’m fired up for developing, but there is just enough time to let you know what the plan is.

When I finally decided on the SCB framework, I sat down to plan how to integrate my menu system, a hack of DashBar, into that structure. It looked like a project that might also suit Pods, as I would need somewhere to store menu item links.

What’s the first thing I notice in SCB? Routines to handle WordPress options and table data. But can’t I just use Pods for that?

Yes, I can!

(more…)

Tags: , , , ,

WordPress Plugins – Beginners Nightmare

December 22nd, 2009 by Keith from shrewdies | No Comments | Filed in Function

WordPress plugins are vital for efficiently functioning websites.

WordPress Plugins Structure Nightmare

WordPress Plugins Structure Nightmare

Given their importance, I would expect much more effort going into helping new plugin developers get to grips with plugin structure.
 

The WordPress development team resist adding features to the core if they are not universal requirements and can be dealt with by plugins. This is a good thing, and they have recently announced plans to develop “canonical” (i.e. official) plugins to “address the most popular functionality requests with superlative execution”[1].

Significantly, these will be “the best possible example of coding standards”[1]. But just what are these coding standards that are deemed so important?

The first thing I want to do when I write a plugin is adopt a structure that:

  • Is the most efficient in terms of performance (i.e. no redundant code, especially admin code loaded for all users)
  • Uses core WordPress functions and methods instead of home-grown alternatives.
  • Uses latest functionality and best practice, avoiding deprecated functions and methods.
  • Is familiar to the majority of plugin developers.

It’s the last point that induces the biggest nightmare. Official coding standards[2] focus heavily on inline documentation and formatting[3][4]. This is all very well, but we need good examples that clearly show best practice in how to organize code in modules. Which bits are best in separate modules, and how should they be organized in sub-folders?

It speaks volumes to me that (more…)

Tags: ,