glz_custom_fields v2 beta for Textpattern v4.7

jakob · 2018-03-10 20:35:54

IMPORTANT: This version is for Textpattern v4.7 only.

For Textpattern 4.6.2 and below, see this release and this repo (legacy branch). Older versions are available here (original thread).

This beta of v2 of glz_custom_fields adds compatibility with Textpattern v4.7 and a few new things besides. While its concept and core workings are still those of Gerhard’s original plugin, this version is significantly refactored. Gerhard’s original plugin dates back to 2007 and a lot of the proprietary solutions he devised then – messaging, language strings, UI styling, preferences – can now be done in the core. That’s all been stripped out and implemented much like the other panels so it is better integrated and more consistent with the rest of the admin area.

The Textpattern core will ultimately support unlimited custom fields, making this plugin obsolete at some point in the future. This version also tries to prepare the ground for a smoother transition by adopting naming conventions that are planned for use in future.

What’s new

Textpattern 4.7. compatibility
Custom field title labels (also per language).
Public-side ‘tag’ for accessing the title – simply use the attribute title="1" with txp:custom_field.
Custom field instruction hints (also per language)
Plugin preferences now handled in Admin › Preferences
Drag-and-drop reordering of the order of custom fields (previously achieved by specifying ‘position’). This can be switched off via a hidden pref if it proves to be too temperamental.
UI now completely translatable with textpacks
New prefs for js/css URLs/paths, making it possible to relocate your css/js files if desired. Domain-less URLs are also permitted.
Multi-site installation compatibility. Place the plugins folder in your admin directory and the installer will attempt to guess the correct locations.
Changing/adding/deleting custom_fields updates the global “last modified” date (i.e. for refreshing caches).
Numerous other minor corrections and checks as well as updates to and minification of the date + time picker libraries.
English, French and German textpacks

Download

Download here: Plugin files and css/js files
Source here: github.com/jools-r/glz_custom_fields

Installation / upgrading

IMPORTANT: – Please don’t ignore this!
Backup your database before experimenting with this version!

Copy the plugins folder including its contents to your textpattern folder. If upgrading, replace all the files as they have changed significantly.
Copy the contents of glz_custom_fields_v2.0 beta_zip.txt and paste it into the Admin › Plugins installation box. Install and activate the plugin.
Visit the Admin › Preferences » Custom fields preferences panel to verify your plugin preferences. Correct if needed.
Visit the Extensions › Custom Fields panel to begin editing and adding new custom fields!

css/js file locations: You can move the files from the plugins folder if you wish to your own assets/js/ and assets/css/ folders (for example) but adjust the new js/css url pref accordingly in the plugin preferences. The Datepicker and Timepicker folders may also be moved but their contents should remain together.

Multi-site installations: Copy the plugins folder including its contents to the admin folder of your multi-site. If necessary, adjust the custom fields preferences to match your admin-side path and subdomain URL.

Compatibility

The plugin makes use of various new features in v4.7 like per-user admin language switching, admin preference groups, field label instructions and plugin help panes. It is therefore not for version 4.6.2.

Upgrading and backwards compatibility: The installer retains but prefixes existing preferences during installation. That makes going back to a previous version not straightforward (though not impossible). Make a backup first so you are covered for all eventualities.

Custom field naming

The naming of new custom fields is now stricter than before but existing custom fields will not be changed to prevent templates from breaking. Custom field names should be:

only lowercase letters and numbers
underscores as separators (no spaces or dashes)
should not start with a number

This ensures they will function correctly as attributes of txp:article / txp:article_custom and will smooth the path to future integration in the core. You will see a warning if your name doesn’t conform to this but your custom field will still be saved.

You can rename custom field names in this plugin but remember you will also need to alter all instances of txp:custom_field and txp:if_custom_field as well as all customfieldname attributes in txp:article_custom in your page templates and forms to match.

Known issues + casualties

