[plugin] [ORPHAN] sed_section_fields

mrdale · 2007-11-28 19:15:35

Just so I understand…

The built in tags that refer to custom fields will continue to work as they have, except that the per-section names a user specifies, will be used.

<txp:custom_field name="About_job_function" />
…will output custom field one, if I have set that in the sections tab under About.

<txp:if_custom_field name="Projects_date_completed" value="incomplete">some text</txp:if_custom_field>
…will test for a value of incomplete in the Project section, etc, etc

Do I understand correctly?

Last edited by mrdale (2007-11-28 19:17:54)

redbot · 2007-11-29 02:49:48

Ehm… I hope I’m wrong but – having tested both plugins – I think an integration between sed_section_fields and glz_custom_fields could be a not so easy task.
In fact they rely on a totally different logic: glz_custom_fields sets the names of the various custom fields directly in the db, under the “txp_prefs” table, while sed_section_fields only changes the labels of custom fields in the “write tab” leaving the db untouched, in other words when a custom field is called in an article form (using txp:custom_field) the “name” attribute must be the one displayed in the “advanced preferences” tab, not the label appearing in the “write” tab.

Other than that, from a logical point of view, if I set the first custom field (using glz_custom_fields) to be a select drop down named “fruit” with possible values “apples” and “oranges” and then – only for a section named “locations” – I label the same custom field (using sed_section_fields) to “city” when editing an article in section “locations” I’ll have a field labeled “city” with possible values “apples” and “oranges”

At this point I think the only way in which sed_section_fields could work nicely with glz_custom_fields is to have the option, other than changing a custom field label, to hide a particular custom field (label +input box) on a per-section basis. This way, once defined all custom fields in the “preferences” tab or in the “extensions -> custom fields” tab, you could simply choose which custom field will appear on a per-section basis.

edit: The post was heavily edited. it was way too garbled ;)

Last edited by redbot (2007-11-29 03:30:15)

net-carver · 2007-11-29 03:56:40

mrdale, redbot

Hehe, that’s why I like a good forum. You’ve spotted an “obvious” oversight on my part. I’ll need to address this so that either the per-section name is used on the public side or the admin side behavior is a little different.

Let me browse the TxP code and think about this a while.

mrdale

No, redbot is right, currently it will try to match on the global names, not on the per-section names.

net-carver · 2007-11-29 04:54:09

All

I’ve withdrawn the plugin until I know I can provide a convenient and understandable admin override model and any needed support so things work fine on the public side. It may be that I do no more with this plugin as Gerhard’s custom field plugin v2 looks like it will be able do this — and way, way more!

Sorry of the inconvenience — for now please just treat this as a proof-of-concept for an admin-side per-section field interface.

Last edited by net-carver (2007-11-29 04:55:56)

redbot · 2007-11-29 12:09:49

Steve,
Please keep in mind that Gerhard’s custom field is not free and I find your solution brilliant and perfectly usable,
given that one knows how to use it.
Also, glz_custom_fields v2 won’t be released soon so I don’t know if the withdrawal of your plugin is a good idea… there are many people which are not using Gerhard plugin and they could certainly benefit from your plugin.
Cheers!

P.S.
I’m still persuaded the solution I suggested in my previous post is the way to proceed.
In fact if the plugin only deals with hiding custom fields on a per-section basis all the inconsistencies outlined will magically disappear

Last edited by redbot (2007-11-29 12:54:30)

net-carver · 2007-11-29 13:07:05

redbot

thanks for the post.

Regarding withdrawing the plugin: this might only be a temporary situation but I don’t want others — particularly those who only get plugins via textpattern resources and seldom come to the forum — to go “Wow! Look at that” and start building a solution for a client and then have it fall apart on the public side.

In fact if the plugin only deals with hiding custom fields on a per-section basis all the inconsistencies outlined will magically disappear

Yes, that’s a possible solution too. Just change this over to a ‘set as many as you need globally and then hide them on a per-section basis’ plugin would ease things.

I’ve done some digging now and on the public interface it seems that TxP will only add a custom field’s contents to an article’s data if there is a valid label for it at the global level so if I don’t go down the road you suggested then I’ll either…

have to use another DB query to populate the fields that TxP passed over or …
need to have all the global level field names defined all the time if you want TxP to retain the custom field data it pulled from the article.

The first case is probably easiest but it will add an extra query per article and probably have to use my own tags to replace the standard custom field ones. Not good (especially seeing the data was pulled out aready and then passed over.)

The second case is ok if you can live with a fully populated custom field set but then all the custom fields will show in every section anyway unless I make the code tri-state (to allow retain/hide/custom for a field.)

