glz_custom_fields v2 beta for Textpattern v4.7

jayrope · 2018-04-07 17:03:57

Testing latest glz_cf beta on 4.7 beta3.
Can’t change order of custom fields. When trying to access “options” on plugins page i get “Restricted area”.

jayrope · 2018-04-07 17:16:07

And Jakob, may i ask if it is possible to implement changing the delimiter type (without using an extra rah_replace script or similar), when displaying content of custom fields with multiple entries?
That | kind of ~~ern~~ sucks :) Mostly needed would be , i guess.

Last edited by jayrope (2018-04-07 17:37:08)

jakob · 2018-04-07 19:30:33

jayrope wrote #310738:

Testing latest glz_cf beta on 4.7 beta3. When trying to access “options” on plugins page i get “Restricted area”.

Not sure which version you tried, but try downloading again (link below). I’ve been working on it intermittently today and just verified that it works on a fresh site.

Can’t change order of custom fields.

Make sure you’ve uploaded the plugins folder too. There’s a zip file in the folder linked above with all the necessary files that I just used for my test installation. Unpack it in your base textpattern folder and the paths should be correct right away. If you decide to move the files, adjusted your paths accordingly to match – there’s a button “Check paths” that will give you feedback on whether there is a problem or not. If you still cannot access the plugin options, simply go to Admin › Preferences › Custom fields settings. That’s where they are now.

If it’s still not working, can you provide any further infos? (Browser, console messages?) I’ve just tried in firefox, chrome and safari and had no problems (I have no internet explorer / edge to hand).

jayrope wrote #310739:

And Jakob, may i ask if it is possible to implement changing the delimiter type … That | kind of ~~ern~~ sucks :) Mostly needed would be , i guess.

I think back when Gerhard made the plugin he deliberately chose the pipe | as a delimiter because it allows you to have option values that might contain a comma. My guess is he thought it was more likely that people might have a comma in their option string than a pipe … in German you could quite easily have 2,5%, 3,5%, 5,5% etc. as options. A method whereby those would be escaped on saving, then deslashed again on output is of little help to you, because it will still be a stumbling point when you come to iterate over them yourself.
The other reason for not changing (now at least) is that it has been like that for nigh-on ten years, so changing it would break people’s sites.

Is it a problem to use rah_replace or rah_repeat (where you can set the delimeter you want to use to iterate with)? Put another way: what output would you like to have, and how are you intending to use it?

jakob · 2018-04-07 19:34:02

A new update is now available on GitHub – with a few more updates and fixes.

Changes:

German Textpack (thanks Uli!)
Error message produced when checkbox custom field is created without options.
Error message produced when radio button or multi-select custom field is created without at least two options.
Fix plugin malfunction when main css/js paths are incorrect:
- Inject main glz_cf css and js files directly into page head and not from file.
- Hide corresponding prefs fields (but not removed, see next item).
- Set $debug = true; at the top of the plugin if you want to load from files (e.g. for debugging or your own styling).
Fix rollover on clipboard icon when no custom field title is provided.
Allow date format translation.
Simplified messages and more obvious link items in write tab error messages.

~~I’ll fold this back into the main branch soon.~~ Now done.

phiw13 · 2018-04-08 00:35:33

~~With your latest build, the order of the values for radio and checkbox fields are changed upon save. The {default} always end up last.~~

If I create a checkbox set with values:

ringo
{biwa}
mikan

after saving, the order of the values is

ringo
mikan
{biwa}

~~I’m not sure now, maybe that was already the case with previous builds, but it jumped out this morning.~~

Edit: Scrap that. My mistake. While playing with the Prefs, I had set the order to Descending, of course this made a mess of my expectations (possibly due to me misunderstanding what the pref does).

Last edited by phiw13 (2018-04-08 08:40:25)

jakob · 2018-04-08 12:11:56

French textpack now also added courtesy of Philippe. Thank you!

The plugin files are updated and the master branch is also now up to date.

jakob · 2018-04-21 15:31:34

A minor bugfix:

Custom fields with a value of “0” would not show (php’s empty() function regards 0 as empty). Now fixed.

phiw13 · 2018-04-22 04:21:54

Big issue #1: with this build (TXP47-dev, up to date), enable debug in the preferences. Access the Write panel (new, unsaved article). Debug spam (notice) for each custom field present.