Admin › Preferences can be slow to load due to the path and url checking code. It would be good to know how widespread this is. Please report.
User-supplied values for fields with multiple values – checkbox/radio button labels or select-box choices – are currently not translatable.
Range fields: To be honest I don’t think these worked in past versions either as the docs asked you to use characters such as &;() that were then stripped out of the custom field name on saving, breaking the mechanism.
Search section: All these years, the plugin installer has created a section called ‘search’ that was needed for the public-side tag txp:glz_custom_fields_search_form which was removed many versions ago (in 2009!). That no longer happens.

Textpacks, feedback and code improvements

English, German (thanks Uli) and French (thanks Patrick and Philippe) are currently included. All further contributions welcome. The original textpack is here.

Corrections and pull requests are likewise welcome.

Credits

Numerous people have contributed to the upkeep of Gerhard’s plugin over the years. The basic concept and parts of the code are still Gerhard’s. Bloke and etc provided invaluable help and guidance and Phil’s sterling work on the hive framework made it much easier to cut back on custom styling. Much of the facilities – such as the instructions text fields – were already in the core waiting to be put to use.

Enjoy!

jakob · 2018-03-10 20:40:16

I’ve done my best to test this in various constellations but I cannot anticipate all situations. I’d be most grateful for any feedback on problems, difficulties … as well as tips to how to iron them out.

I’ll try and address them as best possible and once it looks like it is behaving well and consistently, I shall take it out of beta.

If anyone has been trying my interim betas, please start over with a fresh installation as things have changed in the last day or two.

uli · 2018-03-10 22:17:02

Thanks, Julian, for making your work available. My thanks and all my respect for taming that beast!

Destry · 2018-03-10 22:37:55

This is a huge contrib, Julian, and seemingly a wonderful way to get hands-on with a forward compatible UCFs.

Wondering if I could break up long-form into ‘chapters’ — each chapter to its own textarea CF — and whether Textile endnotes would still work across them (i.e. between citation labels in each chapter box and endnotes list in a final CF?

phiw13 · 2018-03-11 03:40:09

Testing : an up-to-date TXP-dev install, barebones – PHP 7.1, MySQL 5.7.

Overall this works well, good work so far. It is easy to edit / create custom fields, the show up fine on the write panel, output behaves as expected on the front end (so far, this is a very barebones thingie after all).

The thing-that-needs-improvement: the table on the extension panel is absolutely over constrained, and nearly impossible to use on small (and not-really small) screens.

Remove this (I don’t see any use for that):

#glz_custom_fields_container table.sortable {table-layout: fixed;overflow: hidden}

remove all width settings you have (inline or in the stylesheet) for th and td. Then use the following

#page-glz_custom_fields th:nth-child(-n+3),
#page-glz_custom_fields th:last-child {
	width:  5em;
}

For en, the columns are probably slightly too wide, but for one need to account for other languages (e.g de is usually longer).

minor issue: the link to the preferences on the extensions panel is misplace for RTL languages:

[dir="rtl"] .glz-cf-setup-switch { float: left; }

The bad news: loading and saving the preferences panel has become terribly slow.

<!-- Trace summary:
Runtime   : 20098.14 ms
Query time: 34.81 ms
Queries   : 100
Memory (*): 4485 kB
-->

     57.20 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_values_ordering', pre='0']
     57.23 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_multiselect_size', pre='0']
   5062.98 |     0.01 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_css_asset_url', pre='0']
  10068.77 |     0.01 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_js_asset_url', pre='0']
  10068.88 |     0.00 | [Callback_event: 'admin_help_field', step='instructions_glz_cf_custom_scripts_path', pre='0']
  10068.89 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_custom_scripts_path', pre='0']
  15075.10 |     0.01 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_datepicker_url', pre='0']
  15075.16 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_datepicker_format', pre='0']
  15075.21 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_datepicker_first_day', pre='0']
  15075.26 |     0.00 | [Callback_event: 'admin_help_field', step='instructions_glz_cf_datepicker_start_date', pre='0']
  15075.26 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_datepicker_start_date', pre='0']
  20090.15 |     0.01 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_timepicker_url', pre='0']
  20090.21 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_timepicker_start_time', pre='0']
  20090.24 |     0.00 | [Callback_event: 'prefs_ui', step='inputlabel.glz_cf_timepicker_end_time', pre='0']

