Newbie to Features question:
I am trying to add the CSS for the items in a Feature with a stylesheet specified in the .info file:
stylesheets[all][] = "stylesheet.css"
After moving the relevant CSS into that file, I recreated the Feature (don't know if this step is necessary), but the CSS didn't take effect. I tried a full path name for the CSS file as well.
Any advice on to whether/how this works?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

febbraro’s picture

Status: Active » Postponed (maintainer needs more info)

What do you mean when you say "the CSS didn't take effect"?

Can you elaborate on what was happening before you recreated the feature and what is now happening after the recreate.

Mark_L6n’s picture

That there's no CSS styling--it appears the stylesheet is not getting loaded.
What I did was take the CSS out of my big main stylesheet, and put it in a stylesheet as described above. I did this because I thought it would be better to keep the styles for the feature together with the feature.
So, once I took the CSS out of the main stylesheet, the items in the feature were not getting styled. After creating the stylesheet as described above, modifying the .info file and recreating the feature, it was the same--the items in the feature are not getting styled.

Grayside’s picture

Unless I'm off my rocker, modules don't include stylesheets based on that being in the .info file, and if it did, there are many cases where you wouldn't really want it to just load the CSS on *every page*. Good practice is to apply some kind of logic to only load it when needed.

Mark_L6n’s picture

I don't know about D6, but it's OK in D7--from http://drupal.org/node/542202:
Drupal 7 allows you to add CSS files in the module's .info file if it should be added on every page, just like theme .info files do. Here is an example from the node module's .info file:
stylesheets[all][] = node.css

I believe there's also the school of thought that since Drupal can consolidate all the CSS files into one file, it's better to just load one big stylesheet.

So the reason for using the Feature-specific stylesheet is more organizational--just to keep all the relevant code together. It would also make it easier and cleaner for using Features for syncing Dev-Staging-Production.

Grayside’s picture

Okay, I believe all that you said.

Features are just normal modules however. There is nothing about it that should prevent you from adding a stylesheet reference to the .info file and having it load. If a couple cache clears and a file permissions check don't clear it up, this is a mystery.

Mark_L6n’s picture

I'm thinking the same thing as you in #5. Thanks for taking the time to look at it. At least it's not a big problem--I'll just leave the CSS where I originally had it.

febbraro’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Reopen if this turns out to still be an issue

Mark_L6n’s picture

OK, thanks.
Just speculating here--Since Features are normal modules, stylesheets[all][] = node.css should be expected to work if you converted a Feature to a (non-Features) Module.
However, that doesn't necessarily mean that code in Features for 'Recreating' recognizes stylesheets[all]. Might it be the case that there needs to be a code addition for D7 for pulling in stylesheets specified by stylesheets[all][] = node.css?

Grayside’s picture

The only functionality specific to a Features Module and not a Normal module are (1) exported components that are defined in the .info file, and thus managed by Features for Updates and Reverts and (2) hooks invoked by Features that don't otherwise exist.

Anything else in a Features module, or in the .info file, is literally just a module. It's kind of like saying it's an OG module, if you happened to define some OG settings with stuff in the .info file instead of Drupal variables.

So anything you are seeing with a stylesheet definition should be the same as in any module, unless some Features-related module has a bug and is over-mucking about with .info file contents.

ShaneOnABike’s picture

Category: support » bug

Yep it is actually...

I've tested this twice now and it looks like when you add new things to your existing feature it rips out the other settings you have. In this case I had custom style sheets stuff in there that was removed.

How to repo:

* Create a feature
* Edit the info file and add your own stylesheet
* Add something new and it's removed

Now what's interesting is if you do a 'recreate' and don't add anything is re-orders the stylesheet to the bottom and generates everything properly.

Grayside’s picture

Status: Closed (works as designed) » Active

That needs confirmation. If features is scraping out other .info file infos that is a problem. Should be an unremarkable passthru.

jaime@gingerrobot.com’s picture

Hi,

I just recreated this bug

1. I created a feature of a view
2. I manually added a stylesheet to the info file
3. I did a features- update
4. I checked the info file and the style sheet line had disappeared.

I think features-update should maintain the style sheet in the info file even if we shouldn't be putting CSS in there.

Jaime.

muriqui’s picture

Title: Add CSS to Feature with stylesheets[all][] in .info file? » Style sheets in .info file lost when recreating feature
Version: 7.x-1.0-beta4 » 7.x-1.0-beta6
Component: Miscellaneous » Code

Confirming that this is an issue in the latest release. Steps to recreate:

  1. Create and enable a feature.
  2. Manually add stylesheets[all][] = myfeature.css to the feature's .info file.
  3. Recreate the feature.

Result: The stylesheet declaration is removed from the .info file on export.

I'm also taking the liberty of updating this issue's title and settings to be more descriptive of the bug.

joelcollinsdc’s picture

I'm unable to reproduce on 7.x-1.x...

$pwd
/Users/joel/htdocs/openpublic_build/sites/all/modules/test_panels_permissions
$cat *.info
name = "test_panels_permissions"
core = "7.x"
package = "Features"
php = "5.2.4"
dependencies[] = "features"
dependencies[] = "panels"
features[user_permission][] = "administer panels styles"
features[user_permission][] = "use panels locks"
stylesheets[all][] = "test_panels_permissions.css"
$drush fu test_panels_permissions
Module appears to already exist in sites/all/modules/test_panels_permissions
Do you really want to continue? (y/n): y
Created module: test_panels_permissions in sites/all/modules/test_panels_permissions                     [ok]
$cat *.info
name = "test_panels_permissions"
core = "7.x"
package = "Features"
php = "5.2.4"
dependencies[] = "features"
dependencies[] = "panels"
features[user_permission][] = "administer panels styles"
features[user_permission][] = "use panels locks"
stylesheets[all][] = "test_panels_permissions.css"
$
hefox’s picture

My guess is that this issue is from UI only.

My other guess this will be solved by making the UI more like the drush command.

Grayside’s picture

I have wondered if it was worth the madness to try putting together a Drush interpreter for Form arrays. Anyway, back to reality ;)

