Make WordPress Core

Opened 16 years ago

Closed 16 years ago

#5429 closed enhancement (wontfix)

Wordpress Plugin Framework: Simplication and Standardization for Plugin Development

Reported by: husterk's profile husterk Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.3.1
Component: General Keywords: Wordpress Plugin Framework plugin-management
Focuses: Cc:

Description

There are many plugins available for Wordpress. However, all of these plugins are being created haphazardly. These plugins offer various types of administration schemes and usage methods.

To resolve these issues, I have developed the Wordpress Plugin Framework (WPF). This framework is an attempt to commonize the development and deployment of Wordpress plugins in order to make this great web development tool even easier to use.

I have attached the latest release of the Wordpress Plugin Framework files. This attachment includes the core WPF files as well as a simple plugin used to demonstrate the usage of the WPF.

Please feel free to contact me at husterk@… if you would like to discuss this further. Thanks! - Keith

Attachments (1)

wordpress-plugin-framework.0.04.zip (173.8 KB) - added by husterk 16 years ago.
Wordpress Plugin Framework v0.04 with Example Plugin

Download all attachments as: .zip

Change History (7)

@husterk
16 years ago

Wordpress Plugin Framework v0.04 with Example Plugin

#1 @husterk
16 years ago

UPDATE: The current design of the WPF has some limitations (i.e. each instance of the WPF class must be renamed to a plugin specific name in order to prevent duplicate class instantiation errors) due to the lack of namespace support in PHP4. However, if the WPF core files could be integrated into the Wordpress core (or at least the core plugins folder) then these limitations would be lifted.

#2 follow-up: @darkdragon
16 years ago

Your API is actually quite sexy. However, I think an adapter model would be better instead of using inheritance.

I would rather use your class and apply a Template class to change the look and feel than to have it hard coded in the class itself. If you did it that way, then it would be possible for me to use your class, apply my template, and add my options.

#3 in reply to: ↑ 2 @husterk
16 years ago

Replying to darkdragon:

Your API is actually quite sexy. However, I think an adapter model would be better instead of using inheritance.

I would rather use your class and apply a Template class to change the look and feel than to have it hard coded in the class itself. If you did it that way, then it would be possible for me to use your class, apply my template, and add my options.

I definitely agree that it would be useful to follow the adapter pattern. However, the WPF is attempting to standardize the backend (i.e. administration interface) for Wordpress plugins. One of the issues I have with most of today's plugins is that no too look or behave the same. Each plugin requires a special process to administer and use. Since the WPF enforces a specific administration process the plugin developer will no longer need to design a custom administration interface for each plugn that he / she builds. This will allow the plugin developer to focus more on the actual intent of the plugin and less on the common plugin development tasks.

#4 @santosj
16 years ago

What I'm saying is that you can still do that by using your class as the main API, people would still have to conform to your system, because you would have interface classes (as oppose to just interfaces, if you know what I mean), which the plugin author would extend. It would the methods prototype and return defaults.

Then every plugin would just need to instantiate your object and use the API to add their options and whatever else is needed to build the pages. The plugin author won't have conflicts, because the object will be their own.

#5 @darkdragon
16 years ago

  • Keywords plugin-management added

This might go well with another ticket. Will find ticket and post it, but basically it has to do with an options page.

I was thinking that working this ticket and the other ticket in together would allow auto creating a page with options designed and managed by this ticket with the link created by the other ticket.

The other ticket would create a link to the options page, this ticket would allow for the simple creation of the options page. The plugin author won't need to use this ticket for the configure link to work.

It is more work than it is worth sometimes and I know that I created something like this when I created my options page for a plugin I created.

This is a really good idea, but I don't know locking the plugin author in with one way is a good idea. The plugin author should be able to refine how they create their options page.

It should also be assumed that others won't know how to work with objects. A procedural library would also have to be supported.

#6 @santosj
16 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

No traction in 7 months. Good idea, but I don't think it is useful, either you know how to do all of the stuff, or you don't. If you don't, then you should either learn, or get someone else.

Note: See TracTickets for help on using tickets.