Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2009-02-12 11:50:23

redbot
Plugin Author
Registered: 2006-02-14
Posts: 1,410

Re: Custom field improvements and hiding admin elements

Bloke wrote:

OK, my apologies to Yura for the implication.

Hey I didn’t mean your implication was offensive ;-)

Ouch! I suppose if it’s only once per install it’s not so bad, but all the same, if this could be avoided it would be better!

Sure! I was only saying it doesent need the same ‘urgent’ fixes as sed_sect

Some of the problems I bet would go away if the administration of the plugin was moved to its own tab

100% agree

Oh, that complicates things a lot and would probably require cookies, or something other than the prefs table to store which items were on/off.

I invite you to look at Yura’s code. It was not easy for me to follow at beginning but I found it’s very very clever. And it makes not use at all of cookies.
I think (if I remember correctly) that each time you load a page (e.g. the “write” tab) it fetches the db > checks the user level privileges > runs the js accordingly.

For some reason I thought the plugin was used by an admininstrator to set per-role visibility of elements, e.g. Copy Editor / Freelancer / Managing Editor / etc. I didn’t realise individual users could turn on and off admin things at will.

You were absolutely right, I didn’t explain well

In theory, yes. As you say, all you need is another field or two in each ruleset. Perhaps a field called “action”. The default could be “hide” but others could be “move to”, “move after”, “move before”…

Exactly, also unlimited “actions” should be possible with a every element (i.e. take custom_field 7 , move before the “ advanced options” div, set the background to grey and border to dotted etc..

I guess it’s just another “action”, though the list of permissable actions would probably have to be hard-coded in the plugin…

right, but consider with a few ‘actions’ (hide, hidetoggle, insert before and after, addclass toggleclass and css) you can do quite everythig form a presentational point of view.

But all this is speculation. It might be nice, but does it need to go this far? It would be very, very cool but is it asking too much to make it general purpose and make it usable? Is it better to split it into different, smaller, chunks and allow people to choose which bits they want instead of covering everything?

I totally agree, that was exactly my point, imho sed_sections and hide_in_admin can’t be merged toghether as they rely on different approaches

But at the back of my mind there’s this nagging sensation that there’s an awful lot of overlap between sed_section_fields and ied_hide_in_admin; and I hate writing the same line of code twice. If I’ve understood correctly, sed_sf is essentially a very specific version of ied_hide_in_admin; it hides custom fields on the fly if the section is blah blah. Correct? Does it do more than that?

I don’t know, I don’t think there is so much overlap but probably I’m wrong. Anyway yes, another feature of sed_section is hiding sections from the sections list in the “write” tab (for example the “search” section) – this is not tied to the on_change event but is persistent.

If so, the differences are subtle as much as they are far-reaching. They both hide stuff in response to an event, but ied_hia’s event is configured up-front and is therefore “static” (for want of a better word) whereas sed_sf’s event is more reactive, as an editor alters article contents.
Is there enough commonality to make it one plugin?

I think it will be harder to mix the two but if you can do it would be awesome

Or is a better approach to code a library — an engine if you like — that can be a requirement of other plugins. A bit like mem_form is the glue that holds together stuff like TXPhorum and other mem_ plugins, could a library of generic “admin tinkering” snidbits be coded, and then ied_hia and sed_sf can use the underlying methods to do their specific implementations of “hide/move stuff in reaction to some set of conditions”?

hmmm, bot options are good …I have to think about it

Last edited by redbot (2009-02-12 11:53:12)

Offline

#12 2009-03-12 11:38:58

wet
Developer
From: Lenzing, Austria
Registered: 2005-06-06
Posts: 3,267
Website

Re: Custom field improvements and hiding admin elements

Bloke wrote:

every visit to any page triggers the plugin callback that compares the current tab against your preferences, and either uses jQuery to switch off the component(s) or some clever mechanism to actually remove the contents from the admin side before the page is displayed.

It’s quite simple now:

# code intended only for demonstration, details subject to change until the stable release

if (@txpinterface == 'admin') {
    if ($no_i_do_not_want_custom_fields) register_callback('wet_foobar', 'article_ui', 'custom_fields');
}

function wet_foobar($event, $step, $extra='')
{
	return '<!-- nothing here, walk away  -->';
}

Same API on other tabs is yet to come, suggestions welcome.

Offline

#13 2009-03-12 16:18:26

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,842
Website

Re: Custom field improvements and hiding admin elements

wet wrote:

Same API on other tabs is yet to come, suggestions welcome.

I’m still wrapping my head round the pluggable_ui() function but it’s totally awesome that the mechanism to do this admin reshuffle is now in place. You are a God amongst men. I can see someone making a yyy_better_sections_tab plugin just round the corner :-)

