When using exported custom formatters part of a feature an error is thrown...

Notice: Undefined index: export in ctools_export_crud_load() (line 75 of sites/all/modules/ctools/includes/export.inc).

While the error itself is in the ctools module, it seems to be because the first parameter passed in is blank. This should be the "table name". For example for exported views this is "views_view". I'm not certain where the fix is needed in the code; I may look into it, but wanted to get the bug reported.

Comments

mrfelton’s picture

I'm getting this error all the time. I haven't exported any f my custom formats.

mbopp’s picture

Title: Feature Export Throwing Error When Used » Throwing Error When Used

So I believe this may not be related to the export as I originally thought. I traced the problem up to the calling function in ctools_export_ui.class.php on line 46.

function load_item($item_name)

The object instance doesn't seem to have a schema to pass this function.

mbopp’s picture

Version: 7.x-2.0-beta2 » 7.x-2.x-dev
Priority: Major » Critical
Status: Active » Needs review
StatusFileSize
new1.8 KB

Okay, found the issue. CTools requires the export_ui include file to define itself using the $plugin variable or a specified function. This module is using the $plugin variable which is included using 'include_once'. The problem is that it is already included once by the 'custom_formatters' module and thus isn't being included again. Because of this the $plugin variable isn't redefined to the appropriate value... it is just NULL.

It seemed the easiest way around this was to just use the other option for defining a plugin. Defining a function.

I added the function custom_formatters_custom_formatters_ctools_export_ui() to replace the $plugin variable. It returns the same information, but doesn't conflict with running 'require once' more than once.

The patch should work for either the beta or dev version (and maybe others).

Hope this helps.

deciphered’s picture

Priority: Critical » Major

mbopp,

Can you reference any documentation suggesting this method for CTools plugins? I would prefer to only follow supported approaches.

Also, could either of you provide some more steps on how you are reproducing this error? I have yet to come across it and I assure you I am putting the module through rigorous testing. I don't doubt that the error is occurring, I just prefer to be able to see an error before committing code to fix it.

Cheers,
Deciphered.

PS, Dropping this back to major as I can neither reproduce it nor is this a stable release.

mbopp’s picture

Sure, I found this option out via the code comments as I was tracing the error within the function ctools_plugin_load_includes() in ctools/includes/plugins.inc. Copied below...

          require_once DRUPAL_ROOT . '/' . $file->uri;
          // .inc files have a special format for the hook identifier.
          // For example, 'foo.inc' in the module 'mogul' using the plugin
          // whose hook is named 'borg_type' should have a function named (deep breath)
          // mogul_foo_borg_type()

          // If, however, the .inc file set the quasi-global $plugin array, we
          // can use that and not even call a function. Set the $identifier
          // appropriately and ctools_plugin_process() will handle it.
          if (isset($plugin)) {
            $plugin_arrays[$file->uri] = $plugin;
            $identifier = $plugin;
          }
          else {
            $identifier = $module . '_' . $file->name;
          }

So as far as replication goes, I created a custom formatter for use within a view that displays a date range based on a multiple date field. I received the error whenever the view was displayed.

So the problem, as I may have mentioned, is related to the $plugin variable. Setting this variable is only an option if the file is never referenced via "include_once" (with the exception of the ctools_plugin_load_includes function). Because include once won't interpret the code again if the file has already been included, the $plugin variable isn't reset, and because the $plugin variable is nullified right before including this file for the second time the $plugin variable remains null. This ultimately results in ctools throwing the error "Notice: Undefined index: export in ctools_export_crud_load() (line 75 of sites/all/modules/ctools/includes/export.inc)."

Oddly this doesn't seem to prevent the functionality from working correctly. The custom formatter works as designed even when the error is thrown.

Hope this helps. Let me know if there is anything else I can do. Thanks for contributing and maintaining this great module Deciphered!

deciphered’s picture

Hi mbopp,

I had some time to look into this issue, and I was unable to reproduce the issue with either PHP 5.2.x or 5.3.x.

Could you possibly provide me with a Feature and Drush make file, or access to a site where this is 100% reproducible?

Cheers,
Deciphered.

kelvinwong’s picture

Same problem here. Using PHP 5.2.9

annikaC’s picture

Me too. Using PHP 5.3.6.

The functionality still works, I just get the error on every page that uses the view with custom formatters in.

annikaC’s picture

And mbopp, if I use your patch, error goes away, but I have a big ol' "Edit formatter" string turning up in my formatter outputs... and 2 Formatters dashboard menu entries. :)

yareckon’s picture

Same error here.

My custom formatter code is:

$formatter = new stdClass;
$formatter->disabled = FALSE; /* Edit this to true to make a default formatter disabled initially */
$formatter->api_version = 2;
$formatter->name = 'node_ref_as_read_more';
$formatter->label = 'Node Ref as Read more';
$formatter->description = 'Node Reference rendered as a simple read more link';
$formatter->mode = 'php';
$formatter->field_types = 'node_reference';
$formatter->code = 'foreach (element_children($variables[\'#items\']) as $delta) {
  $item = $variables[\'#items\'][$delta];
  $target = $item[\'nid\'];
  return l(t(\'Read more\'),\'node/\' . $target);
}';

Would be great to get an "official" patch that avoids this. :)

hdcwebteam’s picture

Same issue here. I'm using Panels and displaying a node's file field with a simple custom formatter - it works fine but I get the notice as described above.

deciphered’s picture

Status: Needs review » Closed (cannot reproduce)

As I have still not been provided with any information on how to reproduce this issue, and as all searches point to this error being a fixable by Clearing Cache, etc, I have no option but to mark this as closed for the moment.

If someone can provide me with details on reproduction, or any other useful information I would be more than happy to reopen.

Cheers,
Deciphered.

deciphered’s picture

Status: Closed (cannot reproduce) » Fixed

I have reproduce this issue a couple of times, but it's still tricky to nail down exactly how.

Given the multiple reports of this issue I have decided to commit the patch and with any luck it will resolve the issue once and for all.

Thanks mbopp.

odegard’s picture

I just wanted to confirm that this patch fixes the issue. My use case is as follows:

I'm using page manager to show a long-text field in a panel. Don't know if that is important or not. I wanted to show it in a two column fashion so I imported the code from your post here:

http://drupal.org/node/46415#comment-4603910

I installed the module. Imported the code as given, changed $column to 2, went to page manager and set the formatter to the name I gave the imported code. Flushing the cashe and only then, did I get the message in OP.

Automatically closed -- issue fixed for 2 weeks with no activity.