Drupal 7.x - Get field data from within a PHP block on an add / edit page?

CMS & WordPress
1

I’m working on the add / edit form for pages associated to a specific content type I’ve created for video uploads and I’d like to use a PHP block to display helpful field information that assists users with properly using the fields I’ve created. The only part I’m struggling with at the moment is figuring out how to use a PHP block to extract the field usage parameters pertaining to allowed file types, max file size, etc. I need to display this in the block on the add / edit pages and only for specific fields… Can this be done from a block on add / edit pages?

My hair would appreciate any input you can provide.

2

Hasn’t Drupal got the facility to add “Help text” for each content field type?

3

Drupal provides for individual help text on a very generic, underdeveloped and very static level, yes. :slight_smile:

So does anyone know how to do what I asked? If not, no worries.

4

Found this - https://drupal.org/node/1347866 - describes how to manipulate the Help text content block on input forms, you might get some clues from that?

5

Hey Wolf, Happy New Year!

Have you looked at the Field Info API (https://api.drupal.org/api/drupal/modules!field!field.info.inc/group/field_info/7).

Particularly Filed Info Field (https://api.drupal.org/api/drupal/modules!field!field.info.inc/function/field_info_field/7).

As far as using this in a block, I don’t see anything that would prevent it from working unless it has to be fired earlier in the process of requesting a page. If that’s the case, you could build a module that produces your block and then configure it to appear in your node/add - mode/edit scenario.

Andrew

6

Here’s some more information about where I’m going with all this that might help…

I’m using the Field Collection module (I should’ve mentioned this) to group together various fields associated with video file uploads, such as either “uploaded videos” or “URL-based videos” (i.e. - YouTube), which essentially covers every kind of video one really needs for websites (excluding streams). So by using 2 fields (one being a file upload field and another being a link / URL field) I’ve been able to cover both types of video payloads that users will likely need help with. To make this whole interface more usable / friendly, I included an additional radio button field consisting of 2 values: “Upload” and “URL”. By using jQuery, I’ve controlled the visibility of said video fields (Upload / URL), depending on the value of the radio inputs.

All this being said, I’ve decided to move the help text for these fields over into their own jQuery-controlled DIV container that’s only displayed if a little question mark (‘?’) link is clicked on, hence my desire to move everything into a block–because if I get the help text into a block, I can then initialize the block to be something like “display:none” whereby in the jQuery, whenever the Add / Edit page loads, I can then set it to “show()” when the ‘?’ link is clicked on, creating a nice and neat little help dialogue box for the users. It’s a win-win all around that saves screen real estate, makes the Add / Edit page easier to use, and it will make it look overall much better / more professional.

I tried using field_info_field() on one of the forms I’ve been trying to extract the help text stuff like the “Allowed Filed Types” (file_extensions) and the “Max Storage Space Allowed” (max_filesize), but the resulting data structure doesn’t appear to have this info in there as per what I’m seeing with dpm(field_info_field(‘field_video_upload’)). Obviously, field_video_upload is the field I’m using to accommodate for uploaded videos.

After hacking away with many other Field API functions and losing more hair late last night in trying to figure out what constituted the various data structures (i.e. - entity vs. bundle vs. field) within the Field Collection data structure I was playing with, I finally came up with a way to get what I needed:

1.) To get the php.ini-configured max_filesize value, I’ve used $max_size = (int)(ini_get(‘upload_max_filesize’)); (I plan on converting this to a string whereby I then plan on using the same format that Drupal uses to have he same sentence structure, etc.)

2.) To get the file types allowed part, I used $fields = field_info_instances(); and then traversed the structure to get the data I needed. Interestingly enough, if you do this FIRST, you’ll see that each field’s max_filesize array value is set to 0… I’m not sure why this is. I suspect that somewhere in core, it’s not set? Who knows? But regardless, I simply set it before to the $fields variable and later on in the block code, access both the allowed file types and max_filesize using the two following variables:

