Rapidweaver needs an “organizational” folder that does absolutely nothing but help organize pages within a plugin/page. I have pages on my site now that have up to 800 child pages and I’d love to be able to separate and organize those into folders.
Assuming you are using Stacks 3, one option it to turn each page into a partial. Then create a duplicate page, set it to draft, and “file” it however you like.
Here is an example of what I’d like. Assume a folder of hundreds of reports, I want to do as shown below. I actually am doing this now but of course i can’t use certain tools such a breadcrumbs, etc as I want the child pages to appear in “Reports”. The Styled text Alpha pages should be ignored totally by RW. I have over 800 “Reports” and there should be a way to organize within RW that does not affect RW pages and site organization.
I think if you try to have over 800 single pages in a single RapidWeaver file you will quickly begin to hate touching that file.
In general when I see sites like this: a large number of nearly identical pages, save for the content – I usually tell folks that before they embark on that herculean task that they should consider a CMS type solution.
Content Management Systems are designed to manage sites like this more efficiently. You design a few pages, then manage the data that gets injected into those pages with the CMS tool.
Joe Workman has a CMS solution for stack and there are several others. I’d say taking a little time to research those tools might save you a heap of time overall.
Good Luck! It looks like it’s going to be a nice site in the end.
The partials solution I proposed would still work for this. You would just end up with over 1600 pages. 800 + the styled text would never be published. They would just be used for finding and editing the partials used on the published pages. In theory you would never need to go into the published ages so you would just villa a those.
Granted this isn’t ideal for such a large site as yours, but it is a interim solution to use until a nativ RW solution is created.
I am using this solution in a project where I have a 1 page site with 16 “pages”
Each “page” is given its own draft page. This because a necessity because it was taking ages to edit the page which had all the content on it. Every time I wanted to scroll or make an edit it took 30-60 seconds for my computer to render the changes to the view.
This is a site that was handed to me. I just converted 800 blog pages to Stacks pages using a Macro. In total this site has about 2500 pages. Yes, eventually CMS would be great. But that is not going to happen tomorrow.
The time it would take to partial out the draft pages would be better spent designing one Total CMS Blog and the copy and past to the blog post.
Why did you switch from the blog solution?
Addendum: Here is what I’m really looking for. A “housekeeping” folder. In other words, just like making a page INACTIVE but keeping the child pages active. The child pages would relate to the next higher level “active” parent.
I’d vote for that feature.
Well, I understand that RW is trying to make RW layout “Look” like the site layout… But there should be a way to organize differently if that is what you want to do.
This exists in SiteMap Plus. You can turn off an enclosing folder but allow the enclosed child pages to show. That is exactly what I do now for my “Alphabetical List” of Reports and all reports show at same level. No sub-folders.
I’ve never seen a site > 1000 pages. Not that it’s impossible. But some parts of RapidWeaver will likely become less practical. You’re using RapidWeaver in a way that it wasn’t really designed for.
A couple things:
You are heading into unknown territory and blazing a new trail. That’s not a bad thing. There might be undiscovered country out there worth seeing.
But be careful. Text extra precautions when you can. And know that you may have to turn around a few times before finding your way through.
If you hit any hard limits they will be with memory usage. I’d keep a close eye on that. If you see RW using more than 2GB of memory it’s probably a sign that you’ve ventured too far into the woods.
Breaking up a large site into several hierarchical sub-sites is a nice solution too. I’ve used this a number of times myself to keep things manageable. You can use the “offsite page” feature to create links between the sections.
Site is broken into five projects: Reports, Store, etc. The 800 page “Reports” is largest one and you are correct, I may have to sub-divide it.
We migrated away from the blog concept. We were not using the archive or category feature at all and it seems that the blog always caused issues at upgrade time. I very much prefer individual Stacks3 pages and all the options available.
Am I right in assuming you were using RW’s built in blog solution rather than a Total CMS Blog?
Correct… I inherited this project with hundreds of RW blog pages plus hundreds of others. No CMS.