What is the logic behind the static resources folders?

[Ivan Gretsky]

Hey, @teppo! Hope you're doing fine!

I've been using Wireframe for a while without too much thought just relying on it. Thank you for this module! It really helps with structuring PW projects.

Once upon a time I've borrowed your convention to put all the static files to site/templates/static folder. I am putting both sources and generates stuff there. I've handled the build process with VS Code plugins to get rid of the node based build chain. Anyways, now I see that you recommend creating two other folders: site/templates/resources and site/assets/dist. I can guess that you renamed static to resources and probably added assets/dist for the generated files. But could you please describe how you suggest using all these folders in the Wireframe-based workflow for building and maintaining sites in a little more depth. Couldn't find any docs on this. Maybe there are some useful methods and/or settings that can make use of these? How do you use them?

[Ivan Gretsky]

So I am here thinking about this again, @teppo. Didn't find an explanation anywhere still. Could you please explain your idea behind those folders?

[teppo]

Hey Ivan,

Sorry, looks like I've completely managed to miss this topic. Also, this could probably use a bit of an overhaul in Wireframe, and a docs page as well of course.

Quote

Anyways, now I see that you recommend creating two other folders: site/templates/resources and site/assets/dist. I can guess that you renamed static to resources and probably added assets/dist for the generated files.

This is indeed the default setup, and your guess is correct:

• "static" was initially borrowed from somewhere else (possibly some version of Zend Framework, or perhaps our old in-house CMS, but not sure anymore) and eventually replaced by "resources", which seemed to be more common term.
• assets/dist was added with the idea that this would be the location for built/generated versions.

My current workflow actually places dist under resources as well — so there could be e.g. resources/scss/, resources/images/, resources/fonts/, and finally resources/dist/. Additionally I often have a resources/lib/ directory that contains "libraries", which may be third party dependencies that are not installed via yarn or npm, or site-/app-specific JavaScript classes etc.

In my opinion this doesn't matter all that much, as long as there is a convention for placing said files, so that it doesn't change from project to project. Personally I would keep "resources", and place generated files in either resources/dist or assets/dist — latter part doesn't matter a whole lot, and as such I am now wondering if the whole assets/dist thing should just be discarded from Wireframe.

Hope this helps explain things a bit at least 🙂

Technically I would like to have a "public" directory, but I'm not sure if that is really meaningful here: in the context of ProcessWire files are often accessed from other directories as well, so it is almost impossible to split the project into public and non-public parts in such a way. In something like the Sage theme for WordPress (at least slightly older versions, not sure of the current state) there were "resources" for source files and "public" that contained identical structure with built files — or copies in case of files that were not modified during the build process.

[Ivan Gretsky]

Thanks for a great explanation (as always). I guessed almost everything) I also place the source scss/js in templates/static. Before that I used to put the sources in site/static-src and put the generated files in templates/static. I guess, resources could be a better name for the sources. At least it is a standard place to have them as I use Wireframe (and love it).