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)

gerhard · 2010-03-22 10:32:13

That’s a brilliant solution for get_prefs()!

I wouldn’t need to count anything with the new approach, neither would getCustomFields(). Rather than using a for loop to iterate over custom fields, I would use a foreach with $prefs['custom'], like this. A for could still be used, but I think that foreach would be clearer. Checking if a custom fields exists wouldn’t be necessary because get_prefs() already handles that.

Yes, $prefs['max_custom_fields'] would become redundant with prefs organized by event.

Bloke · 2010-03-22 10:48:23

gerhard wrote:

That’s a brilliant solution for get_prefs()!

I have my moments :-)

I wouldn’t need to count anything with the new approach, neither would getCustomFields().

Hadn’t thought of that, thanks for the code. It does add a query to grab the prefs a second time so we’d have to check if that has an impact in terms of page performance; not sure yet. Thinking trousers are on.

A for could still be used, but I think that foreach would be clearer.

Agreed. For the ordered parameter I was actually thinking more along the lines of group_by. With very little overhead to the function it could be possible to offer you the choice of grouping the prefs by ‘event’, ‘type’, ~~or ‘user_name’~~. Not sure *shrug* might be useful for some people, and it’s not much hardship over only allowing ‘event’.

Not sure if ordering by ‘html’ or ‘position’ is of any value so I’d probably not permit those. Whaddya think?

Last edited by Bloke (2010-03-22 10:55:29)

gerhard · 2010-03-22 11:07:17

Yeah, there already are 2 queries, adding a 3rd one would make get_prefs too complicated.

What about introducing a new get_ordered_prefs()? Eventually, it makes sense to transition from a single big array to a more ordered one (ie namespacing). getCustomFields() could be the first function to use the new prefs structure, other parts of TXP could transition to it as and when.

Also, you suggestion about ordering is a very good one. Again, get_ordered_prefs('event') would make most sense. I would keep this as simple as possible though, adding more options at this point would be “premature optimization”.

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

#673 2010-03-22 10:32:13

Re: glz_custom_fields

#674 2010-03-22 10:48:23

Re: glz_custom_fields

#675 2010-03-22 11:07:17

Re: glz_custom_fields

Board footer