Situation report for Textpattern 4.6 and beyond

etc · 2014-03-05 22:12:12

bici wrote #279488:

I would want Custom Fields to be available at the Article publishing stage, and as part of a Section. So Home, About, Movies, Default etc could all have different custom fields or could share a default set.
Does this make sense? Is this the direction being planned?

Sure, it makes sense (for me), but images, files, users and other units are not organized in sections.

Bloke · 2014-03-05 22:20:34

bici wrote #279488:

I would want Custom Fields to be available at the Article publishing stage, and as part of a Section. So Home, About, Movies, Default etc could all have different custom fields or could share a default set.

That was my thinking. Whether the CF’s automatically link to a Section or whether that is something we leave up to plugin authors is a decision we can make later.

I think what etc seems to be referring to is approaching things from another angle, i.e. custom content types. So for example you might create a ‘Movies’ content type by combining an article body (which you might label ‘review’), a Title, an Excerpt, three Image fields, a custom field called Trailer which can contain a YouTube link, and a ‘Star rating’ custom field. So when you want to write a review, you (somehow?) specify that’s the type of content you’re going to create and your Write panel shows only those fields. Please correct me if I’m wrong here, etc.

The ‘somehow’ in the above paragraph is the bit I don’t quite get because you still have to tie the output to a URL and you still need to be able to choose which Prototype you want to create content for. With such varied content and no commonality, things like article lists become interesting to render as you need lots of conditionals on the public side, and some clever mechanisms on the admin side to be able to manage the content. As it stands, with current adopted conventions, you know there’s going to be one body field and one title for every article at minimum, which makes your templates easier (if less flexible) to manage, and makes the admin side simpler.

It usually comes down to convention. If we can come up with a suitable convention that appeals to the majority of users who publish content, then a lot of the complexity can be taken out of the UI. That can make the code simpler, or lower the learning curve, or offer power for advanced content creation, but not usually all three at once.

Making a CMS infinitely flexible can become a chore to maintain because you need to spend days configuring everything up front. Having a few pre-defined conventions (e.g articles are the centre of the Textpattern universe) limits flexibility to some degree but gets you out of the blocks faster. Striking the balance is what we need, as ever.

And, as etc. says, Sections are article specific, which is kind of a spanner in the works, and why I’m on the fence about allowing CFs to link to Sections out of the box — it breaks convention across the content types.

bici · 2014-03-05 22:20:45

etc wrote #279489:

Sure, it makes sense (for me), but images, files, users and other units are not organized in sections.

I can see file types being added as options to Custom Fields : Files , Images, Select Dropdowns, Radio buttons etc.much as EE does. But I don’t see how users applies in Custom Fields

Bloke · 2014-03-05 22:23:19

bici wrote #279491:

I don’t see how users applies in Custom Fields

Profile pages? Like smd_bio. you might define User custom fields this way:

address-line-1
address-line-2
city
state
postal-code
phone
…

Or:

Department
Role / Job title
Manager
…

etc · 2014-03-05 22:26:26

bici wrote #279491:

I don’t see how users applies in Custom Fields

Currently, txp users have a very limited fields collection (login, real name, etc) that you might want to extend with date of birth, address, other info à la smd_bio. These would be CF for users.

bici · 2014-03-05 22:26:32

Bloke wrote #279490:

That was my thinking. Whether the CF’s automatically link to a Section or whether that is something we leave up to plugin authors is a decision we can make later.

Gee I hope there would be no need for plugins for CFs. They should stand on their own. The user creates the CFs for each Section and can assign CF types: Images, Files etc. This should make CFs infinitely useful across Sections. And shared across Sections. But yes if a plugin author wants to engineer the plugin’s to extend Cfs …well sure.

bici · 2014-03-05 22:29:17

etc wrote #279493:

Currently, txp users have a very limited fields collection (login, real name, etc) that you might want to extend with date of birth, address, other info à la smd_bio. These would be CF for users.

I understand. I agree. It’s not a CF type but another list of CFs for the Admin area: i this case USERS. In this case permissions levels could also be baked in at the USER level without the need to have the bot_privs plugin.

Bloke · 2014-03-05 22:50:50

