Every page being published again after adding a new page

Each time I add a new page to a project, the blue dot appears on all of the pages and it publish those page again. I am assuming because of the navigation menu need to be updated on all those pages when a new one is added.

I already created my own navigation menu and I don’t use any of the RW’s navigation feature so I am wondering if I disable that on all other pages, will it stop publishing those page again each time I add a new one?

If so, is there a way to mass disable navigation on all pages or I have to go on each one and disable it one by one?

Thank you

Does it create a sitemap? It could be that as well. I’m not sure about the answer to your Q otherwise though…

Maybe I am wrong about publishing every page but it does seem to be doing something on every page before it would start publishing the new pages. Whatever it doing at first, it take forever on a big site just to publish 1 or 2 new pages.

Sure. You add a new page, and the navigation information has to be updated. It would be interesting if the blue dot also appear on pages, which are excluded from the navigation.

1 Like

It the part where it “Exporting your website” that taking forever when I add a new page I think … I am experimenting with it right now …

It still export every page when it not included in the navigation so it seem that there are other purpose for it.

this probably isn’t helpful to your specific problem, but it might help everyone in understanding exactly what’s going on here, why, and how it works.

feel free to ask questions. if you’d like i can make a video that shows some of these concepts in greater detail.

what’s going on

Any change to the project structure such as:

  • adding a page
  • removing a page
  • duplicating a page
  • enabling/disabling “Show in Navigation”
  • page folder name change
  • page filename change
  • marking/unmarking a page as draft
  • change project settings

Any of these things will cause all pages in the project to be “marked as changed”. That’s when RW puts the little blue dot next to each page in the left-hand sidebar.

why all the changes?

whenever the structure of the site changes then a number of things about each and every page of the project might need to change. the most obvious one of those is a navigation change – but there are also a number of ways it could also affect other links within the site.

so whenever you do any of those things (and a bunch more – i just listed what popped into my head first) then there’s a very good chance that at least some tiny part of each of your pages changed – and each of those changes needs to somehow get uploaded to your server.

how does it find out which files changed

after a page is marked as changed RW needs to find out which parts of that page changed – or more specifically – which files and resources of that page changed. it does this to determine which files need to be uploaded. it then tries to upload as few files as possible to your server.

what’s an export

to find out which files changed it exports the page to your hard disk. this means it fully creates that page and then saves all of its pieces to the hard disk. then compares each of the files associated with that page to the last file that it uploaded to your server.

and, of course – whenever it finds differences in the files, it uploads the file.


it sounds to me like of your pages is taking quite a long time to export. i think that is the real problem.

in my experience there are three causes of slow exports:

  • many image exports
    problem: exporting images is pretty slow. even just a handful of images on each page can take a while.
    solution: consider warehousing your images (search this forum for lots of good advice on that)

  • many many many stacks
    problem: if you pages have hundreds of stacks, then they’re going to be very slow to export. consider breaking them down a bit more – or just simplifying things a bit. a stacks page that is slow to export for this reason will also be slow to when viewed in a browser for the exact same reason. and slow pages tend not to be read, sell many products, or get high google rank.
    solution: simplify your pages. break them down into more pages. combine stacks where possible. keep it simple (did i say that twice). keep it simple. yep. it’s that important.

  • a few stacks that are really slow
    problem: some stacks are really slow. this tends to be stacks with lots of options. stacks with tons of options can be great at tackling a big feature or your page – but try to use those sorts of stacks sparingly. if you find that you’re using a stack that has pages of options, and you’re using this in many places on each page – then that’s probably your problem.
    solution: always use the simplest stack you can to get the job done. keep it simple.

Thank you @isaiah for the clear explanation.

About the slow export experience.

All my images and fonts are warehoused. I do not use the built-in RW resources or any stacks that will not let me warehouse website’s resources.

How many stacks on a page do you consider many many many? I use mostly Joe Workman foundation stacks and Andrew Tavernor BWD stacks to develop all my web pages from a blank theme.

I do think most of all of Joe Workman and Andrew Tavernor BWD stack are as simple you can get and not bloated like most other stacks are.

Nothing against Joes and Andrews brilliant products. But using Foundation and BWD Pro Stacks are everything, but not simple. The more settings you are able to choose from, the more export time it needs.


Tav’s stacks, while they are some of the very finest – the best at doing what they do – tend to be on the slower side. Often I see people using Tav’s stacks not for their intended magnificent purposes, but just as a replacement for basic text or header or separator etc.

My recommendation would be to try to narrow down a bit what on each page seems to be slowing it down. And if possible, see if there are simpler stacks that can replace some of the most complicated stacks.

While having dozens of settings is not guaranteed to mean it will be a slow stack, it’s a good approximation. Over the next few releases Stacks will try to include more hard metrics that users can use to help them find the slowest stacks.

@joeworkman and @tav – if there is any advice you might have for getting to the bottom of a slow page, perhaps you could offer a few words. :slight_smile:


With the exception of Site Styles, all of the Foundation stacks should be very performant. Almost all of them only contain HTML. Site Styles does all of the heavy lifting. But I also disagree pretty strongly that Foundation stacks are not simple to use. I won’t take that bait and will just stop that discussion here.

We are starting to see a glimpse of some tools in the upcoming version of Stacks to help us better measure performance within Edit Mode. Right now it’s a lot of guess work, adding/removing stacks from the page and guessing if things are faster or slower. I should be able to use these new tools in order to make things even better as they progress in development. It’s exciting times as I have started work on Foundation 2 :slight_smile:

Also, none of this discussion really gets to the core of the original question. Why pages are being published every time…

You know your project better than anyone, you know what you have changed. The way that I tend to work, is that if I know that I only modified a single page, I right click on that page in RW’s left pane and publish just that page. If I make changes to my site that I know will affect multiple pages, I republish all files.

I cannot say without a doubt why RW is marking pages as changed in your situation. I would say that RapidWeaver tends to side on the logic of being safe. That means that when in doubt republish a file. It’s the only way to ensure that your site is published correctly.

Maybe you read something out of it nobody mentioned. Nobody said they are not simple to use.

That’s what I wanted to express, and Site Styles are a requirement on every page.

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