$fields['field_collection_item']['<my field collection>']['<my field(s)>']['settings']['max_filesize']
$fields['field_collection_item']['<my field collection>']['<my field(s)>']['settings']['file_extensions']

This gets me what I needed. Now in the Add / Edit theme stuff, I can use the jQuery file I have to control the visibility and do whatever I need with the respective block while gaining a LOT of real estate in the field group area of the page! :slight_smile: I wish I didn’t have to go down this path, but by doing it this way, I didn’t need to mess with any additional modules nor did I even really need to do much in the template.php file other than setting what jQuery file stuff I needed to be accessible in the respective content type. I love it when this stuff works. (Feel free to let me know if you have a better way to do all this.)

And happy new years to you too!

7

Wow… I have a personal site that uses the Field Collection module. I set my site up as a motorcycle user group and attached collections to user accounts so that members can register their motorcycles as unique collections. It works reasonably well but I think I should have instead just created a content type called motorcycle and then allowed users to own their content and create any number of “motorcycles”. I’ll probably rebuild the site to do that at some point and then migrate the 20 or 30 bikes I have registered. Anyway, that is quite different from your use case.

It took me a week to clear my head of other things so I could read and understand what you’ve been doing. I think I see what you’ve done based on my understanding of the Field Collection module, template.php, etc… and I would say it’s probably the simplest solution (now that you’ve gone through all the trials & tribulations). It sounds like a pretty intuitive interface now that it’s done. Awesome!

Andrew

8

There is nothing more fun than crawling through core to figure out why something doesn’t behave as expected. Anyway, long story short is that the max file size value in the settings array for a field is never set unless one is specified on the instance settings form for the field. If one is not set than than a validation callback within the file module uses the native PHP function value for max file size. Though that max file size value native to PHP ini is never added to the settings array for a field just used for validation based on whether the setting for field is empty. One would *expect the default in the field settings array to be the PHP native ini setting but if you think about the way it was done it somewhat makes sense. If it were added to the settings array, those settings being cached and all there is a possibility that the value would be incorrect when moving between different environments. Unlikely with a proper cache clear but possible. The best thing to do when something doesn’t work as expected is to just crawl through core or the contributed module to figure out why as documentation for anything related to Drupal is just about useless.

file.module/file.field.inc



// ...
/**
 * Implements hook_field_widget_form().
 */
function file_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $element) {
// ...
  $element += array(
    '#type' => 'managed_file',
    '#upload_location' => file_field_widget_uri($field, $instance),
    '#upload_validators' => file_field_widget_upload_validators($field, $instance),
    '#value_callback' => 'file_field_widget_value',
    '#process' => array_merge($element_info['#process'], array('file_field_widget_process')),
    '#progress_indicator' => $instance['widget']['settings']['progress_indicator'],
    // Allows this field to return an array instead of a single value.
    '#extended' => TRUE,
  );
//..

}

// ...

/**
 * Retrieves the upload validators for a file field.
 *
 * @param $field
 *   A field array.
 *
 * @return
 *   An array suitable for passing to file_save_upload() or the file field
 *   element's '#upload_validators' property.
 */
function file_field_widget_upload_validators($field, $instance) {
  // Cap the upload size according to the PHP limit.
  $max_filesize = parse_size(file_upload_max_size());
  if (!empty($instance['settings']['max_filesize']) && parse_size($instance['settings']['max_filesize']) < $max_filesize) {
    $max_filesize = parse_size($instance['settings']['max_filesize']);
  }

  $validators = array();

  // There is always a file size limit due to the PHP server limit.
  $validators['file_validate_size'] = array($max_filesize);

  // Add the extension check if necessary.
  if (!empty($instance['settings']['file_extensions'])) {
    $validators['file_validate_extensions'] = array($instance['settings']['file_extensions']);
  }

  return $validators;
}

//..