glz_custom_fields v2 beta for Textpattern v4.7

jayrope · 2020-01-09 14:03:48

While we’re at it:
Can anybody see a way to turn single values from multiple entry custom fields into individual search terms?
Just looking for a roadmap there.
Thank you!

jakob · 2020-01-09 14:14:14

Can you explain what you’re trying to achieve?

Two examples:

1. A list of search links with each selected value:

<txp:rah_repeat value='<txp:custom_field name="your-multi-cf" />' delimiter="|">
    <a href="https://example.com/?q=<txp:rah_repeat_value escape="url" />">
        Search for “<txp:rah_repeat_value />”
    </a>
</txp:rah_repeat>

or 2. a single search term comprised of all chosen values together:

<!-- construct the search term out of the chosen options -->
<txp:variable name="search_term" escape="trim">
<txp:rah_repeat value='<txp:custom_field name="your-multi-cf" />' delimiter="|" break="+" escape="trim">
    <txp:rah_repeat_value />
</txp:rah_repeat>
</txp:variable>
<!-- the search link -->
<a href="https://example.com/?q=<txp:variable name="search_term" escape="url" />">Search for <txp:variable name="search_term" /></a>

jayrope wrote #320971:

Just looking for a roadmap there.

The idea is that this plugin eventually disappears when more flexible custom fields hit the core. Ideally, at that point, you can migrate your glz_custom_fields to the core method and then remove the plugin altogether.

I will endeavour to ensure it keeps working until then to the best of my abilities but I don’t really want to add any functionality that will mean it is still needed after that.

THE BLUE DRAGON · 2020-02-25 09:12:18

Hi I’m getting some errors while creating/deleting a field, regardless the type.
Also in a case of creating a textarea type field it is also “clears” all the data from existing textarea fields from all existing articles, but if I delete that field the data “restores” back.

using TXP v4.8.0 beta3 and PHP7.0, on a migrated installation, in localhost.
I’m currently having 55 custom fields and would like to create more.

On creation error:

User_Error “Incorrect datetime value: ’0000-00-00 00:00:00’ for column ‘Expires’ at row 3”
in C:\wamp64\www\example\textpattern\lib\txplib_db.php at line 403.

Visiting the Write tab returns an error:

User_Error “Unknown column ‘custom_56’ in ‘field list’”
in C:\wamp64\www\example\textpattern\lib\txplib_db.php at line 403.

Deleting any custom field other than the core fields (1-10), returns a error:

There was a problem deleting custom field ID# 25
User_Error “Can’t DROP ‘custom_25’; check that column/key exists”

Last edited by THE BLUE DRAGON (2020-02-25 09:14:04)

Bloke · 2020-02-25 10:42:42

THE BLUE DRAGON wrote #321886:

User_Error “Incorrect datetime value: ’0000-00-00 00:00:00’ for column ‘Expires’ at row 3”

I thought the patched version dealt with the NULLDATETIME issue already. One might have slipped through the net, or your MySQL table definitions may need updating to reflect current Txp practices when dealing with null values. There are topics floating around the forum with NULLDATETIME fixes and avenues of exploration, if that helps.

I’m currently having 55 custom fields and would like to create more… Unknown column ‘custom_56’ in ‘field list’

You’re likely hitting the MySQL column or (more likely) row limit. This is a byproduct of custom fields being stored in the article table and is a key driver for moving them out when we eventually merge unlimited custom fields into core.

I expect most of the issues you face with weird data loss and plugin behaviour is related to this.

jakob · 2020-02-25 16:20:29

Thanks for diving in there Stef. I wouldn’t have known that.

User_Error “Incorrect datetime value: ’0000-00-00 00:00:00’ for column ‘Expires’ at row 3”

The datetime message says it refers to ‘Expires’ which should not be affected by glz_custom_fields at all.

All the same, I haven’t tested glz_custom_fields conclusively against txp 4.8.0 yet, so there may be some tweaks coming.

THE BLUE DRAGON · 2020-02-26 16:56:35

Thank both of you very much.

I ended updating my WAMP server to a newer PHP and MySQL versions:

Before it was:
WAMP server v3.0
PHP7.0
MySQL 5.6 I think.

Now:
WAMP server v3.2
PHP7.4
MariaDB 10.4.10
MySQL 8.0.18.

and now everything seems to be working fine,
by creating a new custom field and deleting it, it “refreshed” whatever was “stuck” and need from the old version and I am able to create/delete new fields with no problems and no errors (at least for now LOL).

I was doing lots of testing today, the reason I have decided to update WAMP server it is because I couldn’t run a query to search for “0000-00-00 00:00:00” in Expires filed in “textpattern” table and replace it with “NULL”.
But after updating to the new WAMP version I do not receive that error anymore and even that there are still lots of “0000-00-00 00:00:00” values in the textpattern table, I do not seems to need to do anything about it as I do not get that error message unlike before.
Is it still better to search-replace the “0000-00-00 00:00:00” values into “NULL” or should I keep it as it is please?

jakob · 2020-02-26 21:00:46

Thanks for the feedback and glad you got it working again.

FWIW: I’ve done some very preliminary testing on a new 4.8.0 release with some sample articles using v2.0beta as found here and the following have all worked without any problems:

