A common question from APG vNext users is whether you can embed a JavaScript snippet or an HTML widget directly inside a blog post, just as you would in a regular HTML page.
The Short Answer
Yes — APG vNext supports raw HTML and script tags inside blog posts, provided the author has the appropriate permissions (typically Administrator or Moderator level). Standard users are restricted to safe HTML to prevent XSS attacks.
How to Enable Script in Blog Posts
- Log in as an Administrator and go to Admin Panel → Roles & Permissions.
- For the role you want to allow script embedding, enable the Allow Raw HTML option.
- Save the settings and test by inserting a simple
<script>alert('Hello')</script>in a blog post draft.
Common Use Cases
- Embedding Google Adsense or other ad units within blog posts
- Adding social sharing widgets (Twitter, Facebook, LinkedIn)
- Inserting YouTube or Vimeo iframes
- Adding custom analytics event tracking
- Embedding interactive demos or code sandboxes
Security Considerations
Be cautious about which roles you grant raw HTML access to. Allowing untrusted users to insert scripts can expose your community to cross-site scripting (XSS) attacks. Always limit this permission to trusted administrators and content editors only.
If you need to embed third-party widgets for regular users, consider creating a custom BBCode tag that safely wraps the widget code rather than allowing unrestricted script execution.
Using Scripts and Code in APG vNext Blog Posts
APG vNext blog posts support embedded HTML, but the platform applies an HTML sanitisation layer that strips potentially dangerous tags and attributes — including <script>, <iframe>, event handler attributes (onclick, onload, etc.), and javascript: protocol href values — to prevent cross-site scripting (XSS) attacks. This means that arbitrary JavaScript snippets pasted into the blog editor will be removed on save, which is the correct security behaviour. For code display purposes (showing a script as text without executing it), use the code block feature in the editor.
Displaying Code Blocks in Blog Posts
The APG vNext blog editor includes a code block button in the toolbar that wraps selected content in <pre><code> tags and applies syntax highlighting via a client-side highlighting library. Use code blocks for displaying shell scripts, SQL queries, configuration snippets, HTML examples, and any other programmatic content. The code block preserves whitespace and line breaks (which the standard paragraph mode collapses), displays the content in a monospace font, and prevents the HTML sanitiser from stripping angle brackets and other special characters by encoding them as HTML entities before saving.
Embedding Third-Party Widgets (Non-Script Embeds)
Many third-party services (GitHub Gist, CodePen, JSFiddle, Google Forms) offer embed codes based on <iframe> or <script> tags. Since APG vNext strips these by default, embedding external content requires a different approach. For iframes, an administrator can use the admin panel rich content editor (which bypasses the member-facing sanitiser) to insert iframe embeds into blog posts created through the admin interface. For script-based embeds (like Twitter/X embedded posts or YouTube video embeds), APG vNext provides a dedicated media embed feature in the blog editor that handles oEmbed-compatible URLs — paste the URL directly into the embed dialog without manually copying the script tag.
Custom JavaScript via Theme Files
If the goal is to add interactive behaviour (custom scripts, analytics, chat widgets, or A/B testing) to blog post pages, add the JavaScript to the theme files rather than embedding it in individual posts. Theme JavaScript added in the appropriate place (the footer of the main layout file) executes on all pages including blog posts, without requiring script insertion into each post individually. This approach is also more maintainable — scripts can be updated in one theme file rather than in every post that uses them. For scripts that should only execute on blog post pages, add a conditional check in the theme footer script using the page body class that APG vNext adds to the HTML element on post detail pages.
Related Resources
Security Rationale for HTML Sanitisation
The APG vNext HTML sanitiser removes <script> tags and event handler attributes from all member-authored content — blog posts, forum replies, private messages, and profile fields — as a fundamental XSS defence. A forum where members can inject arbitrary JavaScript into pages visible to other members creates a critical security vulnerability: a malicious member could steal session cookies, redirect members to phishing sites, or silently perform admin actions under an admin's session if the admin views a page containing the malicious script. The sanitiser is not configurable by default because relaxing it without a thorough security review introduces serious risks. If your forum has a specific use case that requires allowing HTML in posts (e.g., a web developer community where members post HTML code samples), use the code block feature which safely HTML-encodes the content rather than rendering it.
Looking for more help? Browse the support forum or check the Knowledge Base.