New "Custom Fields" tab on Write page

thebombsite · 2010-10-18 14:49:51

Is it possible for the new Custom Fields tab to “not display” if it is empty? I’ve noted that, even though it is empty, it still displays the expander images which might be confusing to users.

wet · 2010-10-18 18:47:07

Yes, it is – I was thinking about this just yesterday. But I think we’d need some sort of hook for themes and plugins to modify this spot, so some kind of markup should remain.

thebombsite · 2010-10-18 21:35:12

OK. Well we are already doing this:-

<div id="custom_field_group" class="empty"></div>

so why not do it with CSS:-

div.empty {
display: none;
}

which leaves all the code in place but doesn’t display it on-screen?

Last edited by thebombsite (2010-10-18 22:06:10)

thebombsite · 2010-10-18 21:48:19

Just tested it and it seems to work fine. ~~Am I right in thinking it only needs adding to “Classic” so that “Remora will pick it up from there?~~ (just tested that as well) Do we have any more possible instances of class="empty"?

Last edited by thebombsite (2010-10-18 21:57:09)

els · 2010-10-18 23:00:02

Yes, but that’s not a problem as long as you stick to div.empty ;)

thebombsite · 2010-10-19 06:24:43

There you go. That’s why I asked but if we stick to the way the core and MLP are currently going we should be OK. Right?

els · 2010-10-19 06:52:34

As far as I can see that is right. But, I’ve said it before, in general I think plugin code should be adapted to work with the core code, not the other way around ;)

wet · 2010-10-19 06:55:43

Interesting fact of the day:

.empty has been in textpattern.css for ages. But it didn’t kick into action until I fixed this HTML error recently.

So, recent SVN builds won’t show an empty custom fields pane anyway.

redbot · 2010-10-19 10:05:45

Pardon if this is slightly off-topic but I wonder if it does make sense at all – from an usability point of view – to group custom fields together under a ‘custom fields’ label.
I mean, probably for a site developer it does but IMHO for a user it means nothing as there is absolutely no semantical difference between “article-image” and, for example, a cf named “files”. All in all a user is not supposed to know that txp has some fields set by default while others are ‘custom’…
I know its too late and after all it can be easily modified hiding the label or changin its text with wet_babble.
Just wanted to say for me it would make more sense to put cfs under “advanced options” altogether.

Gocom · 2010-10-19 10:18:45

redbot wrote:

for me it would make more sense to put cfs under “advanced options” altogether.

To me too.

The advanced section doesn’t even have that many fields, and those three fields do even disappear if the features are disabled.

One thing I do like is that the article image is a separeted from the other fields. Now it’s way easier to make it always visible, w/o revealing all 10+ fields. And now there is even space to show a small preview of the image. Way cool.

Last edited by Gocom (2010-10-19 10:27:42)

thebombsite · 2010-10-19 15:17:08

You are correct as usual Robert. Should have checked it with “Classic” first. Seems to be a case for Els to modify the MLP plugin then.

Bloke · 2010-10-24 03:56:17

*slaps head* I swear I fixed that dangling double quote about three times so far in my dev copy and every time I forgot to commit it or something else cropped up and it got lost by merging a changeset and me missing it. Hopefully it’s finally put to rest, thanks Robert.

Regarding the separate twisty for custom fields, I can see your point redbot. From a user pov, who cares how it’s grouped, right? But by the same token, why should it be under Advanced options? Is an application-defined custom field necessarily ‘Advanced’? Does it make any more sense to lump a ‘files’ custom field with the options to determine how the article’s markup is rendered? Any way we slice it, the fact that custom fields are bolt-on additions (and user configurable) means there’s a built-in disparity between what TXP regards as a ‘core’ feature and what an application designer decides is a ‘core’ thing to capture at article creation time. Can’t think of a way round it unless a clever plugin can shuffle things around. Even In 4.2.0, the article image was separated from the custom fields so it always dangled below them.

If, say, you want to integrate an article image in the custom fields block, the only way to do it reliably (excluding post-page render trickery) is to make a new custom field and use that in your templates instead of <txp:article_image />, then hide the article image twisty entirely so your users are none the wiser.

Oh, and you can always rename the label headers using wet_babble; although that’s maybe just sleight-of-hand and doesn’t solve the issue!

Textpattern CMS

Textpattern CMS support forum

#1 2010-10-18 14:49:51

New "Custom Fields" tab on Write page

#2 2010-10-18 18:47:07

Re: New "Custom Fields" tab on Write page

#3 2010-10-18 21:35:12

Re: New "Custom Fields" tab on Write page

#4 2010-10-18 21:48:19

Re: New "Custom Fields" tab on Write page

#5 2010-10-18 23:00:02

Re: New "Custom Fields" tab on Write page

#6 2010-10-19 06:24:43

Re: New "Custom Fields" tab on Write page

#7 2010-10-19 06:52:34

Re: New "Custom Fields" tab on Write page

#8 2010-10-19 06:55:43

Re: New "Custom Fields" tab on Write page

#9 2010-10-19 10:05:45

Re: New "Custom Fields" tab on Write page

#10 2010-10-19 10:18:45

Re: New "Custom Fields" tab on Write page

#11 2010-10-19 15:17:08

Re: New "Custom Fields" tab on Write page

#12 2010-10-24 03:56:17

Re: New "Custom Fields" tab on Write page

Board footer