Resources - Additional Stylesheets

[indridcold]

There is something very odd about adding additional stylesheets via resources and injecting them … I think it’s broken.

Example:
[1] Using Foundry framework (but could be anything this is not related to Foundry as far as I can see) create a simple page, add simple content, Eg, a paragraph stack.

[2] Create a stylesheet with a single class like;

.customCol {
    color: red;
}

[3] Add the stylesheet as a resource then link to it using the macro in the global or page head container.

[4] Go back to the paragraph stack and add class ‘customCol’.

[5] Preview, export whatever… this MAY work.

Now, open resources and select the custom CSS file. Choose edit with xxxx (E.g. Sublime ). Change the class style directives to use Eg blue text. Whatever, it does not matter. Save the stylesheet.

Save and preview or export then preview:

Expected result:
That the edited and saved class style rules will kick in and the text will be blue (or whatever you configured in the .css).

Actual result:
The previewed page does not reflect the changes and the text will still be red, or whatever it was before. Your updates styles are not honoured even though you have saved the file, closed out of resources and hit ‘preview’.

Want the kicker?..
If you then change any other element on the page, using stacks, for example modify the text in an unrelated header, or anything minor like that… the CSS change you made in your stylesheet is then picked up and the styles are applied. What you changed does not need to have the custom class you added in the css file. Any change, as far as I can tell, will do.

Clearly the rebuild of page styles including possible external resource based stylesheets is not being triggered until there is a conventional page ‘edit’. Altering your resources based stylesheet isn’t calling that rebuild/render. Why?

RMS… what IS going on…? This CANNOT be expected/reasonable behaviour… you surely need to wire up page update routines (especially for *.js or *.css) when an edit has been made to resources NOT rely on subsequent edit to page. As it is, it’s broken, in my opinion because I can’t just edit css in a linked stylesheet and expect it to work without some arbitrary edit on the page.

[teefers (Doug Bennett)]

I guess my first question is why are you doing it that way?

There are sections in the code area for CSS and JavaScript, is there a reason to place the code into resources?

I know a lot has been done to speed up preview both from RealMac and YourHead(stacks).

My second question is are you sure it’s RMS and not YourHead?

[indridcold]

//I guess my first question is why are you doing it that way?

Whats wrong with it? Adding a stylesheet via resources is somehow incorrect? Explain? If an additional/helper stylesheet is not a “resource”, I don’t know what is.

//There are sections in the code area for CSS and JavaScript, is there a reason to place the code into resources?

Yes. Show me where I can style my my code (even the colors) to a minimum standard and I’ll take that idea seriously. What if I want to add styling for 60 classes… that editor cuts it for you? Not me. Take a look… umpteen class definitions or functions with, for example, navy on black and no way to control the colour preferences? Thats bonkers.

Also… note that the option is provided by the software to edit in an external code editor… the intention of this is clear… the execution and implementation is apparently flawed.

//I know a lot has been done to speed up preview both from RealMac and YourHead(stacks).
Preview?

You think they ripped out pre-render checks on resources to accelerate preview? That is not ok. Is that your theory?

//My second question is are you sure it’s RMS and not YourHead?

What does RW processing of resources have to do with YourHead. Explain?

[teefers (Doug Bennett)]

@indridcold

What does RW processing of resources have to do with YourHead. Explain?

A lot of the preview and publishing function is part of the Plugin. I know YourHead is constantly making changes to improve preview/publishing speed. I don’t know (not being a Plugin developer) where the boundary is between the core RapidWeaver and the plugin developer when it comes to preview and publishing.

[indridcold]

My bet is that the work YH does to improve performance in preview is going to be related to collation of stacks content and resolving/processing templates, settings and dependencies or resources related to stacks requirements. Then, again, just my guess, it needs to hand off to the main RW engine to take the payload from the plugin and run with it through to a preview-able, export-able or publish-able rendered block.

I doubt there is much that YH can do, beyond offer tight as possible code generation/consolidation from templates and settings, to influence publishing as such. Happily be corrected on that, but I didn’t think the RW plugin API offered much ingress into publishing services per se.

In this case I’m taking about a CSS file in core RW domain resources, within which changes are not triggering a sufficiently deep recompile of the page, stacks payload notwithstanding.

I will, as always, happily be corrected, but my gut feel is this is nothing to do with YH.

[teefers (Doug Bennett)]

As I said, I don’t know where the boundary is, I know from YH slack channel there is an upcoming “experimental” beta release:

The upcoming releases will have some experimental changes to Stacks publishing system. They have the potential to affect some large changes, and improve speed of publishing. However these changes rely on threading and caching – the more memory and processors you have the more this change will help.

That sounds like a bit more than “code generation/consolidation”,

[indridcold]

Interesting. I wonder if in this context ‘publishing’ is meant as generating the page ‘into’ RW or whether it means publishing in the usual ‘I can’t get my site to publish (to my web host)’ context.

RMS letting YH into the publishing engine/space could, of course, only be a good thing…

