Custom field improvements and hiding admin elements

renobird · 2009-02-11 04:55:42

OK. I know the body is still warm
but with netcarver’s departure (and sed_section_fields not currently working in 4.0.8) I’d like to bring to discussion 2 plugins whose functionality seem fitting for the core. I’m sure they have been mentioned (at probably shot down before).

sed_section_fields – let’s you create meaningful custom_fields
ied_hide_in_admin -I’d bet anyone who builds client sites uses this.

Thoughts?

—
Tom

Last edited by renobird (2009-02-11 04:56:19)

redbot · 2009-02-11 10:11:23

Tom,
yes this has been my first thought when I woke up after the orrible this night nightmare.
For me – and I think for everyone which uses txp professionally – it’s not even imaginable to build a site without sed_section_fields. And the same is true for the MLP in case of multilingual sites. We absolutely need to make something to continue the development of these two plugin. Period.
For what concerns me I will try hard – given my limited programming skills – to see if I can find a way to surrogate in some way sed_section plugin with jquery even if I know it won’t be an easy task. I hope someone with better skills will take care of theese plugins.
Other than that, I don’t know if it’s possible to imagine some sort of community driven development, but I really hope so.

Bloke · 2009-02-11 12:16:01

I’ve considered patching sed_section_fields but it’ll take a bit of work since I don’t know the code. Got a few other plugins in need of attention this week.

The thing that concerns me — has always concerned me — about the plugin itself is that it breaks so easily with admin-side changes. It’s no fault of the design, it’s just the nature of hooking into stuff that may or may not be there tomorrow. I have the same hassle with smd_remote_file.

If the Sections tab goes the way of the other tabs — as has been hinted — I’m not sure how easy it will be to build a plugin such as this onto that tab, as it’ll need to somehow be integrated into a table. Thus, any work taken to fix it now will need constantly tweaking as the admin side is altered.

The same goes for ied_hide_in_admin. A great idea but very prone to breaking with the slightest change to class/ID/position of elements on the page.

I would suspect — but can’t be sure yet — that a better approach might be to break sed_section_fields out to its own tab under the, now very crowded, Extensions tab. Display a dropdown of the current sections in the site and then a bit of AJAX can grab the info for any chosen section from the database. A Save button is then all that’s required… umm, I think. Perhaps those more well-versed in the plugin use model could put me straight as I may have missed the point.

With ied_hide_in_admin my preferred approach would be to have a lookup table containing:

“widgets” that can be switched on and off
their “position” on the page (e.g. class name, ID, closest object with suitable name, etc)
the manner in which the widget relates to its position (is it a child of it, before it, after it, and so on)

Once that table is established it is a simple case of iterating over it, displaying each widget name and some radio buttons/checkboxes and perhaps allowing ranges of things to be selected like you can on the article tab. It would perhaps be cool to sub-divide the list into Tabs as well and you can twist up/down the relevant tab so you’re not presented with the entire list in one go. Not sure.

Again, a Save button commits the changes to the database and then 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. I’m not sure which method the plugin currently employs, nor what people’s thoughts are on either system.

Once the pain of creating the initial lookup table has been done, the beauty of it is that the plugin pretty much looks afer itself until, well, the admin side no longer uses HTML :-) With each new release of TXP/SVN, any changes can be made to the file/table and that file simply “installed” on your server. Perhaps some mechanism of installing it from the plugin’s Extension tab itself so you don’ thave to get your hands dirty with FTP?

Anyone with a modicum of javascript/HTML/CSS knowledge and/or a copy of Firebug can easily figure out the necessary changes to the file and post it on the plugin forum thread, thus giving control of the admin side widget list to the community rather than a single plugin author. Keeping the plugin code separate from the display mechanism is something that fits nicely into the TXP ethos as well. Further thoughts?

Last edited by Bloke (2009-02-11 12:23:04)

redbot · 2009-02-11 12:40:46

Bloke wrote:

Bloke,
first of all thanks for just having considered to take care of this plugin

… I’m not sure which method the plugin currently employs…..