bici wrote #279494:

Gee I hope there would be no need for plugins for CFs.

Why not? Allowing plugins to jump in and alter things is the spirit of Textpattern. At the moment, the CFs would work exactly as they do now, it’s just that instead of only text fields limited to 255 chars, you can choose different types of input. Selects, radios, textareas, blah blah.

Until we figure out how this’ll work at a UI level, I don’t want to think about enforcing a custom field lodged against an article to have an implicit link to a particular Section. You might want the same field (e.g. “YouTube link”) to be applicable across a few Sections, for example. Plus, it complicates the interface for configuring them because no other content type has the concept of a Section, so you need a special type of UI workflow for articles, which is something I’d like to try and avoid. Hence my notion of a freely editable ‘group’ for each field. No implied structure. No implied meaning. You can do with it what you like and apply your own meaning.

If you want to make that link between sections as a site admin, you can do that with five or ten lines of code. We might even offer some officially sanctioned scripts that do this kind of thing, who knows. The point is, if you as a content creator want to link the CFs to Section AND category, we shouldn’t limit you by enforcing the Section-CF link for articles.

I’ll just share an example of the kind of convention I mentioned in my previous post. The way CFs are defined in the database at the moment, they have a data-type which is the field type in the database. But to expose that level of control to most users is unrealistic: who knows whether it’s better to store something as a Text field vs a Varchar(511)?

So, while Textpattern deals with this kind of thing as its currency, you, the site designer won’t. In the code is a function call with a simple map that links a ‘widget’ with a suitable representation for that type’s values. For example:

Radio button -> boolean
Select list -> varchar
Text input -> varchar
Radio set -> boolean
Text area -> Text

Textpattern manages the tables for you under the hood and stuffs the content in the most appropriate table for you, based on the type of content you want to store, without being wasteful. There are only 3 types of content in the above list — boolean, varchar and text — so you’d have three tables storing relevant content for each field.

So, out of the box, I’ve abstracted away the decision making process into a set of reasonable UI choices. Of course, that won’t suit everyone which is why before this list is rendered to the screen, plugins get to play. A plugin could alter one of the types. Maybe you want text areas to be stored as varchar(511) instead of the relatively expensive Text field type. No problem: three lines of code to make the change and Txp does the rest on your behalf. Or if you wanted to add a new type of field entirely, so be it. You add the widget type to the list via the callback, tell it the database field type to store it in, and write a couple of functions to tell it how to a) render it to screen, and b) what to do with the data prior to storage (if it’s significantly different from the routines present in core), then Txp does the rest.

I’ve got the primary callbacks in place for the mappings. The ones regarding rendering UI widgets, validation and pre-processing will come when the UI parts are realised. But the point is, I’ve chosen to adopt a convention which not only simplifies administrator’s lives and simplifies the code (and database) somewhat by taking away some of the decision-making process, it allows plugins to take it to whatever level you need.

P.S. Whether all this works in practice remains to be seen. It might just all be hot air :-)

Last edited by Bloke (2014-03-05 23:00:46)

etc · 2014-03-05 22:50:54

Bloke wrote #279490:

I think what etc seems to be referring to is approaching things from another angle, i.e. custom content types. So for example you might create a ‘Movies’ content type by combining an article body (which you might label ‘review’), a Title, an Excerpt, three Image fields, a custom field called Trailer which can contain a YouTube link, and a ‘Star rating’ custom field. So when you want to write a review, you (somehow?) specify that’s the type of content you’re going to create and your Write panel shows only those fields. Please correct me if I’m wrong here, etc.

You are absolutely right. The site admin creates a ‘Movie’ prototype, and authors create instances of it. Specifying the content type could be just a matter of clicking on ‘Movie’ in ‘Content’ tab.

The ‘somehow’ in the above paragraph is the bit I don’t quite get because you still have to tie the output to a URL and you still need to be able to choose which Prototype you want to create content for. With such varied content and no commonality, things like article lists become interesting to render as you need lots of conditionals on the public side, and some clever mechanisms on the admin side to be able to manage the content. As it stands, with current adopted conventions, you know there’s going to be one body field and one title for every article at minimum, which makes your templates easier (if less flexible) to manage, and makes the admin side simpler.

