Custom fields as part of core

Algaris · 2012-06-25 10:25:03

wet wrote:

I’d rather aim at a more general key/value store. I suspect that once we have unlimited custom fields there’s another group of people who (gasp!) want unlimited categories or more than one image field….

Yes please. I’d like to have my cake and eat it if I may.

Last edited by Algaris (2012-06-25 10:25:22)

Bloke · 2012-06-25 10:29:49

wet wrote:

I’d rather aim at a more general key/value store.

That would also work and is a shedload less effort, which gets my vote. As well as food for thought, my post does highlight the amount of graft involved in the process which is as much a turn-off as the desirability to have it!

When the Basic/Advanced prefs panel is merged into a single, more manageable structure, perhaps that would be a good point to think about key storage. I see a couple of foundation stones already :-)

Last edited by Bloke (2012-06-25 10:32:11)

wet · 2012-06-25 10:37:51

In WordPress they have a nice implementation of lazy-loaded user data from a meta store via magical getters/setters. Perch has similar interiors though one cannot look into it without buying a license from Drew ;)

Destry · 2012-06-25 11:22:33

Bloke wrote:

I don’t really have a clear notion over what should be core and what shouldn’t in this regard.

That’s a worthy point of discussion. Without giving a song and dance about how CMS projects should be looking to the future and taking cues from emerging market demands and niche opportunities, let me just say that a good rule of thumb for the near future, for the sake of progress, is: if the functionality in question is an improvement on functionality that already exists, make the improvement to the core. If it’s an “extension”, make it a plugin.

I think this thread’s topic is clearly defined as core domain. That doesn’t mean it has to work like presented, this is all just brainstorming, after all. But as far as what’s taking place here in this discussion, it’s perfectly on track with doing things right. 1) Somebody or three offers concepts and sketches them out. 2) Somebody else or two who’s more intimate with the code says ‘no’ to this and ‘yes’ to that and a feasible plan starts shaping up. Perfectly normal.

The majority of people here who voice opinions are what I term “power users” and we need to be careful to balance the requirements of these good folk with overburdening the novices or introducing whizzy features that only 10 or 20% of people will use (however great that may be).

I totally agree. I am one power user in the choir you’re preaching to. I came out of grad school nine years ago with a degree in Tech Comm and UCD—which I only say to emphasize the next clause—so the humble user is always front and center in my scope. But without real user enquiry (say from surveying clients we’ve build sites for and reporting that data back to the group) then we have to make a call somewhere, and you make that call from the expert users. I think we have a lot of people in this community who understand that and can say ‘stop’ on something when it needs to be said. In the course of that, however, discussions like this are needed, and usually lead to better things—I have faith.

Let’s be pragmatic about this…

We are. Every new build, if you will, requires some kicking around and sketching for fit and fitness. That exploratory stage is pragmatic.

Ed.: Ha! I“m like 5 posts late already, oh well. Just keeping even keel, is all I’m trying to do.

Last edited by Destry (2012-06-25 11:23:42)

mrdale · 2012-06-25 15:25:31

bloke said
Finally, fugure out how to display it all on the Write, Image, File, and Link panels.

I knew this conversation would eventually come around to the mutinous idea of (ahem) custom content types. ;) there I said it again after all these years. Seems to me that the real way to build it, v5 style, would be to make a content routing table and allow content types to be a collection of these fields in any order and combination. Accessible by a common tag, ie.

<txp:content type="people" limit="3"><txp:custom _field name="gender" /></txp:content>

A new content type produces a new sibling to the articles tab. Another tab under admin would let you construct and order your content tabs.

And no, I don’t want to go use drupal. We’ve had quite enough of that nonsense already.

Bloke · 2012-06-25 15:45:35

mrdale wrote:

A new content type produces a new sibling to the articles tab. Another tab under admin would let you construct and order your content tabs.

Do we get free riding lessons with this pony?

^{(a.k.a. if you thought my post above sounded like a truckload of work, imagine how much this would be)}

Last edited by Bloke (2012-06-25 15:46:39)

renobird · 2012-06-25 15:58:37

Dale,

It used to be a dead horse, now it’s just a bag of dry bones that gets brought out and beaten from time-to-time.

:)

maruchan · 2012-06-25 16:06:53

Which reminds me:

<txp:cms type="tumblr" pagerank="7" style="elegant, hand-crafted, edgy" mood="yellow" just="pops" />

I’ve had a few clients request something like that in the past.

Last edited by maruchan (2012-06-25 16:07:03)

mrdale · 2012-06-25 16:16:54

Yeah, ok guys. your’re right. sqtms

bloke… right on as usual.
reno… how’s that flaming bag of poo I left on your doorstep going?
marc… damn funny. style="elegant,handcrafted, edgy" made me litereally LOL

That was my last post on CC Types. I promise.

I realize that would mean a hoover damn sized project, so the horse has officially decomposed to dust and no further flogging will occur. I’m letting the magical pony free.

