Plugin Template/Framework

[Angryboy]

In this topic I said that I would be producing a tutorial on plugin development from scratch. I've realised that because the process is so heavy and introduces so many concepts that shouldn't be taken for granted, it would be good to provide a plugin template or framework that goes a bit beyond what is on the wiki.

Can anyone tell me what they think of the attached templates? Neither plugin performs any meaningful task - it is about getting the flexible structure set up to actually then produce ones own plugin. The bulk of the structure is lifted from the way mvlcek organises his files.

One example is done purely in a procedural programming style. The other uses OOP techniques to provide a plugin controller that can easily be extended to have more methods; also, the plugin autoloads classes from its folder.

In short, I'm asking is whether or not these examples would actually be helpful for plugin developers (prospective, new or old) and if not, what can be done to improve it?

Thanks for any feedback and kind regards.


  yourplugin_proc.zip (Size: 3.64 KB / Downloads: 7)

  yourplugin_oop.zip (Size: 3.98 KB / Downloads: 7)

[shawn_a]

I do like that the assets are prepackaged, and lang.
although the only htaccess you need is allow for assets folders. js, css etc.

But the organization of the oop seems odd to me.

I think to benefit from this, the entire plugin needs to be class based so no globals are necessary.
And you do not need to replace yourplugin_id all over the place or use a namespace.

$uniqueID = new plugin($uniqueID);
add some stuff here version author
$uniqueid->author =
The only hook into the class could be something like register_plugin(){global uniqueID;$uniqueID->register);

I guess you would still have the same problem though with globals but you could prevent collisions with variable variables and variable function names. But you would need to handle callbacks from filters and hooks with normal functions or you might lose a argument in the process if you can only pass an action.

But another issue is that gs requirements are still 5.2.3, so alot of oop stuff might not be useable until 5.3

[shawn_a]

Every time i write a plugin I think about this and still have not gone far enough to persue it, i think someone also wrote one of these already, not the same thing but similar. Maybe it was just helpers

[shawn_a]

hmm has anyone tested hooks and filters with namespaces or classes?

[Angryboy]

I do like that the assets are prepackaged, and lang.
although the only htaccess you need is allow for assets folders. js, css etc.

But the organization of the oop seems odd to me.

I think to benefit from this, the entire plugin needs to be class based so no globals are necessary.
And you do not need to replace yourplugin_id all over the place or use a namespace.

$uniqueID = new plugin($uniqueID);
add some stuff here version author
$uniqueid->author =
The only hook into the class could be something like register_plugin(){global uniqueID;$uniqueID->register);

I guess you would still have the same problem though with globals but you could prevent collisions with variable variables and variable function names. But you would need to handle callbacks from filters and hooks with normal functions or you might lose a argument in the process if you can only pass an action.

But another issue is that gs requirements are still 5.2.3, so alot of oop stuff might not be useable until 5.3

Yeah, the OOP design pattern I've used is pretty slap-dash I'll admit. xD

So with your example, are you saying that I should wrap up the plugin registration itself into an object, or is there already a plugin object in GS for doing this?

Also, if the OOP functions might not work until 5.3, how has SimpleXMLExtended been working for the core? If there is legacy code to ensure that it works, I would be grateful to know so that I can make my code backwards-compatible too.

hmm has anyone tested hooks and filters with namespaces or classes?

They definitely work with classes (both instances and singletons). Haven't tried with namespaces yet though.

Instances:

PHP Code:

$obj = new yourobject($param1, $param2, ...);
add_action( 'hook_name', array($obj, 'method_to_call'), array($args) ); 


Singleton (static methods):

PHP Code:

add_action( 'hook_name', 'yourobject::method_to_call', array($args) ); 


Unless you mean registering hooks when in the class itself...?

[Carlos]

i think someone also wrote one of these already, not the same thing but similar.

I think you mean this: https://github.com/rjz/getsimple-plugin-template

[shawn_a]

yup I think thats it.

classes work , but some new stuff doesn't, closures, namespaces, reflection class perhaps, are all 5.3
5.3 adds major oops support to php, not just basic.

[Angryboy]

Thanks for the link, Carlos. I hadn't realised that such an extensive template already existed, let alone that it was 2 years old!

As for 5.3: here is the list of new features. Whilst powerful and useful, I don't think that GS developers would be crestfallen without them (with the exception of Namespaces).

Is it worth me still putting out a basic template for use, or do you think rjzaworski's just needs a bit more visibility on the site (e.g. a more prominent wiki link)?

[shawn_a]

Nono, I mean its hard to remember to not use them when coding, especially if your chugging along and its in your toolbox.

Of course a plugin could always say hey you need 5.3+ for this to work.

[Angryboy]

Ah okay then. I'm still not experienced enough to say that I have them in my toolbox yet. It should also be fairly easy to put a flag up within the plugin if the PHP version is too old.

Is this OOP example better now?


  yourplugin_oop.zip (Size: 3.86 KB / Downloads: 10)

[shawn_a]

Now this I like, very nice

I think classes are supposed to be in their own file with nothing else and stuff, I don't know what the code standards are, but they are just standard practices

[shawn_a]

Also I prefer the structure we have in core themes for assets and standard folder for everything else.

pluginfolder/assets/
pluginfolder/assets/js
pluginfolder/assets/css
pluginfolder/lang/
pluginfolder/inc/ (includes)
pluginfolder/lib or class/
pluginfolder/*.php ( public php html)
rootfile.php

[Angryboy]

I'd thought about doing that too. Not sure if it complicates the structure a bit for plugins, since they'll be less complex than other PHP frameworks.

Updated to reflect those changes.

[Angryboy]

Updated again. The /inc folder now has definitions for ckeditor and codemirror (lifted from the code in the /admin folder so that instances of either can be used as follows:

PHP Code:

<textarea id="yourtextarea"></textarea>
<?php
  $textarea = 'yourtextarea';
  include('ckeditor.php');          // or include('codemirror.php') for codemirror
?>

  yourplugin_oop.zip (Size: 7.75 KB / Downloads: 13)