[wp-hackers] Modifying admin forms via plugins

Sat Jul 24 12:49:57 UTC 2004

Hi,

I know this thread is a month old, but I just got on the train and I 
feel I have something to add.
I have only read about 2/3 of the june archive so far, so bear with me 
if you discussed this some time in July (it'll probably take me a couple 
of days to read all the archive mails).

Stephen O'Connor wrote: 
(http://wordpress.org/pipermail/hackers_wordpress.org/2004-June/000221.html)

>Two things about this thread bug me.
>
>First, the additioanl hooks. So far most of these examples can be solved
>using the DOM. Yet people don't like the DOM... Um, tough? I personally
>would like the devs to work toward more meaningful goals than adding hooks
>to every three lines... How about an action/filter registry in WP? This
>would GREATLY help with backwards-compatibility.
>  
>
As much as I love DOM and javascript for dynamic content, I think that 
modifying a page on load is unsightly, when the content is actually 
meant to be static. Besides that, there's obvious fact that proper 
support for DOM javascript bindings is a pretty recent thing.

Anyway, I don't think it's necessary for the devs to add hooks every 
three lines.
I think it could be possible to define insertion points outside of the 
source files in a way that could work across versions and without making 
changes to the source files.

We could make "insertion point" plugins (henceforth IPP) that are 
helper-plugins, which have functionality in them to identify the correct 
place in an existing file to inject code.
When a programmer needs to inject code at a certain point, he'll try to 
find an existing IPP he can use, and if there is none, write it himself.

What I suggest is this:

1) Add ob_implicit_flush(true) and ob_start('ipp_filter') to the header 
of the admin pages (this caches the entire page and runs it through the 
function ipp_filter before sending it on to the client).

2) In ipp_filter we take our list of installed IPPs and see if there are 
any of them that are interested in the current file in it's current 
version. If that's the case, and the IPP has had any hooks added to it 
(if some plugin is using the insertion point), the IPPs 
$myIpp->inject_markup method is called, and it uses a regexp or 
something similar to find the correct place in the output to inject it's 
own markup.
At this point, it runs the hooks from the plugins using this particular 
insertion point, and gets markup to inject from each of them (we might 
want some kind of priority system might be made so you can try and 
decide in what order they are injected).
The inject_markup method makes sure to wrap each injected block of mark 
up with some predefined comment strings that makes it possible for other 
IPPs (that might be called subsequently by ipp_filter) to ignore 
injected markup when looking for it's own injection point.

If you had an injection point called "QuickTagsBar" (for example in file 
ipp_quicktagsbar_wp1.3-pre.php), you would hook your own plugin into the 
insertion point with something like:

add_filter('QuickTagsBar', 'myownpluginfunction', 10);

ipp_filter($document) would then run through it's list of IPPs, getting 
IPPs name and doing an
apply_filter('QuickTagsBar', $document).

You will have to excuse if the code is flawed - I am stil a bit new to 
the hooks and filters.

I know running a series of regexes on the output of every page is a bit 
heavy, but since insertion points are - as far as I can tell - mostly 
needed in the administration interface, I think we can afford to make 
the code required heavier than we could if it would have to run at every 
public page view.
I doubt it makes much of a difference unless the server is either 
insanely slow, or you have a several hundred injection point plugins 
with at least one plugin using each.

IPPs should be versioned and version sensitive, so it's never a problem 
to include it in a plugin. An IPP could be named with a formatted 
version number, so you could have several versions in your plugins dir, 
and wp would choose the newest.
Alternatively, an IPP could have a one-to-one correspondence with WP 
release numbers, so you would just include the insertion point plugins 
for the WP version numbers you want your plugin to work with.

IPPs should not show up in the plugins list. They would be automatically 
active when in the directory, but they would do nothing that required 
any processing power if there were no plugins hooking into them.

If this entire idea violates some kind of wp principle I don't know of, 
please excuse me with the fact that I am new to wp. I am very open to 
criticism as long as it's argumentative.

Comments are very welcome :)

/Brian

>And the plugin extensiblility/configuration/gui thing? Didn't I already do
>that? Somebody even mentioned "framework" in this discussion, which is
>perfect cause guess what I called it!
>
>http://stevarino.com/wp/framework/
>
>Anyway it's .1 now, and it's probably going to mature to 1.0 in a day or two
>with some minor changes, cleanups, and improvements. If you don't take it
>seriously now, then you should check out my static-posts plugin that
>utilizes the framework (again, to be released in a day or two). I really
>like my framework and think it has some real potential. Check out these
>screenshots if you don't believe me (these are from my upcoming plugin)...
>
>http://stevarino.com/wp/fakedfolders/img1.jpg
>http://stevarino.com/wp/fakedfolders/img2.jpg
>
>(all of that is in one file too!) :)
>
>The idea is super-user friendliness and maximizing modularity. I don't
>define 50 unique functions for this to work, just a normal plugin function
>and a new plugin class. Inside that class is where I store the UI, install,
>uninstall, and other methods to make it really easy for a user to figure out
>what's up.
>
>I'm not declaring this as THE PLAN, but I've yet to hear a better idea. So
>far Jason is the only one to comment on it. :\
>
>Have a good night!
>- Stephen
>
>-----Original Message-----
>From: hackers-bounces at wordpress.org <http://wordpress.org/mailman/listinfo/hackers_wordpress.org>
>[mailto:hackers-bounces at wordpress.org <http://wordpress.org/mailman/listinfo/hackers_wordpress.org>]On Behalf Of Alex King
>Sent: Tuesday, June 22, 2004 7:28 PM
>To: hackers at wordpress.org <http://wordpress.org/mailman/listinfo/hackers_wordpress.org>
>Subject: Re: [wp-hackers] Modifying admin forms via plugins
>
>
>A little extra work by the plugin developers is better than a little
>extra configuration for end users.
>
>Your plugin doesn't need an extra file for settings, you can store the
>configuration settings in the database and use the form to manipulate
>them. This is even more friendly for the users. :)
>
>Maybe I should do a proof of concept when I get some time (if no one
>else has by then).
>
>--Alex
>
>http://www.alexking.org/
>
>
>On Jun 22, 2004, at 5:23 PM, Jason goldsmith wrote:
>
>>/ it seems
>/>/ silly to force plugin writers to do that or to have a big block of
>/>/ code surrounded by an if statement to check if the plugin file is
>/>/ being called via the plugins.php page or it is being called by another
>/>/ page and therefore needs to execute.
>/
>
>_______________________________________________
>hackers mailing list
>hackers at wordpress.org <http://wordpress.org/mailman/listinfo/hackers_wordpress.org>
>http://wordpress.org/mailman/listinfo/hackers_wordpress.org
>