Hi Richard, Regarding #1
In short, Before 10.1 SP1 CurrentPage.GetUrl() returns link of page connection type CurrentIndex.GetUrl() returns link of page reference type. Imagine a top navigation generated using CurrentPage.GetUrl(), and publishing pages with following pages enabled. On every page, those top navigation page link generated via navigation will get published n times, n being the number of pages with top navigation. As you can see, this is suboptimal publication performance. Hence, using CurrentIndex.GetUrl() became a best practice. Then with 10.1 SP2 (Thanks goes to Gavin for testing this out). CurrentIndex.GetUrl() also returns page connection type, unless, GetUrl(Bool:True) is used. Hence Current.GetUrl(Bool:True) became a best practice for 10.1 SP2. By using CurrentIndex.GetUrl(), the project is prepared for any issues from 7.x to 10.x. Regarding #2 There is also a feature call "reference page", hence it really comes down to which feature is a best practice. The rules stated will not prevent publication of page fragments, but a well implemented project will not have page fragments. Body modules page should be connected to containers instead of a list or anchor. By following the aforementioned project structure rule, page fragment can be avoided. A nicely structured project should have the following start page http://simplyreddot.blogspot.com/2011/12/what-project-start-page-should-look.html Commonly shared components like header and footer should be organized under its own section. Also, pages instances can be configured not to publish under template settings. However, I usually publish the header and footer as a fragment page, which can be used for 3rd party integration that wishes to have the same header and footer. In a nicely structured/configured project, enabling "related pages" is not neccessary, however, since development say it is best to be enabled to allow "clean up live server" to work better, I would simply do it because it does not cause any harm. Best, -Jian On Feb 24, 12:12 am, "Richard Hauer" <[email protected]> wrote: > 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 > athttp://groups.google.com/group/reddot-cms-users?hl=en. On Feb 24, 12:12 am, "Richard Hauer" <[email protected]> wrote: > 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 > 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.