I’ve yet to figure out how sed_sf can use the callback mechanism to alter the custom fields via some AJAX parked on the ‘section’ dropdown, but I’m sure with some deep thought it’s possible. Certainly ied_hide_in_admin becomes, like, a 10-line program to do the dirty work, with the bulk of it being the user interface. Hurrah!

On the suggestions front, is it possible to put pluggable_ui() to work in txplib_head/foot/html so that the output from pagetop() etc can be customised? Or is that a little too involved? I’m thinking from the smd_skin perspective it would mean that 90% of my hack could be dispensed with and we could offer a ‘clean’ mechanism for people to override the layout of the tabs and footer. Perhaps I could even put all the TXP files back where they were, so the only mod required would be the skin txp_pref (though I might then have to treat ‘default’ as a special case, which is probably no bad thing).

Just a thought.

Last edited by Bloke (2009-03-12 16:19:46)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#14 2009-03-12 23:26:53

thebombsite
Plugin Author
From: Exmouth, England
Registered: 2004-08-24
Posts: 3,251
Website

Re: Custom field improvements and hiding admin elements

On the suggestions front, is it possible to put pluggable_ui() to work in txplib_head/foot/html so that the output from pagetop() etc can be customised?

That would be really cool. I’ve been watching the latest developments with a certain amount of excitement.


Stuart

In a Time of Universal Deceit
Telling the Truth is Revolutionary.

Offline

#15 2009-03-13 00:05:30

redbot
Plugin Author
Registered: 2006-02-14
Posts: 1,410

Re: Custom field improvements and hiding admin elements

Bloke wrote:

I’ve yet to figure out how sed_sf can use the callback mechanism to alter the custom fields via some AJAX parked on the ‘section’ dropdown, but I’m sure with some deep thought it’s possible.

Bloke,
excuse me for the silly question, surely I’m missing something as I just know some very basic php and even less js.
Is really sed_section_fields using ajax? And why, given you only need some jquery to perform this operation?
And, excuse me again, what you mean by ‘callback mechanism’? Are you referring to the classic

register_callback('my_plugin', 'article');

?

As far as I know sed_secion simply hides section fields already present in the page so it does not interact with the server after the page is rendered.
I’m not sure this makes sense, if not, sorry for meddling.

Last edited by redbot (2009-03-13 01:44:14)

Offline

#16 2009-03-13 08:53:30

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,842
Website

Re: Custom field improvements and hiding admin elements

redbot wrote:

Is really sed_section_fields using ajax?

I thought it did, maybe I’m wrong.

And why, given you only need some jquery to perform this operation?

jQuery has AJAX support so yes a bit of jQuery is all that’s required if I’ve understood the function of the section fields plugin correctly (see later)

Are you referring to the classic register_callback(‘my_plugin’, ‘article’);

Yes. To register interest in rewriting the admin side you now register a callback on a ‘ui’ element. If you return anything from the given function then your output is rendered instead of the default output. It’s genius.

As far as I know sed_secion simply hides section fields already present in the page so it does not interact with the server after the page is rendered.

Ah, I thought (maybe wrongly) that, during writing an article, if you changed the section from the dropdown the available custom fields automatically changed on the fly. That’s why I couldn’t see how to register interest in the ‘ui’ callback to alter the list of CFs after the page is rendered. If that is the case then it might just need some more thought on my part. If not then you are right, a quick bit of jQuery is all that’s required.

Last edited by Bloke (2009-03-13 08:54:47)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#17 2009-03-13 09:18:16

wet
Developer
From: Lenzing, Austria
Registered: 2005-06-06
Posts: 3,267
Website

Re: Custom field improvements and hiding admin elements

Bloke wrote:

Yes. To register interest in rewriting the admin side you now register a callback on a ‘ui’ element. If you return anything from the given function then your output is rendered instead

..or in addition. Extend your users’ profiles if you wish.

Last edited by wet (2009-03-13 09:18:42)

