I'm interested in how to quantify "configured correctly" - but leaving that aside for a moment, are you saying that the "Publish related pages" should really only publish full pages that happen to share content either the page/linked pages that the publish was launched against, either by virtue of the "related" page referencing this content (assuming the 'follow references' option is enabled) or by 'connect existing'?
If so, this would make MUCH more sense than that it is intentionally publishing all the page fragments, which is what the training/documentation/experience seems to suggest happens. I'm more comfortable that its design is sensible but its implementation is broken, than that the design is just silly. Which brings me back to "configured correctly". I think a HUGE community service would be to enumerate the configuration steps, "best practices" if you will, regarding project configuration. I haven't looked at an RD best practice project since Up and Away, but I suspect even if one exists it will be very hard for a noob to discern which values need setting and what to leave default from an already setup project. There's just too many places to look. Perhaps a blog post is in order? For example, whether it's necessary to disable publishing on every template variant in order to prevent the fragments from publishing. (Though why they would default to publishable when 8 of 10 templates are only fragments I don't know). Anyway that sort of stuff. Regards, Richard Hauer Solution Architect From: [email protected] [mailto:[email protected]] On Behalf Of Gavin Cope Sent: Friday, 24 February 2012 12:42 PM To: [email protected] Subject: Re: CMS and Delivery Server inconsistency If a project is configured correctly (which for me personally was difficult to achieve prior to Navigation Manager) publish related pages will only push out the desired page and any other page that it shares content with (assuming the shared content is the content that has changed). Publish all following pages will only push out the current page and any page beneath it which will not necessarily find all pages with shared content. In the past, the ability to avoid recursive links was difficult IMO, but with Navigation Manager, I'm now creating projects that the Publishing Engine treats exactly as I'd hope with compact, complete and succinct publications :) As for doing full site publishes, I would usually say a full site publish from the top node should include the all following pages rather than the all related pages option. There's always exceptions to the rule but that would be my first course of action before trying both options together, which will cause a slower publication. Cheers, G. On 24 February 2012 12:34, Richard Hauer <[email protected]> wrote: Hey Jian, Do you *have* to have "Related Pages" enabled when publishing for the cleanup tool to work properly? Cleanup has never worked reliably for me but I *never* publish related pages because it just fille the target directory up with garbage. I could never really work out why anyone would want to publish related pages, but maybe I'm missing something. Regards, Richard Hauer -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jian Huang Sent: Friday, 24 February 2012 4:22 AM To: RedDot CMS Users Subject: Re: CMS and Delivery Server inconsistency Hi Gerald, Welcome to the group. You can enable "Clean up Live Server" under project variant settings. Do a full site publish with "always replace page" and "always replace media" enabled, so CMS builds a database of what was published. After full site publish, any pages deleted after that would get recorded and synced/deleted when publishing from parent page will "all following pages" and "related pages' enabled. Hope that helps, -Jian On Feb 23, 4:32 am, Gerald Holzmeister <[email protected]> wrote: > Hey, > is there a way, so called best practice, to remove pages from the > delivery server they are already deleted in the CMS? > Because we have some of these "old" pages in our system. > > Kind regards > Gerald -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:reddot-cms-users%[email protected]> . For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en. -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:reddot-cms-users%[email protected]> . For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en. -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en. -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.