But… we are now off topic speculating about a YH beta with incomplete information.

In the here and now CSS changes in a RW resource linked stylesheet don’t trigger a page update unless the page is somehow edited and I’d appreciate knowing whether this is expected behaviour or not. If it is expected it means a workflow based on linked stylesheet edits is a bit broken. If it’s not expected behaviour then its a bug. The second option has potential for a happy ending…

[indridcold]

@Aaron
@dan

Would appreciate your views.

[dan (Dan C.)]

Sounds like it might be showing the cached page, if you export the site is the CSS exported correctly?

Cheers
Dan

[indridcold]

Nope. Not until the page is conventionally “edited”, does the stylesheet update get reflected in the project structure map.

Can you describe the relationship between a stylesheet file which has been added as a file in resources and how or if RW monitors that file for changes? Would you expect changes to that file to be picked up and baked back into the project for example?

Or, is this why the resources panel includes a 'edit with…" dialog to ensure that what is opened for editing is the version of the file which has been mixed into the working project structure which the user would not normally interact with?

[dan (Dan C.)]

Does it work on a non-Stacks page, say on the html page for example?

[indridcold]

I’ve not tried that yet. Will try when I get home from work tonight, it will be very easy to tell.
I think in future for any reports/issues like this I’ll base my testing on a built in page type to avoid delays

[indridcold]

@dan

Changing to a non stacks page makes no difference.

Steps to recreate the scenario:

1. Create new project, use html page and any built in RMS theme.

2. Add an html fragment and give it a class. Let say something like:
   <p class="custom">This is a sample paragraph with the custom class</p>

3. Preview. All looks absolutely normal because the custom class has no styling.

4. Create a CSS file which contains:

.custom { color: red; }
Save that file somewhere. In this example mine was named ‘extra.css’.

5. Click resources and choose ‘add files’. Browse to and select the css file you just made.

6. Control click the CSS file in resources and grab the macro…

7. Go to Code->Head and add:
   <link href="%resource(extra.css)%" type="text/css" media="all" rel="stylesheet">

8. Preview.

Expected Result:
Your new CSS file in resources would be injected into the page head and the styling rules applied. In other words the text in that sample paragraph should be red.

Actual Result:
Nothing changes. The CSS stylesheet stying is not observed because it is not present in the project structure.

Next…

9. Make some sort of edit to the page. Add a header, change the text. Anything.

10. Preview
    Now the CSS sheet is present and being interpreted.

Next…

11. Click on resources. Select the stylesheet file icon. Choose to “Edit in…” In my case I was using Sublime text. This is an option offered to me by Rapidweaver, remember…

12. Change the styling rule for custom class to be something like:
    .custom { color: green; }
    Save the file.

13. Preview.

Expected result:
The custom class paragraph text should be green.

Actual result:
The style is not updated - still red. Preview in Chrome, inspect the page and find the /resources/extra.css stylesheet. Click on it… What’s this? The class still references red. Why?

14. Make an edit to the page (anything). Save. Preview. Custom class text is now green.

You get the idea.

Why are changes to the linked stylesheet not being picked up until some sort of manual edit to the page is done.

If this is a bug:
Can this please be changed so that edits to files (a facility being offered from within resources) are properly handled and the resulting edits pushed back into the project.

If this is not a bug:
I’d love to hear the rationale and the user story where an edited CSS file is not actioned.

[dan (Dan C.)]

We’re looking into this a little more right now, @tpbradley will ping you if he needs any more details.

I can’t guarantee this fix will make it into RW 8.x, it all depends how large the scope of the fix is. The fix may be better off being rolled into RW 9 as we’ve already made some big changes there on how all this is handled. We’ll know more once we dig into it.

Sorry it’s not working exactly how you want it to. We’ll keep you posted!

[indridcold]

@dan
Appreciate you guys looking into this. The ability to inject CSS or JS into projects using files in resources is a technique I’ve been using since RW5; it’s a little disorientating to find that something so simple just doesn’t work.

Did you also see my observation that the %resource()% macro does not appear to be being processed in the global or the page level body containers. Explained here:

Macro conversion in global and page level body containers

Bump. Is this a bug?

[joemart1951 (Joe Martin)]

I have been using RW since Ver 2.
Are you sure you are wanting to use RW…the main reason I use RW is to not have to build the code from scratch.
Let RW do the work for you and NOT try to start from scratch!!!
Just one old farts opinion!!!

[indridcold]

Thanks Joe - appreciate your thoughts.

I had written a big long response, but it boils down, to me at least, that the interaction between resources, macros and injection of those resources at a time which syncopates with a user’s natural workflow is one subject. How you use RW, or how I use RW is another subject entirely and is to my way of thinking at least, off topic.

If you want to create another thread discussing the merits and demerits of using RW from a code-free amateur through to pro, I’d contribute to that discussion.

[indridcold]

Any update on this?

[dan (Dan C.)]

None yet, we hope to have this fixed for RW 8.6 — Sorry for the delay.

[indridcold]

No worries. Getting it into 8.6 would be superb