10 comments

• 

  wesley

  10 months ago

  Thanks, this is interesting. I've been thinking about cross platform plugin support.
  reply
• 

  Rick Cockrum

  10 months ago

  Nice comparison of some of the differences between writing WordPress and Habari plugins.
  
  You are quite right about Habari's documentation on writing plugins being a little thin right now, but there is an introduction to writing plugins on Habari's wiki, as well as a list of Habari's plugin hooks that makes the job of finding what to hook into to accomplish a task easier.
  reply
• 

  skippy

  10 months ago

  Excellent introduction! We know that the documentation is weak right now. The API is really starting to settle down, so now that it's less of a moving target documentation will get a greater priority.
  
  And of course, you're invited to help us generate that documentation! Your introduction here demonstrates a terrific understanding of what new plugin authors need to gain proficiency.
  reply
• 

  Matt Read

  10 months ago

  "With Habari you must have a folder and the plugin file must share that name, using the format [folder name].plugin.php. This is important as it is part of the system that finds and runs plugins."
  
  Actaully that is not true. You can name the folder anything you want and the plugin file [anything].plugin.php. So you do not need to make them match.
  
  And this is a great post! Thanks for doing it. And nice idea about the plugin wizard (can you make it use tabs instead of spaces ;) ).
  reply
• 

  mikelietz

  10 months ago

  Thanks!
  
  I'm looking forward to the plugin info for adding to the admin pages - thinking about creating a theme/plugin editor for the admin.
  reply
• 

  Andrew Rickmann

  10 months ago

  @Wesley, I have thought about it but I am not yet convinced. There could be a lot of work involved. I am going to look at converting one or two over though just for the practice.
  
  @Rick, Thanks for linking to those pages. I have been using those and really should have linked to them in the article.
  
  @Skippy, so far I haven't done anything that isn't documented but once I do I will certainly look to add to the documentation.
  
  @Matt, thanks for the clarification. The documentation suggests that it is required although it doesn't state it outright. Consider the tabs done as of the next update.
  
  @Mike, I am looking forward to the admin pages bit a lot as I think there are UI helper classes, which means I won't have to write any.
  reply
• 

  Ali B.

  10 months ago

  "I am looking forward to the admin pages bit a lot as I think there are UI helper classes, which means I won’t have to write any"
  
  Yup. FormUI takes care of the GUI and whatnot for the plugins configuration. In fact, even the admin pages (the publish page for example) use this class to construct and handle their GUI. It's pretty cool.
  
  Thanks for the enjoyable article and the detailed comparison. It sure sheds some light on how robust and easy the plugin system in Habari is. And great job on the plugin generation tool, that's neat!
  
  We sure could use your help to make the documentation better. I agree with skippy that you show a great deal of understanding on what potential plugin authors might need.
  
  You can always stop by at #habari on freenode if you need anything.
  reply
• 

  Owen

  10 months ago

  Nothing like writing about Habari and getting the PR squad showing up at your doorstep!
  
  I have only a couple of minor thoughts to add to your excellent post.
  
  Habari also allows you to manually register functions/methods as plugin sinks using the Plugins::register() method. This could be useful for when you want to do only one of multiple things based on a configuration option, and register only the correct function. Of course, you could just as easily do this with a switch() within the automatically registered function.
  
  The filter_post_content_out() function is interesting in that it affects the output of $post->content_out. $post->content contains the actual post body content. Adding the "_out" suffix allows it to be modified by that specific filter.
  
  Using this mechanism, you can create multiple suffixes that filter in different ways. You could, for example, output $post->content_summary and then code a plugin function filter_post_content_suffix() to alter just that output. If a filter for a suffix doesn't exist, it just outputs the full content, so nothing breaks. This can be useful for outputting post archive listings specially for just the archive pages, or on any page.
  
  This bit of functionality is probably not documented well because we're (at least I am) expecting it to change slightly to improve filtering and output support, but that's how and why things are named as they are.
  
  I'm looking forward to part 2!
  reply
• 

  Andrew Rickmann

  10 months ago

  You're not wrong Owen. I had heard about the community ethos surrounding Habari and, PR aside, I got a glimpse of that.
  
  I must admit to jumping into the plugin writing before reading all the getting started stuff. Having read into it more I am starting to understand how the filters work. It makes it very easy to look at the template and filter what you want.
  
  Is there a trac ticket somewhere that explains how it might change?
  reply
• 

  Owen

  10 months ago

  There aren't any concrete plans for this right now, but the idea I came up with and we had discussed a bit can be found in this recent mailing list post. The change would basically be to go from echoing $post->content_out to echoing $post->content->out, and would extend to more of Habari's intrinsic objects. But keep in mind that this isn't finalized, so it might change before it's implemented or not be implemented at all.
  reply