Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
-1 on anything that extends custom fields stored in the main textpattern table.
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
ruud wrote: -1 on anything that extends custom fields stored in the main textpattern table.
You mean, no more than 10 CFs in the tetxpattern table? I assume that you’re concerned this affects performance? If fields are only added past 10 when a user activates a new CF wouldn’t it be simply a caveat emptor kinda situation, ie…
user: “my performance sucks.”
dev: “Do you have 150 custom fields”
user: “176 to be precise”
dev: “dont do that”
Offline
#15 2009-09-21 21:17:43
- kevinpotts
- Member
- From: Ghost Coast
- Registered: 2004-12-07
- Posts: 370
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
ruud wrote:
-1 on anything that extends custom fields stored in the main textpattern table.
Ruud can you please expand on what you mean? I am very curious as to why you say this from a development perspective.
Kevin
(graphicpush)
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
I meant moving custom fields out of the textpattern table entirely if people want a variable amount of custom fields. It was already ugly with 10 fields, but that’s not enough reason to make it even worse.
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
fine by me.
- You could move ‘em all out if you included an upgrade script to migrate existing cfs that way.
- Would doing so affect performance, given that db calls would have to ding two tables and not one?
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
If one were to move custom fields out of the textpatern table couldn’t you just move everything out of it and assemble an article all out of custom fields? Hello cck.
Shoving is the answer – pusher robot
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
Or hello Symphony, about as abstract a CMS as there is. I don’t know how much pain would be involved in the transition, but custom fields in their own table, that could be applied to any content type, would be good fun.
Categories too, while we’re dreaming.
Code is topiary
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
hakjoon wrote:
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.
It’s not so easy, but it is possible to output content detail pages without involving articles. With Stef & Maniqui’s help we recently managed to generate working URLs to permlink each file in a particular category. Without testing I guess the a variation of that logic would allow you to generate image galleries too. From memory I think the key plugins were glz_cf (with a spot of regex) and smd_if.
Having said that, it did involve plenty of hoop jumping. I personally would have struggled to manage it without help from two of the most experienced Txp users around. Being tied so tightly to articles and article-based custom fields is one area where Txp reaches it’s natural limits of scalability IMHO.
Without much understanding of the trade-offs, I’d be a happy bunny if it was easier to do such things.
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
From memory I think the key plugins were glz_cf (with a spot of regex) and smd_if.
Pieman, it was gbp_permanent_links, not glz_cf.
And, in any case, Bloke and you were the ones who made the beast behave!
Pieman really knows how to handle gbp_p_l to go beyond the common /section/category/title setup.
So, a mix of:
- gbp_p_l (to create custom URL schemas that doesn’t throw a 404).
- an URLs dispatcher (we have done it with raw PHP’s explode function), which let you create some
txp:variables. - then you can do crazy stuff with smd_if, by testing those variables.
In any case, this thread is about uncapping custom fields powers…
I agree that the “article metaphor” falls too short some times. On the other hand, unlimited custom fields that can lead us to create unlimited cfields as textareas may create a big monster out of TXP.
Textpattern is a CMS (not a full-blown framework with ORM and all that geeky stuff —hard to learn— that would make some of us, TXP simplicity lovers, cry) created around the concept of “articles” as units of content. Not sure how or why, but that limitation sometimes feels like a bless. Usually, when you have a limited set of limited tools (strictly speaking, yes, every tool has its limits), you learn how to get the most of them on clever ways.
WP already has Flutter. Let’s see what TXP could come up with (maybe for TXP 5.0?).
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
ruud wrote:
I meant moving custom fields out of the textpattern table entirely if people want a variable amount of custom fields. It was already ugly with 10 fields, but that’s not enough reason to make it even worse.
Depends on the definition of “variable”, I suppose.
If, in OO lingo, variables are “per content object class”, the current flat table structure is the perfect match for the dogmatically correct normalized table, even if the data model is not hard-coded but defined at site-configuration time.
If “variable” means “variable per object instance” or “variable after site-configuration time”, it depends on how you address the performance penalties of m:n relations vs. flattening normalized tables.
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
mrdale wrote:
Great! So can you tell me how I can define 25 custom fields without a plugin… ie where’s the UI?
What’s the difference of a pluggable UI and a built-in UI (besides logistics and, apparently, cost)?
Textpattern core supports unlimited custom fields for articles without any patch, a dedicated, explicitly coded feature, new in 4.2.0, for plugins to build upon.
I think we have to cater for rather volatile needs in this area and thus a plugin-based UI is a benefit, not a burden.
Core has a release cycle of about six to eight months, while plugins can adopt to your wishes and act upon contributions in days or weeks. If demand arises, you do not need to fork the core for yet another custom fields UI which better suits your needs better than Gerhard’s implementation, you just have to commission a plugin writer.
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
wet wrote: What’s the difference of a pluggable UI and a built-in UI (besides logistics and, apparently, cost)?
In this case I think it’s the difference between a polished CMS with broad appeal and a patchwork quilt. TXP has some rough edges, quirks and non-intuitive stuff for the new user to decode…
If I were a new TXP user I would expect to see CF configuration in a content sub-tab with a couple of placeholder CFs and a big “Add Custom Field” button. Just like “Categories”. You create a new CF and it appears, and is configurable.
Regardless of where it sits I think that a simple mechanism to add/config more than 10 custom fields belongs in the core. Not talking something all glz/sed, just a way to create em, and rename em. Just makes sense. The requirement of a plugin to unlock basic functionality is flaky.
BTW, I have nothing against the pluggable UI, which I think is brill (since bloke showed me how) but it’s not something a beginner to intermediate user is going to tackle.
*That said, big ups to the devs! Being open to discussions like this is so much better [description of the bad old days omitted].
Offline