Once that’s done you have to decide if you want to keep your label semantics all the way to article context forms. If you do want to keep semantics then you need to relabel what TxP has already pulled from the DB and given the global label to — which can be done with a single new tag. Of course, if you don’t care about using the per-section label in the custom_field tags then you could get by without the last part.

I’m not sure I want to do all that.

I need some more time to think through where this is going as I originally had several other features I wanted to add to this — but yes, your idea might be the solution.

mrdale · 2007-11-29 16:30:36

redbot & netcarver > Thanks for the clarifications… That helps a lot.

Now I understand better how the plugin works and can see how glz and sed go about things in a very different way.

I’m just glad I got a copy of this prior to steve pulling it down, (which is understandable) as I will find it extremely useful.

Last edited by mrdale (2007-11-29 16:30:51)

redbot · 2007-11-29 19:15:15

Steve,
I’m sorry but today I’m dumber than usual, so I can only partially follow your reasonings.
Furthermore I haven’t the time to examine your plugin code. Consider also I’m quite ignorant in php and jquery.
Apart from this I would go for a very lo-fi solution: I noticed when your plugin is active each custom field in the “write” tab has an id for the input tag ( id=“custom-1”, custom-2 and so on) and an id for the label ( id=“custom-1-label”, id=“custom-2-label” etc.).
In this scenario I would simply add some css rules via jquery (is this possible?) on a per-section basis.
So, for an example, if we are editing an article in a certain section – in which we have choosen to hide some custom fields with your plugin – a css rule would be applied to the page, something like:

#custom-1-label, #custom-1 {display:none;}

Am I saying absurdities? Probably yes ;)
And, by the way, you said:

...but then all the custom fields will show in every section anyway unless I make the code tri-state (to allow retain/hide/custom for a field.)

I don’t understand this: it is the normal txp behaviour to show all the custom fields in every section anyway, so it wouldn’t be a problem, no? This is one of the very few things I never liked about txp: when you build a site for someone you’re always saying “dont’ fill this field in section x” or “remember to fill that field in section y”… that’s why I find your idea so great

cheers

Last edited by redbot (2007-11-29 19:17:15)

net-carver · 2007-11-30 04:18:42

redbot

Sorry, my post above was as clear as mud on a moonless night. I was trying to describe a couple of other ways this might be developed other than making it just hide some of the custom fields.

Bottom line: your solution sounds the best.

Additional benefit: It fits in with the next set of features I wanted to add to the plugin. (Clues as to what they might be are here and here.)

redbot · 2007-11-30 11:05:54

Steve,
That’s great! …and with the additional features you mentioned this plugin could be really revolutionary .
By the way, have you noticed the latest posts in the first forum thread you mentioned? Just some days ago I was suggesting a simple hack based on the same principle ;)

P.S. Thanks again!

net-carver · 2007-11-30 15:29:40

Well what do you know. I hadn’t noticed who the posting party was until you pointed that out.

mrdale · 2007-11-30 17:08:05

Great news, nc >

If I read your clues correctly we may have excluded static sections from the section drop down and some other hidden elements on the write page. Yay!

So, I’ve never been able to get ied_hide_admin_fields to work. And It’d be great to be able to remove some clutter for my clients instead of telling them to “ignore all that stuff… oh except the custom fields”. Any chance some explicit hiding could make it’s way into your plugin?

Textpattern CMS

Textpattern CMS support forum

#13 2007-11-28 19:15:35

Re: [plugin] [ORPHAN] sed_section_fields

#14 2007-11-29 02:49:48

Re: [plugin] [ORPHAN] sed_section_fields

#15 2007-11-29 03:56:40

Re: [plugin] [ORPHAN] sed_section_fields

#16 2007-11-29 04:54:09

Re: [plugin] [ORPHAN] sed_section_fields

#17 2007-11-29 12:09:49

Re: [plugin] [ORPHAN] sed_section_fields

#18 2007-11-29 13:07:05

Re: [plugin] [ORPHAN] sed_section_fields

#19 2007-11-29 16:30:36

Re: [plugin] [ORPHAN] sed_section_fields

#20 2007-11-29 19:15:15

Re: [plugin] [ORPHAN] sed_section_fields

#21 2007-11-30 04:18:42

Re: [plugin] [ORPHAN] sed_section_fields

#22 2007-11-30 11:05:54

Re: [plugin] [ORPHAN] sed_section_fields

#23 2007-11-30 15:29:40

Re: [plugin] [ORPHAN] sed_section_fields

#24 2007-11-30 17:08:05

Re: [plugin] [ORPHAN] sed_section_fields

Board footer