ACS Commons Shared Component Properties | Community
Skip to main content
A
Ashish_Ranjan1
November 30, 2017
Solved

ACS Commons Shared Component Properties

  • November 30, 2017
  • 1 reply
  • 2597 views

Hello All,

I am using Shared Component in my site but have few questions which are as follows:-

The site hierarchy of my site is /content/moduleName/en and the same is specified as the root page for Shared Component too. Hence the shared properties are stored on the node /content/moduleName/en/jcr:content/shared-component-properties and global properties on the node /content/moduleName/en/jcr:content/global-component-properties .

Now if I edit the shared component on a page under /content/moduleName/en for eg: /content/moduleName/en/test and activate this page it doesn't gives me the pop-up prompting to activate the root page(/content/moduleName/en) and hence those values are not pushed to publish unless I specifically activate the root page.

Secondly I have around 50k pages under /content/moduleName/en and if I activate the root page my dispatcher invalidates the cache for all the pages beneath it which is the default dispatcher behavior.

I will be very much helpful if anyone can help me with answers to the below scenarios.

Thanks in advance

Ashish Ranjan

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by brett_birschbac

    Hi Ashish, these are great questions.

    Agreed that there is not currently a prompt to publish the root page when you change a shared/global property and then activate a page on the site.  Something like this might be a great enhancement to the feature in ACS Commons (which is open source).  Being the original creator of the feature, I'd be happy to review a pull request for such an enhancement.

    Note that it's not just the root page that you want to activate, though.  Shared and global properties are liable to be used on any and multiple pages on your entire site.  So publishing the root page automatically is just the first step - it will ensure your current page now gets the latest shared value but any other page on the site will be subject to whether it is cached (using old shared value) or not cached (will use the new shared value).  It might be nice to also give an option to activate any page that is using a shared property as well.

    As for your second question regarding the full dispatcher being cleared by publishing the root page - in some ways this is good because it ensures all pages now get the latest shared/global properties.  However, for a site your size if this causes a load on your servers that is too great, this seems like an already existing problem that you would have for someone authoring and publishing the home page, it just now happens more often due to the shared/global props.  If you already do have that problem, it might be worth changing the dispatcher configs so that only the published page is cleared.  However, I understand that may not be an option.

    An alternative may be a custom OSGi listener that replicates just the shared/global properties nodes instead of the full root page without actually triggering a dispatcher clear of the home page.  The shared/global properties are not in any way cached on the dispatcher, so simply getting them over to the publish server is good enough (no dispatcher clear required).  As for the issue of the pages throughout your site that may be cached with old shared/global property values, using Dispatcher TTL is a good way to ensure the pages eventually flush from the cache on their own, ensuring they eventually are rendered with the new values.

    1 reply

    brett_birschbac
    brett_birschbacAccepted solution
    December 1, 2017

    Hi Ashish, these are great questions.

    Agreed that there is not currently a prompt to publish the root page when you change a shared/global property and then activate a page on the site.  Something like this might be a great enhancement to the feature in ACS Commons (which is open source).  Being the original creator of the feature, I'd be happy to review a pull request for such an enhancement.

    Note that it's not just the root page that you want to activate, though.  Shared and global properties are liable to be used on any and multiple pages on your entire site.  So publishing the root page automatically is just the first step - it will ensure your current page now gets the latest shared value but any other page on the site will be subject to whether it is cached (using old shared value) or not cached (will use the new shared value).  It might be nice to also give an option to activate any page that is using a shared property as well.

    As for your second question regarding the full dispatcher being cleared by publishing the root page - in some ways this is good because it ensures all pages now get the latest shared/global properties.  However, for a site your size if this causes a load on your servers that is too great, this seems like an already existing problem that you would have for someone authoring and publishing the home page, it just now happens more often due to the shared/global props.  If you already do have that problem, it might be worth changing the dispatcher configs so that only the published page is cleared.  However, I understand that may not be an option.

    An alternative may be a custom OSGi listener that replicates just the shared/global properties nodes instead of the full root page without actually triggering a dispatcher clear of the home page.  The shared/global properties are not in any way cached on the dispatcher, so simply getting them over to the publish server is good enough (no dispatcher clear required).  As for the issue of the pages throughout your site that may be cached with old shared/global property values, using Dispatcher TTL is a good way to ensure the pages eventually flush from the cache on their own, ensuring they eventually are rendered with the new values.

      Terms & ConditionsAccessibility statement

      Loading footer...