The plugin operates through Javascript (I think jquery for the latest versions) and is based on the onchange event applied to the sections list on the “write” tab.
Note that the plugin modifies also the “sections” tab in two stages: the first adding the necessary fields with an output buffer and the second with jquery to refine the layout.

As for “targeting” elements on the “write” tab using jquery I took some notes in the past while I was writing a plugin. I can’t access them now but I remember that the majority of them could be targeted trough their id, while others (especially custom fields) need another approach lacking an id. I found the most reliable mechanism (in my deep ignorance) was to target them with

$("p:has(input[name*=custom_1])")

this approach has the advantage of being compatible with glz_custom_fields and to be language indipendant.

Damn… I must stop writing now cos I’m at work. Let me just say that your approach is right for me. When I ‘ll have a bit of free time I’ll try to elaborate further (for what is worth)

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

Bloke · 2009-02-11 12:43:27

Further to my ramble above, here’s my initial thoughts on what needs to be present in each “row” of said hide-in-admin table (it could be managed as XML or JSON or whatever is easiest for processing):

widget name : as it appears to you on the Extensions tab
tab id : the admin-side tab (“event” and/or “step” to techies) on which this widget resides. Note: could also be other plugin tabs in Extensions :-)
position : an HTML #ID / a CSS .class name / some DOM identifier that uniquely loactes this widget on the page
pos_type : whether the position is directly addressable, a child, an ancestor, or whatever. See jm’s Ctrl-S plugin for a use case
id : some kind of unique internal reference that the plugin uses to store the preference for this widget against. When you hit “Save” the current state of each widget is stored in the database against this name (possibly concatenated with its tab). Thus it is independent of actual widget name — again, separating presentation from the underlying plugin mechanism

The reason for the pos_type and not simply always relying on a fixed DOM element, btw, is so you can target multiple widgets with one rule by their class name or relative position to some other element. e.g. in the Sections tab, you could remove all the “show on front page” radio buttons if you like.

Couple of fringe benefits to the above:

new widgets could be added on a one-by-one basis, if the plugin is built with a widgets editor in place
the entire table could be exported/imported or new widgets could be exported/imported singularly/by tab for distribution to other users
alterations/omissions in the table won’t impact existing prefs unless you tell it to wipe them and start again
widgets are easily translated into other languages by altering the widget name and/or using MLP… when we can bring it back to life. The database stores the prefs against the unique ID that has been “internationally agreed” (!) as the name the plugin will use
if you don’t like a particular rule or prefer to roll your own for a client, you can set your own rules if you know the names of the widgets and their relation to the name. Thus the plugin is automatically customisable by you not the plugin author and is as extensible as you need it to be from now until UNIX runs out of time. This has the caveat that your rules must be given an ID so you’ll have to choose a sensible name but you could always prefix the ID with a 3-letter prefix, like plugins do, so you can guarantee it won’t clash with someone else’s rule. Dunno, not thought this through, it’s just off the top of my head

EDIT thanks for the clarification redbot. Makes sense. Looking forward to your elaboration

EDIT2: Yay, I’m omega :-)

Last edited by Bloke (2009-02-11 12:55:51)

jakob · 2009-02-11 18:03:23

ied_hide_in_admin 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. I’m not sure which method the plugin currently employs, nor what people’s thoughts are on either system.

As far as I remember ied_hide_in_admin doesn’t use Jquery to locate the item but stores the DOM-node/path of each element to hide. I adapted it to fit my two-column write-pane a while ago and, perhaps because I lacked the right tools, remember feeling like a blind man feeling the notches – kind of 3-along, then 2-down.
Jquery’s method is far preferable and more forgiving, particularly as it doesn’t break with the slightest code adjustment as long as the element name and perhaps parent element remains the same. For example, both smd_tags and glz_custom_fields use jquery to mark the insertion point. For my own admin redesign, I just need to change the insertion address and they works fine. And because you can target parent and child elements with jquery and insert before or after, it’s quite versatile.

The php-method would be the most robust method, but I imagine it will require adjustments to the core. It may be faster to simply re-cast ied_hide_in_admin to use jquery rather than the DOM path.

