glz_custom_fields

phiw13 · 2017-03-23 22:38:51

Bloke wrote #304997:

Eeek. Not good. Will have to set up a site that uses glz_cf in 4.6.2 and perform an upgrade to see if we can locate where this is going wrong.

I‘m sorry I don’t have any debug messages for you. That install was in testing mode, I realised too late . Bad tester, phiw13 :-(.

Bloke · 2017-03-23 22:59:41

phiw13 wrote #305014:

I‘m sorry I don’t have any debug messages for you. That install was in testing mode, I realised too late . Bad tester, phiw13 :-(.

Hehe, no probs. Will see if I can figure it out.

jpdupont · 2017-04-29 16:24:36

I encounter I think the same problem as phiw13. As for phiw13, I could fix it by going in the glz_custom_fields admin panel and re-saving each one of them.

I do not understand what can cause this. Initially an update to the latest version 4.7. But then it seems that it happens randomly. During a demonstration at a customer this morning it happened. And already the night before by simply working on the articles and pages or forms. I have each time re-registered the fields in the admin of cf. But it seems that the link with the original custom field disappears, because as some are related to javascript, I then have to reconnect the good number of cf with the javascript.

This is painful and disturbing because I can not provide a stable environment. Help would be very valuable!

jpdupont · 2017-04-30 14:47:16

Any Idea or workaround ?

phiw13 · 2017-04-30 23:46:21

jpdupont wrote #305564:

Any Idea or workaround ?

Simple one? Don’t use TXP *-dev for production or demonstration work. There are still way too many things in flux.

—
I have removed this plugin from my TXP 4.7-dev install. It constantly reverts the core (custom-1 … custom-10) fields to Type not supported, and prevents me from doing other, more meaningful testing and experimenting.

jpdupont · 2017-05-01 08:24:22

phiw13 wrote #305566:

Simple one? Don’t use TXP -dev for production or demonstration work. There are still way too many things in flux.

Yes, phiw13, I know, I know …

However in the latest versions 4.7 dev there are some very interesting features that become indispensable. The dev versions of txp are slow to become official, and even at this time (official release), there are too many plugins that will no longer work or cause errors. Will actual glz_custom_fields be repaired at 4.7 ??? And custom fields in core are not provided before … 4.8 ???

jpdupont · 2017-06-28 10:34:53

@phiw13

I searched for why glz_custom_fields no longer works with the latest versions 4.7 dev.

I discovered that at times the html value of the custom field preferences would go back to custom_set instead of staying at the value assigned by glz_custom_fields.

After looking without success in the plugin code what does a reset of these values, I realized it happened at new login.

By commenting checkprefsintegrity in txp_auth, no more bug after a logout / login.

function checkPrefsIntegrity() is in /textpattern/vendors/Textpattern/DB/Core.php

github.com/textpattern/textpattern/issues/907

Last edited by jpdupont (2017-06-28 11:05:15)

phiw13 · 2017-06-29 22:49:40

jpdupont wrote #306111:

I discovered that at times the html value of the custom field preferences would go back to custom_set instead of staying at the value assigned by glz_custom_fields.

Thanks for the debugging! I see that makss has offered a patch that would potentially fix this. I’ll have to test next, perhaps over the WE.

phiw13 · 2017-07-03 00:14:49

Upon install (TXP4.7-dev up-to-date – using v1.5.0b from Stefs repo):

User_Error "Specified key was too long; max key length is 1000 bytes"
in /Users/XXX/Sites/_txp47/textpattern/lib/txplib_db.php at line 409.
adminErrorHandler()
textpattern/lib/txplib_db.php:409 trigger_error()
textpattern/lib/txplib_misc.php(1407) : eval()'d code:1285 safe_query()
glz_custom_fields_install()
textpattern/lib/txplib_misc.php:1948 call_user_func_array()
textpattern/include/txp_plugin.php:565 callback_event()
textpattern/include/txp_plugin.php:50 plugin_install()
textpattern/index.php:222 include()

After activating the extension and creating a new field (a simple text_input) – in the UI the field is not visible (not in the extensions tab, not on the Write panel:

User_Error "Unknown column 'prefs_id' in 'field list'"
in /Users/XXX/Sites/_txp47/textpattern/lib/txplib_db.php at line 409.
adminErrorHandler()
textpattern/lib/txplib_db.php:409 trigger_error()
textpattern/lib/txplib_misc.php(1835) : eval()'d code:361 safe_query()
textpattern/lib/txplib_misc.php(1835) : eval()'d code:89 glz_new_custom_field()
textpattern/lib/txplib_misc.php(1835) : eval()'d code:1458 glz_custom_fields_MySQL()
glz_custom_fields()
textpattern/lib/txplib_misc.php:1948 call_user_func_array()
textpattern/index.php:225 callback_event()

Checking with Sequel Pro, I see that the custom fields table does not exist. However, I find a custom_11 entry in the textpattern table.

The good thing: my preexisting custom fields (custom_1 – custom_4) are never affected by this. Login out and logging in, the fields remain (functional).

On another test install, where the extension was already installed, but disabled. I reactivated the extension, didn’t see any errors at that point. But going to the extensions panel, and creating a custom field, I get the same errors as above. If i remember correctly, before disabling the extension I had deleted all custom fields it had created (custom_11 and up) – at least there is nothing left according to Sequel Pro.

I don’t have time to dig deeper atm.

Bloke · 2017-07-03 09:30:41

phiw13 wrote #306144:

Specified key was too long;

Thanks for the report. I’ve fixed it but haven’t released it as a new version yet.

If you want to patch yours, install it but before activation, find the glz_custom_fields_install() function in the code and change the KEY() in the CREATE TABLE statement to read:

KEY (`name`(50))

Then try enabling/ using the plugin.

If that works I’ll compile up a version and release another beta.

makss · 2017-07-03 10:55:01

Still need to remove the use of the field prefs_id in txp_prefs table.
This line

Bloke · 2017-07-03 11:09:58

makss wrote #306149:

Still need to remove the use of the field prefs_id in txp_prefs table.

Good catch, thanks. Fixed.

EDIT: Uhh, twice !

Last edited by Bloke (2017-07-04 09:03:05)

Textpattern CMS

Textpattern CMS support forum

#1165 2017-03-23 22:38:51

Re: glz_custom_fields

Bloke wrote #304997:

#1166 2017-03-23 22:59:41

Re: glz_custom_fields

phiw13 wrote #305014:

#1167 2017-04-29 16:24:36

Re: glz_custom_fields

#1168 2017-04-30 14:47:16

Re: glz_custom_fields

#1169 2017-04-30 23:46:21

Re: glz_custom_fields

jpdupont wrote #305564:

#1170 2017-05-01 08:24:22

Re: glz_custom_fields

phiw13 wrote #305566:

#1171 2017-06-28 10:34:53

Re: glz_custom_fields

#1172 2017-06-29 22:49:40

Re: glz_custom_fields

jpdupont wrote #306111:

#1173 2017-07-03 00:14:49

Re: glz_custom_fields

#1174 2017-07-03 09:30:41

Re: glz_custom_fields

phiw13 wrote #306144:

#1175 2017-07-03 10:55:01

Re: glz_custom_fields

#1176 2017-07-03 11:09:58

Re: glz_custom_fields

makss wrote #306149:

Board footer