I like the way TXP is moving ahead. Just puttered around with a bleeding edge build and there’s a lot of good hard work on everyone (else)s part in there. Excellent work guys.

Now can we talk about unlimited universal categories? That counts as a separate horse/pony right?

^{mrdale scurries off and hides in a corner… starts whistling}

Last edited by mrdale (2012-06-25 16:29:46)

maverick · 2012-06-25 22:41:32

As the discussion has unfolded re: unlimited custom fields linked to sections (and/or categories), with custom grouping and flexibility in displaying on the page, as well as the custom content, it reminds me a bit of what Symphony CMS was doing last time I checked in on it. Basically they had an admin tab that allowed you to create templates for other admin tabs.

In the imaginary world of “if only we could”: Build our own admin side tabs using txp tags (Stef got us part way there with smd_tabber – thanks again Stef)

Whatever may come to fruition from this discussion, I appreciate all the work, changes, and direction Texpattern CMS is receiving from so many of you.

mrdale · 2012-06-26 00:07:18

maverick wrote: In the imaginary world of “if only we could”

welcome to ponyville

maruchan · 2012-06-26 00:24:10

it reminds me a bit of what Symphony CMS was doing last time I checked in on it

I know at least renobird and I have been invoking some ProcessWire features here, but there is a fair amount of overlap between Symphony and PW in terms of end-user features.

I’m pretty happy with the direction of TXP 4.5 though, and the way it points toward future developments, so I have to say that I’m not interested in TXP becoming a clone of some other CMS. Of course, a lot of the features are sufficiently generic that it seems worth looking over the fence and scrutinizing other implementations.

It really feels like TXP is developing at a vigorous pace these days, and it’s great to see the things that TXP core devs and designer are bringing up.

Last edited by maruchan (2012-06-26 00:26:20)

Algaris · 2012-06-26 08:02:01

mrdale wrote:

Now can we talk about unlimited universal categories? That counts as a separate horse/pony right?

I’d love this to come to Textpattern at some point (even if it’s further down the road). I’ve lost track of the number of times I’ve wanted to assign an image to more than one category.

tye · 2012-09-13 05:57:39

Just a couple more ideas…. can the new custom fields have a small field for a description (for image sizes for example), and the option to make a custom field ‘required’ before article can be saved

Destry · 2012-09-13 06:52:22

tye wrote:

can the new custom fields have a small field for a description (for image sizes for example), and the option to make a custom field ‘required’ before article can be saved

Hmm… Fields on fields is going to start looking pretty congested in the UI, I think. If you have a specific need for image size descriptions (I’m guessing as a kind of user instruction/reminder), then just put it on the custom field’s name, e.g., XYZ Image 300×250. (Though using sized images anymore is probably something to try and stay away from in design, unless you’re already sizing with responsiveness and retina in mind.)

For making a custom field required, granted this could be useful in some cases (for the mavericks), and I wouldn’t have any objection if it was added, but this is really a question of having the proper editorial tools and workflow in place: style guides, page tables/templates, etc. No author should be publishing anything if they don’t know the procedure for what should be posted and how, and then somebody else should be reviewing the draft (everyone needs a spotter for web content) to catch typos, missing data, etc. Part of the workflow. Documentation and workflow first! Then the tyranny if it’s really needed.

I don’t know if this is helpful, but here’s a little trick I use sometimes. Let’s say you’re talking about an image (could just as well be a pull quote, or whatever)… In your output form (article…whatever), use a conditional that outputs the image, and if the author didn’t provide an image, the conditional spits out a nasty message where the image is supposed to be: “Forget something? Image here please. Go see custom field XYZ Image 300×250 in the Write panel!”.

Works great. If they ever let one of those slip into public, they’ll never forget again. ;)

Textpattern CMS

Textpattern CMS support forum

#31 2012-06-25 10:25:03

Re: Custom fields as part of core

#32 2012-06-25 10:29:49

Re: Custom fields as part of core

#33 2012-06-25 10:37:51

Re: Custom fields as part of core

#34 2012-06-25 11:22:33

Re: Custom fields as part of core

#35 2012-06-25 15:25:31

Re: Custom fields as part of core

#36 2012-06-25 15:45:35

Re: Custom fields as part of core

#37 2012-06-25 15:58:37

Re: Custom fields as part of core

#38 2012-06-25 16:06:53

Re: Custom fields as part of core

#39 2012-06-25 16:16:54

Re: Custom fields as part of core

#40 2012-06-25 22:41:32

Re: Custom fields as part of core

#41 2012-06-26 00:07:18

Re: Custom fields as part of core

#42 2012-06-26 00:24:10

Re: Custom fields as part of core

#43 2012-06-26 08:02:01

Re: Custom fields as part of core

#44 2012-09-13 05:57:39

Re: Custom fields as part of core

#45 2012-09-13 06:52:22

Re: Custom fields as part of core

Board footer