• How about a proper plugin archtecture? I know there are lots of hacks and the like, but shouldn’t this be simplified to a case of uploading a file to your server? At most unziping somthing in a directory? Or am I missing something?

Viewing 3 replies - 1 through 3 (of 3 total)
  • In v1.2, there is a plugin architecture. Look in the wp-contents/plugins folder for the plugins which ship with the version. Look in the “admin” section for the “Plugins” menu to activate plugins.
    I’m anxiously waiting for some documentation for writing plugins. It looks as though those details are being held closely by the WP developers at this time. Once they release the documentation, I imagine we’ll begin seeing a steady stream of enhancements to the WP experience.
    <rb>

    Thanks for the link to the documentation, though I think I am more depressed now that I can see the whole list….
    There are far too few plugin hooks in the current system.
    Some places that DESPERATELY need hooks are:
    The Write/Edit pages. Plugins need ways to insert control data into the editor for posts, particularly to modify the way the custom meta data is displayed. For example, I want to create a plugin that allows for mood and music to be set on a per post basis. Because I want the moods compatible with LiveJournal (for a LiveJournal update plugin) I need to make sure that if the user wants to use a predefined LJ mood that I can get the right moodID for it. This is best interfaced by having the user be able to choose a mood from a drop down list and storing that in the meta data for them, rather than them adding a Custom Meta data key/value pair in the advanced interface which is a downright terrible user interface.
    ‘the_meta’ filter isn’t displayed by default in index.php. It would be very good from a Plugin Standpoint to have ‘the_meta’ as part of the default index.php, possibly with an option in the Blog Settings to wrap the meta in HTML comment tags turned on by default. That way you won’t get weird meta data (which I think ‘the_meta’ prints as a UL?) in all of the posts, but plugin developers could massage that to look nice without telling people to hack index.php. While you are at it, make the UL formatting a filter so that a plugin developer can use remove_filter on it so that we can get the raw meta data, or just drop ‘the_meta’ formatting altogether as a built in function and turn it into a plugin.
    It would be nice to be able to store meta data for other things besides posts. Links, Categories, and User Profiles come immediately to mind. This would allow plugin developers to do things like have a custom color per category. Or maybe store a custom CSS style per user who logs in to the site. If this custom data is already available, I apologize in advance for being ignorant of it.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Plugin archtecture please?’ is closed to new replies.