Could we feasibly see unlimited CFs in 2017? :)

Destry · 2017-02-16 11:00:28

Bloke wrote #304010:

My thinking is that it’s out of scope for the core to dictate what you want to use the fields for — they’re just for you to store “stuff” in and associate that stuff with a core content type: that’s it. But the facility is there for some plugin to narrow it down and make a concrete implementation for using the ‘family’ feature.

Hmm… I haven’t fully visualized the concept of a new CF panel yet in relation to the Write panel, but I suppose it’s arguable that there could be at least one default article group/family — “Blog article” — which accounts for the fields already existing in the Write panel (backwards compatibility?) and is easily overridden.

If it wasn’t for backwards compatibility, however, I’d want to see a rethink of the out-of-box Write panel that doesn’t put emphasis on any particular field labels (e.g. ‘excerpt’ and ‘body’), and doesn’t predetermine a textarea size except for a modest minimum (i.e. boxes grow as content is added).

Also, in terms of framing the semantics, which will be important for documenting it…
I like the term ‘group’ better than ‘family’, but ‘set’ — as in field set — might be most logical. A given custom field “set” defines a given content type per content panel (article, image, etc). So in the Custom fields panel the UI indicates a “Set” or “Field set” feature to group CFs, and the resulting set defines a content type for that kind of panel content.

Article content types could be anything, for example:

blog article (default, for backwards harmony)
glossary definition
recipe
speaker profile
product description
etc

Curious, would we be able to use CF sets just like individual CF fields? In other words, define different sets then append the sets — that could be where a ‘family’ or ‘group’ comes in, actually, describing a family of sets. An example of that might be an ePub or longform article that has distinct chapters, and each chapter is defined by a unique set.

Bloke · 2017-02-16 12:23:56

Destry wrote #304050:

there could be at least one default article group/family — “Blog article” — which accounts for the fields already existing in the Write panel (backwards compatibility?) and is easily overridden.

My initial thoughts on the ‘family’ field was to offer a way for plugins to group them ‘behind the scenes’ so they could offer Ajax goodness when you (for example) change Section. While visually making them into sets as you describe is interesting, I’m not sure it applies here. Bear with me a moment as I tend to your other points.

I’d want to see a rethink of the out-of-box Write panel that doesn’t put emphasis on any particular field labels (e.g. ‘excerpt’ and ‘body’)

Textpattern has always adopted convention over configuration. Usually (not always) to its users’ benefit. With the Write panel, we have to start somewhere — a suitable baseline for 80% of use cases — and title/body/excerpt as main protagonists serve that purpose.

Projecting into the drag ‘n’ drop world, if you don’t like that arrangement, drag the Body elsewhere. Move the Status to the main column. Textpattern won’t care where it is on the screen as long as the field exists when it’s saved.

So this is where I see the value-add, and is why I don’t think visual grouping at the database table level is beneficial. We have a default twisty box on the Write panel called Custom fields. You define a bunch of new ones. They appear there. You want to move one or two to the main column, drag, drop. Done. You want a new fieldset (twisty panel), fine. Click ‘add’ (or something), give it a name and it appears. Drag custom fields into it. Drag that set about to your heart’s content. Delete fields if you like and we’ll figure out how to handle it when you save. Whatever.

Is that feasible in terms of UI and code? I don’t know yet. But it sounds good.

The question then becomes how much you allow users to tinker. Dragging UI blocks around is great for customisation, but should the administrator do it and set it for all users? For all users of a particular privilege level? Is there wiggle room for users to tweak things or to completely lay out the panel to taste? Do we permit an extension of convention over configuration: allowing administrator to configure the convention that their user base will see? Or give users freedom to choose by default? Or give an administrator the power to choose who can and can’t tweak stuff?

Plugins add further sauce: group custom fields into per-section families and you can allow admins (or users) to configure the panel per section. So changing Section immediately alters the UI elements on display. Again, visually jarring? I don’t know.

Such discussions on layout and UI interaction haven’t been had. They should be had (in another thread, probably).

