Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Hooks for more custom fields
I’m loading glz_custom_fields on pretty much every site. It’s pretty much indispensable if you need to coerce your users input into standard ranges. It has a whole host of other benefits. To use this plugin properly it requires hacks to the core getCustomFields function.
I’m not making a pitch to bring this functionality into core, because not everyone needs/wants it. Rather that the infrastructure to handle it should become core.
What would be cleaner is if getCustomFields could be altered to accommodate more than 10 custom fields without breaking existing functionality. This is not rocket science, donesn’t screw anything existing up, and would have benefits for everyone.
Please?
Offline
Re: Hooks for more custom fields
I haven’t used glz_custom_fields, but I don’t see why it doesn’t use its own tables. For TXP itself, it would be a lot nicer if custom fields were moved into their own table, which would allow for unlimited fields. Something like txp_cfs(parentId, cfId, type, value) and txp_cf_type(id, name) (for cf type, like radio button, textarea, etc.). However, this is also something a plugin could do with minimal duplication of core code.
Offline
Re: Hooks for more custom fields
jm wrote:
For TXP itself, it would be a lot nicer if custom fields were moved into their own table
Yes, it would. So would categories. Compatibility suggestions, anyone? (No, database views are not an option.)
Offline
Re: Hooks for more custom fields
jm I haven’t used glz_custom_fields, but I don’t see why it doesn’t use its own tables.
I think it actually does. but it also allows you to customize the first 10…
Personally I think all content including articles belong in their own tables.
I’m looking for an simple incremental solution for the existing behavior that will almost get us to customizable content types (glz_custom_fields + sed_section_fields), not a broad sweeping solution that we all have to agree on. Been there, done that.
;)
Last edited by mrdale (2009-03-10 17:54:57)
Offline
Re: Hooks for more custom fields
So, er Wet…
How about the original topic? Big changes mean slow changes. How about some low hanging fruit?
Last edited by mrdale (2009-03-10 17:56:50)
Offline
Re: Hooks for more custom fields
Define: When will the number of cfs be determined? At setup, once, ad lib?
Offline
#7 2009-03-10 18:31:09
- masa
- Member
- From: Asturias, Spain
- Registered: 2005-11-25
- Posts: 1,091
Re: Hooks for more custom fields
While I haven’t yet hit the 10-cfs limit, I would prefer, if you could add more cfs at any time. Sites tend to evolve and it’s impossible to make the right assumptions in the very beginning.
Offline
Re: Hooks for more custom fields
I think this is all mrdale is asking for, as a replacement to function getCustomFields() near line 1145 in publish.php:
function getCustomFields()
{
global $prefs;
$out = array();
$i = 0;
$custom_fields_num = count(preg_grep("(^custom_\d+_set$)", array_keys($prefs)));
while ($i < $custom_fields_num) {
$i++;
if (!empty($prefs['custom_'.$i.'_set'])) {
$out[$i] = strtolower($prefs['custom_'.$i.'_set']);
}
}
return $out;
}Presently the number of custom fields is hard coded into this function, but the modified version above allows the glz tag to publish custom fields beyond the previous limit, without seeming to break anything else.
Incorporating this function into the core would be useful to me too, even without more extensive changes to the way custom field infor is databased.
Offline
Re: Hooks for more custom fields
masa> Thanks, yes that is what I meant. Seems like it’d do no harm right?
Offline
#10 2009-03-10 22:00:39
- redbot
- Plugin Author
- Registered: 2006-02-14
- Posts: 1,410
Re: Hooks for more custom fields
FWIW I agree on every word mrdale said at the beginning of this thread.
I was about to ask the same identical thing so
1) thank you mrdale for raising the question
2) thanks to everybody else answering here and here
Offline