CMS and Delivery Server inconsistency

[Gerald Holzmeister]

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

[Jian Huang]

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 <gerald.holzmeis...@gmail.com>
wrote:

[shanson]

Gerald,

 

Filter your search on HTML content group based on date range and once you get all the old dated pages you can easily check and delete those which are obsolete and to avoid this in future follow what Jian has suggested and CMS will take care of removing pages automatically once it is synced based on day to day publication.

 

Thanks,

Shankar

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To post to this group, send email to reddot-c...@googlegroups.com.
To unsubscribe from this group, send email to reddot-cms-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.

[Richard Hauer]

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

Hi Gerald,

Welcome to the group.

Hope that helps,

-Jian

--

[Gavin Cope]

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.

[Richard Hauer]

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

[Jian Huang]

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

> <mailto:reddot-cms-users%2Bunsu...@googlegroups.com> .
> 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 reddot-c...@googlegroups.com.
> To unsubscribe from this group, send email to
> reddot-cms-use...@googlegroups.com

> <mailto:reddot-cms-users%2Bunsu...@googlegroups.com> .
> For more options, visit this group athttp://groups.google.com/group/reddot-cms-users?hl=en.

[Richard Hauer]

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?

[Jian Huang]

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

> 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/

> 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/

[Holzmeister, Gerald]

Shankar,

Good idea and I guess I can remember that we have done this in another project some time ago.

But in our current Delivery Server we don’t have a useful date field to filter or sort.

 

Have tried to do it like this:

-          Select in Project Menu: Content => Find

-          Used HTML as Type in the search form

 

But there are only two date field to filter: Validity and Created

In the help file of this form the two date fields are described like the text below:

-          Validity: Click Options to specify a validity period. Only content items valid for at least the entire period entered are returned as a match.

-          Created on: Choose Options to specify the period during which the content was created.

And also there is not date field like published in the search result.

 

Did I something wrong?

 

Thanks,

Gerald

---

INFONOVA GmbH
Sitz: Unterpremstätten bei Graz
Firmenbuchgericht: Landesgericht für ZRS Graz
Firmenbuchnummer: FN 44354b

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

[Rob]

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

> A nicely structured project should have the following start pagehttp://simplyreddot.blogspot.com/2011/12/what-project-start-page-shou...

> ...
>
> read more »

[Jian Huang]

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

> > From: reddot-cms-users@googlegroups.com
>
> > [mailto:reddot-cms-users@googlegroups.com] On Behalf Of Jian Huang

> > > From: reddot-cms-users@googlegroups.com
>
> > > [mailto:reddot-cms-users@googlegroups.com] On Behalf Of Jian Huang

[Rob]

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

> > > > From: reddot-c...@googlegroups.com
>
> > > > [mailto:reddot-c...@googlegroups.com] On Behalf Of Jian Huang

> > > > > From: reddot-c...@googlegroups.com
>
> ...
>
> read more »