glz_custom_fields

bici · 2017-07-31 03:04:32

phiw13 wrote #306493:

I am not sure your custom field name can contain characters like á. Perhaps that is the issue?

why cant custom fields have utf8 characters? big oversight if they are not allowed

phiw13 · 2017-07-31 03:47:17

bici wrote #306494:

why cant custom fields have utf8 characters? big oversight if they are not allowed

I don’t know… another weirdness with this plugin? When I tested, creating a custom field with the plugin, name: tést, the name was truncated to tst after saving. It does work for standard (the 10 provided but Textpattern) custom fields.

EDIT
Or maybe that part is something wrong on my install? I see the custom_fields table has latin1 set for name and value. Puzzled, as this TXP4.6 was definitely created with the charset set to UT8-mb4.

—
Anyway, I also wanted to note, I created a textarea custom field (test_textarea), and could verify that with the code provided by David, it does work.

<input type="hidden" name="foo" value="<txp:custom_field name='test_textarea' />">

Last edited by phiw13 (2017-07-31 09:15:15)

uli · 2017-07-31 16:39:32

david@druna.cz wrote #306492:

I want to use the new custom field in php script.

Is that script stored in a Textpattern form? If not: try it from there. I’ve no experience with such sripts in TXP, maybe you’d need to wrap it in a pair of <txp:php> tags. EDIT: There are admin settings that allow/disallow the use of PHP in several places. Check whether they‘re set accordingly.

In case the accented letter is part of the problem and you want the client to see proper spelling: There’s a plugin, bot_cf_titles, that lets you replace custom field names on the surface while the actual field name can remain without accent for the proper functionality of TXP and plugins involved.

GugUser · 2017-08-01 05:41:46

I can not figure it out what’s the problem with glz_custom_fields, radio or checkbox after an upgrade from Textpattern 4.5.7 to 4.6.2 (it’s not the first time I did that ;-) ):

“Ooops! custom_2 has some problems. Go fix it.”

But I can’t fix anything.

If I change to input type all is fine.

Any idea? Thanks.

uli · 2017-08-01 13:29:19

Simply to spur some thoughts:
Is the plugin the most recent one?
Are there any errors, maybe hidden by the current production state (backend/frontend)?
Does glz_cf throw that message if it’s the only active plugin?
Could it be caused by the name of the field?
Or by any contents/special characters in that/these field(s)? (Also: too much content in there?)

GugUser · 2017-08-01 15:06:50

Hi uli, thanks for your answer.

uli wrote #306508:

Is the plugin the most recent one?

Yes.

Are there any errors, maybe hidden by the current production state (backend/frontend)?

Notice "A non well formed numeric value encountered"
in /home/www/web111/html/la-lengua/textpattern/include/txp_prefs.php at line 819.

textpattern/include/txp_prefs.php:819 adminErrorHandler()
textpattern/include/txp_prefs.php:90 real_max_upload_size()
textpattern/include/txp_prefs.php:49 prefs_save()
textpattern/index.php:211 include()

Notice "A non well formed numeric value encountered"
in /home/www/web111/html/la-lengua/textpattern/include/txp_prefs.php at line 819.

textpattern/include/txp_prefs.php:819 adminErrorHandler()
textpattern/include/txp_prefs.php:90 real_max_upload_size()
textpattern/include/txp_prefs.php:49 prefs_save()
textpattern/index.php:211 include()

Does glz_cf throw that message if it’s the only active plugin?

Yes.

Could it be caused by the name of the field?

No, the names are “Ancho” and “Zoom”, the same like in other installations without problems.

Or by any contents/special characters in that/these field(s)? (Also: too much content in there?)

Are checkboxes.

uli · 2017-08-01 16:42:36

Sorry, no ideas.

In order to speed things up: The function in txp_prefs is the following one, the line with case 'm': $val *= 1024;