The point is, layout is separate from how the fields are defined at the database level. In reality all fields are custom — they hold content — it’s just that Textpattern’s convention dictates that some are primary. Whether that suits your application is where the configuration comes in, not necessarily how the stuff is stored in the tables.

Does that make sense or have I missed something?

doesn’t predetermine a textarea size except for a modest minimum (i.e. boxes grow as content is added).

Plugins. I don’t like autogrowing content areas. I don’t like too-small areas either. I recently adopted a UI paradigm on a site that the textboxes were a reasonable, fixed height until you click in one. Then it expands, autogrowing to the entire content height. When you tab out, it shrinks again to the fixed height. Appealed to me, but some might hate it.

I like the term ‘group’ better than ‘family’, but ‘set’ — as in field set — might be most logical.

Sadly, group and set are reserved words in SQL. Naming tables after reserved words is permissible, it can just make queries trickier as we may have to escape table names. And Ruud recently stripped out the escaping, because we don’t need it (at present). That was the only reason behind me calling it a family: SQL doesn’t use that word yet, and it was a nice generic term to denote grouping. If there’s something better — even a reserved word — then let’s use it and we’ll have to write defensive code accordingly.

A given custom field “set” defines a given content type per content panel

Content type is handled separately. It falls into the which panel does each field appear in. We define the main ones, but plugins could add more content types under a new panel and hook into the meta store. The advantage? No need to write custom tags to output such content: <txp:custom_field type="smd_video" name="youtube_url" /> will throw it on the website.

Content types are just freeform text fields in the DB table at the moment for precisely that reason: it’s not very “correct” (in terms of database design, 4th normal form, etc) but it’s far more flexible.

Here’s the current table definition, if anyone’s interested:

