Most widgets arrive through a script tag. The browser loads the page, then the script, and only then does the script build the widget. Until that happens, the widget simply isn't there. A search engine that doesn't run JavaScript never sees it, and neither does a visitor who has JavaScript turned off.

Widget Storm has a script tag too, and we explained why it works without an iframe in Native widgets vs. iframe embeds. On a PHP site, though, we'd go the other way and let your server render the widget along with the page.

One line of PHP

From the Station you download two files, your personal wgclient.php and wghandler.php. Your account key lives in wgclient.php, so treat it like a password. Put both next to your page and write:

<?php include "wgclient.php";
$wg->get("wg_flipcard", "WidgetStormSystem", '{"front":"What is this?","back":"Rendered on the server."}', "php"); ?>

No echo needed. $wg->get() prints the HTML itself.

How to check it worked

Open the page in your browser and view the source, Ctrl+U in most browsers. The widget's HTML is right there, in this case a <div class="wg-flipcard"> with your text "What is this?". That's the same HTML a search engine gets.

You'll also find a new folder next to your page, wgbuilds/WidgetStormSystem/, holding the widget's files. More on that below.

Styles in the head, script at the end

The fourth argument decides what you get back. "php" returns just the HTML, "css" just the styles, "js" just the script. An empty string returns all three, wrapped in a style and a script tag. Here's how to put each part where it usually goes:

<?php include "wgclient.php"; ?>
<!doctype html>
<html lang="en">
<head>
  <style><?php $wg->get("wg_flipcard", "WidgetStormSystem", '', "css"); ?></style>
</head>
<body>
  <?php $wg->get("wg_flipcard", "WidgetStormSystem", '{"front":"What is this?","back":"Rendered on the server."}', "php"); ?>
  <script><?php $wg->get("wg_flipcard", "WidgetStormSystem", '', "js"); ?></script>
</body>
</html>

Where the code comes from

The first time your server asks for a widget, the handler fetches its code once, encrypted, from widget-storm.de and stores it in wgbuilds. From then on everything runs from that local copy. The files are ordinary code, so you can look at exactly what runs on your server whenever you like.

New versions arrive on their own. At most once an hour the handler asks whether a widget has changed. It only replaces a file if the new copy matches the checksum our server reports, and if anything goes wrong it keeps the old one. That one request an hour waits for our answer; every other page view doesn't touch our server. Your own widgets in your account's folder are never overwritten. This needs handler version 4.2 or later, and the version is printed at the very top of wghandler.php.

Ideally PHP can write to wgbuilds. If it can't, a handler from version 4.4 on stores the widget's code in the system's temporary directory instead. The widget still shows, and it names the reason as a comment in the page source and a line in the PHP error log. Older handlers show the widget empty, with no message on the page.

What you get out of it

The text inside the widget is in the HTML a crawler receives. Static widgets show up without JavaScript. Interactive ones still need their script for the interaction. And because the widget is part of your markup, your own stylesheet applies.

What you need

PHP, the curl extension for fetching, and ideally a wgbuilds folder PHP can write to. Composer works too, through the private repository with your Station login:

composer config repositories.widget-storm composer https://widget-storm.de/composer
composer require widget-storm/wgclient:^4.1

The package says 4.1, but the handler inside is the current one. If you installed through Composer a while ago, composer update won't bring a newer handler, so download it again from the Station.

For a quick try, the script tag on the widgets page is still the shortest route. If your site runs on PHP anyway, we'd start with $wg->get().