Sorry Jian but I don't really understand what you're recommending here... 1) Why CurrentIndex instead of CurrentPage? When the rendering context is established the PageId for the current page being processed is the pivot point. CurrentPage gets you the page that owns that Id, like this: PageId -> Page CurrentIndex goes like this: PageId -> Page -> MasterPage -> Nav Index
When you call GetUrl() against the Page it calculates the Url based on the NavigationLink by preference (where you are in a nav context) or the MainLink otherwise. When you call GetUrl() against the Index it first gets the Page (can you guess which one) then does the same thing... Summarising... CurrentPage.GetUrl() => PageId -> Page -> Url CurrentIndex.GetUrl() => PageId -> Page -> Master Page -> Nav Index -> Page -> Url >From the code I can't see that they'd ever give different results, only that CurrentIndex has to work harder to get there. 2) Ensure pages are only connected in one location This completely flies in the face of a major tenet of a CMS, and makes it hard to understand why there would be a feature called "Connect Existing Page" Further, I don't think that following your "rules" will prevent the publication of page fragments, filling up the production environment with "rubbish" files, and I don't believe anyone has categorically said whether it is necessary to check the "related pages" option in order to make the Cleaner function work. If the point of the Cleaner is to remove unnecessary files it seems counter intuitive that you would need to poblish unncesary files in order to make it work. Or am I still missing something? Regards, Richard Hauer -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jian Huang Sent: Friday, 24 February 2012 3:18 PM To: RedDot CMS Users Subject: Re: CMS and Delivery Server inconsistency 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. -- 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.