GugUser · 2018-03-11 03:55:07

This are very good news, an important step and you have done a great job. I don’t know much more than say “thank you”.

philwareham · 2018-03-11 07:58:03

This is great Jakob – I’ll test in due course and if there’s any core CSS needed that helps reduce custom CSS further let me know. I will then consider additions to the core.

jakob · 2018-03-11 09:17:04

phiw13 wrote #309885:

The thing-that-needs-improvement: the table on the extension panel is absolutely over constrained, and nearly impossible to use on small (and not-really small) screens.

Thanks for the excellent and useful feedback. Just what I was hoping for. I’ve made it less constraining, along the lines of your suggestion. It makes for a rather wide type column but I can live with that.

The problem stems from jqueryui.sortable. As soon as a table row is dragged, it’s taken out of the context of the rest of the table and all the column width calculations for the entire table no longer hold for the single row causing its widths to jump around. The same principle applies to the containing table too. I’ve resorted to a jquery solution that reads the column widths at the moment of dragging and fixes the draggable row’s column widths at that moment.

Remove this (I don’t see any use for that):

#glz_custom_fields_container table.sortable {table-layout: fixed;overflow: hidden}...

Without this the table concertinas wildly when you drag a row. The overflow:hidden; I’ve removed. Before I added the constraint to only shift vertically, dragging a row produced horizontal scrollbars in the table. The ui-sortable class that jqueryui adds is only on the tbody so I can’t attach it to that. Maybe there’s another solution to this but I haven’t found it yet.

[dir="rtl"] .glz-cf-setup-switch { float: left; }...

Done. Thanks!

The bad news: loading and saving the preferences panel has become terribly slow.

I think I know why, but I’m not sure how to deal with it. Thanks for the trace: that shows that time jumps coincide with the url and path prefs. That one contains a function that tries to establish if the destination is readable, and if not informs you that your path is incorrect or your file is missing. That’s probably what’s taking time. In my predominantly local testing, that wasn’t an issue as local file handling is fast.

If you comment out the lines from here to here in the code, you’ll probably find the time lag goes away, but you lose the error check (use the updated download from GitHub or you’ll get an error message when you do that). You’ll then have to rely on the message in the write tab if the paths are wrong. Will have to think about that one. All suggestions welcome.

Check back on GitHub for an updated plugin file and updated css files (+ zip).

phiw13 · 2018-03-11 09:51:06

jakob wrote #309891:

Thanks for the excellent and useful feedback.

:-)

(ref table-layout:fixed) Without this the table concertinas wildly when you drag a row. The overflow:hidden; I’ve removed. Before I added the constraint to only shift vertically, dragging a row produced horizontal scrollbars in the table. The ui-sortable class that jqueryui adds is only on the tbody so I can’t attach it to that. Maybe there’s another solution to this but I haven’t found it yet.

Hmm. So the problem is that table-layout: fixed renders the table as a mess on small screens. See this screenshot. That is with Sandspace, but Hive would have the same issue.

Now, as far as I know, JQUI drag and drop does not work on iOS + Android; perhaps you could set the table to table-layout: fixed only on larger screens? something like this (I know, that is absolutely no proxy, an iPad is 1024px or wider in landscape mode – but then on larger screens it is much much less of an issue)

@media (min-width: 60em) { /*code here */}

(although I tried the drag and drop with table-layout: auto (the default) and didn’t have problems. That may be just me.)

If you comment out the lines from here to here in the code, you’ll probably find the time lag goes away, but you lose the error check (use the updated download from GitHub or you’ll get an error message when you do that). You’ll then have to rely on the message in the write tab if the paths are wrong. Will have to think about that one. All suggestions welcome.

