glz_custom_fields

gerhard · 2009-11-23 14:45:38

speeke wrote:

Just wondering what the size limit is for a custom field of type select.

There is no limit for how many values a select/radio/checkbox custom field can have. Each value corresponds to 1 row in the custom_fields table.

whaleen · 2009-11-23 23:51:38

gerhard wrote:

whaleen wrote:

A routine that would update all modified values per custom field then one could change: bugz to bugs and all articles assigned that value would have that custom fields column updated.

I feel this functionality wouldn’t benefit a lot of users and for the effort required, there is a quicker way. Check this article which I posted a few years back.

That is a perfect solution Gerhard. Thanks. I may be able to concoct some controls for dummies with smd_query. Thanks for the forthcoming DatePicker too!

Last edited by whaleen (2009-11-23 23:52:57)

Cantide · 2009-11-24 02:22:35

Hi there,

wondering if it’s possible to change the | character used as a separator for field values to a comma, so I can input those values as HTML Form Select values (actually in a zem_contact_select element, as comma-separated words turn into Form Option Values)

i.e. the custom fields used in a ‘product’ article become the options in an order form attached to that article?

I had a quick search through the source of the plugin but couldn’t find something that looked like it could be changed without breaking something…

This could possibly be put into a future version as an option in Plugins > glz > Options

Cheers,
Dan

Last edited by Cantide (2009-11-24 02:42:07)

whaleen · 2009-11-24 02:40:36

Cantide wrote:

wondering if it’s possible to change the | character used as a separator for field values to a comma, so I can input those values as HTML Form Select values, i.e. the custom fields used in a ‘product’ article become the options in an order form attached to that article?

I’ve been using this plugin to help with something like that. Whatever the custom_11 outputs for separators gets replaced with what you specify using this plugin.

<txp:rah_replace from=" | " to=", ">
<txp:custom_11 /> for example outputs: This | That | Other
</txp:rah_replace>

Becomes: This, That, Other.

Last edited by whaleen (2009-11-24 02:46:57)

Cantide · 2009-11-24 02:43:40

Thanks heaps whaleen, I’ll try it out and post the results of my cross-plugin/CMS/language experiment…

Cantide · 2009-11-24 04:28:04

It looks like the statements are being parsed in the wrong order within TXP’s logic. Within my ‘misc’ TXP-Form:

<txp:rah_replace from="|" to=",">
<p><txp:zem_contact_select label="Size:" list='---,<txp:custom_field name="size" />' selected="---" /></p>
</txp:rah_replace>

(where the normal ouput of custom_field name="size" is small|medium|large|x-large ), is outputting:

<option>smallmediumlargex-large</option>

instead of:

<option>small</option>
<option>medium</option>
<option>large</option>
<option>x-large</option>

in the zem_contact form.

Interestingly, without the rah_replace container, it won’t parse at all. With, spaces around the commas are included, but no commas, and certainly not the comma’d string I desire for the zem_contact_select to parse into <option> tags.

Cantide · 2009-11-24 04:38:59

Well, I found a solution for anyone interested:

<p><txp:zem_contact_select delimiter="|" label="Size:" list='---|<txp:custom_field name="size" />' selected="---" /></p>

The delimiter option to the rescue, thus removing the need for rah_replace or any change to the default glz_custom_fields separator character. It parses properly, leaving me with a wonderful user-definable, per-product drop-down Select box.

Interestingly, commenting out the rah_replace tags:

<txp:hide><txp:rah_replace from="|" to=","></txp:hide>
statements...
<txp:hide></txp:rah_replace></txp:hide>

while I was testing had no effect, they seem to override <txp:hide>

Cantide · 2009-11-25 19:18:04

1. To my understanding, if you were to create something like a Checkbox-Type custom field, and entered a bunch of values, Custom Sets Ordering would control the alphabetical/numerical order of the resulting fields.

They would be in both the Article ‘Write’ interface where those custom fields were available to interact with, and in your Article output, through the <txp:custom_field name="fieldname" /> tag.

I guess that’s helpful for custom fields that you add values to over time, but don’t want to manually sort them alphabetically each time.

2. In admin > prefs > basic > values_ordering — that’s exactly the same variable as available in Plugins options: Order for custom field values — it’s linked to this one. I don’t think these options should be available in Admin > Prefs — as they’re for a specific plugin, not TXP itself.

Feature request!:)

Hope that helps.

Last edited by Cantide (2009-11-25 19:18:29)

redbot · 2009-11-25 23:28:21

speeke wrote:

…If that’s true, then my value of custom in values ordering should be as entered to match the option in Order for custom field values.
Not sure where custom came from. I wonder, should I change it???

No. Plugins preferences should be changed from the plugins tab only.

BTW – Sarah, Gerhard and all, I noticed there must be some little problem with txp 4.2 as even with other plugins preferences are showing in the “basic preferences” tab when they shouldn’t.
This seems to happen only if a value is set for column “html” in the “txp_prefs” table.

Last edited by redbot (2009-11-25 23:32:20)

gerhard · 2009-11-29 21:39:42

rebdot wrote:

BTW – Sarah, Gerhard and all, I noticed there must be some little problem with txp 4.2 as even with other plugins preferences are showing in the “basic preferences” tab when they shouldn’t. This seems to happen only if a value is set for column “html” in the “txp_prefs” table.

Luca, thanks for your input mate. The problem with plugin configuration values has been addressed, it will be fixed in the next revision.