☑ Adding new custom fields of types textarea, text input, date input
☑ Changing custom field order per drag and drop
☑ Adding field label titles and instruction text
☑ Switching language and adding field label titles and instruction text
☑ Switching back to the original language and field label titles and instructions are still intact
☑ Deleting custom fields

Obviously that’s not conclusive by any means, but it looks like the main functionality works out of the box. Oleg has since added the possibility to bundle dependencies along with a plugin as part of a zip installer file, e.g. a zip file one imports via the Plugins panel: that would make it possible to include the javascript and css that currently needs installing separately and could allow one to simplify the prefs. I will investigate.

phiw13 · 2020-02-26 22:00:21

jakob wrote #321952:

Thanks for the feedback and glad you got it working again.

FWIW: I’ve done some very preliminary testing on a new 4.8.0 release with some sample articles using v2.0beta as found here and the following have all worked without any problems:

FWIW – I haven’t had any issues with the plugin on TXP 4.8.0 or dev, save for the hiccup I mentioned up thread

Everything working with PHP v7.2+ and mySQL 5.7 or 8

jayrope · 2020-09-10 14:00:58

Just for clarity: Does the the beta 2.0 from github work with 4.8.2 or should one be careful? I read through the thread here, but can’t see a clear “yes! it works!”

thanx in advance!

GugUser · 2020-09-10 16:54:37

In various installations it works without problems so far.

phiw13 · 2020-09-10 23:32:12

jayrope wrote #325870:

Just for clarity: Does the the beta 2.0 from github work with 4.8.2 or should one be careful? I read through the thread here, but can’t see a clear “yes! it works!”

ditto what GugUser says – the latest from GH you linked to works OK from here.

(as always have a backup of the DB at hand before any upgrading etc etc and so on)

peterj · 2020-09-19 15:18:12

Hi, I’m just playing with the multi-select, as I build up the courage to make a custom script based field. My multi-select field is throwing an alert on the write tab (see below), though values save.
Running 2.0 Beta on TXP 4.8.2 on PHP 7.4. In debug mode.

8192 "implode(): Passing glue string after array is deprecated. Swap the parameters"
in /home/xoxoxo/2020dev/textpattern/plugins/glz_custom_fields/glz_custom_fields.php at line 1808.
adminErrorHandler()
textpattern/plugins/glz_custom_fields/glz_custom_fields.php:1808 implode()
textpattern/lib/txplib_misc.php:1506 glz_custom_fields_before_save()
textpattern/index.php:224 callback_event()

I found the code in glz_custom_fields_before_save():

$value = implode($value, '|');

Changed this around to

$value = implode('|', $value);

Now it’s happy. Old way deprecated in 7.4.

Last edited by peterj (2020-09-19 15:18:48)

wavesource · 2020-10-15 03:46:59

peterj wrote #325968:

I found the code in glz_custom_fields_before_save():
$value = implode($value, '|');...
Changed this around to
$value = implode('|', $value);...
Now it’s happy.

This bug is confirmed in TXP 4.8.3. Fix works.

Last edited by wavesource (2020-10-15 03:49:10)

peterj · 2021-03-24 04:48:43

Same problems with checkboxes.
TXP 4.8.4 on PHP 7.4.

jakob · 2021-03-24 09:05:55

peterj wrote #329414:

Same problems with checkboxes.
TXP 4.8.4 on PHP 7.4.

Thanks for prodding me. I’ve updated that online and done a minor re-issue with that change included.

Textpattern CMS

Textpattern CMS support forum

#76 2020-01-09 14:03:48

Re: glz_custom_fields v2 beta for Textpattern v4.7

#77 2020-01-09 14:14:14

Re: glz_custom_fields v2 beta for Textpattern v4.7

jayrope wrote #320971:

#78 2020-02-25 09:12:18

Re: glz_custom_fields v2 beta for Textpattern v4.7

#79 2020-02-25 10:42:42

Re: glz_custom_fields v2 beta for Textpattern v4.7

THE BLUE DRAGON wrote #321886:

#80 2020-02-25 16:20:29

Re: glz_custom_fields v2 beta for Textpattern v4.7

#81 2020-02-26 16:56:35

Re: glz_custom_fields v2 beta for Textpattern v4.7

#82 2020-02-26 21:00:46

Re: glz_custom_fields v2 beta for Textpattern v4.7

#83 2020-02-26 22:00:21

Re: glz_custom_fields v2 beta for Textpattern v4.7

jakob wrote #321952:

#84 2020-09-10 14:00:58

Re: glz_custom_fields v2 beta for Textpattern v4.7

#85 2020-09-10 16:54:37

Re: glz_custom_fields v2 beta for Textpattern v4.7

#86 2020-09-10 23:32:12

Re: glz_custom_fields v2 beta for Textpattern v4.7

jayrope wrote #325870:

#87 2020-09-19 15:18:12

Re: glz_custom_fields v2 beta for Textpattern v4.7

#88 2020-10-15 03:46:59

Re: glz_custom_fields v2 beta for Textpattern v4.7

peterj wrote #325968:

#89 2021-03-24 04:48:43

Re: glz_custom_fields v2 beta for Textpattern v4.7

#90 2021-03-24 09:05:55

Re: glz_custom_fields v2 beta for Textpattern v4.7

peterj wrote #329414:

Board footer