Offline

#18 2009-03-13 10:57:05

redbot
Plugin Author
Registered: 2006-02-14
Posts: 1,410

Re: Custom field improvements and hiding admin elements

Thanks as always for the clear explanation, now I understand the pluggable_ui thing and its very cool!
Anyway, regarding the sed_section_fields question I meant that yes, it uses jquery but not the jquery ajax functions.
The “write” tab is simply displayed normally and then with jquery (without ajax) a css display:none is added. In other words if you look at the html source hidden custom_fields are still there, they’re just hidden.

Ah, I thought (maybe wrongly) that, during writing an article, if you changed the section from the dropdown the available custom fields automatically changed on the fly.

Once again, while you talk about ‘available custom fields’ I would say ‘visible custom fields’…

At the end I don’t think you’ll have time to waste with this (and rightly so) , but just in case, if you feel a little masochistic, have a look at this plugin I desperately made the same day wet fixed sed_section_fields. It lacks an interface and is configurable adding some values directly in the plugin code but just makes the same thing sed_section does (and even something more) in a few lines.

Offline

#19 2009-03-13 12:11:41

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,842
Website

Re: Custom field improvements and hiding admin elements

redbot wrote:

Anyway, regarding the sed_section_fields question I meant that yes, it uses jquery but not the jquery ajax functions.

Which version are you using? When I change section in the Write tab (using wet’s fixed version) Firebug indicates that the plugin sends a real-time (ajax) request to the server which results in some of the custom fields either hiding or displaying. It might not be using jQuery to do that (haven’t looked at the code).

But anyway, I just thought about it and technically it doesn’t have to do that; it can function exactly as you suggest. Simply set up the various rules server-side as net-carver does now, then download the entire section->CF mapping on the Write tab to a javascript array. Then it’s a simple case of hooking an onchange to the section dropdown, looking up the currently selected section in the js array and applying display:none to the given custom fields. No ajax, just a line or two of jQuery, as you say.

The (minor) downside is that if you change the configuration on the server you’d have to refresh the Write tab for the changes to take effect but that’s a small price to pay for the simplicity.

In fact — my mind’s in freewheel right now — a good use of the pluggable UI could be to initially ‘rewrite’ the custom field area so that the custom fields appeared in a specific order. Sometimes a new requirement appears that results in having to add CF8 about six months after a project started. CF2-CF7 are used in many articles, and I wish I could place CF8 next to CF1 because it’s kind of related. Now we can do that kind of thing really easily — hooray!

Last edited by Bloke (2009-03-13 12:15:12)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#20 2009-03-13 13:28:33

redbot
Plugin Author
Registered: 2006-02-14
Posts: 1,410

Re: Custom field improvements and hiding admin elements

Bloke wrote:

… When I change section in the Write tab (using wet’s fixed version) Firebug indicates that the plugin sends a real-time (ajax) request to the server which results in some of the custom fields either hiding or displaying. It might not be using jQuery to do that (haven’t looked at the code).

mmm… yes, probably you are right, I can’t check now, anyway I never understood why it should be sending request to the server as it is completely useless in this case, given that you can achieve the same result with simple server-side jquery.

Though I’m happy to hear about the new pluggable_ui I don’t think it will be so useful for adding a functionality similar to sed_section_fields. In fact this plugin has an unique peculiarity as it depends on a on_change event, related to a select element, which must operate after the actual html is rendered. So I don’t see the advantages of pluggable_ui (which operates server side) in this specific case.
Sure, now you’ll be able to use ajax to send a request everytime you change a section in the dropdown to make the fields disappear (and not simply hide) from the html but it’s worth it? It would be at the expenses of speed and probably the effect wouldn’t be so nice with slower connections.

Conversely, a plugin like ied_hide_in_admin could take great advantage from the new features as – in this case – the plugin can operate before the html page is rendered and you can get a ‘perfect’ html page witout the initial ‘flash’ in which you see the complete page.

…a good use of the pluggable UI could be to initially ‘rewrite’ the custom field area so that the custom fields appeared in a specific order…

Yes, that would be another good use of pluggable_ui, I already do this with an homemade plugin using jquery but, again, taking advantage of pluggable_ui the end result would be a lot faster and cleaner.

Last edited by redbot (2009-03-13 13:29:54)

Offline

Board footer

Powered by FluxBB