NEW WAY TO SUBMIT BUGS AND REQUEST FEATURES + MUCH MORE

Hope that got your attention : ).

All, there is a new public glz_custom_fields repo on github which will be used for wiki & bug reports + feature requests. There is no source code there, only plugin documentation. This forum thread has become a bit crazy, finding anything helpful on the plugin is nearly impossible.

I would like to highlight the Issues tab where all bugs & feature requests should be filed. This is important because we’re finally getting a sense of what’s coming, when and, most importantly, you decide what gets done next. Vote for what you want me to code next and I will oblige. After all, it’s your plugin just as much as it’s mine.

Bugs will always have top priority and will be dealt with first, so if other issues will get done before the most voted one, you will know why.

Also, if you have any stuff you want to put into the wiki, set yourself up with a github account and get creating/editing that wiki page.

Unfortunately, I won’t be able to do any coding on the plugin this month (well, what’s left of it), but I do hope that you’ll find the above addition helpful. This plugin has become more successful than I would have ever thought, and to take it even further a better way to gather & distribute information was necessary.

For those that have been expecting to see new things this month, worry not, Christmas is just around the corner : ).

whaleen · 2009-11-29 23:40:07

Gerhard wrote:

All, there is a new public glz_custom_fields repo on github which will be used for wiki & bug reports + feature requests. There is no source code there, only plugin documentation. This forum thread has become a bit crazy, finding anything helpful on the plugin is nearly impossible.

I agree and that’s great to move the conversation to a possibly more accommodating place. We’ll see. Thanks Gerhard. No bugs to report at the moment.

Last edited by whaleen (2009-11-29 23:40:35)

jstubbs · 2009-12-01 20:32:34

Hi Gerhard, the Github bugs/issues seems a great idea – except it means creating a Github account, and I’d rather not :-)

A quick question re a previous post – I still have this problem. Your setting is a little confusing because you can set the ordering in Preferences (its custom for me) and in Plugins > Options (As entered for me).

My countries list displays correctly in Extension > Custom Fields, but NOT in my form drop down field. Not sure why this is..

Edit: Forgot to say my States list is fine. Tags are like:

<txp:mem_glz_select name="article_custom_2" required="1" label="State/Province" break="" custom_field="2" />
<txp:mem_glz_select name="article_custom_3" required="1" label="Country" break="" custom_field="3" />

Last edited by jstubbs (2009-12-01 20:34:32)

Manfre · 2009-12-02 05:17:44

jstubbs wrote:

My countries list displays correctly in Extension > Custom Fields, but NOT in my form drop down field. Not sure why this is..

It’s not using a pretty display function on the default prefs page. On the plugin options page, the select values map to “ascending”, “descending” and “custom”.

…mem_glz_select sort errors…

I fixed mem_glz_select so it uses the same sorting logic as glz_custom_fields.

whaleen · 2009-12-02 16:35:23

Re: Github: A thread for each issue is a step in the right direction IMHO and that is what we have over there now if we choose it. I’ve often though that some of the more popular plugin here in the TXP forums, for the benefit of devs and end-users, could use their own forum. The benefits are too many to list. There can be so many different topics that arise within one thread and the ability to sub-group them in my opinion would be really nice. Not only could these sub-threads be issue-related, as in support-related, they could also be based on implementations. If a group of users exists that tend to use the plugin for a like purpose they could pool discussion and you’d end up with sub-thread with a use-case quality to it.

Sub Thread types:

Feature Requests
Bugs / Issues
Implementations

Then your getting into sub-sub-forums… Maybe too far but still, an example of classification of the main discussion types. Maybe TXP could benefit from sub-forum with universal login solution for it’s plugins. You could do that here in the existing one and if there were the option to categorize new threads then you’d be set. Sorry to take that idea that far but it seems reasonable to me. Anyway it looks like Gerhard want to use Github and I went ahead over there to make a couple remarks on the issue posts he made. I support his choice to use Github because I can see how it will make things easier on everybody so hopefully others will give it a try to find out if it will work well overall.

Last edited by whaleen (2009-12-02 16:38:07)

jstubbs · 2009-12-03 15:27:53

Anyone know how to set an initial blank value in a drop down select, forcing the user to choose an option?

Textpattern CMS

Textpattern CMS support forum

#601 2009-11-23 14:45:38

Re: glz_custom_fields

#602 2009-11-23 23:51:38

Re: glz_custom_fields

#603 2009-11-24 02:22:35

Re: glz_custom_fields

#604 2009-11-24 02:40:36

Re: glz_custom_fields

#605 2009-11-24 02:43:40

Re: glz_custom_fields

#606 2009-11-24 04:28:04

Re: glz_custom_fields

#607 2009-11-24 04:38:59

Re: glz_custom_fields

#608 2009-11-25 19:18:04

Re: glz_custom_fields

#609 2009-11-25 23:28:21

Re: glz_custom_fields

#610 2009-11-29 21:39:42

Re: glz_custom_fields

NEW WAY TO SUBMIT BUGS AND REQUEST FEATURES + MUCH MORE

#611 2009-11-29 23:40:07

Re: glz_custom_fields

#612 2009-12-01 20:32:34

Re: glz_custom_fields

#613 2009-12-02 05:17:44

Re: glz_custom_fields

#614 2009-12-02 16:35:23

Re: glz_custom_fields

#615 2009-12-03 15:27:53

Re: glz_custom_fields

Board footer