http://localhost/drupal/admin/structure/features/cleanup/clear
After calling cleanup seeing:

Notice: Array to string conversion in features_get_orphans() (line 700 of /home/s8weber/svc/drupal/app/drupal/profiles/uwlib_profile/modules/contrib/features/features.module).
Notice: Array to string conversion in features_get_orphans() (line 700 of /home/s8weber/svc/drupal/app/drupal/profiles/uwlib_profile/modules/contrib/features/features.module).
Notice: Array to string conversion in features_get_orphans() (line 700 of /home/s8weber/svc/drupal/app/drupal/profiles/uwlib_profile/modules/contrib/features/features.module).
....

Looking into the features.module i did some debugging:

function features_get_orphans($reset = FALSE) {
...
        var_dump($modules[$module]->required_by);
        echo 'ssssssssssssssssssssssssssss';
        var_dump($enabled);
        die;
        $dependents = array_intersect($modules[$module]->required_by, $enabled);
...

And the debugging output truncated:

array(16) {
  ["date_views"]=>
  array(1) {
    ["name"]=>
    string(5) "views"
  }
  ["draggableviews"]=>
  array(1) {
    ["name"]=>
    string(5) "views"
.......
}
ssssssssssssssssssssssssssss
array(57) {
  ["strongarm"]=>
  string(9) "strongarm"
  ["block"]=>
  string(5) "block"
  ["webform"]=>
  string(7) "webform"
..........
}

It seems that the format of the array has changed
$modules[$module]->required_by is nested array of strings.
$enabled = module_list() is array of strings .

Drupal 7.x commit 33234ac2d
Date: Wed Sep 5 22:58:31 2012 -0700

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

steverweber’s picture

Also hit another notice.

Notice: Array to string conversion in features_export_prepare() (line 190 of /home/s8weber/svc/drupal/app/drupal/profiles/uwlib_profile/modules/contrib/features/features.export.inc).
btopro’s picture

Priority: Major » Normal

Also reproducing this in local development. Not sure that it's major but it is slightly annoying when doing a lot of features development

mpotter’s picture

Do you have a step-by-step procedure for triggering this that you can share? Looks like it only happens when there are orphaned dependencies and I've had a hard time making this happen easily.

eldrupalista’s picture

FileSize
186 bytes

Meanwhile a better solution is provided, you can fix this including this piece of code:

      foreach($modules[$module]->required_by as $module_name => $dependency){
          $modules[$module]->required_by[$module_name] = $dependency['name'];
       }

Check the attached patch, apply in features.module file.
My version of Features is 7.x-1.0

eldrupalista’s picture

Status: Active » Needs review
mpotter’s picture

Can you please roll that patch properly? I don't see any of the normal "git diff" header information in your patch file. Also, for patch naming, please see http://drupal.org/patch/submit.

(This is a simple enough patch that I'll try to take a look, but you should learn how to submit patches properly or you'll run into trouble with the community)

mpotter’s picture

Also, seems like your code should be modifying the $dependents array and not the $modules[$module]->required_by[$module_name] array directly.

Topcheese’s picture

I've not had a chance to look at the code, nor test on another server yet, but I did get this error after upgrading to the latest dev release. I suspect that it's possibly PHP 5.4+ related, as the latest dev cleared up a different string to array conversion error. Notice: Array to string conversion in EntityAPIControllerExportable->applyConditions()

Edit: This issue seems to still exist. The latest Entity API dev had cleared up the other issue which was related to PHP 5.4+

kclarkson’s picture

I to am getting this message: Array to string conversion in features_get_orphans() (line 714

I have upgraded my MAMP which is now PHP 5.4.4 not sure if this helps.

@mpotter

I tried adding the code
foreach($modules[$module]->required_by as $module_name => $dependency){
$modules[$module]->required_by[$module_name] = $dependency['name'];
}

in the .module file around lines 700 but it didn't remove the error. Anyway to help us out on this ?

Thanks
K

Topcheese’s picture

Hi, I haven't had the chance to get to my old issue queue, and I'm also currently using PHP 5.3, so I'm not sure I can help.

Edit: I believe what it was is that I had the same issue when using PHP 5.4+. I just listed the other issue in #8 because it was 5.4+ related. All I can say for sure is that at some point updating Entity API helped me with an issue.

Now that the Commons Beta is out I plan to spend more time organizing my issues and helping out with the Commons issue queue.

kclarkson’s picture

Is this patch ready to go ? Error is def driving me a little bonkers :)

Updating Entity API did not fix the error.

Topcheese’s picture

@Kclarkson, I believe your answer can be found following this issue Array to string conversion error from line 625 of entity/includes/entity.controller.inc. I'm pretty sure you have to apply the patch yourself as it has not made it into any release yet. There are also others having issues with PHP5.4 and you might want to see what solutions worked for them.

waverate’s picture

Similar to another Features issue #1588596: Notice: Array to string conversion in features_export_prepare() (line 190 of features.export.inc) that was solved with a patch.

Notices exist using:

Drupal 7.19
PHP 5.4.9
features-7.x-2.0-beta1

I do not have the Entity API module installed so I doubt the patch at #12 (entity/includes/entity.controller.inc) is the solution.

waverate’s picture

Patch at #4 worked for me against features-7.x-2.0-beta1

Re-uploading it.

haxney’s picture

Here is a patch against 7.x-2.0-beta1 which solves the problem for me. This is a correctly-formatted version of the code from #1776738-4: Notice: Array to string conversion in features_get_orphans.

steverweber’s picture

Thanks haxney, it seemed to solve the issue.
I hope the maintainer pulls this patch in soon.

pfrenssen’s picture

Status: Needs review » Needs work

I haven't tested the patch but it is not compliant to coding standards and is not correctly indented.

  • Control statements such as foreach should have a space before the opening bracket.
  • Curly brackets should be preceded by a space as well.
Jaesin’s picture

I only made the comment #15 patch code complaint.

jlporter’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Component: User interface » Code
Assigned: Unassigned » jlporter
Status: Needs work » Reviewed & tested by the community

#18 is a go

drwits’s picture

same here. 18 worked for me

kingfisher64’s picture

#18 worked lovely. Let's get this committed asap :)

steverweber’s picture

+1

kclarkson’s picture

rtbc

thelee’s picture

can we get this committed and rolled out?

NOTE - does this actually break anything or is it just a minor warning - IE can i still be using features just fine in php 5.4?

mpotter’s picture

Status: Reviewed & tested by the community » Fixed

Committed to b84e900.

Status: Fixed » Closed (fixed)

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

joelwallis’s picture

Hi.

Do you have a plan to incorporate this bugfix to the 1.x branch?

nedjo’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
Issue summary: View changes
Status: Closed (fixed) » Patch (to be ported)

Bug is present in 1.x, so patch should be backported.

hefox’s picture

I don't believe anything is being backported to 1.x

  • mpotter committed b84e900 on 8.x-3.x
    Issue #1776738 by agviu, waverate, haxney, Jaesin | steverweber: Fixed...
marcelovani’s picture

I am still using 1.x, will upload the patch here, in case other people still want to use it.

mpotter’s picture

Status: Patch (to be ported) » Closed (won't fix)

There is no reason to be using 1.x. 1.x is deprecated and no longer supported. 2.x is fully compatible with 1.x.

Thanks for the patch, but closing the issue as a won't-fix.

donquixote’s picture

Not happy with what was committed 7 years ago.
(found this issue with git blame)

TLDR:
- The function is not used anymore since #719308: Remove orphan module detection. So the problems I mention here are mostly theoretical.
- The function, if called, will poison original objects cached in other functions (this was introduced here).
- The function is not properly documented. It is not clear from the doc what it does.
- The function seems to not really work. It will return an empty list most of the time.
- It contains a redundant call to _module_build_dependencies() which is pointless because features_get_modules() already adds this info (indirectly).

Poisoning

@mpotter (#7)

Also, seems like your code should be modifying the $dependents array and not the $modules[$module]->required_by[$module_name] array directly.

Absolutely.
With the current version (as introduced here), original objects (cached in other places) are poisoned.

Not working

Why do I say it does not work?
The structure of ->required_by seems to be like this:

$[$module]->required_by[$depending_module]['name'] = $dependee_module;
// with, anywhere I checked:
$module === $dependee_module

After the (poisoning) modification introduced here, it is like this:

$[$module]->required_by[$depending_module] = $dependee_module;
// and still, anywhere I checked:
$module === $dependee_module

This means the array_intersect() below will never be empty, and thus the module won't count as orphan:

        // Determine whether any dependents are actually enabled.
        $dependents = array_intersect($modules[$module]->required_by, $enabled);
        if (empty($dependents)) {
          $info = features_get_modules($module);
          $orphans[$module] = $info;
        }

The $modules[$module]->required_by will always contain the module itself as a value, which is also in $enabled, so the module is never counted as orphan.

Why do I care

I am doing some (non-disruptive) clean-up on the features module.
If I find some defunct leftovers, I want to at least document it.