Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 953
Website

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

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.

Offline

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

Destry
Moderator
From: Alemannia
Registered: 2004-08-04
Posts: 3,266
Website

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

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.

Offline

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

sacripant
Plugin Author
From: Rhône — France
Registered: 2008-06-01
Posts: 449
Website

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

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 7,485
Website

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

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


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

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 7,485
Website

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

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.


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

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

Destry
Moderator
From: Alemannia
Registered: 2004-08-04
Posts: 3,266
Website

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

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.

Offline

Board footer

Powered by FluxBB