Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#601 2009-11-17 16:24:27

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: glz_custom_fields

That worked perfect now, thanks for the tip!

Offline

#602 2009-11-18 23:20:22

speeke
Member
From: Bruny Island, Australia
Registered: 2009-03-29
Posts: 161
Website

Re: glz_custom_fields

Just wondering what the size limit is for a custom field of type select. I have nearly 200 country names I would like to input into a custom field (of type select), named “country”.

I gave it a whirl, but found that the custom field appeared in sections that it was explicitly asked not to (using the sed_section_fields plugin).


“People who value their privileges above their principles soon lose both.”
Dwight D. Eisenhower

Offline

#603 2009-11-19 02:21:10

johnstephens
Plugin Author
From: Woodbridge, VA
Registered: 2008-06-01
Posts: 999
Website

Re: glz_custom_fields

speeke wrote:

I gave it a whirl, but found that the custom field appeared in sections that it was explicitly asked not to (using the sed_section_fields plugin).

This issue is separate from how many entries a select-type field can hold, and I don’t know the answer to that. But sed_section_fields can be tricky to understand. The yes-no radio buttons in your sections tab ask whether to hide the field in the specified section, so “Yes” means the field is hidden.

This makes sense from the TXP perspective, that custom fields are visible by default, but it isn’t intuitive. Check your select field’s yes-no settings again for the sections in question. Make sure that “Yes” is selected next to Hide field# n for items you want hidden.

Offline

#604 2009-11-19 02:35:32

speeke
Member
From: Bruny Island, Australia
Registered: 2009-03-29
Posts: 161
Website

Re: glz_custom_fields

Hi John,

Thanks for your reply. But I went through all sections and double-checked the hide field status. So I guess it’s something else ???

Edit: Well, I deleted the custom field, and then added it again, with all the countries, and everything is now OK. Bizarre!

Last edited by speeke (2009-11-19 02:44:52)


“People who value their privileges above their principles soon lose both.”
Dwight D. Eisenhower

Offline

#605 2009-11-23 14:40:50

gerhard
Plugin Author
From: London, UK
Registered: 2005-06-29
Posts: 409
Website

Re: glz_custom_fields

whaleen wrote:

A TimePicker akin to the DatePicker.

Great suggestion, already on the TODO : ).

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.

Offline

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

gerhard
Plugin Author
From: London, UK
Registered: 2005-06-29
Posts: 409
Website

Re: glz_custom_fields

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.

Offline

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

whaleen
Member
From: Portland
Registered: 2006-05-11
Posts: 373
Website

Re: glz_custom_fields

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)


txtstrap (Textpattern + Twitter Bootstrap + etc…)

Offline

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

Cantide
Member
From: Wellington, New Zealand
Registered: 2004-03-03
Posts: 27
Website

Re: glz_custom_fields

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)

Offline

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

whaleen
Member
From: Portland
Registered: 2006-05-11
Posts: 373
Website

Re: glz_custom_fields

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)


txtstrap (Textpattern + Twitter Bootstrap + etc…)

Offline

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

Cantide
Member
From: Wellington, New Zealand
Registered: 2004-03-03
Posts: 27
Website

Re: glz_custom_fields

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

Offline

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

Cantide
Member
From: Wellington, New Zealand
Registered: 2004-03-03
Posts: 27
Website

Re: glz_custom_fields

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.

Offline

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

Cantide
Member
From: Wellington, New Zealand
Registered: 2004-03-03
Posts: 27
Website

Re: glz_custom_fields

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>

Offline

Board footer

Powered by FluxBB