Publishing in stacks

I believe this is the right place to ask this, but if not, please point me to the right place.

I see that when I publish a site that is based on stacks, each page other than the home page (or primary index, if you like) has its own directory with a files subdirectory containing a css and js file for the page.

I am not a tremendously experienced designer, however: what I am used to is having a single js file and a single css file for the entire site. Changes from these global files are in the html files themselves.

So…while I cannot claim my way is the best way, it is the way that works for me. Is there any way I can set up the publishing directory structure for a stacks project?

(Hoping this isn’t a question that has been answered many many times.)



Themes usually have global resource files (CSS Javascript) that apply styling and functions for the entire site.
Stacks pages have separate CSS javascript, and PHP files based on the stacks being used on the page.

I’m not sure what difference it would make to you since you aren’t going in and changing the actual CSS or javascript data in these files. If you want to add/change JS or CSS you can do that at the page level or sitewide.

1 Like

What you’ve noticed is somewhat true, except for a couple of missing details, and that seems to have lead you astray. The missing details:

  1. The structure you’ve noticed is not unique to, or defined by, Stacks. The structure of the site is dictated by RapidWeaver and every page follows the same general structure.

  2. Your site has both page specific assets AND site wide assets. Again, this is not Stacks specific. The site structure is defined by RW.

the site-wide directory is: rw_common. That folder is divided into: plugins (like Stacks) and themes. inside the stacks folder you’ll always find at least: stacks.css. This is all the styles needed for the built-in stacks along with any site-wide CSS that 3rd party stacks need. Depending on the content and 3rd party stacks you’re using you’ll see other css, js, php, fonts, and images here too. For example, if a 3rd party site uses the jQuery library or Font Awesome – then this is where those assets will be located. All pages on your site will share these assets.

That’s one way to go. It’s certainly simple. And if your site is very uniform – with all pages seeing exactly the same css and js – then it’s perfect.

But in many cases, we can do better.

A stacks page will try to load a CSS file that contains the styles used on every page. And a css file containing things that are needed just on each page. The same for JS. The same for php, etc.

Why split things up this way?
Oh, there are a zillion tradeoffs and pros and cons I could list, but I think the strongest comes down to this:

Many people want their landing page to be very lean – to load as quickly as possible. Often this page is free from jQuery, extra fonts, or large images. If loaded the same css and js on every page, then we couldn’t achieve that.

But there are other reasons too: This way tends to be more optimal for a wider range of projects – and RapidWeaver is all about making things easy. RW is very modular… there are page addons, theme addons, stacks, and frameworks. That leads to a very very extensible environment with literally thousands of available addons – but it requires a bit more rigor in how the project is set up. This means that each different piece works with each other different piece – or at least that’s the goal most of the time.

Of course that thriving community is both a blessing and a curse. With thousands of addosn it is not terribly difficult to find a few that subvert the nice site structure and try to do their own thing. Sometimes for good reasons, sometimes just to cut corners.

But, I can talk about this stuff forever. So I should stop here. However, if you have ANY QUESTIONS AT ALL, please ask. I’d love to talk about it. Whatever it is. I know how every single line of every single stacks file is published, why it’s published the way it is, and love to talk about the decade long process of how each line got to it’s current home. :yum:

And if you have specific suggestions about moving any line or any file, I have an open bug/feature list that you can contribute to. It’s right here: Issues · YourHead / stacks · GitLab You have to sign in to gitlab, but it’s a free account, they just don’t let you post anonymously to keep spam low – but it’s otherwise open to the public.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.