Hi Richard, I agree with Gavin regarding building a correctly configured/ structured project publishing. It is not hard, just had to following a couple of simple rules.
Always use CurrentIndex.GetUrl() instead of CurrentPage.GetUrl() Ensure pages are only connected to one location. If it can't be avoided, in the case of keyword list, use the solution mentioned in my blog. If possible, use dynamic anchor and references page instance of connecting them. I wrote a plugin that detects pages connected to multiple locations. http://www.solutionexchange.info/check-multi-page-connection.htm. Having a master page connected to more than one location is a terrible thing to do navigation manager (will cover it in a blog post). Always ensure the first 2 setting (do not following page references, do not following link references) in publishing settings are checked. Ensure link to the following pages are visible, in HTML comments are OK. Especially lst_navigation, people tend to forget to include it or the list blockmark in templates. Please see my blog for more info. http://simplyreddot.blogspot.com/ I think that's it, just 4 rules to follow during project development and I guarantee a speedy full site publish because pages will not get published more than once. I will make a blog post on this later. -Jian On Feb 23, 9:26 pm, "Richard Hauer" <[email protected]> wrote: > 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 > athttp://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 > athttp://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 > athttp://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.
