Notice: Undefined property: stdClass::$status in features_export_form

Confirming that patch removes error for PHP 5.4.

Yes this does solve the problem, but what exactly status mean? also it does not exist in features_load_feature.

This code was introduced in [5cfef41e]

+++ b/features.admin.inc
@@ -142,7 +142,7 @@ function features_export_form($form, $form_state, $feature = NULL) {
   // If recreating this feature, disable machine name field to ensure the
   // machine name cannot be changed, unless user role has granted permission to
   // edit machine name of disabled features.
-  if (isset($feature) && ($feature->status || !user_access('rename features'))) {
+  if (isset($feature) && !user_access('rename features')) {
     $form['info']['module_name']['#value'] = $feature_name;

This worked for me but I wasn't trying to change the feature name, just generate the feature from the UI.

However, the comments about the check no longer reflect what is actually being checked.

@mkhamash, from what I'm reading it appears status should be showing if the module is enabled or not, and if not allow the users to change the name regardless of the specific permission.

Removing the check on status appears to be the correct thing. Especially given the parameter doesn't appear to be present.

@john.oltman, I know it's been a while but if you could update the patch I'd be happy to test and RTBC the issue.

Re-rolled the patch. Looking through, I can confirm the status property is no longer being used.

I believe the intent was that for installed feature export modules, the $feature->status field is whether the module is enabled or not. A module can be disabled but still installed (so $feature->status is false). This status field comes from the Drupal module core. It's the module status info.

There might be cases where this property isn't present, or perhaps it is no longer getting loaded properly upstream. But I don't think just removing the status test is necessarily the correct fix. Personally, I'd check the object upstream where it is being passed and figure out why the status property isn't available.

If you read the comment above, it specifically says it is allowing the machine_name to be changed if the module is disabled OR if the user has the rename feature permission.

#10 works well. Thanks.

This is not RTBC because the issues in #11 have not been addressed.

When the form is loaded, the $feature argument is coming from the feature_load() function based on the machine name of the feature in the URL. This data initially comes from scanning the module list, and the "status" property shows if the module is enabled or not.

I do not see any cases where this status would not be set, so somebody who can reproduce this issue needs to help debug it to determine why the status property is not available for their feature module.

How to re-produce this bug:

In drupal 7, some developers(like me) would skip the last step of installation, leaving some site information and first user blank,
then, using drush to create an admin user.

This will cause the issue mentioned,
I do agree with mpotter that simply remove that part of code accessing $feature->status is not a correct fix.

But trying complete the last step of installation actually fixed the problem for me.
Features module has nothing wrong to assume the user will have these information filled in.

Totally agree with #13 and #14, however my features are enabled and working and I still get the message although the "status" column in the system table in my database shows "1" for the currently viewed feature, but the property of the currently passed features objects is missing.

OK, not really sure what is going on but I cannot see where the status property for a feature is being set, see features_load_feature() and #7 and #9.

So the proper fix would be to set that property during features_load_feature().

Attached patch should solve this.

Changing metadata etc.

You shouldn't be doing a db query for this.

1. You should not use db_query in D7. You should use proper db object functions, such as db_select.
2. You shouldn't do a query for data that Drupal already has loaded and cached. You should just be able to use the module_exists() function to determine if a module is enabled.

If that's the case, this should satisfy as a fix. module_exists returns TRUE or FALSE if the feature is enabled, thus setting the status.

Yep, I think that should cover it. Committed to 85f4a9b.