Textpattern Support Forum

nardo wrote:

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

Possible Article Fields

• ID
• Posted
• Expires
• AuthorID
• LastMod
• LastModID
• Title
• Title_html
• Body
• Body_html
• Excerpt
• Excerpt_html
• Image
• Category1
• Category2
• Annotate
• AnnotateInvite
• comments_count
• Status
• textile_body
• textile_excerpt
• Section
• override_form
• Keywords
• url_title
• custom_1-20
• uid
• feed_time

Select that lists article titles and returns article url titles from the “venues” section

<?php
function my_venues($custom_field, $custom_id, $custom_value) {
  $titles = array();
  $query = safe_rows('url_title, title', 'textpattern', "section like 'venues' AND status !=5");
  $titles[] = '&nbsp;';
  foreach ($query as $title) 
    $titles[$title['url_title']] = $title['title'];

  // for a multi-select allowing multiple values change "2" to "1" and add ", true" without quotes after it.
  return glz_selectInput($custom_field, $custom_id, $titles, $custom_value, "2"); 
  }

?>

faux unlimited categories multi-select (restricted to children of a “my_parent_cat”)

<?php
function my_wine_cats($custom_field, $custom_id, $custom_value) {
  $titles = array();
  $query = safe_rows('name, title', 'txp_category', "parent like 'my_parent_cat' AND type like 'article' order by title asc");
  $titles[] = '&nbsp;';
  foreach ($query as $title) 
    $titles[$title['title']] = $title['title'];

  // for a select allowing only a single value change "1" to "2" and remove ", true" without quotes after it.
  return glz_selectInput($custom_field, $custom_id, $titles, $custom_value, "1", true);
}

?>

Last edited by mrdale (2012-06-29 15:23:07)

Does anyone know how fix GLZ_CF for working with Textpattern 4.5?

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.

Last edited by photonomad (2012-09-04 20:50:30)

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

Last edited by joebaich (2012-09-05 11:27:06)

joebaich wrote:

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.

Same sort of thing applies to rss_unlimited_categories, btw.