Custom fields as part of core

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….

Algaris · 2012-06-25 10:25:03

wet wrote:

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….

Yes please. I’d like to have my cake and eat it if I may.

Last edited by Algaris (2012-06-25 10:25:22)

Bloke · 2012-06-25 10:29:49

wet wrote:

I’d rather aim at a more general key/value store.

That would also work and is a shedload less effort, which gets my vote. As well as food for thought, my post does highlight the amount of graft involved in the process which is as much a turn-off as the desirability to have it!

When the Basic/Advanced prefs panel is merged into a single, more manageable structure, perhaps that would be a good point to think about key storage. I see a couple of foundation stones already :-)

Last edited by Bloke (2012-06-25 10:32:11)

wet · 2012-06-25 10:37:51

In WordPress they have a nice implementation of lazy-loaded user data from a meta store via magical getters/setters. Perch has similar interiors though one cannot look into it without buying a license from Drew ;)

Destry · 2012-06-25 11:22:33

Bloke wrote:

I don’t really have a clear notion over what should be core and what shouldn’t in this regard.

That’s a worthy point of discussion. Without giving a song and dance about how CMS projects should be looking to the future and taking cues from emerging market demands and niche opportunities, let me just say that a good rule of thumb for the near future, for the sake of progress, is: if the functionality in question is an improvement on functionality that already exists, make the improvement to the core. If it’s an “extension”, make it a plugin.

I think this thread’s topic is clearly defined as core domain. That doesn’t mean it has to work like presented, this is all just brainstorming, after all. But as far as what’s taking place here in this discussion, it’s perfectly on track with doing things right. 1) Somebody or three offers concepts and sketches them out. 2) Somebody else or two who’s more intimate with the code says ‘no’ to this and ‘yes’ to that and a feasible plan starts shaping up. Perfectly normal.

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

I totally agree. I am one power user in the choir you’re preaching to. I came out of grad school nine years ago with a degree in Tech Comm and UCD—which I only say to emphasize the next clause—so the humble user is always front and center in my scope. But without real user enquiry (say from surveying clients we’ve build sites for and reporting that data back to the group) then we have to make a call somewhere, and you make that call from the expert users. I think we have a lot of people in this community who understand that and can say ‘stop’ on something when it needs to be said. In the course of that, however, discussions like this are needed, and usually lead to better things—I have faith.

Let’s be pragmatic about this…

We are. Every new build, if you will, requires some kicking around and sketching for fit and fitness. That exploratory stage is pragmatic.

Ed.: Ha! I“m like 5 posts late already, oh well. Just keeping even keel, is all I’m trying to do.

Last edited by Destry (2012-06-25 11:23:42)

mrdale · 2012-06-25 15:25:31

bloke said
Finally, fugure out how to display it all on the Write, Image, File, and Link panels.

I knew this conversation would eventually come around to the mutinous idea of (ahem) custom content types. ;) there I said it again after all these years. Seems to me that the real way to build it, v5 style, would be to make a content routing table and allow content types to be a collection of these fields in any order and combination. Accessible by a common tag, ie.

<txp:content type="people" limit="3"><txp:custom _field name="gender" /></txp:content>

A new content type produces a new sibling to the articles tab. Another tab under admin would let you construct and order your content tabs.

And no, I don’t want to go use drupal. We’ve had quite enough of that nonsense already.

Bloke · 2012-06-25 15:45:35

mrdale wrote:

A new content type produces a new sibling to the articles tab. Another tab under admin would let you construct and order your content tabs.

Do we get free riding lessons with this pony?

^{(a.k.a. if you thought my post above sounded like a truckload of work, imagine how much this would be)}

Last edited by Bloke (2012-06-25 15:46:39)

Textpattern CMS

Textpattern CMS support forum

#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

#31 2012-06-25 10:25:03

Re: Custom fields as part of core

#32 2012-06-25 10:29:49

Re: Custom fields as part of core

#33 2012-06-25 10:37:51

Re: Custom fields as part of core

#34 2012-06-25 11:22:33

Re: Custom fields as part of core

#35 2012-06-25 15:25:31

Re: Custom fields as part of core

#36 2012-06-25 15:45:35

Re: Custom fields as part of core

Board footer