[PAGES-71] Pages Detail-App: Missing & strange ActionBar behaviour with missing cms:page and/or cma:area directives Created: 12/Jan/16  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: 5.4.3
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Christian Ringele Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicate
duplicates PAGES-47 Page-editor: Notify users about broke... 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   

During training material creation I have encountered bad and strange behavior of the ActionBar of the page's detail subApp.

Generally:
When using a script not containing cms:page and cms:area no ActionBar is displayed in the page's detail app.
I think this can be defined as a bug -> why should the outer Content App framework react in its ActianBar to the inner rendered item within the subApps workbench?
=> the ActionBar should always be there.

Reproduce:

  • Create a type Freemarker page template
    • Have a 'main' area of type 'list' in it
    • Don’t add any components into the main (no component content)
  • Use this code in its script:
    <!DOCTYPE html>
    <html xml:lang="en" lang="en" class="no-js">
        <head>
             [#--[@cms.page /]--]
        </head>
        <body>
             <h1>Hello Test</h1>
             [#--[@cms.area name="main" /]--]
        </body>
    </html>
    

    Be aware:
    The cms:page and cms:area are commented out. I will use them for the different scenario explanation.

Situation 1.: Bug
(Use the code as it is)
Setup:
Mode of editor: view or edit the same
cms:page -> NOT used
cms:area -> NOT used
Result: No ActionBar

Situation 2.: Strange behaviour (Bug)
Setup:
Mode of editor: view
cms:page -> NOT used
cms:area -> IS used
Result:

  • Has ActionBar, but wrong -> as if you had clicked on the area itself
  • BUT the area itself is not rendered

Situation 3.: Strange behaviour (Bug)
Setup:
Mode of editor: edit
cms:page -> NOT used
cms:area -> IS used
Result:

  • Has ActionBar, but wrong -> it does not change from the 'view' state. Still having "Preview Page". But its not reacting at all, not able to switch back to the 'view' mode.
  • BUT the area itself is not rendered

Situation 4.: Correct behaviour
Setup:
Mode of editor: edit and view
cms:page -> IS used
cms:area -> NOT used
Result:
Correct behaviour

Situation 5.: Correct behaviour
Setup:
Mode of editor: edit and view
cms:page -> IS used
cms:area -> IS used
Result:
Correct behaviour, also the area is rendered as expected.

For a second round of test scenarios use now this code:
[#--[@cms.page /]--]
<h1>Hello Test</h1>
[#--[@cms.area name="main" /]--]

Be aware again:
The cms:page and cms:area are commented out. I will use them for the different scenario explanation.

Situation 6.: Bug
(Use the code as it is)
Setup:
Mode of editor: view or edit the same
cms:page -> NOT used
cms:area -> NOT used
Result:
Same as in situation 1. (Problem)

Situation 7.: Strange behaviour (Bug)
Setup:
Mode of editor: view
cms:page -> NOT used
cms:area -> IS used
Result:
Same as in situation 2. (Problem)

Situation 8.: Strange behaviour (Bug)
Setup:
Mode of editor: edit
cms:page -> NOT used
cms:area -> IS used
Result:
Same as in situation 3. (Problem)

Situation 9.: Correct behaviour
Setup:
Mode of editor: edit and view
cms:page -> IS used
cms:area -> NOT used
Result:
Same as in situation 4. (Correct)

Situation 10.: Correct behaviour
Setup:
Mode of editor: edit and view
cms:page -> IS used
cms:area -> IS used
Result:
Different to situation 5.

  • Same behaviour with the ActionBar as in Situation 2.
  • Main problem: the area-bar itself is not rendered at all.
    => I think with even no html doc tag etc the area bar should be there. Try outs and page rendering snippets (called for example via Ajax) will probably not have them.


 Comments   
Comment by Mikaël Geljić [ 11/Apr/16 ]

I expect that if you uncomment the area tag, without uncommenting the page tag, you should get a warning since PAGES-47 (considered a broken template script). This should stand for situations 2, 3, 7 and 8.

If I exclude the correct cases, we're only left with the cases where templates do not have any cms tag at all:

  • In that case, we don't consider the template broken, so there is only a warning in the browser console.
  • I agree, action bar is still empty then, because we don't have any actionbar configuration for "static" pages, nor for "external" pages. I would suggest this as an improvement (though, besides the edit-preview toggle, not sure what actions are relevant still, but ok)

Hope this helps

Comment by Christian Ringele [ 11/Apr/16 ]

This should stand for situations 2, 3, 7 and 8.

Why should I add a "cms:area" tag to non existing areas, which I don't want to use?
This is a (ugly) work around or I understand your suggestion wrong.

If I get then a pop up, that would also not be beneficial.
(Missing) Markup I only need, if I also want to return html, which is in my hands for what content type the script is being used.
And I could also use pages to be included as sub-snipets again of other renderings etc.

Out of my view, it leaves all the situations open as BUG or as WRONG POP UP.

Imagine you start with a empty script and want to try out things, and in the end

Comment by Roman Kovařík [ 19/May/22 ]

Hello,

This ticket is now marked as closed due to one of the following reasons:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you.

Thank you,
The Magnolia Team

Generated at Mon Feb 12 06:15:20 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.