EDIT: just wanted to say too that sed_section_fields is indispensable for any site that requires custom fields for different purposes. Personally, I’d find it preferable to keep the settings in the (possibly redesigned) section tab. Each section could have a sub-pane, like the categories currently do for the detailed setting and a list view similar to the articles as previously suggested elsewhere.

Last edited by jakob (2009-02-11 18:06:58)

gomedia · 2009-02-11 20:34:41

Bloke wrote:

I would suspect — but can’t be sure yet — that a better approach might be to break sed_section_fields out to its own tab under the, now very crowded, Extensions tab. Display a dropdown of the current sections in the site and then a bit of AJAX can grab the info for any chosen section from the database. A Save button is then all that’s required…

This was the approach I took with adi_menu after seeing the conflict problems with cnk_section_tree. It’s work well so far. Although I haven’t used AJAX, JIF or any other cleaning products – just dirty old PHP & MySQL.

With regards to jQuery, my only concern – & I don’t know if it’s really a problem – is that it won’t work for users on older browsers.

renobird · 2009-02-11 20:46:32

Good. good. good. This has a life of it’s own. These are both a big concern for me – as I use them on every install.
The ability to show/hide things in the admin (which is basically what both of these do) is essential.

I’ve got some reading to do in order to catch up on this thread…I’ll be back with some thoughts….

—
T

redbot · 2009-02-12 02:31:14

Bloke, all
it’s very late here and I feel dummier than ever so forgive me if these random thougths are senseless.
I have re-read your post and I found a lot of interesting stuff here (and sure I’ll need to re-read it once again). Also I’m amazed at how your ideas are similar to the ones I had some time ago when I decided to write an ‘ultimate admin customization’ plugin (which obviously I never brought to an end).
Some thoughts:

1) Contrary to the common beliefs, I think ied_hide doesen’t need an ‘urgent’ fix as it works well even with txp 4.0.8. and all in all is not so ‘very prone to breaking’.
The only problem (which I experienced since his first release) is that to make it work you have to repeat for each option check option -> save, check option -> save and so on.
On the other hand sed_section doesen’t work with 4.0.8 and has been more subject to problems and incompatibilities in the past (probably due to the intrinsic difficulties of operating on a sectionchange event and not on page load as ied_hide does).

2) As I said I really like your ideas about a ‘general purpose admin customization’ plugin. Just remember that ied_hide_in_admin operates on a ‘per user’ basis so you’ll have to use jquery only after a user level check and maybe this adds a little more complexity to the process.

3) Given that imho ied_hide_in_admin works ok, I’ll disgess a little.
When I was planning my admin customization plugin my primary purpose was to give the possibility to arrange ‘elements’ (roughly corresponding to your ‘widgets’) in the admin interface (allowing, for example, to modify the order of custom fields, or move the excerpt before the body, or the entire left table column to the right and so on – everything is doable with jquery and I already do so regularly in my txp installations).
If I understood correctly this should be quite compatible with your idea… or maybe not…
…my idea was based (and worked) on this kind of logic:
$element1 (defined from a select input of all page elements – or ‘widgets’) => $before_or_after (a radio button determining if we must use insertAfter or insertBefore in the resulting jquery function) => $element2 (defined from another select input of all page elements/widgets), this way (I’ve tested it and it works ok even with ie6) you can really customize the admin interface as you like.
As soon as I saw this was doable I started to think the plugin could be extended with the option to hide an element (as ied_hide does but not on a per user level basis) so, for example, one could easily obtain a two column layout on the ‘write’ tab (hiding the left column and moving its contents to the right column).
Well, why then not add another option to change – trough the jquery css property – the background color of a given page element? And what about having the option to give a rounded corners effect to an alement? and this? and that? … so I came to an approach very similar to yours: it would have been better if one could enter by hand his specific parameters (like you said: widget name, tab id and so on) an I had your same idea about ‘giving control of the admin side widget list to the community’.

Ok, I really must sleep now, I hope I said something not totally senseless.
I’d like to add more but ….zzzz…. good night.

Bloke · 2009-02-12 10:36:32

redbot wrote:

