@Bfarkas hey have you ever encountered this by chance?

@JZenker hi - you are going to run into a problem. The editor that Docebo supplies strips any tags / attributes that it considers to be unsafe. If you are using it with a <label> tag and as part of a form, yeah - you are going to run into issues on two levels - not only will you find that you cannot use that? I believe you are going to find you are running into issues with the form itself.

I will admit I am a little out of my league but consider using an iFrame and an external form builder.

Yeah its a labellfor= attribute that does not seem to be working - it actually gets auto removed upon clicking save changes

The workaround - Can you iframe in a page that you publish elsewhere? Maybe that is where you can get away with what you are doing?

I was thinking about it, but we have lots of extended enterprises that would share the page and I want to be able to use the path element of the URL (e.g. /pages/579/home) so all can use it rather than using full URLs which would force a sign in or 404.

I’ve tried an iframe before and the path elements unfortunately call to the site its being hosted on.

I apologize if I am not understanding - when using an iFrame the url for the Docebo page remains intact and you should be able to continue your path element usage. You should be able to share it so that people can land on that page for an experience with the iframed detail only acting as an element as part of the page.

In the html code of the page - yes - the iframe would call out to somewhere else - but unless someone is looking for it? They really can’t tell the difference. And if the iframe widget doesnt do it - maybe the HTML widget can do it for you.

For example - we share a banner on the top of our homepage - that is an HTML widget of a service (comslider) that comes in from somewhere else. It feels seamless.

What am I missing??? Help me help you .

Thanks, @dklinger - always appreciate the help!

Let’s say I create a standard custom content widget for a page. For the internal Docebo URL, I can put something like /pages/579/home and it will route the user to that page no matter what extended enterprise they are on. If I use the full URL test1.com/pages/579/home, if someone not associated with that test1 extended enterprise, they will get an error pop up that they aren’t approved to use that domain.

However, if I iframe in a custom box widget from say Canva, and try and put /pages/579/home in the hyperlink for the button, it will try and find that specific page in canva, throwing an error of course.

Building the design inside of docebo will allow us to use those enterprise friendly path URLs.

Yes - you will need to use full urls on the other end (the app lets call it).

I see your point - once a person interacts with the content thats in the iframe  - you want to continue their experience to another Docebo page. In there can lie a problem and you are correct - a person can run into a need to login and you run a risk of a 404 error if their permissions are not squared away on that newer landing page. At the very least it can trigger a page refresh as part of your experience. At the very most - login requests/404 errors can show up.