Custom fields as part of core

masa · 2012-06-24 00:00:13

Destry wrote:

There are a lot of times when I’d like to use custom fields for a fair bit more text than there is visual room in the field for, and thus edits to that content are rather awkward (not user-friendly).

I agree.
Just being able to see all the text entered in a CF would be great. A toggle switch to change it to an auto-expanding textarea would do the trick.

philwareham · 2012-06-24 06:38:49

@destry

I did this mockup last year which had columns switched.

Destry · 2012-06-24 15:22:59

philwareham wrote:

I did this mockup last year which had columns switched.

I like the concept. Without analyzing this particular mockup, I’d just say from the birds-eye view that I like having the main content in the left like this. It has my +1 for implementation. The rest could be fine-tuned, perhaps, but textareas in the left is a good call, I think.

I’m pretty sure Jakob did a mockup of this layout idea too, back during the Xpattern mutiny. Wish I could find it.

colak · 2012-06-24 15:27:22

I like it as well but Shouldn’t there be a ‘convert line breaks’ option too?

lazyadmin · 2012-06-24 16:12:45

Destry wrote:

I’m pretty sure Jakob did a mockup of this layout idea too, back during the Xpattern mutiny. Wish I could find it.

You mean this one?

renobird · 2012-06-24 16:42:33

Destry,

I seem to remember a theme Jakob did as well — I don’t think it had anything to do with the xPattern mutiny, haha — I like that. ;)
I’ll dig around and see if I can find it, the thread is probably ancient at this point, but I suspect it’s still around.

I see your point about sometimes using custom fields for just a number or a price.
What about a column width setting for the smaller fields (similar to Processwire)?
That way you could have a consistent location for all custom fields in the main column, but the ability to reduce vertical space by having fields float next to each other.
Larger text inputs that need to show more information could take up an entire line, and the same for textareas.

This Processwire demo video doesn’t completely translate, but at about 0:28 you can see how the width of a particular field is set.

Lazyadmin,

That mockup you linked was the initial concept for the xPattern admin — just a rough concept. :)

Last edited by renobird (2012-06-24 16:51:29)

phiw13 · 2012-06-24 23:16:39

Fwiw, Sandspace 4 alpha [*] and previous version(s) uses a similar layout as Phil’s mockup linked up-thread (2 column layout for the Write pane, with less reshuffle than what Phil has done; it has to work with the current html codebase :-p ).
Ideally, I would probably end up with something very similar as that mockup.

[*] probably slightly broken due to the most recent changes in the code base, I’ll post an updated version soonish.

mrdale · 2012-06-25 01:52:13

Destry wrote:
…back during the Xpattern mutiny…

lol. Mutiny meaning a frustrated inability to have contributed ideas taken seriously by then pompous and uncommunicative devs followed by a brief pythonesque attempt at putting those ideas into practice, yes.

arg… this salty dog likes the cut of your jib. P)

Q: Did you ever participate in a forkin’ mutiny.
A: Well, yes. Once in 2007ish. but I never inhaled.

Destry · 2012-06-25 06:33:49

@Dale: Frustration is often the start of mutiny, for sure!

All,

I found those mockups by Jakob, in context here, and this is the one I was thinking of: http://www.flickr.com/photos/39591683@N00/3259270849/sizes/m/in/photostream/

To bad it’s kind of small, but I think it’s a great concept, and I really like how he’s organized the right column, including the custom fields when they’re not textareas.

Destry · 2012-06-25 07:22:50

I forgot to mention this originally, but something else that has often bothered me with using custom fields, and maybe this ties in with what Maruchan was saying earlier, is that when you define CFs for different content types (different Section-related articles), you can’t easily group the related fields together. So if you had ten CFs used and 1, 3, 4, 7, and 10 were for Article type A, and 2 and 6 for Article type B, and 5, 8, and 9 for Article type C, then it becomes kind of a hunt-n-peck to fill in the custom fields, and especially confusing for client users if left that way.

