2

In Drupal 7, my commons wiki gives an error when editing.

EntityMetadataWrapperException: Unknown data property field_target_nodes. in EntityStructureWrapper->getPropertyInfo() (line 339 of /home/content/44/11622944/html/sites/all/modules/entity/includes/entity.wrapper.inc).

According to Drupal, the problem is that when commons is installed, it doesn't reset features because it might cause the user to loose work. So the solution is to reset features.

So I go /admin/structure/features/commons_wikis here and reset all I can, but I'm still having issues. My FIELD INSTANCES and MESSAGE TYPE are "stuck" in overridden. I've tried clearing the cache too.

I can't install or use drush because I'm on a hosted solution and SSH isn't an option.

How can I reset FIELD INSTANCES and MESSAGE TYPE without drush?

2
  • 1
    If those components don't revert using the UI, they wouldn't revert using drush either. You need to figure out first of all why your features are listed as overridden. Can you enable the diff module and click on the overridden component names to see what the overrides are?
    – goron
    Commented Dec 16, 2013 at 23:47
  • I think all my problems, from Drupal Commons saying it was an older version even though I had updated it, to the Wiki errors, were all a result of upgrading. To fix the problems, I finally gave up and installed Drupal Commons from scratch with an empty database and empty filesystem. Only then did the wiki errors go away. Thank you everyone for your help. I am not sure who to award the rep to, so I will give it to the first person.
    – rlb.usa
    Commented Dec 17, 2013 at 22:14

4 Answers 4

1

You can revert features in an update hook

e.g, in MYMODULE.install:

/**
  * Revert the 'field' component in my_feature_module
  */
function MYMODULE_update_7001(&$sandbox){

  features_revert(array('my_feature_module' => array('field')));

}

http://drupalcontrib.org/api/drupal/contributions!features!features.module/function/features_revert/7

Note, if you have manual access to the code, you can check in the wrapper if the field isset first prior to use, preventing that EntityMetadataWrapperException:

e.g:

// Check if field is set prior to use, avoid EntityMetadataWrapperException
if (isset($wrapper->field_target_nodes)) {
  drupal_set_message('<pre>'. $wrapper->field_target_nodes->value(). '</pre>');
}
1

If you did want to try this with drush you could do so locally, as long as your site could live with a few minutes of restricted user interaction.

I would recommend testing this out first (steps 1,3) to avoid disruption to users.

  1. download site (inc db via backup_migrate) and setup on local development server (eg acquia dev desktop, which includes drush)
  2. block users on live site (take care with notifications)
  3. run drush features-revert-all to resolve your features issue - test
  4. unblock users on local site
  5. create backup of local db using backup_migrate (to avoid mysql timeouts etc on upload)
  6. overwrite remote site db
0
+100

Not sure if this will work for you with the wiki commons editor, but something you might want to take a look at is features tools (https://drupal.org/project/ftools). Mainly the feature to look at is:

Revert them all Adds a "Revert Them All" button on the main features page, which let you (as it says), revert all features in one click. Especially useful for Dev and Prod environments, where there no drush around.

Again, not sure if this will work for you, but it's worth a shot. Also, as always, if your monkeying around with your site, make sure you back up your DB before doing anything too drastic incase something gets fouled up.

2
  • This did indeed revert all the features! But it didn't solve the problem. Hmm...
    – rlb.usa
    Commented Dec 17, 2013 at 17:16
  • 1
    Hmmm, have you checked the content type to make sure it has field_target_nodes associated with it? I noticed a comment in the thread you posted had mentioned that they had the error pop up only to discover the content types were missing some fields, may be the same issue your experiencing now. drupal.org/comment/7095316#comment-7095316
    – Jance
    Commented Dec 17, 2013 at 19:22
0

The Features module has, in the past, refused to revert (without any useful errors) if it meant removing a field instance. It has also been tripped up by trying to revert a content type that was already created before the feature was enabled, but was missing field instances.

As far as I am aware, those two specific problems got fixed. Or I could just have been lucky and never run into them again!

You're going to have to remove whatever hangups the Feature might be having by doing one of the following. I find that when Features is giving me trouble the solution can boil down to trying to make it do its job easier:

  1. Add the missing field to the type that won't revert, by hand. The field is clearly not there yet, so simply adding a field named 'field_target_nodes' and then try to revert might do the trick. Fields can be added (if the Field UI core module is enabled) at Administer > Structure > Content types > Content-type-name.

  2. Completely delete the offending content type and try to revert the feature, afterward. Consider even going as far as deleting each field from the type beforehand, to make sure everything is totally removed and anything that Features might be getting hung up on are out of the way. This will remove all data saved in the content type, all data saved in those fields, etc.

Alternately, if you can understand PHP, you can go a step further in #1 and pretend you're the features module. All of the settings options you'll need are all wrapped up in the features include file(s), and they're actually quite easy to read and understand. If you set the fields up the way they're "supposed" to be initially, it should remove any future revert issues.

Additional side questions: What version of Features are you running? What version of wiki commons? Following up on goron's question in the comment would be helpful, too.

1
  • Even though this is what some of the drupal community responses say, it was not helpful for me.
    – rlb.usa
    Commented Dec 17, 2013 at 22:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.