This forum has moved, please join us on github discussions. We will keep these old posts available for reference. Thank you!

Apostrophe Widget html clutter

#1

Just a quick question, why when logged out is there still so much apostrophe-generated code?
I completed the tutorial on page-links and was expecting the rendered HTML to only contain what I specified in my widgets html (in my case a single anchor tag)
instead it’s wrapped in all sorts of apostrophe clutter

<div class="apos-area" data-apos-area="">
  <div class="apos-area-widget-wrapper" data-apos-widget-wrapper="page-link">
  <div class="apos-area-widget" data-apos-widget="page-link" data-apos-widget-id="w57323936527548614" data="{&quot;_id&quot;:&quot;w57323936527548614&quot;,&quot;pageId&quot;:&quot;cj64eyzyu0004zwg4cgtqvs7g&quot;,&quot;type&quot;:&quot;page-link&quot;}" data-options="{&quot;edit&quot;:false}">
  <a href="/link">Link here</a>
</div>
</div>

I can understand this is needed for the editor side (when logged in) but why is it still rendered when logged out?
Is there a way to keep your widget’s code clean of this apostrophe generated wrappers?

#2

The data attribute is used to populate the widget editor, though I find it rather confusing – why bother storing the values inside the data if the modal could simply take it using the id of the widget.
More than that, storing the editor data as it is now is a serious security issue. Imagine someone storing email addresses or API keys or God knows what else inside the widget config. I’m glad I have come across this post before launching any production site.I hope the apostrophe team can address it one day.
In the meantime I think I’ve found a workable solution:

go to apostrophe-areas/views/widget.html and decorate whatever you want to hide in the user mode with this clause:

{%- if data.widget._edit and data.options.edit != false -%} {% endif %}

I’m not sure what long term consequences it might have, but hiding the widget parameters seems to have done no harm.

1 Like
#3

The data is available both so that the editor can manipulate it and so that javascript-based widget “players” can play it. Disabling those attributes would cause problems for widget players that rely on the convenience of access to the data. Implementing the latter via an API that “phones back” to get the data for the widget would slow down the page.

I would not recommend putting sensitive data in widgets that will be on the page, no. They are normally for display purposes and the data they contain is what they need to display something, usually to the public.

You could safely put sensitive information in the schema of a piece, that is what I would recommend. It would seem strange to put it in a widget since they are so display-oriented.

That being said, although JavaScript-based widget players often need some of the information, it would make sense to provide a way to distinguish between information those who can edit the widget will need and information that everyone will need. I can see some use cases for what you’re describing, like a widget that fetches a feed from another site using a username and password.

I’ve opened a ticket to track that. Contributions are of course welcome: