Could we feasibly see unlimited CFs in 2017? :)

bici · 2017-02-13 18:52:50

maverick wrote #304006:

From a data entry stand point, when you go to the write tab, how would that work?

It definitely makes sense if CFs are only shown if relevant. From a work-flow stand point, if they are specifically tied to a section:

Wouldn’t you need to select your section first, before writing anything, and before saving it? Vs. the current just write. Worry about the details later.

And what if you want to change the section after you have saved it and perhaps added some section only CF data. Is that CF info deleted? orphaned?

CFs show up as fields when one is editing/adding to a section

You would need to be in the section to write, don’t see that as a deal breaker, right now you need to be in section to edit.

changing Section name would cause CFs to disappear. too bad too sad.

i would suggest one take a look at the free EECore to see the way CFs are handled. it might provide some hints for TxP to proceed.

i am not a dev so I have no clue of the issues on the backend. just a user.

p.

phiw13 · 2017-02-13 22:50:32

jakob wrote #303999:

For tips, take a look at wet’s plugin template for adding fields to the user profile.

Thanks for the pointer! It is even easier than I thought it would be.

Bloke · 2017-02-13 23:20:57

maverick wrote #304001:

Imagining aloud

No need to imagine that bit! When I said ‘UI’ I should have been clearer, sorry. The (in need of merging with dev) custom-fields branch has a new panel Admin->Custom fields. In there you can add and edit any custom field for any content type that we permit out of the box. That includes articles, images, links, files, comments, sections, users, and categories. I think that’s it. But there are callbacks that allow plugins to alter or extend what content types are available.

Custom field data types are provided as a dropdown. Usual crew: textbox, integer, decimal, textarea, select list, radio set, blah blah. Again, callbacks allow plugins to augment or alter the available data types and map how they are represented in SQL. If there are options for people to choose from in radio/checkbox/select lists, you set them there. Unlike glz_custom_fields which mainly uses textbox (and occasionally text) fields, Textpattern figures out the most efficient storage methodology and creates the appropriate tables on the fly if you don’t currently have a table for the ‘type’ that best fits the intended data. That, by the way, was a bitch to write and get working!

Now, there’s one major caveat here: if you change a type, your data will be modged to fit into the destination type. For some data, it’s no problem. For other types this will either mean it’ll be truncated or lost. So think before you assign or alter a type. Or take a backup beforehand, tweak the .sql file you download and reupload it into the new type’s table.

All that is done and working, as far as I can remember.

Now, there’s one other field that the core doesn’t use: family (think grouping). It’s a completely freeform field. A plugin could hijack that to group fields, or you can (out of the box) type whatever you want against each defined field. That means, for example, you can define a bunch of fields and “group” them by giving a bunch of related fields all the same name: say, a Txp Section. I stress again here, core doesn’t do anything with that information in terms of tweaking the UI, but a plugin could use that to hook into the Section dropdown on the Write panel so it alters the available fields on change. Up to the plugin. 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.

With all that said, the next bit is the UI in terms of what you see on the individual panels: Write, Images, Files, Users, etc. Mainly I envisage that’s a drag ‘n’ drop feature, remembering what fields you dropped where on each panel. Again, nothing to stop a plugin going further (think about the above Section example) so the Write panel could have a different layout depending on the chosen Section, altering it on the fly. That’s not core functionality, though.

There’s also the behind-the-scenes SQL, which needs to start doing JOINs instead of just expecting all the data to be in the same table. That’s hardcore stuff that we need to manage carefully for backwards compatibility. Existing field content from the “main 10” is migrated on upgrade, that’s no problem. glz_cf data will need to be massaged first, but I’ll worry about that another day. But fashioning queries to efficiently get the data into our on-page globals is where the trick lies.

And then there’s tags. Expanding the <txp:custom_field> and associated conditional tag to be able to grab fields and display appropriate content. Even appropriate input widgets (maybe) based on the type of data expected. Who knows, maybe that’s plugin territory.

Bottom line is that the facility to define the CFs and store them is done (barring any bugs we find). How we allow people to enter data into those fields and then extract the info to display it is not. When I get round to merging dev with the custom-fields branch, I’m hoping that more people start to play with the back-end as it is now and we can then start to work out how to build core functionality to allow each panel to have access to the meta store, and how to efficiently expose that data to the website.

Last edited by Bloke (2017-02-13 23:26:22)

maverick · 2017-02-14 13:17:12

Bloke wrote #304010:

No need to imagine that bit!

Wow. I clearly did not realize how far along you were. This sounds great Bloke!

Last edited by maverick (2017-02-14 13:32:01)

bici · 2017-02-15 04:20:29

yabba dabba doo!

Destry · 2017-02-16 09:14:52

maverick wrote #304000:

I apologize Destry if I was stating an unspoken understanding.

No apology necessary. Always good to be sure. I certainly wouldn’t intend for anyone to do multiple developments of the same thing. I’d suspect Bloke would have that under control, and indeed he does. ;)

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.

Textpattern CMS support forum

#31 2017-02-13 18:52:50

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

maverick wrote #304006:

#32 2017-02-13 22:50:32

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

jakob wrote #303999:

#33 2017-02-13 23:20:57

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

maverick wrote #304001:

#34 2017-02-14 13:17:12

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

Bloke wrote #304010:

#35 2017-02-15 04:20:29

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

#36 2017-02-16 09:14:52

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

maverick wrote #304000:

#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:

Board footer