glz_custom_fields

gerhard · 2010-02-18 07:42:46

speeke wrote:

For some reason, the plugin doesn’t like a custom field name that includes the word “range”.

Range is a trigger keyword for the plugin. If for example you have the following setup:

Price range $
1-10
11-20
21+

The plugin notices the range word and will automatically format the values as follows

$1-$10
$11-$20
$21+

Check the plugin help for more info on the ranges subject.

speeke wrote:

On a separate matter, I’ve changed the type preference for all glz_custom_f events in the txp_prefs table from 10 to 2 (as per Stef’s suggestion), and all appears to working well.

Thanks for confirming this, I have now changed the default behaviour, all plugin preferences will be updated to be of type 2 when you install the next version of the plugin.

gerhard · 2010-02-18 07:49:42

aslsw66 wrote:

Are you allowed to “plug” your own plugin in another author’s support thread?!

I am very glad Stef is chipping in on this thread, he can plug as many plugins as he wants here, I honestly don’t mind : ).

On the date & time custom fields note, I must agree that they have been quick implementations without much thought for stuff such as sorting or filtering. I have created a new issue on github, I will try to implement proper support for timestamps in the next version.

aslsw66 · 2010-02-18 09:49:14

Thanks for looking at this. I really like the implementation of the date and time pickers, but because I need the ability to extract and sort on the basis of dates I’m still having to use the article date as well.

Clearly, the best solution would be to store a date field as a date (because then smd_query can be used for those really tricky situations) but I guess that means the plugin would need to change the database structure.

vk · 2010-03-20 10:56:31

gerhard : Just sent you the donation... how to download the plugin ? Thanks! (sent from My paypal email : vikingkarwuryahoo.com)

gerhard · 2010-03-20 11:36:55

Hi Viking, I’ve just e-mail you all the details : ). Welcome to the club!

ps: I have also added you to the Google Group, you can find all versions of glz_custom _fields there.

kevinpotts · 2010-03-21 04:19:16

Now getting this error in my Write tab:

Notice: Undefined variable: custom_11_set in /path/to/mysite.com/textpattern/include/txp_article.php on line 478

Any clues on what is going on? I have been messing with the fields quite a bit, but this startin appearing out of nowhere. And one of my text_input custom fields just is not rendering info at all in an article form.

Now also getting this at the top of the admin page:

Warning: Unknown column 'custom_11' in 'field list' update textpattern set

Last edited by kevinpotts (2010-03-21 04:22:35)

gerhard · 2010-03-21 10:38:24

Hey Kevin, I am pretty sure Non-sequential custom fields will answer your question : ).

Bloke · 2010-03-21 10:43:54

gerhard wrote:

I am pretty sure Non-sequential custom fields will answer your question : ).

What needs changing in the core to support non-sequential CFs? Is it a trivial alteration or is it something that needs deeper thought? Or is it something glz_cf can work around with a bit of extra error checking?

Anything I can do to make the ride easier?

Last edited by Bloke (2010-03-21 10:46:21)

kevinpotts · 2010-03-21 12:55:25

gerhard — Thanks. So I guess I have to perform open heart surgery on MySQL with my wrecking crane skills.

gerhard · 2010-03-21 15:35:09

kevinpotts wrote:

gerhard — Thanks. So I guess I have to perform open heart surgery on MySQL with my wrecking crane skills.

Nope, you just need to create a new custom field. The plugin will figure which is the next custom field that needs creating.

gerhard · 2010-03-21 15:48:15

Bloke wrote:

Anything I can do to make the ride easier?

I’m really glad you asked mate! I came with a solution quiet a while back, but Robert thought it would impact the performance. So this is what I came up with last year.

I don’t really know what implications will that change have, but that’s what makes most sense in my opinion. It makes all $prefs more organized and easier to traverse.

The reason why we’re having problems with custom fields is because currently there is $prefs['max_custom_fields'] which counts how many custom fields there are. So if I have 1-10 & 11, 13, 15 max_custom_fields will be 13 and will assume that 1-13 exist, hence the undefined error. I cannot work around this because this is one of TXP’s core functions, getCustomFields().

Bloke · 2010-03-22 09:55:20

gerhard wrote:

I don’t really know what implications will that change have, but that’s what makes most sense in my opinion. It makes all $prefs more organized and easier to traverse.

If that would help, that’s easy to fix; we could add an optional argument to get_prefs() to allow you to return the prefs list sub-categorized if you wish. No backwards-incompatibilities would be introduced and no animals would be harmed.

Then you could simply re-fetch the $prefs array manually yourself and use that version instead of the one that TXP publishes, thus ignoring the max_custom_fields pref and counting it yourself.

However, that still might not address the inherent problem of holes in the custom field array. Bear with me while I think out loud here. As you point out, getCustomFields() grabs the ‘max’ custom field count — say it’s 14, made up of 1-10, plus 11, 12, 15, and 16 because 13 & 14 have been deleted — and only iterates up to this number. The fact that it checks if the custom_n_set is empty before populating the array is only half the issue; worse, it will only count as far as — in this case — 14. So the CF array will only contain 12 items; and items 15 & 16 will never be ‘seen’.

Not only is the warning issued by TXP because it only checks if the custom_n_set is empty and doesn’t check if it exists first (it should probably do that), it misses anything with an n > $prefs['max_custom_fields']. Does that about sum it up?

If optionally organising the prefs array by event is what you want and will allow you to build a better plugin, I can do that for you no probs. We should probably fix the getCustomFields() function too so that it uses actual custom_n_set fields and not computed ones based on max_custom_fields, though as Robert rightly said, we’d need to do that really efficiently; hmmm, that’ll require some brain power (any cool ideas?). Under this scenario, of course, it begs the question over the efficacy of $prefs['max_custom_fields'] at all!

Last edited by Bloke (2010-03-22 09:56:10)

Textpattern CMS

Textpattern CMS support forum

#661 2010-02-18 07:42:46

Re: glz_custom_fields

#662 2010-02-18 07:49:42

Re: glz_custom_fields

#663 2010-02-18 09:49:14

Re: glz_custom_fields

#664 2010-03-20 10:56:31

Re: glz_custom_fields

#665 2010-03-20 11:36:55

Re: glz_custom_fields

#666 2010-03-21 04:19:16

Re: glz_custom_fields

#667 2010-03-21 10:38:24

Re: glz_custom_fields

#668 2010-03-21 10:43:54

Re: glz_custom_fields

#669 2010-03-21 12:55:25

Re: glz_custom_fields

#670 2010-03-21 15:35:09

Re: glz_custom_fields

#671 2010-03-21 15:48:15

Re: glz_custom_fields

#672 2010-03-22 09:55:20

Re: glz_custom_fields

Board footer