nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Linefeed when using Display Space Property macro

Scott Eade

I can use the "Display Space Property" macro on a space home page to successfully include a property value within the text of a paragraph. But when I am not on the space home page a div element surrounds the value so that with the following in the editor (the macro follows immediately after the "is"):

> The property value is \[ Display Space Property : some-parameter]

is output as (note the linebreak after "is"):

> The property value is

> some-parameter's value

This HTML (in Chrome) is:

<p>

<span>The cluster name is currently set to </span>

</p>

<div class="content-wrapper conf-macro output-inline" data-hasbody="false" data-macro-name="projectdoc-space-property-display-macro">some-parameter's value</div>

Back on the space home page the div element does not appear - why is this included in the other pages? This is breaking my content.

This issue occurs with the Display Property macro as well.

projectdoc-test-res2.png

HTML-fragment.png

projectdoc-test-src.png

projectdoc-test-page.png

projectdoc-test-src2.png

image2016-9-9 1:7:22.png

image2016-9-9 1:47:39.png

Accepted answers

Robert Reiner _smartics_

I'd like to sum up the solution to this problem as discussed in the comments to this question:

Since Confluence 5.10.x the rendering of table cells has changed. There is an additional div element with class "content-wrapper" around the value. This is no problem for the rendering of the HTML tables, but since the projectdoc Toolbox extracts the value from a cell, the value is now boxed in a div element. If then this property value is rendered with the Display Document Property Macro or the Display Space Property Macro - for instance - in a paragraph, the paragraph will be closed before the div element is rendered. Therefore there will be a linebreak (the paragraph end) and there is no way to properly render the property value in a paragraph.

This is the example from the question:

&lt;p&gt;
&lt;span&gt;The cluster name is currently set to &lt;/span&gt;
&lt;/p&gt; 
&lt;div
 class="content-wrapper conf-macro output-inline" data-hasbody="false" 
data-macro-name="projectdoc-space-property-display-macro"&gt;some-parameter's
 value&lt;/div&gt;

You can see that the paragraph is closed before the div element. Since the div element is not allowed inside the p element.

To work around this problem, please update to version 1.12.3 of the projectdoc Toolbox. This will remove the div element so that the HTML rendering will not be forced to render the paragraph end.

All comments

Robert Reiner _smartics_

Hi Scott,

may I ask which version of Confluence you use?

There is a know issue (PDAC-660) which is solved for the upcoming version 1.13 of the projectdoc Toolbox. The problem is reported on version 5.10 of Confluence.

I'm unsure if this issue applies to your report, since the rendering makes no difference according to the page the macros are used. Maybe this is an issue after the update of Confluence? That would mean that the rendering will break on the space homepage once you change and save the page.

I cannot reproduce the problem on the current development version. So I assume the problem you describe is fixed in 1.13. I assume you are using the latest version of the projectdoc Toolbox (1.12.1)?

Scott Eade

Confluence version is 5.10.3. Projectdoc version is 1.12.1.

What is the ETA on 1.13?

Thanks, Scott

Robert Reiner _smartics_

I'm currently looking at the issue and we are planning to release a 1.12.2 with a backport of PDAC-660. I will give you feedback today.

Scott Eade

That would be totally awesome Robert. Thanks!

Robert Reiner _smartics_

Hi Scott,

I'm still trying to reproduce the problem you describe. Now I'm not sure if this is really related to the PDAC-660.

It would help me a lot if you could show me the content of the property table in storage XML. I'd need only the table row (<tr>...</tr>) that contains the property you select.

If this table data containing the property value contains a div element (what I suspect) then this div element needs to be removed. Otherwise it would be rendered by the display macro.

The problem then would be that - following your HTML snippet example - the browser encounters p, then encounters a div (which forces it to close the p) and then encounters the end of the paragraph (which forces the browser to add a p start tag). The result would look like this:

HTML-fragment.png

If this reproduces your problem, then you should also have a <p></p> after the HTML snippet you provided in your example.

In this case you could fix the problem by using the source editor and remove the enclosing block element (in your case probably a div).

We are currently discussion if we should remove block elements by default, but this would interfere with some representations that block elements on purpose.

I would be happy if you could provide the content of the property row. Thank you in advance!

Edit 1: We could reproduce the problem if we add a macro that renders a <div class="content-wrapper"> ... </div>. In this case the PDAC-660 actually fixes the issue. We will create a release for 1.12.2 and upload it to the Atlassian Marketplace.

Edit 2: Version 1.12.2 with the PDAC-660 fix is now available on the Atlassian Marketplace. If your issue is related to "Edit 1" this should fix the problem. If it is not, I'd like to ask you for the information concerning the property value. This would help me a lot to reproduce the problem.

Scott Eade

Hi Robert. I have installed version 1.12.2 but unfortunately the problem persists. The property in question is still rendered in a div:

<div class="content-wrapper conf-macro output-inline" data-hasbody="false" data-macro-name="projectdoc-space-property-display-macro">some-parameter's value</div>

A detail I failed to point out is that "some-parameter's value" is a property defined using two other properties.

I have just constructed a test page in a new space to try and show this, but unfortunately this exhibits a different, though perhaps related, problem. Source of the page looks like this:

projectdoc-test-src.png

But this time, instead of the div, nothing is rendered for the combined property value. Rendered page looks like this:

projectdoc-test-page.png

Note how var-ps renders correctly in the Space properties table, but is not rendered in the last line of the page. In my non-test page the equivalent of var-ps is rendered, but within the aforementioned div.

I see the same behaviour if I reproduce the above as display properties on a new page the existing space, i.e. var-ps is not rendered. Weirdly the properties constructed in a similar fashion from elsewhere in the original space are continuing to be rendered (but with the div).

Thanks for your help so far. Hopefully this will help you figure out what is going wrong.

Robert Reiner _smartics_

Hi Scott!

Thank you for your detailed report!

I just started to have a look at it, but yet could not reproduce the problem.

But here are some thoughts ...

According to your HTML fragment I miss the paragraph element inside the div element that is typically added on the configurations I encountered by the Confluence editor. So your pattern will not be recognized (by version 1.12.2) and the div is not removed. Since this rendering is not part of a public API we try to stick close to the patterns we see in each Confluence version.

image2016-9-9 1:47:39.png

Could it be that the p has been manually removed? May I ask you to add it to check if 1.12.2 is fixing that problem?

Version 1.13. will provide a feature to remove single block elements surrounding property values sad . If there is no workaround I could have a look at it and check if I could move it to a 1.12.3 ...

I'm running Confluence 5.10.3 and the projectdoc Toolbox 1.12.2 and created a space homepage with the following contents using the macros you show in your example (BTW: having no Name property is not recommended, but seems not to lead to problems in your scenario).

image2016-9-9 1:7:22.png

Your example could be the result of a 'race condition'. If the page is rendered before the save and index events have been completed, some property values my not yet be available for rendering. I suppose a page reload in your browser or refresh the page in the cache does not do the trick?

Side note: That the value of var-ps is rendered in the table, but not in the text below. is based on the fact that the value of var-ps is not used in the table, but the values of var-prefix and var-suffix. var-prefix also does not fail to show up in the text.

I personally never used the Display Space Property Macro in this context. Either the Display Document Property Macro or the Space Property Placeholders worked in my use cases. So the value of var-ps in your example could be rewritten as

${prefix}-${suffix}

Although the scenario you described worked on my machine, may I ask you to check if using placeholders would work? They are rendered differently than the macros you employed in your example.

I have to admit that I do not fully understand the with the display properties in relation to the space property. I replaced the space property macros with display property macros and it works fine. But this is no surprise since the original scenario also worked. Therefore: I suspect that there is something wired going on, so that I would expect to see some hints in the logs. May I ask you to check if there are messages that may give us an additional clue?

I'm sorry that I still do not have a solution for this issue!

Scott Eade

Hi Robert,

Here is the results of looking at Space Property Placeholders.

Page source:

projectdoc-test-src2.png

And here is the result:

projectdoc-test-res2.png

So certainly something inconsistent going on here.

Looking for logs an p markers now.

Scott

Scott Eade

Back in my original space the placeholder syntax for Space properties does seems to be addressing the problem of the prepended linefeed. This is not the case however for properties defined on other pages - on these pages the placeholder syntax cannot be used and the formatting problem (inclusion of div) occurs.

I can't see a way to remove the p or the div - the table cell where the property is defined appears to be a paragraph, but there is no way I can see to get rid of this.

I can't see anything in the logs for the confluence instance. Is there a particular place I should be looking or a particular log I should be enabling?

Thanks, Scott

Robert Reiner _smartics_

Sorry Scott,

I did not point out clearly that I think we are tracking two different problems here, three if we throw in the placeholder replacement thing you have shown in your last reply.

(1) Boxing-Problem

Form version 5.10 on Confluence seems to handle adding table cell content differently. If I add a macro to a table cell, e.g. the Iteration Macro, there will be an extra div with class "content-wrapper" and an additional p inside.

To address this the release 1.12.2 of the projectdoc Toolbox figures out if this nested elements are wrapped around the property value and automatically removes it.

For some reason, I cannot find the root cause, the value in your example ended up with a div and class "content-wrapper", but the p element is missing. I'm thinking of a fix where the p element need not exist to have this 'correction algorithm' triggered.

I'm a bit reluctant to apply the correction algorithm so that we do not remove HTML elements where the user deliberately added it. But we are probably save checking for the div and class.

This all occurs when the page is saved. On saving, the values are cached and each further access, space or property, will fetch the value from that cache.

