PHP Error when exporting a feature

Removing the name_features_api() function at the bottom of name.module will probably resolve this if urgent. What version of Features?

Related #1890178: Cannot Recreate Features

Can you try this if you are still interested in helping debug this:

static $debug = TRUE;
if ($debug && is_string($value)) {
  //$debug = FALSE;
  $trace = debug_backtrace();
  $output = '';
  foreach ($trace as $n => $v) {
    $output .= $n . ': '
      . (empty($v['file']) ? '' : $v['file'] . ', ')
      . (empty($v['line']) ? '' : $v['line'] . ', ')
      . (empty($v['function']) ? '' : $v['function'] . ', ') . "\n";
  }
  // dpm() may work too :)
  drupal_set_message('<textarea rows="10" cols="25">' . $output . '</textarea>');
}

thanks for an advice, but it does not work when dealing with fatal errors.

Here is work around:

    function error_handler () {
      dpm(debug_backtrace());
    }
    set_error_handler( 'error_handler' );

Getting the same error with Features 7.x-2.0-beta2 and Name 7.x-1.8 all running on Drupal core 7.22. Here is my backtrace:

( ! ) Fatal error: Cannot create references to/from string offsets nor overloaded objects in /includes/common.inc on line 6548
Call Stack
# Time Memory Function Location
1 0.0001 358416 {main}( ) ../index.php:0
2 1.6841 10469428 menu_execute_active_handler( ) ../index.php:21
3 1.6895 10848200 call_user_func_array ( ) ../menu.inc:517
4 1.6895 10848420 drupal_get_form( ) ../menu.inc:517
5 1.6896 10848944 drupal_build_form( ) ../form.inc:131
6 1.6941 11051920 drupal_process_form( ) ../form.inc:374
7 1.6942 11053580 form_builder( ) ../form.inc:842
8 1.7033 11395568 form_builder( ) ../form.inc:1857
9 1.7593 11916824 form_builder( ) ../form.inc:1857
10 1.7594 11920032 form_builder( ) ../form.inc:1857
11 1.7596 11924784 form_builder( ) ../form.inc:1857
12 1.7596 11925120 _form_builder_handle_input_element( ) ../form.inc:1795
13 1.7596 11925452 drupal_array_set_nested_value( ) ../form.inc:2003

Hope this helps. Let me know if you want me to test any code/patches.

k, wasn't helpfil :(

I am wondering if two modules are defining the component 'name'

<?
dpm(features_get_components());
?>

If all is ok, things will be similar to:

... (Array, 18 elements) 
  ....
  name (Array, 4 elements)
    name (String, 12 characters ) Name formats
    default_hook (String, 20 characters ) name_default_formats
    feature_source (Boolean) TRUE
    file (String, 49 characters ) sites/all/modules/name/includes/name.features.inc
  .....

If there is a conflict then it will look like this:

 ... (Array, 18 elements)
    ....
    menu_links (Array, 4 elements)
    menu (Array, 4 elements)
        name (String, 10 characters ) Menu items
        default_hook (String, 18 characters ) menu_default_items
        default_file (Integer) 1
        feature_source (Boolean) FALSE
    name (Array, 2 elements)
        0 (Array, 4 elements)
        1 (Array, 4 elements) 

I am also getting this error after upgrading to Name 7.x-1.8.

@jlapp

The same error? Only when doing things related to features?

I'm running features + name and having no issues, difficult to debug :(

If anyone is willing to share a db dump + sites/module folder please PM me and I will provide an email address to send to

Or can someone try this:

/**
 * Implements hook_features_api().
 */
function name_features_api() {
  return array(
-    'name' => array(
+    'namefield' => array(
      'name' => t('Name formats'),
      'default_hook' => 'name_default_formats',
      'feature_source' => TRUE,
      'file' => drupal_get_path('module', 'name') . '/includes/name.features.inc',
    ),
  );
}

ie: replace name with namefield and completely flush your caches and registry

I changed 'name' to 'namefield' and still get this error. Also, I was able to easily replicate this error. If I leave the Feature name to blank, I don't get an error. As soon as I enter a Feature name and then attempt to download it, I get the above error.

So limited to some Features 2.x versions. Renaming to namefield worked for me.

@humansky did you flush the cache? Running update.php will be enough.

Root cause is what is likely to be a core bug in the FAPI that is probably worth none of our time chasing, namely there are two name FAPI elements on the page and this is confusing drupal element lookup.

Will tag and release if people are happy with this. (already pushed to dev name => namefield)

Alan D, thanks for your quick responses. Yes, I am getting the same error that others are reporting only when recreating a feature (right after clicking the "Download" button). I will try your latest dev version today and report back with the results.

@Alan D. I did clear the cache.....but I changed the wrong 'name' key.....UGGG. Either way, I changed the correct field to 'namefield' and cleared cache several times, now it works. Thank you!!! I apologize for the misguidance, it was late :-)

I have jumped the gun and pushed it into 7.x-1.9.

My development was with Features 7.x-1.x (only locally running system with Features) that had no issues. :/

Thanks again Alan D. I tried version 7.x-1.9 and after a cache clear am able to export features again. However, with 7.x-1.9 I no longer have the ability to export Name Formats (the NAME FORMATS section is missing from the COMPONENTS list on the feature creation page).

I believe the issue stems from changing the $component in name_features_api() from "name" to "namefield". For all of the Features hooks, the Features API docs state:
"The hook should be implemented using the name ot the component, not the module, eg. [component]_features_export() rather than [module]_features_export()."
I have updated all of the implementations of Feature hooks and a couple of other places where the component is referenced and that seems to restore the Name Formats export functionality for me. Please see the attached patch for your review. This is my first experience implementing Feature hooks, so please let me know if anything looks off in my patch.

Confirmed that changing things to namefield in #9 and #15 fixes the 500 error.

Crazy. I changed and managed to export after the change. Now it doesn't... maybe another level of caching somewhere... or I simply stuffed up after trying to quickly do this after an 80 hour week at work :P

I have tested and pushed jlapp's code to dev.

I still need to remove the id's from the export, so back to needs work

This one removes the db serial id. Now, hopefully we can put this issue to bed :)

Reopen if there are any issues. No plans to re-roll for this fix, but dev should be fairly static for a long time until I finally get around to figuring out the last remaining bug for i18n integration.

Thanks so much for your work on this issue Alan D! I'll update to the latest dev release with the removed DB ID in the next couple of days.

I should be thanking you for your follow up in #15! Same for everyone else who helped!

It will teach me to cut n paste a new feature in, particularly just before releasing a new version.

sorry to ask Alan,

could we please have this patch include changes for the previous patch? your patch isn't reflecting the actual code of the file but changes after the 1st patch. that's kind of confusing :\

thanks for getting this figured out as fast as y'all did.

Everything is in the latest dev version, so no patches are required. :)

This is the only fix in dev and there is unlikely to be any activity for months now there.

If you need one, just overwrite 1.9 with dev (excluding name.info) and generate a patch from that.

Hi Alan,

I just created the patch between 1.9 and the dev version. It is attached to this note, just in case for those folks that want to apply the diff quickly in their environment.

Cheers,
Mitch