Notice "Undefined variable: custom_2"
in /Users/username/Sites/_txp47/textpattern/lib/txplib_misc.php(1826) : eval()'d code at line 1745.
textpattern/lib/txplib_misc.php(1826) : eval()'d code:1745 adminErrorHandler()
textpattern/lib/txplib_misc.php:1945 glz_custom_fields_replace()
textpattern/lib/txplib_misc.php:2145 callback_event()
textpattern/include/txp_article.php:1592 pluggable_ui()
textpattern/lib/txplib_misc.php:373 article_partial_custom_fields()
textpattern/include/txp_article.php:709 updatePartials()
textpattern/include/txp_article.php:124 article_edit()
textpattern/index.php:258 include()

It is a notice, not a real error, so nothing bad happens. This does not happen with an already existing article.

Big issue #2: Head over to the Extensions > custom fields panel. Edit a custom field (for example cf #2), save. The custom field is now at the bottom of the list. IOW, the whole set is reordered. This is more annoying, me thinks.

- – - -

A minor issue I noticed the other day (and reproduced with todays build): insert a custom field, type is radio with two values, e.g. yes/no with ‘no’ as default, checked. Thing works fine.
The minor thing is this: access an article, and toggle the value from the default (N -> Y), then click “reset”. The odd thing, to me, is that both values are unchecked at this point, as if the radio group is now undefined. Save the article and the default is now displayed.

Not sure if that is the plugin code or some something in the ajaxy routines.

jakob · 2018-04-22 08:21:42

phiw13 wrote #311301:

Big issue #1: with this build (TXP47-dev, up to date), enable debug in the preferences. Access the Write panel (new, unsaved article). Debug spam (notice) for each custom field present.

Notice "Undefined variable: custom_2"...

Thanks for the report. Sorry, I introduced that with the last change. It only applies to new articles because those articles do not yet have any existing values. I’ve silenced that error now.

Big issue #2: Head over to the Extensions > custom fields panel. Edit a custom field (for example cf #2), save. The custom field is now at the bottom of the list. IOW, the whole set is reordered. This is more annoying, me thinks.

I’ve not been able to replicate this, either with drag-and-drop sorting or using manual position entries. When using drag-and-drop sort, a new custom field is added at the bottom of the list (position 999) which is intentional. You can then drag it to the required position.
If not using drag-and-drop, a new custom field is added at the same position number as its custom field number (if not specified by the user).
When editing, it should save with the existing position settings.

A minor issue I noticed the other day (and reproduced with todays build): insert a custom field, type is radio with two values, e.g. yes/no with ‘no’ as default, checked. Thing works fine.
The minor thing is this: access an article, and toggle the value from the default (N -> Y), then click “reset”. The odd thing, to me, is that both values are unchecked at this point, as if the radio group is now undefined. Save the article and the default is now displayed.

Thanks again. This is because – up to now – the “reset” button deselected all checked statuses from the radio button. It therefore saves with no radio checked. When you come to reload the article (or async save) the {default} value is checked if no value is already specified.
I’ve now changed the behaviour of the “Reset” button. If no {default} setting is specified, everything is as before: reset deselects all radio buttons. If a {default} has been specified, the “Reset” button will now reset to that {default} state.

I’ve updated all the files accordingly :-)

phiw13 · 2018-04-22 09:10:10

jakob wrote #311305:

I’ve silenced that error now.

Issue #1 resolved. Now we have a quite write panel again!

I’ve not been able to replicate this, (…)
When editing, it should save with the existing position settings.

So, when changing the order from the list panel things worked OK. The issue was (and still is) editing. But perhaps that is something peculiar to this test install.

I can only reproduce it thus: open the first field (ID=1, sorted as the 1st field) for editing, don’t touch anything, but click Save. The field is sent to the bottom of the list. I think that field existed before I installed GLZ-custom field – v2.

(minor issue) Thanks again. This is because – up to now – the “reset” button deselected all checked statuses from the radio button. It therefore saves with no radio checked. When you come to reload the article (or async save) the {default} value is checked if no value is already specified.
I’ve now changed the behaviour of the “Reset” button. If no {default} setting is specified, everything is as before: reset deselects all radio buttons. If a {default} has been specified, the “Reset” button will now reset to that {default} state.

Looks much better now. Thank you.

NB – a radio-button set without a default value always feels very weird to me.

uli · 2018-05-01 20:38:10

Julian, I’ve just marked Gerhard’s plugin version as outdated (planning to archive the topic after 4.7 is final) and link from there to this topic here. Now I find you also link back there for 4.6.2. Or do I get your wording wrong, and the link to Gerhard is only for TXPs < 4.6?

jakob · 2018-05-01 20:47:33