Side note regarding your observation that the placeholder do not remedy the block problem: The boxing problem (or problem of prepended linefeed) is not addressed by the placeholders. The algorithm in resolving the property values is different, but not the way the properties are accessed. I did throw in the placeholders to check problem (2).

Side note regarding the problem that the placeholders do not work on pages: You are right, space property placeholders are only defined for space properties. That is indeed confusing and we are considering to allow them for document properties, too.

To edit the value of the property table cell you would need to install the Confluence Source Editor provided by Atlassian. This allows you to edit the storage format of the page.

Please note that the div might seem unproblematic since it does not add any formatting rules. But as soon as the div appears inside a block element like p, the paragraph gets closed. Then the div is rendered and the the rest of the paragraph. Therefore there is the line-break between the p div p.

How can we deal with this?

Option 1: If you would consider to install the source editor you could check if my theory of adding the p inside the div in the table cell will work. If this is the only place on your Confluence server then this would be solved. If you experience that the p element appears at different places, then we have to switch to Option 2.

Option 2: I remove the div element if it has a class attribute value that contains "content-wrapper". It would imply that all other class information for HTML element will get lost. Therefore I might want to guard it with a system property that needs to be set in order to apply it. This implies that you would need to restart the server.

This should fix problem (1). I'm confident unless proven otherwise. wink

(2) Space Property Values

The second problem is that compound space properties do not get resolved on your machine. I'm still not able to reconstruct the problem. Unfortunately currently all three versions (space property display macro, document property display macro) work on my machine.

I asked for the logs since I suspected that there are stacktraces that would lead us to the root cause. These messages should be logged to the standard log file.

CONFLUENCE_HOME/logs - e.g /var/atlassian/application-data/confluence/logs/atlassian-confluence.log

The location of your Confluence home is configured in

confluence/WEB-INF/classes/confluence-init.properties -> 
confluence.home = /var/atlassian/application-data/confluence

If there are messages you are unsure what they are telling, you could create a support zip file and send it to us so that we can have a look at it. But I am a fan of selecting the snippets from the log file manually and send it to the support. Log files may contain sensitive data ... sad

How can we deal with this?

Action 1: I ask a colleague to try your scenarios on one of our test servers. I hope that he can reproduce the issue. He has already started ...

Action 2: When things get funny, a restart of the Confluence server sometimes helps. sad Maybe there has been a problem installing the add-on ...

Action 3: If restarting did not change anything, I'd check out which components could provide more information and we could turn on debug level messages for those components.

(3) Placeholders in Code Macro

I'd like to postpone this until we resolved the first two issues. I suspect that the macro currently does not deal with the space property value templates.

Therefore I'd like to suggest to use the Display Property Macro for composing until I had fixed this.

I'm very sorry again for using that much of your time. Unfortunately I have to reproduce the issue on one of our machines to find a solution. I thank you very much for your patience in providing my all this information!

Edit 1: I added the bugfix release 1.12.3 to the Atlassian Marketplace. This will remove div elements with a class attribute value containing "content-wrapper". This should remove problem (1).

Edit 2: The issue (3) will be resolved with version 1.13 (PDAC-678). Then the code macro will also resolve template values.

Scott Eade

Hi Robert. The latest update seems to have addressed the linebreak issue and in my existing spaces the rendering of placeholders actually seems to work. The test space I created last week on the other hand is a different story. The paceholders continue to function poorly in that space (even after restarting confluence).

I am head down on a deliverable this week and so do not have much time to put into this. The fixes so far will hopefully allow me to use projectdoc for this current deliverable. I will certainly shout out if I came across anything else unexpected.

I will hopefully have some time next week to dig further.

Thanks, Scott

Robert Reiner _smartics_

Hi Scott!

If you encounter any problems, I'm happy to help!

I will add an answer to the question so that we can close the issue regarding the linebreak. This is just a summing up so that users do not need to follow this discussion in the comments.

I'd like suggest to look at the test space next week (or whenever you have time) separately from this topic. Maybe this is something we could analyse by email (we would check if a new space still has this problem and may analyse if rebuilding the caches on the existing spaces will help)? Please get in touch once you have time!

Robert Reiner _smartics_

I'd like to sum up the solution to this problem as discussed in the comments to this question:

This is the example from the question:

&lt;p&gt;
&lt;span&gt;The cluster name is currently set to &lt;/span&gt;
&lt;/p&gt; 
&lt;div
 class="content-wrapper conf-macro output-inline" data-hasbody="false" 
data-macro-name="projectdoc-space-property-display-macro"&gt;some-parameter's
 value&lt;/div&gt;

You can see that the paragraph is closed before the div element. Since the div element is not allowed inside the p element.

To work around this problem, please update to version 1.12.3 of the projectdoc Toolbox. This will remove the div element so that the HTML rendering will not be forced to render the paragraph end.

Scott Eade

Awesome support from Robert & Smartics. Thanks!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

macro