[plugin] [ORPHAN] sed_section_fields

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?

net-carver · 2007-12-01 19:35:24

All

I have this working as a pure field-hiding plugin now on my local install. Doesn’t touch the field values or field labels now, so you’ll be able to use it with unmodified txp:(if_)custom_field tags.

It needs some cleanup and a few other changes but I hope to have something ready early next week.

redbot · 2007-12-02 13:14:17

net-carver wrote:

It needs some cleanup and a few other changes but I hope to have something ready early next week.

Great! Can’t wait to try it

gerhard · 2007-12-02 17:27:54

Steve and all others, I had 10 mins to quickly go through this thread and yes, I will be looking into integrating Steve’s plugin into glz_custom_fields 1.x IF Steve is OK with this. (Steve, give me a shout mate).

v2 might be while, if a quick integration is possible and Steve is OK, hey, why not?

net-carver · 2007-12-02 18:02:52

Gerhard

no problem. Feel free to get in contact if you need any info.

I do think I’ll keep developing this now though — I deliberately kept the word ‘custom’ out of the title to give it more scope as a per-section field control plugin.

net-carver · 2007-12-02 18:13:31

redbot, mrdale

Here’s how my local sections interface is looking presently…

Not started work on any other hiding aspects yet.

redbot · 2007-12-03 00:57:51

Here’s how my local sections interface is looking presently…

…it’s perfect

I deliberately kept the word ‘custom’ out of the title to give it more scope as a per-section field control plugin

wow, another good news!

I will be looking into integrating Steve’s plugin into glz_custom_fields 1.x

Thank you Gerhard! Both plugins are fantastic by themselves so an integration will result in something spectacular

Textpattern CMS

Textpattern CMS support forum

#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

#25 2007-12-01 19:35:24

Re: [plugin] [ORPHAN] sed_section_fields

#26 2007-12-02 13:14:17

Re: [plugin] [ORPHAN] sed_section_fields

#27 2007-12-02 17:27:54

Re: [plugin] [ORPHAN] sed_section_fields

#28 2007-12-02 18:02:52

Re: [plugin] [ORPHAN] sed_section_fields

#29 2007-12-02 18:13:31

Re: [plugin] [ORPHAN] sed_section_fields

#30 2007-12-03 00:57:51

Re: [plugin] [ORPHAN] sed_section_fields

Board footer