Hi. I’m posting here because my post to the regular Community failed to yield an appropriate response.
Does anyone know how to view the HTML of a Confluence Cloud Fabric Editor page that will be sent for conversion to PDF via the PDF-export option? We are struggling to customise the PDF-export stylesheet because we can’t find the tags, IDs, and classes used by some new macros.
The View Source option in a browser doesn’t reveal the HTML. Chrome’s Inspect option looks like it does, but when we add the classes to the PDF stylesheet, we see no impact on the PDF.
Using the Confluence API to report on the page content doesn’t include the classes and IDs either.
Does anyone have any ideas?
2 Likes
To hopefully explain this issue further, when using the legacy editor, we used to modify the CSS of an information tip element using the class “confluence-information-macro-tip”. When we view the source of a new-editor page that uses the new success-tip macro, Chrome’s Inspect function tells us that this macro uses the class “ak-editor-panel”. If, however, we attempt to modify the look of the tip panel by applying CSS to the class "ak-editor-panel’ in the PDF-export stylesheet, nothing happens. We can, however, modify the look by inserting the old class, even though Chrome’s Inspect function tells us that class isn’t used.
To me, this suggests that the HTML rendered in the browser must be further processed before it is sent to the PDF-export process, so maybe I don’t need a way to view the actual source HTML (maybe I can see that already). Perhaps I need a way to find out what HTML is being sent to the PDF-export engine. Perhaps the best approach will be to submit a support ticket to Atlassian. If they are modifying the HTML “behind closed doors” so to speak, only they will be able to disclose what is actually being sent to the PDF-export engine.
I don’t know that this is true, it’s only my own theory:
The new fabric pages seem to use an entirely distinct renderer from legacy pages. As I understand it, the new ADF page format is used to directly render fabric pages, but the legacy SFXML renderer still exists to service old page content. A translation engine exists to convert SFXML and ADF content between one another (but the conversions do not map 100% due to the fact that the two feature sets do not overlap perfectly, by design). As far as I can tell, the REST API only supports rendering using the legacy rendering engine, judging by the HTML it produces. This is also true for static content macros – feeding SFXML into a fabric page by way of a static content macro still awkwardly produces legacy-style HTML. The dual rendering engine set up inside Confluence now seems to be making for odd mixed-mode HTML combinations which appear to be hard, if not impossible, for vendors to exert control over. All of this makes me suspect that the PDF exporter uses the legacy page renderer. I also suspect that this may be due to the fact that some of the “new” web components used by AUI and AtlasKit don’t seem particularly well suited to PDF (or REST-based HTML) rendering (though I could easily be mistaken there).
This dual renderer situation is making our life tough for some of the static and dynamic content macros we have. I’ve been told over time that they will eventually phase out the legacy renderer, which makes it even harder to stay on top of this leaky internal transition as things change. We have requested API help to allow us to tell what kind of page we are rendering content in and for stylesheets to help make that content look correct for the parent page, but to no avail yet.
Again, this is all just my own theory mostly reverse engineered from our experiences with these macros and the REST API, but I have had some confirmation of the rough shape of the theory from some Atlassian engineers and PMs.
2 Likes
Thanks for your comments, @BobBergman.
A colleague of mine has posted the following discussion to the regular Confluence Cloud Community pages: Fabric Editor: how to customise Info, Success, Err...
It explains how we have been successful in customising the look of some Fabric Editor macros using the classes associated with their legacy counterparts, although Atlassian has messed up the mapping of some.
I entirely agree with you that it appears that the legacy PDF-export process is being used for Fabric-editor pages even though there is a mismatch between functionality available in the two editors.
1 Like
@BobBergman If, as you suggest, there is a translation between the two types of content, it won’t help us to identify the CSS classes used by the Fabric Editor since those aren’t supported by the PDF renderer. What we really need to know, then, is how each element and macro is being translated. It would really help if there were a way to view a translated page for comparison purposes.
1 Like
I agree with you. The support for Connect apps to know what kind of page or renderer is in play appears to be next to impossible unfortunately, which is very frustrating. If we learn anything new from our open DEVHELP tickets relating to these issues I’ll be sure to post back here.
1 Like
Thanks for the link to the other post, also. We’ve been having issues with the message boxes in non-PDF contexts as well, FWIW.
1 Like