Some objects shifting when adding new pages

Just to pick up on the earlier question about undoing an unintended override on the footer.

If the footer is still linked to its Parent page but has been overridden locally, select the footer on the document page and choose

Pages panel menu > Parent Pages > Remove Selected Local Overrides.
 

That should restore the footer to its Parent page settings without affecting the other objects on the page.

I'd avoid Remove All Local Overrides, especially in a document with so many individually positioned objects.
 

Also, if the footer is being affected by text wrap, you can select its text frame and enable under Object > Text Frame Options

Ignore Text Wrap
 

For chapter-opening spreads where you don't want a footer, I'd recommend creating a separate Parent page without one, rather than covering it with a white rectangle.

Regarding the more recent page-shifting issue, ​@rob day suggestion about page shuffling is worth investigating, but I'd test that on a copy of the document before making changes across the entire book.

My experience as a developper is that linked/chained textboxes will have a tendency to shift when a page with such objects is copied over. I have a lot of code in my plugin to handle such cases.

I’ve experienced this myself for the first time today -- at least this sounds like what I’m seeing -- the original asker seems to have spreads also but no additional central gutter, so the only left/right offset is the bleed -- thus, his shifting is limited apparently to the width of the bleed.

This seems to be some sort of InDesign-native automated feature to offset page objects so that they are oriented properly outside of and relative to the central gutter–but in my case, it failed miserably because it did not affect all objects, and it operated inconsistently—possibly due to an InDesign bug or my exact workflow. Instead of gracefully adjusting the changes to the left/right page spreads, it moved objects when it needed to, but in the opposite situation when it “should have” moved them back, it did not. Most objects moved away from the gutter. There were some objects that were moved TWICE away from the gutter, but never back.

Most of my projects are books, which are carefully laid out as spreads (with master spreads) with mirror margins, gutter at center, and master text frames that are biased toward the page edge, away from the central gutter -- to allow more space for the gutter than the outer page margins.

I usually make it my habit to duplicate or insert full 2-page spreads just to save the bother of having to insert or delete a page to get the even-page “left” layouts back on the left and odd-page “right” layouts back on the right, and maintain it that way, never triggering this feature or dealing with reversed left/right spreads.

THIS TIME, I used the “duplicate page” function, duplicating ONE page, inline, the used the move page function to move that page to the end of the document (had I done this in one step: duplicate page at end of document”, this left/right master swap would not have occurred).

My expectation here was NO automatic swapping of content to re-align for left- vs. right- spreads  I had never seen such behavior before and always just do this manually. I’ve inserted single pages before, and the result is always NO adjustment in any object position—the pages simply are mis-aligned relative to the gutter (ie, objects that were deliberately farther from the gutter are now doubly too close to it), and it’s obvious that I must insert or delete another page to return the flip-flopped evens/odds back to the intended state. And that’s what I do.

The page I duplicated caused 30% of the book content to shift -- without any rhyme or reason I can figure out. For example, on a page with a gallery of 24 objects and 24 captions… two objects and six captions shifted. On some pages, all content shifted -- grouped and ungrouped objects alike -- On some pages, no content shifted. On some pages, the main text frame shifted. On others, objects.

The size of the shift is 1” -- my exact gutter size, but apparently the wrong direction. When shifting a right-spread to the left, it still had the gutter space on the left (outer edge) -- no change. But when shifting back right, a right shift was applied. 

In any case, InDesign failed to do this properly and shredded the layout (which was saved and closed before I realized what had gone wrong). Fixing it only took 20 minutes of manual work.

What happened here? My guesses:

1. This has something to do with the object styles—and/or whether there are object-level overrides to a given object’s styles. There’s a lot of serialized content in this project, and I’ve been using lots of object styles for the first time to automate different types of objects and keep them tidy and identical (24 near-identical objects per page) -- so I have to think that the core issue here is that I managed to assign an object-level attribute that triggers an object to suddenly pay attention to it’s alignment to the gutter. Some objects may have styles applied that speak to the alignment relative to the margin. Others may not? A lot of work went into applying styles to all similar objects, and clearing overrides… but some might have been missed.

2. A bug in InDesign’s features to offset content by the difference the gutter offset left vs. right, intended to keep the content centered in the master frame, even when the gutter location shifts left vs. right. Seems like the PRECISE WORKFLOW I used to insert/move this page fooled InDesign, which made the shift properly on one of those changes (twice in some cases where this was accidentally doubled), but ignored it when it moved back to the original left/right spread orientation? I hate to be the guy that blames the software when experimenting with new features -- and conflicting settings that make some objects comply but others ignore is undoubtedly due to inconsistent object layout settings, but clearly the automated handling was asymmetrical--in some cases, the automatic layout shift worked. But when reversing the layout shift, it didn’t. So, a process that should have been reversible, was not. Moreover, a few objects got confused and DID participate in the second round, but stepped the wrong direction.

3. This may have something to do with whether items are grouped or not. Seems like grouped items tended to move together in patterns based on groupings -- which is consistent with my experience -- grouped objects have muddled settings in a variety of ways that sometimes favor one or another object’s settings (or perhaps have object-level settings applied to an entire group).

4. My ID has been running slowly -- and a few times recently, I’ve had issues with it backgrounding tasks and then quietly crashing -- no indication of crash until I try to save with the manual menu. Perhap my fast copy/move caught ID before the swap propagated to all pages?

Unfortunately, I fixed this and didn’t retain a screwy version, so don’t have examples.

Just to add 2¢ regarding your 47 chapters in 1 file. I think you should explore the book function in ID. Your odds of a giant, image heavy file going corrupt increases in this kind of situation. I have found the book function perfect for this type of project. 

When dealing with an overridden objects page, followed probably by improvements to the Parent page, I find that the next step is often re-applying the parent page to the local page (and probably first deleting heavily-modified objects overridden in the first place.)

1. I'm not sure what you mean by this statement. My general experience has been if you add pages before a page, the page moves down in sequence and the pasteboard items go with it. That is, if all the objects are independant and not heavily threaded/linked. Also, I try to keep my pasteboards largely empty of stored pieces of object.

2. If a parent page footer is unwanted on a certain page, why not Cmd/Ctrl+Shift+Click it to override it to the local page and simply delete it, instead of covering it with a paper-filled box?

3. If a parent page object is NOT overridden to the local page, text wrapped objects will have no effect on it. If the parent page object IS overridden on the local page, it becomes sensitive to another object that has text wrap on.

4. Have you had a good look at your parent pages and layers? Is everything well-organized?