[wp-hackers] Question about the architecture of the admin widgets.php
skeltoac at gmail.com
Tue Jan 5 02:33:30 UTC 2010
On Mon, Jan 4, 2010 at 5:59 PM, John BouAntoun <jbouantoun at gmail.com> wrote:
> On Tue, Jan 5, 2010 at 9:45 AM, Andy Skelton <skeltoac at gmail.com> wrote:
>> Study the way WordPress modifies the behavior of TinyMCE. Then do as core
> It's not so much about modifying the behaviour of TinyMCE, which I think
> I've figured out, but am open to suggestions. The issue is that since the
> widget admin screen was cleaned up in WP circa 2.8 (to support auto
> multi-widgets), the widget options forms are preloaded and saved using
> boiler plate code that isn't complex enough to understand how to extract the
> html form a rich text editor, which is why I needed to play silly buggers
I dug deeper. It's been a while since I parsed jQuery core and
live/die are new to me. They are cleverly efficient but not very
friendly for creating exceptional behaviors in matching elements.
The jQuery serialize function boils down to "return elem.value;". I
was hoping for something like PHP's __get magic method but I couldn't
In both 2.8 and 2.9 the core logic assumes your form elements have the
intended values by the time you click Save. The problem is that
TinyMCE doesn't do that for you. But if you could guarantee your form
elements had the correct values prior to the click event you would
have the save problem solved.
I don't know whether you can trust the editor's blur event with
TinyMCE.triggerSave() but if so, that would be an elegant solution.
None of this does anything about the broader issue: you don't have
simple control over the order of bound events, as in the queue you
proposed, which reminds me of the core filter/action system. jQuery
doesn't let you bind with priorities the way WordPress does. That
would be a nice feature.
There may be an audience for this sort of thing but, as you have shown
in your solution, there are already ways around.
More information about the wp-hackers