Jian, Thanks. I will be able to be relaxed at will on my publishes and careful only on my nightly publishes.
I checked the manuals and online but couldn't resolve another issue. I am noticing that my content from my Asset Manager is not being published always with these settings so I can't detect out of sync items and manually delete them. Does this shortfall make sense? Are they already deleting automatically (I found a couple not synced on a quick check)? Is there a way to get it to automatic? Is there a good way to clean up out-of-sync items? Thanks, Rob On Apr 17, 11:02 am, Jian Huang <[email protected]> wrote: > 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 <[email protected]> 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" <[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] > > ... > > read more » -- 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.