Great minds :-) We both had the same idea and … we both edited the first post of the old thread at pretty much exactly the same time. I’d updated with a fresh set of links, clicked publish and your revised version appeared so we must have clicked within a few milliseconds of each other with yours winning. I left it as you had it.

I’ve updated the first post of this thread to point to the correct branch (I’d forgotten that when bloke deleted his repo that the link would be dead, but all the older versions including bloke’s and gerhard’s are in the legacy branch of my repo).

jayrope · 2018-05-27 20:25:26

Can’t change order of custom fields.

I cannot unpack your plugins zip file, it seems there is a loop in it. Instead i downloaded those files one by one, and they resolve well in Custom fields preferences. However, i still can not change the order of custom fields. The version before had the option to order manually, which was nice. I am running 60++ custom fields in a culture database site. Especically in the backend it’s important to be able to rearrange custom fields as desired, because the range of data input constantly expands…

jakob · 2018-05-27 22:10:32

I cannot unpack your plugins zip file, it seems there is a loop in it. Instead i downloaded those files one by one, and they resolve well in Custom fields preferences

Hmm, I’m really not sure what that’s down to. If I click the download link on Github (direct link) or the “View raw” link I get a zip file downloaded that instantly unpacks into a folder. I tried especially to clean it before uploading to avoid it being riddled with mac-specific hidden files on windows machines.

However, i still can not change the order of custom fields.

I’m not sure about this either. Does your browser inspector give you any hints of files it can’t find or load, or javascript errors with the code? or perhaps a conflict with something else?

The version before had the option to order manually, which was nice. I am running 60++ custom fields in a culture database site.

Here, I can at least help. You’ll need to go into phpMyadmin / sequel pro or another sql editor … or smd_prefalizer. Look in the table txp_pref for the entry glz_cf_use_sortable and change the value of the type column from 2 (hidden) to 1. Now reload the preferences and you’ll have a yes-no switch to use sortable or enter the position value manually.

jayrope · 2018-05-27 23:44:08

Jakob, Extensions-> Custom fields gives me those errors in Console:

SyntaxError: expected expression, got ‘<’[Learn More] glz_jqueryui.sortable.min.js:7

jQuery.Deferred exception: $(…).addClass(…).find(…).prepend(…).appendTo(…).sortElements is not a function https://site.com/textpattern/index.php?event=glz_custom_fields&step=get_js:7:5 lhttps://site.com/textpattern/vendors/jquery/jquery/jquery.js:2:29373
a/</c<@https://site.com/textpattern/vendors/jquery/jquery/jquery.js:2:29677 undefined
jquery.js:2:30920

TypeError: $(…).addClass(…).find(…).prepend(…).appendTo(…).sortElements is not a function[Learn More]
index.php:7:5

Great about the sort order solution, i’ll deal with taht in PHPMyAdmin then

Textpattern CMS

Textpattern CMS support forum

#31 2018-04-07 17:03:57

Re: glz_custom_fields v2 beta for Textpattern v4.7

#32 2018-04-07 17:16:07

Re: glz_custom_fields v2 beta for Textpattern v4.7

#33 2018-04-07 19:30:33

Re: glz_custom_fields v2 beta for Textpattern v4.7

jayrope wrote #310738:

jayrope wrote #310739:

#34 2018-04-07 19:34:02

Re: glz_custom_fields v2 beta for Textpattern v4.7

#35 2018-04-08 00:35:33

Re: glz_custom_fields v2 beta for Textpattern v4.7

#36 2018-04-08 12:11:56

Re: glz_custom_fields v2 beta for Textpattern v4.7

#37 2018-04-21 15:31:34

Re: glz_custom_fields v2 beta for Textpattern v4.7

#38 2018-04-22 04:21:54

Re: glz_custom_fields v2 beta for Textpattern v4.7

#39 2018-04-22 08:21:42

Re: glz_custom_fields v2 beta for Textpattern v4.7

phiw13 wrote #311301:

#40 2018-04-22 09:10:10

Re: glz_custom_fields v2 beta for Textpattern v4.7

jakob wrote #311305:

#41 2018-05-01 20:38:10

Re: glz_custom_fields v2 beta for Textpattern v4.7

#42 2018-05-01 20:47:33

Re: glz_custom_fields v2 beta for Textpattern v4.7

#43 2018-05-27 20:25:26

Re: glz_custom_fields v2 beta for Textpattern v4.7

#44 2018-05-27 22:10:32

Re: glz_custom_fields v2 beta for Textpattern v4.7

#45 2018-05-27 23:44:08

Re: glz_custom_fields v2 beta for Textpattern v4.7

Board footer