Disabled that, and the Preference panel is back to normal speed. Dunno what to do with the error check…

phiw13 · 2018-03-11 09:58:04

BTW, something to optimize in the stylesheet:

/* CUSTOM FIELDS EDIT PANEL + PREFS PANE

the two blocks can be made one: instead of using max-width on the media query, use min-width; then you only need to specify the padding + max-width once.

@media screen and (min-width: 47em) {
    .txp-prefs-group .txp-form-field .txp-form-field-instructions,
    .txp-edit .txp-form-field .txp-form-field-instructions,
    #prefs_group_glz_custom_f.txp-tabs-vertical-group .txp-form-field-instructions {
        max-width: 50%;
        padding-left: 50%;
    }
}

Not convinced personally you need to specify a max-width, though. Also, I don‘t think you need the 3rd selector, I may have missed something.

jakob · 2018-03-11 10:42:13

Destry wrote #309884:

Wondering if I could break up long-form into ‘chapters’ — each chapter to its own textarea CF — and whether Textile endnotes would still work across them (i.e. between citation labels in each chapter box and endnotes list in a final CF?

Short answer: I’m not sure.

Long answer: Only the regular body and excerpt fields are pre-processed as textile by textpattern and its results are stashed under body_html and excerpt_html in the database. Any other textarea custom fields you’ll need to run through textile with smd_wrap or etc’s new escape attribute. That might give you the opportunity to first output multiple textareas, then pass them all through textile in one final go to process endnotes for them all together. You’d need to style any HTML markup between your blocks so that textile doesn’t ruin them when processing the whole block (notextile, or the space trick). If you want to use the body field in that series, you’d probably also need to disable textile processing for that field too so you can process it with the others. And finally, it would then be a good idea to use a caching plugin so that it doesn’t have to be textiled on the fly on every page load.

Two-three other ideas for long-form chapters:

What about using something like rah_replace or another plugin (there was a column one I’ve used in the past) to place break markers in your text that mark a new section. You then replace that marker with your chapter break markup. If that acts on the already textilised content, you may also avoid difficulties with textile mangling html tags.
Maybe a custom chapter break tag would serve this purpose too (in 4.6 days smd_macro or rah_beacon, in 4.7 etc has brought this facility into the core).
Jeff Soo had a plugin / collection of plugins designed for multi-part longform documents. See ipsedixit.com/txp.

One other thing to be aware of. Stef tells me that there is a maximum size for a database row (I’ve forgotten how much exactly), and that very liberal use of longform custom fields might end up reaching that. I’m not sure when that kicks in, though. The future plans for custom fields in the core will probably shift custom fields to a separate table and store them more efficiently by type removing that hurdle.

jakob · 2018-03-11 11:04:49

phiw13 wrote #309892:

Hmm. So the problem is that table-layout: fixed renders the table as a mess on small screens. See this screenshot. That is with Sandspace, but Hive would have the same issue.

Now, as far as I know, JQUI drag and drop does not work on iOS + Android.

I guess this requires more detailed investigation, or perhaps another (jquery?) solution instead of table: fixed. I know that sortable adds touch-related code, so I wasn’t aware that it didn’t work on iOS or android. Again, more investigation needed.

Disabled that, and the Preference panel is back to normal speed. Dunno what to do with the error check…

I’m not sure either. Ideas might be:

@devs Is it possible to only perform the check on saving preferences. If so, one could do that then and set a flag when okay so that it’s not checked on every prefs-load. It’s not ideal, because if someone moves or deletes the files, it doesn’t show an error.
Make a separate “check paths” button that only checks on demand.
Ditch the checking mechanism altogether. It’s certainly useful to ensure the plugin works. But we don’t have paths checking anywhere else in the prefs, only in diagnostics.
Return the custom fields preferences back to its own plugin preferences panel – which would be a pity.

Textpattern CMS

Textpattern CMS support forum

#1 2018-03-10 20:35:54