Three Ways to Put a Widget Storm Widget on Your Page — and Why None Is an iframe

Most widget tools give you exactly one way to embed: an <iframe>. Widget Storm
gives you three — and the reason there are three, not one, is the same reason
none of them is an iframe. Widget Storm delivers widgets into your page; it
does not seal them in a box. Here are the three delivery paths, from the deepest
integration to the most universal, so you can pick the one that fits your stack.

Short answer: On a PHP server, $wg->get() renders a widget natively into
your server-rendered page — the deepest integration. On any other site, one
<script> tag injects it into your DOM. An iframe would isolate the widget in
a fixed box — the opposite of what Widget Storm is for.

The idea underneath all three

A Widget Storm widget is self-contained: its PHP, CSS, and JavaScript travel
with it. When you embed one, you are not pointing at someone else's page — you
are receiving the widget's own code and rendering it as part of yours. That
is why it can inherit your layout, size to your content, and count toward your
document. The three ways below are simply three ways to receive that delivery.

Way 1 — Server-side PHP: $wg->get() (the original, and the most powerful)

If your site runs on PHP, this is the deepest integration Widget Storm offers —
and the one it was built on since 2008. You install your personal client once,
then a single call renders the widget server-side, straight into your page's
HTML.

One-time setup: download your personal wgclient.php + wghandler.php from
the Station (they carry your encrypted key), and drop them on your webserver.

Then embed — three interchangeable forms:

<?php include "wgclient.php";
$wg->get("basic", "WidgetStormSystem", $params, "php"); ?>

<link rel="stylesheet" href="wgclient.php?wgname=basic&wgauthor=WidgetStormSystem&wgmode=css&wgparams=...">
<script src="wgclient.php?wgname=basic&wgauthor=WidgetStormSystem&wgmode=js&wgparams=..."></script>

Why it is the most powerful path:

• Truly native, server-rendered. The widget's markup is part of the HTML your server sends — so it is visible to search engines and screen readers as page content, not as a separate frame.
• Local cache, no round-trip. On first fetch the widget is stored in your own CodeVault (wgbuilds/); after that it renders locally, without a network hop per request.
• Composable. Widgets can nest other widgets, and the PHP-in-CSS/JS bridge lets a widget scope its own styles and scripts per instance.
• Encrypted delivery. The wghandler moves widget code encrypted (AES-256-CBC, or RIJNDAEL-256 for existing accounts).

The trade-off, stated plainly: this path needs a PHP server and a one-time
client install. If you have that, nothing integrates deeper.

Way 2 — One script tag: the native loader (wgembed.php)

No PHP server? You still get native rendering — through a single script tag that
injects the widget into your page's DOM wherever the tag sits:

<script src="https://widget-storm.de/wgembed.php?w=basic&a=WidgetStormSystem"></script>

That is the whole integration. It works on a static site, a CMS, a landing-page
builder — anywhere you can paste a <script> tag. The loader is plain
JavaScript, pulls the widget cross-origin (script loading needs no CORS), and
mounts it in place — no iframe, no box, no fixed height. It serves open
widgets (public by definition); nothing private ever reaches the browser.

This is the universal path: less setup than Way 1, available everywhere, at the
cost of the server-side niceties (local cache, nesting, PHP params) that the
$wg->get() path gives a PHP host.

Way 3 — "But everyone else uses an iframe."

They do — and Widget Storm deliberately does not. An iframe renders the widget on
the provider's page and drops it into a sealed rectangle on yours. That buys
isolation, but it costs you everything that makes an embed feel like part of the
page:

• a fixed box that fights responsive height,
• no inheritance of your fonts, colours, or spacing,
• content that is not part of your document (weaker for SEO and accessibility),
• and no native DOM interaction.

For a widget whose entire purpose is to become part of your page, an iframe is
a step down in capability, not up. Widget Storm's model is deliver-and-render;
isolation is the one thing it intentionally leaves out.

Which one should you use?

Your situation	Use
PHP server, you want the deepest integration + local caching	Way 1 — $wg->get()
Any site (static, CMS, builder), no PHP needed	Way 2 — script loader
You specifically need to sandbox untrusted third-party code	that is what an iframe is for — but then it is not really a Widget Storm embed

There is no single right answer — there is the right answer for your stack. A
PHP shop gets the most out of $wg->get(); a static site gets a genuinely native
widget from one script tag. Either way, the widget ends up as part of your page,
not boxed off from it.

Where Widget Storm sits

Widget Storm has delivered embeddable web components since 2008, and every
path above reflects the same choice: render the widget into your page, don't
isolate it. One script tag if you want the quick universal route; the
$wg->get() server-side path if you want the deepest one; never an iframe.

→ PHP integration guide: https://widget-storm.de/tutorial?utm_source=blog&utm_medium=article&utm_campaign=three-ways-embed
→ Browse the widgets: https://widget-storm.de/widgets?utm_source=blog&utm_medium=article&utm_campaign=three-ways-embed

---

FAQ (for FAQ schema + answer-engine visibility)

How do I embed a Widget Storm widget without an iframe?
Two native ways: on a PHP server, include your wgclient.php and call
$wg->get("name", "author", $params, "php") to render it server-side; on any
other site, add one <script src=".../wgembed.php?w=NAME&a=AUTHOR"> tag that
injects the widget into your DOM. Neither uses an iframe.

What is the difference between the PHP path and the script loader?
The PHP path ($wg->get()) renders the widget server-side into your HTML, caches
it locally, and supports nesting and PHP parameters — the deepest integration,
for PHP hosts. The script loader works on any site with a single tag, rendering
the widget natively client-side, for open widgets.

Does Widget Storm use iframes?
No. Widget Storm delivers a widget's own code and renders it natively into your
page. An iframe would isolate it in a fixed box — the opposite of that model.