Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

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

New "Custom Fields" tab on Write page

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.


Stuart

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

Offline

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

wet
Developer Emeritus
From: Schoerfling, Austria
Registered: 2005-06-06
Posts: 3,330
Website Mastodon

Re: New "Custom Fields" tab on Write page

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.

Offline

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

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

Re: New "Custom Fields" tab on Write page

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)


Stuart

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

Offline

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

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

Re: New "Custom Fields" tab on Write page

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)


Stuart

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

Offline

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

els
Moderator
From: The Netherlands
Registered: 2004-06-06
Posts: 7,458

Re: New "Custom Fields" tab on Write page

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

Offline

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

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

Re: New "Custom Fields" tab on Write page

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?


Stuart

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

Offline

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

els
Moderator
From: The Netherlands
Registered: 2004-06-06
Posts: 7,458

Re: New "Custom Fields" tab on Write page

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 ;)

Offline

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

wet
Developer Emeritus
From: Schoerfling, Austria
Registered: 2005-06-06
Posts: 3,330
Website Mastodon

Re: New "Custom Fields" tab on Write page

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.

Offline

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

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

Re: New "Custom Fields" tab on Write page

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.

Offline

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

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: New "Custom Fields" tab on Write page

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)

Offline

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

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

Re: New "Custom Fields" tab on Write page

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.


Stuart

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

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,453
Website GitHub

Re: New "Custom Fields" tab on Write page

*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!


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

Board footer

Powered by FluxBB