To fix you have to reorganize the order, but even then you can’t clearly label the groups (making the associations easier to see) so you have to be careful about the CF names and make them a bit more suggestive with prefix conventions, or whatever, of the article type association. All possible, but still more arduous than it could otherwise be.

With the latest round of discussion about being able to create textarea fields, etc. that helps quite a bit, and if we could figure a way to make them Section-specific (only CFs for articles assigned to a given Section appear) that would solve it entirely, and nicely.

So it seems going back to the context-specific showing of CFs like Maruchan first suggested offers even more value now that I think about it.

philwareham · 2012-06-25 07:24:47

Textpattern 4.5 introduces a few classes for different widths of text input field, see here.

So you have .input-medium, .input-small and .input-xsmall. It would not be a great leap to make these optionally inline – but it will have to wait for Txp 4.6 though.

Around that time I’ll also be getting rid of the last of the tables used for layout (i.e. write page, pages/forms/styles pages, categories page). We will probably make the whole admin side HTML5 at that point too, so that means the data- attribute could come in very handy.

Last edited by philwareham (2012-06-25 07:26:12)

maruchan · 2012-06-25 08:12:23

when you define CFs for different content types (different Section-related articles), you can’t easily group the related fields together.

One solution I’ve seen is to use fieldsets for this. So in your “arrange custom fields” context, you have two custom fields that are called “fieldset Organization_Contact” (as an example, supposing you are grouping a name, photo, address, etc.) and “fieldset end”. You put the first before your little subset of fields, and the second at the end. Then the CMS understands and wraps those custom fields with whatever label you assigned to the fieldset. So a fieldset is treated in the back end like a type of custom field. Pretty handy.

You can use this type of “wrapper field” concept for other things too, like “tab start” and “tab end” if you want to group sets of fields into tabs.

So you might have a list like:

Title
Body
Color
Model Number
FIELDSET Organization Contact
Name
Phone Number
Photo
FIELDSET END
TAB Image Gallery
Gallery_Photos
Gallery_Caption
TAB END

Does that seem to match up with your requirement?

Last edited by maruchan (2012-06-25 08:16:36)

Destry · 2012-06-25 09:48:55

Yes, fieldsets would be a good way to handle the grouping as far as it goes in the markup/presentation, I would presume.

That would just leave the final question of how to tie CFs to specific article types. We were talking about it possibly being done via Pages or Sections earlier, and thus how to provide for that in the UI. Here’s a broken example…

It’s basically another control for assigning a given CF to a Section/Page (one or the other, whatever is better). So in this case you can assign “all” (default), mean it shows up on all articles if initially created, or a given Section/Article.

But there could be the cases—and I’ve had them—where a given CF is not used for all, but more than one. We can’t do that with the concept here.

So it looks like the best course of action would be to provide for defining article types. So maybe there’s a new panel under the Content section called “Types”, and the CF preferences are moved out of preferences and to the Type panel, where article types can be created by assigning custom fields to each type. Essentially named article templates (just like having page templates).

Then maybe to tie it all together, you just add another control in the Sections panel for the article Type assignment, in addition to the existing page and style assignment. Then when you start a new article in the Write panel and make the Section assignment, the corresponding article components (custom fields) display for that article.

I’m just putting thoughts on the table for kicking around.

Bloke · 2012-06-25 09:58:47

Custom fields have always been badly implemented, and that started with the table design.

To do it better, the textpattern table needs normalizing to remove custom_1 through custom_10 and then introduce a new txp_custom_fields table with:

auto-incrementing ID cf_id.
name: sanitized, and with spaces replaced by underscores.
title.
type: article, image, link, file, or other flavour as defined by plugins.
input: text_input, longtext_input (a.k.a. textarea), yesnoradio, selectlist, etc (in a similar vein to the prefs panel) which can call trusted 3rd party plugin functions to render input controls.
group: similar to what maruchan suggested above.
… maybe some other columns that I haven’t thought of yet.

Then a link table txp_cf_content needs introducing to map CFs data to content:

