Discussions
Allow JavaScript and HTML5 in Shared and Dynamic Content to provide ability to globally manage landi
Eloqua disallows the use of JavaScript and HTML5 in Shared Content and Dynamic Content, which prevents us from managing certain pieces of code in one place for our landing pages. Can this restriction be removed? Here are some examples of fundamentals pieces of code that are restricted:
Restricted HTML in Shared Content
The "data-toggle" attribute is not allowed for the element "input"
Restricted HTML in Shared Content
The "data-placement" attribute is not allowed for the element "input"
Restricted HTML in Shared Content
The "script" element is not allowed
Restricted HTML in Shared Content
The "section" element is not allowed
Restricted HTML in Shared Content
The "article" element is not allowed
Restricted HTML in Shared Content
The "footer" element is not allowed
Restricted HTML in Shared Content
The "header" element is not allowed
Restricted HTML in Shared Content
The "nav" element is not allowed
Restricted HTML in Shared Content
The "iframe" element is not allowed
Restricted HTML in Shared Content
The "figure" element is not allowed
Restricted HTML in Shared Content
The "figcaption" element is not allowed
Restricted HTML in Shared Content
The "role" attribute is not allowed for the element "form"
Restricted HTML in Shared Content
The "required" attribute is not allowed for the element "label"
Restricted HTML in Shared Content
The "placeholder" attribute is not allowed for the element "input"
Comments
-
I ran into this issue trying to embed a video in dynamic content for use on a landing page. The page had dynamic content for all 7 of our brands, and I was planning to only create only one page. In the end, I had to create 7 separate landing pages because of this issue.
-
I ran into this issue trying to embed a video in dynamic content for use on a landing page. The page had dynamic content for all 7 of our brands, and I was planning to only create only one page. In the end, I had to create 7 separate landing pages because of this issue.
We want to put our Tealium tags in their own container of shared content in case we need to add or remove things in the future. Would be nice to edit once instead of thousands of LPs.
-
I have a similar use case when needing to trigger js, which is only applicable on certain languages (the dynamic content was looking up the user country) - otherwise a very manual process when covering 10+ languages. Would be great for this functionality to be added!
-
Encountered this issue as well. We would like to modularise (we do, in all other systems) our landing pages, both in terms of design (html and css) as well as functionality (Javascript). These restrictions mean we have to duplicate work across many landing pages, making the process error-prone and time consuming to update and maintain both the pages and the relevant documentation. Imagine updating a brand for a customer where they have 20 or 30 landing pages where no or few assets are shared or updating functionality in terms of Javascript across all of these.
Time consuming and error-prone...
-
This is definitely a roadblock for us. Let's all spread the word and see if we can get more votes.
-
Dealbreaker.. please consider this
-
Video element is also not allowed. This is a big roadblock for us as well. We cannot use our embedded email video elements in dynamic content, which means we end up creating multiple versions of the same email as a workaround.
-
Does anyone know if this is being considered for future updates? We are in desperate need of this to avoid having to duplicate landing pages and emails.
-
Brianna - They're aware of the issue, but I don't think it's actively being addressed. This suggestion needs more votes.
-
Running into this issue right now and it's causing a great deal of grief. I would also add iframes to what can be allowed in dynamic content-- I'm building a landing page that encourages interaction: visitors answer questions (forms) and the form serves up immediate content based on their interaction through the form's redirect website processing step. We also capture the visitor's answer and can use in following up actions. The idea is to serve up different questions through dynamic content but display the answer-based content within the section of the page we designate as dynamic, instead of on the redirect refreshing to a new page.
-
Brianna - They're aware of the issue, but I don't think it's actively being addressed. This suggestion needs more votes.
@brettg This is actively being addressed and we are currently in a concept phase. We hope to have an option for customers soon.
Cheers,
Thamina Christensen
-
@brettg This is actively being addressed and we are currently in a concept phase. We hope to have an option for customers soon.
Cheers,
Thamina Christensen
Thanks, Thamina. Any updates?
-
Thanks, Thamina. Any updates?
We are working to prioritize this among the other projects. No ETA yet.
-
This is a definite issue for most folks trying to host landing pages and/or microsites in Eloqua. While it is being looked at by the team over there, please also consider removing the restrictions around hosting fonts as well. Right now for any brand-specific fonts that are not "standard" we have to host them externally as eloqua will not allow these file types. It seems to be another restriction that is counter-productive for a software marketed for hosting of web pages. Hosting fonts externally will often produce errors like the following: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://xxxxx.com/library/fonts/myFont.woff2 (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)".
-
This is a definite issue for most folks trying to host landing pages and/or microsites in Eloqua. While it is being looked at by the team over there, please also consider removing the restrictions around hosting fonts as well. Right now for any brand-specific fonts that are not "standard" we have to host them externally as eloqua will not allow these file types. It seems to be another restriction that is counter-productive for a software marketed for hosting of web pages. Hosting fonts externally will often produce errors like the following: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://xxxxx.com/library/fonts/myFont.woff2 (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)".
I second Tom's comment about hosting fonts. We host our brand fonts externally as well, which requires the involvement of a team outside of ours.
-
We are working to prioritize this among the other projects. No ETA yet.
Hey Thamina! Happy Holidays to you! Do you have any update for us on this enhancement? We are greatly anticipating the ability to put html 5 in dynamic content!
Thanks!
-
Hi,
This lack has an impact on the compliancy to accessibility when it comes to adding the "role=presentation" into shared or dynamic content and avoid accessibility enhancement on those part of the email.
The whole interest of it is described here : https://www.emailonacid.com/blog/article/email-development/why-should-i-set-my-table-role-as-presentation/ and is compliant to W3C rules, please consider this feature soon.
Thanks,
Aurore
Oracle Consulting Team
-
Hello,
Our company needs to be able to include JavaScript in shared content and dynamic content for several use cases:
- Embedding videos
- Global Script Tags (for all pages)
- Redirecting users with JavaScript disabled to a specific form
For now, I've tried to be sure to include Google Tag Manager on every page; and I host additional scripts and code on Google Tag Manager so that I can manage it in a single location. Hopefully Eloqua allows scripts soon so that this can be managed in one system, without workarounds.
-
Hello Oracle Team,
This issue came up again today. Can we be provided with an update? Will this be included in a future release?
Thanks,
Brett
-
I have also faced this issue however to overcome it I just put the base URL inside the dynamic/shared content and then handled the other parts of the HTML (i.e. <script> or <link>) inside the pages itself. This way you have one place to handle the actual URL should it need updating and then you can still control it via html/javascript on the page itself appending it to the body.
