3

The Feature I have created is stuck in the "Overridden" state. (I have also deployed the Prod Environment's database to the Dev Environment's database to ensure that everything was in sync during this test).

I am using Drupal 7 and am using the following modules in this situation:

  • Webform
  • Context
  • UUID
  • Features
  • UUI Features

Here are the additional dependencies:

enter image description here

Under "Configuration > Content Authoring > UUID Features Integration", I have selected the "Webform" Content Type as one of the "Exportable Node bundles" and "Files exported for Node bundles" on both my Prod and Dev environment.

When viewing the overridden page, the only component that is stuck in the "Overridden" state is the "Content" section (with the UUID of the two nodes listed):

enter image description here

When clicking "Revert components", it actually does revert the two nodes listed back to the state in the features. (Tested it by modifying the nodes and then clicking "Revert components" to see it revert back.

Despite that, it remains in the "Overridden" state.

In this particular situation, why does this remain Overridden?

Improve this question
2

FWIW, features should only be used to export configuration, and not content. I have audited a site which used UUID features and was not able to find a solution for reverting it. Exporting content (nodes, taxonomy terms, etc.) also makes the feature heavy.

Some things which you could do to :

Have multiple instances: (approach 1)

  1. Dev : continuous deployment happens here. E.g. After every commit or pull/merge request.
  2. Stage : Intermediate deployment; maybe after some feature is done completely. Think of this as a release. Or at every sprint end. When the code deployment happens. Database from the production instance is copied to this instance. So, that the testing can happen on live data.
  3. Live : Sometimes called production instance. Data is only created here. Deployment to this instance happens very infrequently.

These are all servers located on internet. Then, each of the developers have their own "local" site setup. Database from the live site should be used to test new features being developed (or bug fixes). This will ensure more accurate results, as testing happens on latest content.
Note: You can use features in this case only to export configuration.
If you do not want direct addition of content to live environment, try modules like Workflow, Workbench, or Workbench Moderation; which enables you to empower checking of content before the actual publish happens.

Important note: If you are using live database make sure you sanitize it. drush sql-san commands can come in handy.

Use Deploy module: (approach 2)

The Deploy module is designed to allow users to easily stage and preview content for a Drupal site. Deploy automatically manages dependencies between entities (like node references). It is designed to have a rich API which can be easily extended to be used in a variety of content staging situations.

Using this module, you can create content on one environment and push it to others. It is pretty easy to setup, with extensive documentation available.

In a nutshell -> KEEP "CONFIGURATION" AND "CONTENT" SEPARATE TO MAKE YOUR LIFE EASY!

Improve this answer
2
  • The problem with the approach outlined is that Deploy requires a 1-time setup where you put Deploy on a Source server and export to a destination. It doesn't work in an ad-hoc development cycle where you start to use Features late(r) in a project for example. There are other means to export content; such as the Default Content module, the Profiler module for D7, Node Export and others. I would recommend Featurizing Configuration seperate from Content if possible, as you say.
    – tenken
    Aug 8 '16 at 20:18
  • Thank you! I will be sure to try this out ASAP so that I can pick a best answer for this. I appreciate the time on this. It was well worded and easy to understand =)
    – AndrewMRiv
    Aug 12 '16 at 0:23
1

In general I agree with @AjitS - content probably should not go in a feature.

But to answer your actual question - sometimes Features just gets stuck as overridden even if everything actually matches. There is a good series of troubleshooting steps to clean it up, see here: https://www.drupal.org/node/986932

I would suggest: 1. Make sure you have Diff module, then you can click on "overridden" and see if there are any differences you missed between your module and the feature. 2. Disable and re-enable the Feature 3. Try the other steps if those don't work.

Improve this answer
1
  • Thank you for your answer! This was very informative =). I have since downloaded the Diff module and see "'revision_uid' => 1," listed twice. I cannot figure out what that means, though.
    – AndrewMRiv
    Aug 12 '16 at 0:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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