"txp_meta",
    "`id` int(12) unsigned NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NULL DEFAULT NULL,
    `content_type` varchar(31) NULL DEFAULT NULL,
    `data_type` varchar(31) NULL DEFAULT '',
    `render` varchar(255) NULL DEFAULT 'text_input',
    `family` varchar(255) NULL DEFAULT NULL,
    `textfilter` tinyint(4) NULL DEFAULT NULL,
    `ordinal` smallint(5) unsigned NULL DEFAULT NULL,
    `created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
    `modified` timestamp NULL DEFAULT NULL,
    `expires` timestamp NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `name_content` (`name`,`content_type`)"

id, name: self explanatory.
content_type: which panel the field can appear in.
data_type: how the data will be stored internally (MySQL field type).
render: what type of field will be used to collect the info. Textbox, checkbox, radio set, select list, textarea, etc, or some custom definition. Available options for the ‘set’ types are stored in another table.
family: discussed above. Arbitrary grouping of fields within a content type (panel). Not necessarily for display, but they could be if a plugin exposed it. Unused by core at present.
textfilter: which markup system the field uses. Textile, nl2br, none, markdown, whatever plugins have installed.
ordinal: nominally what order the field appears on screen by default. Can be overridden by drag n drop in the fullness of time, but we need some way of defining order other than ‘by name’ or ‘by id’, neither of which may be convenient.
created, modified, expires: self-explanatory to a degree. The expiry of custom fields is experimental. Useful? I don’t know.

I stress again: that’s not where the data is stored — that’s in a whole bunch of other tables that reference this one — it just defines the custom field properties. Also note the absence of ‘title’: that’s handled by txp_lang to allow translation of fields into other languages. Always got my eye on the long term :-)

philwareham · 2017-02-16 12:43:36

Autosized text areas are primarily so the UI plays nice on tablets (and mobile if that’s your bag). It avoids the ‘trying to scroll the page but actually scrolling a textbox’ annoyance. Anyway, I’m not totally wed to it if custom fields layouts become a reality and have issues wth autosize.

The HTML/CSS of the panels form fields was intentionally harmonised to allow for future custom page widgets during the 4.6 development cycle. For example, on Write page theoretically you could create a new custom ‘textarea’ and either drop it into the main column (where body/excerpt are) or into one of the side column panes – it’s the same code structure. What would need some thought is whether new side panes themselves can be created, or if the current panes suffice? Also, can panes themselves be dragged from side column to main and vice versa (again the HTML/CSS allows for this in theory)?

Other panels (such as any of the ‘edit’ panels) also have same HTML/CSS so yet again in theory it’s doable.

Some of the form widgets have IDs so some logic would have to be programmed into the system to make sure there are no clashes there. Maybe prefixed IDs for any custom stuff, plus unique numbering.

jQuery UI can provide drag/drop of HTML chunks within a page (which can then be stored in database via jQuery). It doesn’t work on touch (that’s a future roadmap goal of jQuery UI) but don’t see that as a major roadblock.

Destry · 2017-02-16 12:49:57

Bloke wrote #304051:

My initial thoughts on the ‘family’ field was to offer a way for plugins to group them ‘behind the scenes’

Ah, I think I see what you mean now. There is no UI controls for front-side grouping, in fact. A plugin would dictate that for all (or a specific need). Yes?

If that’s the case, then I highly advise a brave soul to start working on a plugin as a kind of test case against the core CF development. I would hope there would be a single plugin that does all possible configurations over having to install 20 different plugins for each kind of ‘family’ I might need.

The question then becomes how much you allow users to tinker. Dragging UI blocks around is great for customisation, but should the administrator do it and set it for all users? For all users of a particular privilege level? Is there wiggle room for users to tweak things or to completely lay out the panel to taste? …

I just look at it like this: content modeling is an information architect’s role. Which particular role in Txp’s permissions structure most closely matches the architect in an editorial hierarchy? That’s the one that has right to modify (and any higher role).

Such discussions on layout and UI interaction haven’t been had. They should be had (in another thread, probably).

Yes.

Plugins. I don’t like autogrowing content areas. I don’t like too-small areas either. I recently adopted a UI paradigm on a site that the textboxes were a reasonable, fixed height until you click in one. Then it expands, autogrowing to the entire content height. When you tab out, it shrinks again to the fixed height. Appealed to me, but some might hate it.

Yes. I like that. I only meant that I don’t want to have to scroll boxes, and I don’t want needlessly large boxes with little content in them (an old plague of the ‘body’ field).

Sadly, group and set are reserved words in SQL.

I see. Well, ‘family’ is probably okay. Only others that comes to mind: ‘collection’, ‘cluster’… We know where that last one will lead. ;)

Content type is handled separately. It falls into the which panel does each field appear in. We define the main ones, but plugins could add more content types under a new panel and hook into the meta store.

OK.

maverick · 2017-02-16 16:32:40

Destry wrote #304053:

over having to install 20 different plugins for each kind of ‘family’ I might need.

I understand a 1:1 ratio for new content types, and specialty plugs, but as Destry notes, things could get out of hand. Fortunately we have a lot of savvy code writers in our community, and this probably will not happen.

I just look at it like this: content modeling is an information architect’s role. Which particular role in Txp’s permissions structure most closely matches the architect in an editorial hierarchy? That’s the one that has right to modify (and any higher role).

Agreed. At least out-of-the-box it should be limited by default.

I see. Well, ‘family’ is probably okay. Only others that comes to mind: ‘collection’, ‘cluster’

I too find “field set” my initial (sensible) go-to. Family works though. Cohorts might also work but given that one of my pet peeves in the world of CMSes is the insatiable need for each project to define words and terms differently, it’s probably not a worthy suggestion. Just consider the debates over forms, blocks, chunks, snippets, etc. Go with terms that have the most universal, standard meanings when possible rather than some unique insider language.

Destry · 2017-02-16 22:42:47

There’s a good article here by John Williams, Content (Modelling) First Design, which talks about it in context of Webflow CMS semantics. Coincidentally, Webflow calls sets of fields ‘collections’, which was one I pulled out of thin air earlier.

The first step you’ll take in building a site powered by Webflow CMS is to create a Collection. A Collection is essentially a content type that you’ll define by selecting Fields from the following list… (14 field types)

It goes on to talk about “referencing” collections so they work together, but it was the use of ‘collections’ that caught my eye. Just thought I’d point it out.

sacripant · 2017-02-17 09:25:45

Thanks Destry, I agree with the author. I use ‘Content First’ approach with my client since 2013. I writed a article about that.

But Unlimited Custom Field is not good enough for “Custom type creator” funtionnality.

If I understand Steph, It will be possible to modify and organize the fields of the default content types proposed by Textpattern (article, image, etc.). But not create a new content types.

Actually it’s just possible to simulate several content types by adapting the display of content type article (hidden some fields) according to the sections (with plugins glz_cf + bwt_customize + rah_wrach).

For me, Unlimited custom field is just a first step to allow what the author explains in his article.

Bloke · 2017-02-17 09:30:37

‘Collection’ works for me.

Destry wrote #304053:

I would hope there would be a single plugin that does all possible configurations over having to install 20 different plugins for each kind of ‘family’ I might need.

Absolutely. One plugin to rule them all is possible. It’s up to the plugin author to define the scope. e.g. abc_cf_by_section might be a specific one for the Write panel, while abc_cf_groups might permit grouping across any content type.

Bloke · 2017-02-17 09:48:01

sacripant wrote #304077:

If I understand Steph, It will be possible to modify and organize the fields of the default content types proposed by Textpattern (article, image, etc.). But not create a new content types.

Not out of the box in core, no. But plugins could easily create custom types. They can now, it’s just that nobody’s done it, as far as I know. Write a new admin panel called abc_location under the ‘Content’ menu which lists/exposes a bunch of form fields, add a table to the DB and a tag to get the data out. Job done. It won’t necessarily be efficient in terms of storage, but it’ll work.

Under the proposed CF route, that could change to: Write a new admin panel called abc_location as above. On plugin install, add a bunch of custom fields to define the field contents you want to store. Set their ‘content_type’ to abc_location. Use core widgets to display appropriate input controls for that content on your new admin panel’s Edit step. Job done. <txp:custom_field type="abc_location" name="latitude /> will display that field from your new ‘location’ content type. Textpattern will manage the storage for you in the most efficient manner possible.

Destry · 2017-02-17 10:58:42

Bloke wrote #304078:

Absolutely. One plugin to rule them all is possible. It’s up to the plugin author to define the scope. e.g. abc_cf_by_section might be a specific one for the Write panel, while abc_cf_groups might permit grouping across any content type.

Nice.

Now that I think about it. I wouldn’t mind if they were designed by admin section, actually. If I didn’t want a links modifier right away (or ever), I could avoid that CF plugin/module and it’s one less plugin.

At the same time, no single plugin author has to dev/maintain THE ONE plugin, which might be a bit of a bloat endeavor. Plus it gives more devs a chance to have a go at an individual section plugin, as opposed to say, smd_megalodon_contentype_spellcaster. :)

On the other hand, I could imagine it turning out that devs will design content type solutions such that, “to use this plugin you must also install plugins, x, y, and m.” :/ In which case it might be nice to just have the one megalodon.

Textpattern CMS

Textpattern CMS support forum

#37 2017-02-16 11:00:28

Re: Could we feasibly see unlimited CFs in 2017? :)

Bloke wrote #304010:

#38 2017-02-16 12:23:56

Re: Could we feasibly see unlimited CFs in 2017? :)

Destry wrote #304050:

#39 2017-02-16 12:43:36

Re: Could we feasibly see unlimited CFs in 2017? :)

#40 2017-02-16 12:49:57

Re: Could we feasibly see unlimited CFs in 2017? :)

Bloke wrote #304051:

#41 2017-02-16 16:32:40

Re: Could we feasibly see unlimited CFs in 2017? :)

Destry wrote #304053:

#42 2017-02-16 22:42:47

Re: Could we feasibly see unlimited CFs in 2017? :)

#43 2017-02-17 09:25:45

Re: Could we feasibly see unlimited CFs in 2017? :)

#44 2017-02-17 09:30:37

Re: Could we feasibly see unlimited CFs in 2017? :)

Destry wrote #304053:

#45 2017-02-17 09:48:01

Re: Could we feasibly see unlimited CFs in 2017? :)

sacripant wrote #304077:

#46 2017-02-17 10:58:42

Re: Could we feasibly see unlimited CFs in 2017? :)

Bloke wrote #304078:

Board footer