Modify .module file when a features.inc is added

I'm having the same problem. I agree that having this message would be easier to fix this problem, but the question is: Shouldn't be the features module who writes this line in the first place?

This is largely a duplicate of #922130: *.module does not get updated when *.features.inc is added, though where that issue discusses what might be done in modifying .module sanely, this one focuses on tweaking the existing warning. I am in favor of adding additional information--it will help some people until (if ever) this is resolved magically.

Someone want to roll a patch?

Moving this one to "Active" status since there is actually no patch that "needs work" (that's what the status is for typically).

This happened to me a few months ago, when this thread helped me solve it. I just had it happen again. After fighting with trying to revert etc for a while, I remembered my previous experience and was able to fix things. But, I thought I'd pass on that I didn't even get the warning this time.

This was on 6.20.

Here's a patch to fix this problem.

Note, I didn't take the make the warning better approach and instead added the file at the end of the .module file.

I believe this is better than assuming someone is going to actually go in an edit that file themself.

Also the warning is honestly display way to late for a user, and even worse if you're using drush as you would never see that.

This issue might also be consider a duplicate of #922130: *.module does not get updated when *.features.inc is added except that is for drupal 6 but essentially the some problem.

This should really be handled the same way in both versions. This thread should apply to rewording the message, that one should be for changing the .module.

Won't repeat my arguments again, but this is really one great big issue and it needs to be settled.

Personally, I prefer an approach where instead of creating a dummy module, turning it on, and running drush fu on it, you instead create a drush feature-create "module.info" which takes an info file exports the feature code, and turns on the feature. With that in place, the ugly workarounds for warning the user or creating a blank .module file go away entirely.

Probably that should be in the other thread, or a separate issue entirely.

Patch in #6 works just fine for me. Thanks!

I'm going to be bold and move this to RTBC re: the patch in #6.

Given the patch is a fix to the underlying problem, I'm also changing the ticket title to be in line with the D6 companion issue, #922130: *.module does not get updated when *.features.inc is added.

Hopefully the new status will help get some attention on this from the project maintainer and perhaps some guidance on the best way to fix this definitively.

Don't duplicate the names, you'll break my head.

I've come around on this issue. If someone wants to hand-edit the .module file to use a non-standard mechanism for file include, it's not hard to delete a line.

However, that line must always be in the same place. Include statements at the end of the file are non-standard, and could create error cases if someone puts functionality in features.inc and attempts to use it in the .module file.

I would detect the first comment block and insert it after that, since all files should have an initial @file comment block.

fixed the problem for me

This breaks features when components requiring the .features.inc file are added after its initial creation -- the components do not deploy and do not report as being correctly stored in the feature.

Accordingly, I'm changing status to a bug.

Here's an updated version of the patch that adds the include statement to the top of the file code.

Note that it doesn't remove this:

// Drupal needs this blank file.

as it looks like newer versions of features put this in the actual @file docblock.

There's a warning to update the file, tmk, so yea, this is a feature request.

I've seen that warning several times, and it's never made any sense to me!

I maintain this is a bug -- parts of features are totally broken until it's fixed.

You're told to do something but instead you ignore it -- who's at fault? It's not great usability or development experience, but that doesn't make it a bug.

features_log(t('@module does not appear to include the @include file.', array('@module' => "{$module_name}.module", '@include' => "{$module_name}.features.inc")), 'warning');

That's an ambiguous statement. I took it as meaning that the module package doesn't contain the features.inc file. It's not clear that the use of 'include' in the message means specifically the PHP 'include'.

UI that can't be understood *is* a bug.

If that was the case, everything is a bug because what makes sense to one person doesn't make sense to another.

If it at least said the user should take action that could be better; something like "You should ensure that PHP includes it by some means".

Could we maybe just get this fixed and a new release made so people stop getting burned by this one? I for one wasted a lot of time chasing this.

Seems to me the quick answer is to get a handbook FAQ page that can easily be searched for whatever message, and explains what needs to be done.

The message as it stands would not even prompt that.

The user sees it and thinks, 'Features is telling me this file isn't there. But it is there. Oh well, must be a minor bug.'

The user sees it and thinks, 'Features is telling me this file isn't there. But it is there. Oh well, must be a minor bug.'

Yup. I just lost time to this.

So #922130 was closed as a dup of this, which means this thread needs to focus on the solution to this issue and not just improving the help message. So changing this to "code". Also, I don't care if we call it a bug or a task...I mostly ignore the Issue Category. Let's just find a way to improve it. Right now I'm testing the patch in #12 and would like others to look at this also as a possible solution.

I agree with #20. I see the warning, but when I refresh and it goes away, I think, maybe it found the file the second time. I had a thought that maybe the inc file was not including the strong arm stuff, since that is what I just added, but I did not know that I needed to add the include once statement until I found this issue.

Making an improvement to the warning seems like a good first step along the way to getting features to recreate correctly.

How about..
hmm. I'll test my suggestions locally.

Well, I tried moving the inc file to a different name, editing the version of the feature in the .info file, and reloading the features page. Then putting back the inc and increasing the version in the .info again. I was trying to get the warning to show again.. and I can't. What's a simple way to trick the system into showing the warning to make testing this a bit faster?

I am marking this as a Bug, and Needs Work.

Its a bug either that the message is easily missed. I refreshed and it went away never to return. (thought to myself it must have been a cache issue)
Or its a bug because this makes features unreliable.

I created a feature with taxonomy. Exported the Feature to put it into code. The I wrote a migration around that taxonomy. Then I built a content type and exported again. I began to write a migration around the content type only to find that it didn't exist.

I marked it as Needs Work because, even if the patch #12 works it doesn't work well because it doesn't fix the comment in the .module file.

Did a bunch of testing and this seemed to work well. Fixed one of my features having this problem. Committed to 16300df.