[Discussion] "Hello World" Redux (towards a possible Plugin SDK)

[Angryboy]

I like the idea of a 'Hello World' plugin for GS (especially since so many other libraries, CMS'es, and web-related stuff have one). I don't like the idea of having a 'Hello World' plugin in which the functions demonstrated are not in the GS core. In that sense I would rather consider this plugin to be just a plugin SDK in which an elaborate example is included about the use of the plugin. So basically I say "YES!" to all features you mentioned in the intro post, but "NO" to mixing the last feature with the preceding ones.

I like the OO approach, but expected to see in the code a working example with elaborate documentation about core functions like add_action and its different parameters; how to load scripts only on your own plugin page; how to implement your own hooks (so other devs can hook into them); how to use the init function; how to split your code into different files: etc. (for the record, I know how to do all this but took some effort finding out first).

Plugin Toolkits are great (and there already is one), I just don't think it's good to mix them up with a plugin that is meant to demonstrate the very basics of building a plugin.

Good insight, and I'm open to critique here.

The original Hello World plugin and the existing wiki illustrates a plugin simple enough to start grasping the basic functions, actions and hooks available to the developer. It doesn't show how to extend the plugin into something real-world usable (e.g. as soon as you start wanting to add i18n hashes, it introduces variable scoping issues and doesn't have a real solution beyond using globals).

Basically, every plugin developer is forced to make their own wrapper of sorts, or implement their own solution around the problems that immediately start appearing when extending the Hello World plugin. I'm not sure how best to illustrate the uses of all of the core functions without either showing an example plugin with its own wrapper (e.g a HelloWorld class), or with a plugin that uses global scope (or singleton objects, which can scare off some people).

So no matter how it is diced, plugin development with just the core functions is troublesome, and I suppose I don't know how best to introduce newcomers to the fun parts of development without detailing my own hacky solutions or abstracting them away from those implementation details entirely.

As for the functions not currently being core, I agree that it is not ideal. I've opened an issue on the GS github page about exposing a lot of these functions in a possible release, and shawn_a seems to have it penned for an eventual milestone. Until then, the best we can do to facilitate code reuse is to have a wrapper or polyfill for these methods.

And this example is unfinished and still in need of full documentation on the cases that you've said. I've submitted it now to see if there were any immediate no-nos as to its structure/conception (and again I'm glad to hear your responses).

I really like this, it will give some much needed OOP-ness to plugins, but I don't think that dropping a lib folder into each plugin folder is the way to go, it should rather be built into the core so that every plugin just references once fileset instead of having it fragmented, but until that is in place, I will probably be using this or a modified version of it in the future.

Keep it up

Again, a /lib/ folder is not ideal for the reasons discussed above, but more complex plugins might employ other PHP libraries. A /lib/ directory gives a focal place to store all class-based scripts, and allows for easy autoloading integration (eventually).

I advise against using the example as-is now, because this is still experimental. People may vastly disagree with the design principles shown, and it would be a shame to have to rewrite your code later if this tanks.

I suppose the main thing to take away from both of your comments is that there is concern over what the example plugin should illustrate, and what the eventual SDK should consist of (and how separate it should be from the example). Obviously the SDK should be fully documented and elaborate more than the example plugin. How  much should be shown in the Hello World example to keep it simple and accessible, but demonstrative enough to be a useful starting point?

Also, should this topic be moved to Developer Discussions?