function real_max_upload_size($user_max)
{
    // The minimum of the candidates, is the real max. possible size
    $candidates = array($user_max,
                        ini_get('post_max_size'),
                        ini_get('upload_max_filesize'), );
    $real_max = null;
    foreach ($candidates as $item) {
        $val = trim($item);
        $modifier = strtolower(substr($val, -1));
        switch ($modifier) {
            // The 'G' modifier is available since PHP 5.1.0
            case 'g':
                $val *= 1024;
            case 'm':
                $val *= 1024;
            case 'k':
                $val *= 1024;
        }
        if ($val > 1) {
            if (is_null($real_max)) {
                $real_max = $val;
            } elseif ($val < $real_max) {
                $real_max = $val;
            }
        }
    }

    return $real_max;
}

david@druna.cz · 2017-09-29 02:07:52

I have found out that glz_custom_fields is applying textile to my custom textarea field. Is there a way to stop this? Textile has been turned off for the said article. (Nonetheless I would like to stop the textile even if it was turned on for the article.)

phiw13 · 2017-09-29 04:59:36

david@druna.cz wrote #307253:

I have found out that glz_custom_fields is applying textile to my custom textarea field. Is there a way to stop this? Textile has been turned off for the said article. (Nonetheless I would like to stop the textile even if it was turned on for the article.)

Start your blocks with notextile. ? Hmm not necessarily user friendly…

Maybe there is a plugin that can prevent Textile to work, such as “smd_wrap”?

david@druna.cz · 2017-09-29 12:06:21

I found out notextile. inside a custom textarea does not get interpreted and acts like a plain text. Actually textile might not be the issue I’m having. The text from the custom field just gets wierdly encoded/padded when I get it from php.

Not sure if I can post links to other questions here but here my main question greatly involving glz_custom_fields. Any help would be greatly appreciated. https://forum.textpattern.com/viewtopic.php?pid=307250#p307250

phiw13 wrote #307254:

Start your blocks with notextile. ? Hmm not necessarily user friendly…

Maybe there is a plugin that can prevent Textile to work, such as “smd_wrap”?

p.

jayrope · 2018-02-25 21:01:14

When i use custom fields in glz_cf 1.5.0, which are set to accept multiple entries, then those show up in an article as

entry1|entry2|whateverelseentry|thelastentrymaybe|butmaybenot

how can i use a different separator than | – say i want to use commas to display between single entries?

unfortunately <txp:custom_field /> doesn’t have a break="" attribute…
and note, that sthg. like <txp:if_custom_field name="genre 1" separator=", "> doesn’t help either.

I suspect i have to edit glz_cf ?

Thanx much in advance!

Last edited by jayrope (2018-02-26 02:41:33)

jakob · 2018-02-26 08:39:56

Yes, that’s how glz-cf stores multiple values. I think the reasoning was so that you could have values in your multiple values that contain commas. What you can do is to use rah_replace to turn it into a comma-delimited list or rah_repeat to process the list using the separator it has.

@all: BTW: A new version that’s compatible with v4.7 can now be found in this thread.

Textpattern CMS

Textpattern CMS support forum

#1177 2017-07-31 03:04:32

Re: glz_custom_fields

phiw13 wrote #306493:

#1178 2017-07-31 03:47:17

Re: glz_custom_fields

bici wrote #306494:

#1179 2017-07-31 16:39:32

Re: glz_custom_fields

david@druna.cz wrote #306492:

#1180 2017-08-01 05:41:46

Re: glz_custom_fields

#1181 2017-08-01 13:29:19

Re: glz_custom_fields

#1182 2017-08-01 15:06:50

Re: glz_custom_fields

uli wrote #306508:

#1183 2017-08-01 16:42:36

Re: glz_custom_fields

#1184 2017-09-29 02:07:52

Re: glz_custom_fields

#1185 2017-09-29 04:59:36

Re: glz_custom_fields

david@druna.cz wrote #307253:

#1186 2017-09-29 12:06:21

Re: glz_custom_fields

phiw13 wrote #307254:

#1187 2018-02-25 21:01:14

Re: glz_custom_fields

#1188 2018-02-26 08:39:56

Re: glz_custom_fields

Board footer