Perennial "Improved (and unlimited) custom fields in core" discussion

mrdale · 2009-09-21 17:29:42

This one has been kicking around for almost the entire life of TXP, and has resurfaced again in discussion of the next version of glz_custom_fields so…

I propose we talk about moving basic unlimited custom field functionality into core. Then allowing custom field types and exotic configurations to be handled by plugins like glz_custom_fields.

Further, I think TXP devs should expose a roadmap of features and functionality.

Anyone?

Last edited by mrdale (2009-09-21 17:34:40)

wet · 2009-09-21 18:10:05

First, I’d like to add some pointers regarding the current state of affairs in this matter:

As per Textpattern CMS 4.2.0, plugin authors have a well-defined interface to extend articles, images, files, authors, sections, categories, and links at their disposal.

glz_custom_fields is probably the best-known plugin which takes advantage from this capabilities for articles, while Bloke’s smd_bio and my wet_native allow extra fields for authors. sed_section_fields would be a great candidate for a 4.2.0-compatible realign.

So, with 4.2.0 we have a built-in base for plugins to work with all intrinsic content types. We do not have any base for building custom content types like e.g. Drupal has with CCK. Would we want this, given the increase in complexity this burdens on the site builders’ shoulders?

kevinpotts · 2009-09-21 18:11:23

This is definitely something I’ve brought up and written about for years. Right now, I think the native functionality works great — if someone needs a basic website (such as a blog), TXP works well out of the box because a number of key fields (title, body, excerpt, keywords and publish/expiration date) are right there for use. A designer getting their feet wet has no immediate need for custom fields.

However, when TXP made custom fields available, the functionality possibilities scaled tenfold — even with just a limit of ten text fields. But it was like getting on an elevator going 90 MPH and immediately slamming into a ceiling. To get the most power, custom fields functionality needs to go to the next level — the development of custom schemas.

In my workplace, we use SDL Tridion, which is a very expensive and for the most part cumbersome product. In many ways it is a nightmare to get things in order (stuff that TXP handles with absolute ease). But it’s one feature that we website builders love, and which it handles well, is the development of custom schemas. This enables us to look at a particular section of the website, and dictate exactly what data fields are needed, which will be required, and how they collect data (textareas, dropdowns, multi-selects, radio buttons, etc).

Wet asks about target audience, and essentially, if this will lead us into the world of “developer CMS” versus “designer CMS”. While I could expound on this back and forth all day, it comes down to this. Textpattern out of the box is an elegant, designer-frindly CMS that gets most people where they need to go. I do not think layering in additional functionality to custom fields jeopardizes this at all. In fact, I find some of the newer tags and their functionality (if_different, yield, variable) far more developer-centric than just giving more options in the administrative interface and using the same familiar tags to unlock more of their power.

There have been so many incredible advancements in this system over the last two years, and I finally feel as if we are using a CMS that could take over the world. Some quick examples:

Multi-site capability
The ability to use the form attribute on section and category tags
Front-end searching across all article data versus just title and body
Nested variables and conditionals

Expanding the functionality of custom fields would be equally game-changing, and for me at least (and I think there are others who feel this way) a far better use of worth-their-weight-in-dilithium-crystals development resources than stuff like the yield tag. (I have nothing against the yield tag — it is great — but it just would not have been anywhere near the top of my “gotta have” feature list.)

Enough from me for now. I hope others weigh in as well.

masa · 2009-09-21 18:14:55

mrdale wrote:

I propose we talk about moving basic unlimited custom field functionality into core. Then allowing custom field types and exotic configurations to be handled by plugins like glz_custom_fields.

Yes, that gets my vote, too.
The ability to add more standard custom fields is probably sufficient for a lot of applications. Then let optional plugins take care of the modifications such as turning the custom fields into drop-downs, textareas etc.

wet · 2009-09-21 18:18:29

masa wrote:

Yes, that gets my vote, too.

This is what we already have now.

kevinpotts · 2009-09-21 18:21:29

I propose we talk about moving basic unlimited custom field functionality into core. Then allowing custom field types and exotic configurations to be handled by plugins like glz_custom_fields.

To be specific, and inline with wet’s comment above, I am advocating for the functionality of glz_custom_fields to be rolled into the core wholesale, and then extended to all data types (articles, files and images, specifically, since the recent smd_bio just knocked it out of the park for authors).

colak · 2009-09-21 18:22:23

Playing devil’s advocate: It is true that custom fields can make some aspects of site management easier but wouldn’t an unlimited number of them make things unnecessarily complex?

kevinpotts · 2009-09-21 18:24:18

Playing devil’s advocate: It is true that custom fields can make some aspects of site management easier but wouldn’t an unlimited number of them make things unnecessarily complex?

I guess I don’t understand your question. A designer/developer would only use the fields they needed. I have developed sites without any; I’m working on another one now that requires 15.

masa · 2009-09-21 18:45:17

wet wrote:

This is what we already have now.

I was under the impression, that while unlimited CF support is built-in now, we would still need to resort to a plugin to go beyond the limit of 10 ?!

Sorry, if I misunderstood.

Last edited by masa (2009-09-21 22:48:02)

hakjoon · 2009-09-21 19:03:06

Regarding content-types I think there is middle ground that could be achieved without building out something like CCK. One issue I have is that given the way the URL resolving works the only “first class” content-type in TXP is the article. I can’t for example create a /section/image-title url, so even if I can add all the fields I want to image I still have hamstring it somehow into an article for it to be called, this requires jamming everything into article, which is awkward.

If we could have the other content-types tie into the url resolution than new content-types could be built out as plugins without requiring something as complicated as CCK.

That way I don’t have to cram file info into an article that is attached to a file it can just be part of a display method for the file. Doing image galleries wouldn’t require articles with article images you culd link to image pages created form the images.

Just a thought, this could lead the way to something like CCK but it wouldn’t have to, and the “designer” user would just ahve install plugins for the new types.

mrdale · 2009-09-21 19:06:51

wet wrote: This is what we already have now.

Great! So can you tell me how I can define 25 custom fields without a plugin… ie where’s the UI?

Last edited by mrdale (2009-09-21 19:07:01)

mrdale · 2009-09-21 19:15:14

hakjoon wrote: If we could have the other content-types tie into the url resolution than new content-types could be built out as plugins without requiring something as complicated as CCK.

That way I don’t have to cram file info into an article that is attached to a file it can just be part of a display method for the file.

+1 as long as it doesn’t add massive overhead.

I’ve been a fan of this approach for a while. It would certainly make TXP easier to learn, being that other content’s listing tags would behave exactly like the article tag with output being piped through forms…

Last edited by mrdale (2009-09-21 19:16:23)

Textpattern CMS

Textpattern CMS support forum

#1 2009-09-21 17:29:42

Perennial "Improved (and unlimited) custom fields in core" discussion

#2 2009-09-21 18:10:05

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#3 2009-09-21 18:11:23

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#4 2009-09-21 18:14:55

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#5 2009-09-21 18:18:29

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#6 2009-09-21 18:21:29

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#7 2009-09-21 18:22:23

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#8 2009-09-21 18:24:18

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#9 2009-09-21 18:45:17

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#10 2009-09-21 19:03:06

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#11 2009-09-21 19:06:51

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#12 2009-09-21 19:15:14

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

Board footer