id (of content)
cf_id
value

with a unique index on the two ID columns.

Perhaps a new pref to control overall size (width), or some way to specify the dimensions of the input control, or simply some good class names such that themes / admins can influence the layout. Then the data needs migrating from the textpattern table to the new structure. And that’s just on upgrade.

The custom field names need “namespacing” so they can’t clash with existing fields when injected into the global $thisarticle. They also may need to be referenced twice here: once by their name (for b/c) and once by their custom_N ID so that i18n plugins can refer to them without language issues.

After that we need to remap any tags that refer to custom fields, primarily <txp:article_custom>, <txp:custom_field> and <txp:if_custom_field>. With the sanitized names we can keep the article_custom functionality of <txp:article_custom txp_my_cf_name="some match" /> (‘txp_’ being the arbitrarily chosen namespace prefix). It would be beneficial to open this up so that custom_N="some match" is an optional syntax.

Then worry about an admin tab to manage the CF properties. They make no sense in prefs. I’d be tempted to make this really simple with perhaps just a few scant types built in and allow plugins to extend it. After all, we’re not trying to be everything to everyone: each thing we add is potential bloat because a lot of sites won’t use them so we need to be careful to pick and choose what functionality is core and what should be offered by plugins.

Finally, fugure out how to display it all on the Write, Image, File, and Link panels. Not sure about the whole ‘per-section’ thing. Although it’s handy, someone will always then want it linked to category, or linked to status or use one CF across more than one section. Plus ‘section’ only applies to articles, so in a generic table that applies across content types I think this is best left out of core, and plugins should be allowed to fill the void.

Well, that’s off the top of my head. Certainly not something for today or this release, but maybe in future.

I don’t really have a clear notion over what should be core and what shouldn’t in this regard. To date I’ve never used more than 10 CFs (on other collaborative projects yes, but not my own) and have been inconvenienced by the grouping thing Destry mentioned; especially if CFs are added late during the development cycle, or in response to client feedback after go-live. I’ve also occasionally wished that the fixed 255 char text input could be bigger / of a different type.

The majority of people here who voice opinions are what I term “power users” and we need to be careful to balance the requirements of these good folk with overburdening the novices or introducing whizzy features that only 10 or 20% of people will use (however great that may be).

There’s a place for core features and a place for plugins to extend. Let’s be pragmatic about this and discuss upon which side of the lake the responsibilities lie, then we can start to get somewhere and plan this thing.

Last edited by Bloke (2012-06-25 09:59:48)

wet · 2012-06-25 10:20:27

Bloke wrote:

To do it better, the textpattern table needs normalizing to remove custom_1 through custom_10 and then introduce a new txp_custom_fields table

I’d rather aim at a more general key/value store. I suspect that once we have unlimited custom fields there’s another group of people who (gasp!) want unlimited categories or more than one image field….

Textpattern CMS

Textpattern CMS support forum

#16 2012-06-24 00:00:13

Re: Custom fields as part of core

#17 2012-06-24 06:38:49

Re: Custom fields as part of core

#18 2012-06-24 15:22:59

Re: Custom fields as part of core

#19 2012-06-24 15:27:22

Re: Custom fields as part of core

#20 2012-06-24 16:12:45

Re: Custom fields as part of core

#21 2012-06-24 16:42:33

Re: Custom fields as part of core

#22 2012-06-24 23:16:39

Re: Custom fields as part of core

#23 2012-06-25 01:52:13

Re: Custom fields as part of core

#24 2012-06-25 06:33:49

Re: Custom fields as part of core

#25 2012-06-25 07:22:50

Re: Custom fields as part of core

#26 2012-06-25 07:24:47

Re: Custom fields as part of core

#27 2012-06-25 08:12:23

Re: Custom fields as part of core

#28 2012-06-25 09:48:55

Re: Custom fields as part of core

#29 2012-06-25 09:58:47

Re: Custom fields as part of core

#30 2012-06-25 10:20:27

Re: Custom fields as part of core

Board footer