Hi Rob, "Clean up live server" need to be enabled always if you want the tracking to be done.
"always replace pages", "always replace media" for first full site publish after "clean up live server" to ensure all pages are tracked. Then you can turn off those 2 settings because you don't want unchanged pages and media to always publish and slow down the transfer pipe. Yes, you can publish for a sub directory of the CMS project, but watch out for pages from any section connected under this section, then the publisher would crawl 2 sections. "all following pages" is needed, related pages is not really needed unless the project has many pages connected to many locations. Best, -Jian On Monday, April 16, 2012 5:33:35 PM UTC-4, Rob wrote: > > Jian, > > I am wondering how flexible my publishing can get and not break the > tracking of deletes on the CMS so I can occasionally do the full site > publish with "following" and "related" and successfully synch up the > deletes on my web server. > > Can I turn off the "Clean up Live Server" for a publish and then turn > it back on? > Can I turn off the "always replace page" or "always replace media" or > both for a publish and then turn them back on? > Can I publish for a sub-directory of the CMS project? > Can I publish without "all following pages" or "related pages" or > both? > > Following relaxing our protocol in any of these ways, will the sync of > deletes still work if I do a full site publish with "all following > pages" and "related pages"? > > Rob > > On Feb 24, 2:05 pm, Jian Huang <jhuangsoftw...@gmail.com> wrote: > > 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 pagehttp:// > simplyreddot.blogspot.com/2011/12/what-project-start-page-shou... > > > > 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" <richard.ha...@gmail.com> 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: reddot-cms-users@googlegroups.com > > > > > [mailto:reddot-cms-users@googlegroups.com] 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" <richard.ha...@gmail.com> 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: reddot-cms-users@googlegroups.com > > > > [mailto:reddot-cms-users@googlegroups.com] On Behalf Of Gavin Cope > > > > Sent: Friday, 24 February 2012 12:42 PM > > > > To: reddot-cms-users@googlegroups.com > > > > 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 <richard.ha...@gmail.com> > 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: reddot-cms-users@googlegroups.com > > > > > > [mailto:reddot-cms-users@googlegroups.com] 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 > > > > ... > > > > read more ยป -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/reddot-cms-users/-/rUVcQWPaKFMJ. To post to this group, send email to reddot-cms-users@googlegroups.com. To unsubscribe from this group, send email to reddot-cms-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.
