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] > > > [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 > > ... > > 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.