Well, no body field — no body output, caveat emptor. We have already this problem with <txp:custom_field name="not_existing" />. Basically, everything (body, excerpt) becomes a custom field. But every content instance needs some url identifier, of course. Well, let’s sleep on it.

springworks · 2014-03-06 08:30:38

etc wrote #279498:

But every content instance needs some url identifier, of course. Well, let’s sleep on it.

I’m not sure I completely agree with that.

I’ve built plenty of sites where I’ve used content instances for parts of pages, where the content instances themselves are never referenced on their own by a URL.

Bloke · 2014-03-06 08:47:17

springworks wrote #279502:

I’ve built plenty of sites where I’ve used content instances for parts of pages, where the content instances themselves are never referenced on their own by a URL.

Interesting, do you have some Page template examples you could share?

To get this straight in my head, you have articles in sections that you don’t expose to a URL (hidden status, maybe?) but you use them internally in your Page/Forms to compile a ‘master article’ that visitors can see? Is that so you can get authors to write content in a familiar interface without having to expose them to Forms?

I’m curious how that all works, given Textpattern’s one-article-to-one-URL paradigm.

springworks · 2014-03-06 08:56:15

I think there’s a danger here with looking at another CMS and just trying to copy that, rather than thinking about what is the best and most flexible way of implementing CFs. I realise I may be guilty of this by mentioning ExpressionEngine earlier in this thread! ;-)

And to risk digging myself in deeper…

EE has the idea of channels as content silos. Each channel has its own set of custom fields, but one or more channels can share the same set of custom fields. Similarly, each channel can have their own specific categories and statuses too.

So with EE you can have several different sets of custom fields, categories and statuses and these can be assigned to different channels at will. Note, however, that it is not necessarily normal to have the same custom fields, categories and statuses shared between several channels of content, so individual pieces of content are very much ring-fenced in their own channel. You can only move content from one channel to another if they both share the same custom fields, categories and status groups.

URLs are primarily dependent on template groups and templates, rather than channels, so there is no direct link between a content silo (channel) and a URL structure, unless the developer decides to create one.

In Textpattern, we currently have just one content silo, which includes all the custom fields created for the site, plus (article) categories, sections and statuses. So, currently in Txp the section that a piece of content resides in is fluid and can be changed easily.

But, with section, we have an attribute of a piece of content (article) that is commonly used to decide which area of a site it lives in (and hence its URL).

Txp uses sections (and linked pages) to create site structure and, commonly, URLs.

To use the same attribute to determine what type of content is represented in that part of the site seems to be overly restrictive so I think I’m coming around to idea of needing some other “thing” to determine the data structure of a piece of content other than its position in the site navigation.

Textpattern CMS

Textpattern CMS support forum

#37 2014-03-05 22:12:12

Re: Situation report for Textpattern 4.6 and beyond

bici wrote #279488:

#38 2014-03-05 22:20:34

Re: Situation report for Textpattern 4.6 and beyond

bici wrote #279488:

#39 2014-03-05 22:20:45

Re: Situation report for Textpattern 4.6 and beyond

etc wrote #279489:

#40 2014-03-05 22:23:19

Re: Situation report for Textpattern 4.6 and beyond

bici wrote #279491:

#41 2014-03-05 22:26:26

Re: Situation report for Textpattern 4.6 and beyond

bici wrote #279491:

#42 2014-03-05 22:26:32

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #279490:

#43 2014-03-05 22:29:17

Re: Situation report for Textpattern 4.6 and beyond

etc wrote #279493:

#44 2014-03-05 22:50:50

Re: Situation report for Textpattern 4.6 and beyond

bici wrote #279494:

#45 2014-03-05 22:50:54

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #279490:

#46 2014-03-06 08:30:38

Re: Situation report for Textpattern 4.6 and beyond

etc wrote #279498:

#47 2014-03-06 08:47:17

Re: Situation report for Textpattern 4.6 and beyond

springworks wrote #279502:

#48 2014-03-06 08:56:15

Re: Situation report for Textpattern 4.6 and beyond

Board footer