So I’m troubleshooting a bug for a user and I ran into a problem where their files folder, once the site is exported or published, is named index_files instead. Is this a bug or is there a setting somewhere that I’m unfamiliar with that is causing it to be name the files folder in this way? I ask because Alloy is looking for the folder to be named files and it is causing problems because it is instead named index_files.
The user is currently using RapidWeaver v8.0.3 and Stacks v3.6.5.
whenever the project has two pages that share the same folder, when the user manually changes the “Folder:” setting in the info-sidebar general settings, then RW will export the files like this. Int will name the place where all the associated files are published <page_id>_files
this is most often done when users want to all of their pages at the root level of the site – so they change all the Folder: settings to /. it’s a pretty normal thing for users to do and RW handles it well. it’s mostly transparent. but it means plugin and stack developers can’t hard-code the directory names.
the stacks API takes care of this detail for you tho. 
if you need to get access to any of the main template file paths to get access to those things:
%cssPath%: /templates/cssPath/ · Stacks API
%jsPath%: /templates/jsPath/ · Stacks API
%phpPath%: /templates/phpPath/ · Stacks API
those paths should be correct even when the user changes folders – and it will rectify the little differences too. paths inside CSS files need to include the extra layer of hierarchy, but in JS and HTML they don’t. etc.
and that’s just the tip of the iceberg, RW loves to change the names and locations of these folders. they can change between edit/preview/publish modes and RW 8 changes them from RW 7. and if the user changes the advanced RW setting “Folders are relative to:” then everything is totally brand new again.
but stacks takes care of all of those things so you don’t have to. 
you’re welcome.
as well as the docs above, there’s also a test stack (mostly for my use, but useful all the same) to test out some of this huge matrix of folder craziness.
isaiah
Thanks @isaiah!! I really appreciate you insight. I’d never come across an instance of this before, or a user with a project file that presented this change in folder names, so it threw me for a loop. You taking the time to go through all of that was very kind. I know you’re really busy with other stuff, so thank you.
I replied to you in Slack as well, and think I tracked down how to sort out my particular problem.
no worries – and for any other stack dev that’s reading this – please please please let me know if you find any bugs in any of the path variables. since so many things cause a change to these paths (and the changes are often subtle, transparent to users, and totally undocumented) it’s easy to miss some things.
i’d say a solid 25% of the bugs that make it through to released versions of Stacks are some quirk of one of these paths.
it should go without saying, but i’ll say it anyway: if you report one of these bugs, please include lots of detail of how to reproduce it, because if i don’t know every last one of those variables, then chances are i won’t ever see the bug – the matrix of possible path combinations is astronomical. 
