[MAGNOLIA-5029] Components with areas does not behave as expected on a public instance: areas are displayed even if they are empty Created: 20/Jul/12  Updated: 25/Jun/13  Resolved: 16/May/13

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 4.5.9

Type: Bug Priority: Major
Reporter: Samuel Schmitt Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File Demo Project - About - On public.jpg     JPEG File jcr-view.jpg     JPEG File stkTeaser.jpg    
Issue Links:
causality
is causing MAGNOLIA-5132 Make rendering of empty areas configu... Closed
is causing MAGNOLIA-5045 Fix selenium integration tests Closed
documentation
to be documented by DOCU-433 Rendering of area content is skipped,... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

On a public instance, components that have in their configuration areas defined do not behave as expected while this behavior is correct on the author instance.

On the public, even if the area is not existing , the component displays it.

Let's take an example.
Open these pages
http://demoauthor.magnolia-cms.com/demo-project/about.html
and
http://demopublic.magnolia-cms.com/demo-project/about.html

Inspect the HTML code of the "Standard Article" on both page.
You will remark that on the public site you have an extra div where class is links.
See the screenshot .

Standard article is a STK Teaser, its configuration is stkTeaser.
And you can see that it has an area linkList.

And this area has as a template script /templating-kit/components/teasers/linkListArea.ftl that renders this HMTL code

<div class="links">
    [#if (content.title)??]
       <${headingLevel}>${content.title}</${headingLevel}>
    [/#if]
    <ul>
        [#list components as component ]
            [@cms.component content=component /]
        [/#list]
        [#if cmsfn.editMode]
		    <li cms:add="bar"></li>
	    [/#if]
    </ul>
</div><!-- end links -->

But why this code is rendered on public and not on author.
By the way you can have a look at the JCR Browser Website, the content is 100% the same, there is no empty linkList node on public (that could lead to the same behavior).

So I think that the problem comes from the tag cms.area.

In internalPage.ftl

        [#-- Rendering the teaser's linkList --]
        [@cms.area name="linkList"/]

The tag should not render the area linkList as it's not existing.
Well it works on the author, but why not on the public?



 Comments   
Comment by Jan Haderka [ 03/May/13 ]

But why this code is rendered on public and not on author.

Actually this is not completely true. The empty div is rendered also on author when not in preview mode. In preview mode it is skipped because:

AreaElement.java
    private boolean canRenderAreaScript() {
        // FYI: areaDefinition == null when it is not set explicitly and can't be merged with the parent. In such case we will render it as if it was enabled
        return this.isAreaDefinitionEnabled && (areaNode != null || (areaNode == null && areaDefinition.isOptional() && !MgnlContext.getAggregationState().isPreviewMode()));
    }

Values:
this.isAreaDefinitionEnabled == true
areaNode == null
areaDefinition.isOptional() == true

  • edit view on author:
    • return true && (false || (true && true && true)) ==> true, will render
  • preview mode on author:
    • return true && (false || (true && true && false)) ==> false, will NOT render
  • on public:
    • return true && (false || (true && true && true)) ==> true, will render
Comment by Jan Haderka [ 13/May/13 ]

Changing the template script is good as temporary workaround, but can't be final solution. There are other areas that can be used under components and they all suffer from same problem. This is why we need to solve it from within canRenderAreaScript() method.

Comment by Jan Haderka [ 15/May/13 ]

just a tiny thing, but helps to understand the code next time there's some bug to fix:

               if (!((AreaDefinition.TYPE_LIST.equals(areaDefinition.getType()) || AreaDefinition.TYPE_SINGLE.equals(areaDefinition.getType())) && numberOfComponents < 1)) {
 272 

is not really easy to read, partly because it is long and partly because of the negation of the whole statement. Can we maybe just swap if/else parts of the code below so the test expression doesn't have to be negated?

Also IIRC expressions are evaluated left to right so I would put the simple (numberOfComponents < 1) test first because if that is not satisfied, there's no need to evaluate the rest ... but that's really nitpicking.
Thx.

Generated at Mon Feb 12 04:01:18 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.