ShaneOnABike’s picture

For what it's worth I didn't place this at the bottom of the file but actually somewhere in between. This could just be a UI coding issue who knows.

weri’s picture

Title: Style sheets in .info file lost when recreating feature » Style sheets (stylesheets[...][]) and Scripts (scripts[]) in .info file lost when recreating feature
Priority: Normal » Major

I can confirm this problem.

When I update the feature with drush, everything is fine. When I update the feature over the UI, the styles and scripts are removed/lost.

mstef’s picture

+1 to #18

keesee’s picture

Same issue. I found the same as #18 true.

sylus’s picture

Same Issue and +1 to #18

wouters_f’s picture

FileSize
2.45 KB

A patch for this can be found in attachment.
Please test it.

wouters_f’s picture

Status: Active » Needs review
FileSize
2.18 KB

A more correct patch (with issue and comment nr)

Shawn DeArmond’s picture

Version: 7.x-1.0-beta6 » 7.x-1.0
Status: Needs review » Reviewed & tested by the community

#23 works great for me.

Applies fine to 7.x-1.0.

Thanks!

harald_’s picture

Is there a chance this patch will be integrated to the module?

mpotter’s picture

Still looking at this one, but in general I'm waiting to integrate the new UI 1.1 branch before doing a lot of other issue commit. Should be soon though.

mpotter’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
3.56 KB

Here is an updated patch that does things a bit cleaner and applies to the latest 1.x-dev version.

mpotter’s picture

Status: Needs review » Fixed

Seems to be working well in my testing here, so committed to 21f5271.

wouters_f’s picture

By the way the same issue occurs when using the ftools module.
Do I create an issue there too?
** EDIT this is the issue: http://drupal.org/node/1830564

mpotter’s picture

Yes, that module has a separate maintainer so you should post to that issue queue. The extensive changes in the Features 1.1 branch might require additional changes to other modules.

wouters_f’s picture

The features tools module was fixed also.
http://drupal.org/node/1830564

Status: Fixed » Closed (fixed)

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

Itangalo’s picture

Status: Closed (fixed) » Needs work

I'm still experiencing this problem, using the latest dev of Features. I've been using drush as well as the UI to update/recreate features.

Sorry :-/

mstef’s picture

Latest 1.x dev not working for me either.

mstef’s picture

The commit is missing the changes that the patch has on features.export.inc. Even after manually adding those changes, the issues still exist..

Scripts are added, but I'm getting scripts[] = 1, scripts[] = 2, etc.

This is actually part of another issue that I've reopened: #1131062: scripts manually added to info file have the path broken

mstef’s picture

Patched 1.0 with http://drupal.org/node/1335634#comment-6202028 works fine. Like I said before, I just pulled the latest 1.x-dev and it's not resolved.

Shawn DeArmond’s picture

Thanks @mstef.

I'm putting this back to RTBC.

Please use patch in #23.

mpotter’s picture

Version: 7.x-1.0 » 7.x-2.x-dev
Status: Needs work » Reviewed & tested by the community

Slipped off the radar because didn't actually get moved back to RTBC ;)

Will be applying this to the 2.x branch however since the 1.x branch is frozen at this point.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, features-missing-css-1335634-27.patch, failed testing.

mpotter’s picture

Status: Needs work » Fixed

Closing this because the patch in #27 is already part of the code. Must have been done in multiple commits. If this still occurs in the 2.x-dev then we need steps to reproduce it and a new patch.

Status: Fixed » Closed (fixed)

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

rafenden’s picture

Issue summary: View changes
Status: Closed (fixed) » Active

I still experience this issue when I'm executing drush fua -y.

mpotter’s picture

Status: Active » Closed (fixed)

Please do not re-open old issues with committed patches. If you have a problem, document the exact steps to reproduce it in a new issue.