ied_hide doesen’t need an ‘urgent’ fix as it works well even with txp 4.0.8. and all in all is not so ‘very prone to breaking’.

OK, my apologies to Yura for the implication. I admit I’ve not tried it on 4.0.8, I just installed it once a while ago, saw an entire sea of radio buttons/checkboxes on the tab and thought “man, that’s a good idea, I wonder what cleverness goes on behind the scenes”, then looked and saw it was a giant list of DOM elements. I concluded therefore that when the admin side changes, the chances are the plugin will not work in its entirety.

to make it work you have to repeat for each option check option -> save, check option -> save and so on.

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!

On the other hand sed_section doesen’t work with 4.0.8 and has been more subject to problems and incompatibilities in the past (probably due to the intrinsic difficulties of operating on a sectionchange event and not on page load as ied_hide does).

Yes I would guess that too. Some of the problems I bet would go away if the administration of the plugin was moved to its own tab, as confirmed by gomedia (and you’re right, AJAX / Vim / Cillit Bang is just a nice-to-have — or a nightmare-to-have, depending on your viewpoint of the intrinsic UI problems with a lot of AJAX implementations today. It could be done with plain old events/steps just as efficiently). Of course the field list still needs to be dynamically altered if you change the section dropdown in your article, which is perhaps the bigger problem, as implied.

remember that ied_hide_in_admin operates on a ‘per user’ basis

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. 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.

the possibility to arrange ‘elements’… If I understood correctly this should be quite compatible with your idea

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”, “swap with”, etc, as analogs to jQuery’s manipulation methods. You could then supply — in the second optional parameter — the target element and jQuery would do the rest. It’s just code!

But if you’re considering this approach, perhaps aro_myadmin is a better bet? I believe it does that kind of thing already and adds the dashboard. I don’t know, never used it, but we could probably learn from (or use) what rloaderro has already done to save reinventing existing functionality.

Well, why then not add another option to change… the background color… a rounded corners effect… and this? and that?

I guess it’s just another “action”, though the list of permissable actions would probably have to be hard-coded in the plugin so it knew the “mapping” between what you see and what the corresponding jQuery method is. That of course means that changes to jQuery could cause parts of the plugin to stop working because it’s more tied to its function arguments than the simple “select this, hide it” which is unlikely to change any time soon. Admin skinning and admin hiding step on each other’s toes a bit — it’s a case of where you draw the line! Remember that my admin skinning patch/plugin allows javascript to run on any/all admin-side pages so skin authors could do the jQuery hiding there if they wished.

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?

It’s the same as my reservations about an all-in-one front-end management system (ha! And this coming from the guy who crams too much into his own plugins) — sometimes it’s just better to do one job really well and allow people to pick and choose the best bits, than try to do it all.

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?

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) on page load, whereas sed_sf’s event is more reactive; as an editor alters article contents.

Is there enough commonality to make it one plugin? 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”?

Just stuff to think/argue about. I don’t know the answer (sorry!)

Last edited by Bloke (2009-02-12 10:45:29)

redbot · 2009-02-12 11:50:23

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)

wet · 2009-03-12 11:38:58

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.

Textpattern CMS

Textpattern CMS support forum

#1 2009-02-11 04:55:42

Custom field improvements and hiding admin elements

#2 2009-02-11 10:11:23

Re: Custom field improvements and hiding admin elements

#3 2009-02-11 12:16:01

Re: Custom field improvements and hiding admin elements

#4 2009-02-11 12:40:46

Re: Custom field improvements and hiding admin elements

#5 2009-02-11 12:43:27

Re: Custom field improvements and hiding admin elements

#6 2009-02-11 18:03:23

Re: Custom field improvements and hiding admin elements

#7 2009-02-11 20:34:41

Re: Custom field improvements and hiding admin elements

#8 2009-02-11 20:46:32

Re: Custom field improvements and hiding admin elements

#9 2009-02-12 02:31:14

Re: Custom field improvements and hiding admin elements

#10 2009-02-12 10:36:32

Re: Custom field improvements and hiding admin elements

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

Re: Custom field improvements and hiding admin elements

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

Re: Custom field improvements and hiding admin elements

Board footer