Re: glz_custom_fields

Is it possible to have a dropdown select that is automatically populated with articles from a given section?

And is it possible to reference fields from an article selected in this way?

The use case is as follows – we have articles in a section venues that hold the name, address, lat/long & other details relating to a venue. When we enter an event in section events, we want to choose the venue from a dropdown. We also want to access a number of venue article fields when displaying the event page.

Re: glz_custom_fields

Is it possible to have a dropdown select that is automatically populated with articles from a given section?

yes

And is it possible to reference fields from an article selected in this way?

Yes

I would just nest a second article_custom call from within the events article form. It’s sole purpose is to list the venue fields. So when you are putting in a new “event” article you’d use a glz scripted select to tell it to associate with the selected venue article. Just like using an article image really.

This sucker should create a select that lists all non-sticky articles in the venue section and return the url-title. Throw it in your glz_custom_fields folder

Edit: Actually returns the url-title not article ID, but just replace instances of url_title with whatever database field (see below) you’d like the field to return. Also note, the first script will produce a select and the second will produce a multi-select. Read comments to see how

Re: glz_custom_fields

Re: glz_custom_fields

Nope. Didn’t seem to “fully work” when I tested – before I screwed something up on my Mamp – install of beta 4.5
If my memory serves me well (which it rarely does) – there was some issue with the fields at the top not being visible or something. It looked like some cels went wonky. You have to look at it for yourself though cause I ain’t reinstalling.

Re: glz_custom_fields

After upgrading a site to 4.5, I tested to see what types of glz_custom_fields work or fail:

Text Input = works
Checkbox = fails
Radio = works
Select = works
Multi-Select = fails
Text Area = works
Date Picker = fails (little calendar icon appears to right of image, so it may just be a styling issue for the calendar pop-up)
Time Picker = fails (not little icon appears for the picker)
Custom script = didn’t test

If you click Save or Publish when when a cf checkbox is checked or a selection is made in a cf multi-select area, the following error will pop up and you won’t be able to save the article:
“Sorry, the form could not be submitted Please try again later.”

The only appearance/styling issue I found on the glz_custom_fields extension/settings page occurs when using the Hive theme. There is an overlap of the “Add new custom field” title bar covering the top half of the Name input field.

The “Configure glz_custom_fields” link that appears to the right of the “Type” field on the plugin’s extension page when multi-select, or any of the “Special” types is selected is broken.

Re: glz_custom_fields

philwareham wrote:

Gerhard is currently fixing glz_custom_fields for use in Textpattern 4.5, so just be patient – it will happen.

I’m not sure I got such a warm fuzzy feeling as that from Gerhard’s recent emails. He said that he was ‘dragging his heels’ mostly because PHP didn’t ‘light his fire’ any more (I paraphrase, having deleted the emails and am unable to recall his precise terminology). The replies to his survey indicated that more than 90% of his plug-in users wanted GLZCF capabilities incorporated into Textpattern and he announced that he would enter negotiations with the TXP Devs about that. That is the right answer to the wrong question isn’t it? As I understand it, that incorporation is an aspiration for TXP 4.6 and not before. In these circumstances, don’t we just want him to fix his plug-in to work with the current TXP version one more time and then he can be done with it.

I’m sure popular plug-ins do become albatrosses around the necks of TXP plug-in developers when they move on. I understand completely where Gerhard is coming from, so I still love him to bits

Re: glz_custom_fields

On a fresh new 4.5, I install the last glz_custom_fields. Don’t work because the table custom_fields is not created. I created it with phpmyadmin and in my particular case (I need a custom script), it work.

I’m creating 4 new sites actually with 4.4.1 because I need rss_unlimited_categories … and glz_custom_fields. Sad … So 4.5 is a fine/wonderful release but plugins prevent migration

Re: glz_custom_fields

The replies to his survey indicated that more than 90% of his plug-in users wanted GLZCF capabilities incorporated into Textpattern

For full disclosure, I should mention I was one of them :-)

Although still at an embryonic stage, my gut feeling is that we may just improve the database table structure, and put the infrastructure around to permit different data types (radio buttons, textareas, blah blah); probably along with some nice tag improvements and API to allow plugin authors to go to town without all the massive overhead that Gerhard had to go through to bring glz_cf to us. Whether we put a CF management interface into core is not something I have an answer to right now. It may be necessary, it may be prudent, it may be “easy”, so we might do it. And we’ll of course do it as quickly as we can.

In the meantime I’m not sure what to suggest. I don’t think it’s a huge job to patch glz_cf to work in 4.5.0. The fact that some non-text fields are failing is probably down to the new constraints built into core (just guessing). Raising a callback on the article constraints (article_ui / validate_save) and augmenting the allowable set may help (oh, and changing the plugin type to 5 of course). A hook for the article_ui / partials_meta callback is probably also needed. That should at least stop the javascript warnings when saving.