If you run a product on WordPress and want a "what's new" widget on it, you need to get one script tag onto every page. WordPress makes that harder than it sounds, mostly because the obvious method is the one that quietly undoes itself.
Here are three ways to do it, worst to best.
Before starting: this is the script tag method, which works on any WordPress site. There is no Patchlog plugin in the WordPress directory, so nothing here involves installing one.
Method 1: editing the theme's footer.php (do not do this)
Almost every tutorial says to open Appearance, then Theme File Editor, then
footer.php, and paste your script before </body>.
It works, right up until your theme updates. Then the file is replaced with the theme author's version and your script is gone. There is no warning and nothing in your dashboard tells you it happened. You find out weeks later when you notice the widget has not been showing.
If your theme is one you built and never update, this is fine. If it came from the directory or a marketplace, do not.
Method 2: a child theme (correct, but heavy)
The proper WordPress answer is a child theme, which inherits from the parent and
survives its updates. Create wp-content/themes/your-theme-child/functions.php
and add:
<?php
function add_changelog_widget() {
?>
<script
src="https://patchlog.io/widget.js"
data-project="YOUR_PROJECT_ID"
defer
></script>
<?php
}
add_action( 'wp_footer', 'add_changelog_widget' );
wp_footer is the hook that fires just before </body> on every front end page,
which is where you want it.
This is correct and it is also a lot of ceremony if a child theme is the only
reason you are making one. Setting one up properly means a style.css with the
right header comment, enqueuing the parent styles, and re-testing your site.
Method 3: a code snippets plugin (what to actually do)
Install one of the code snippet plugins from the WordPress directory. They exist precisely so you can add small pieces of PHP without touching theme files, and they store the snippet in the database, so nothing in your theme or its updates can remove it.
Add a new snippet, set it to run everywhere on the front end, and paste:
add_action( 'wp_footer', function () {
?>
<script
src="https://patchlog.io/widget.js"
data-project="YOUR_PROJECT_ID"
defer
></script>
<?php
} );
Activate it and you are done. Changing your theme later will not affect it.
The one value people get wrong
data-project takes the project ID, not the slug. The slug is the part that
appears in your hosted changelog address; the ID is what the widget uses to fetch
your entries. They look different and only one of them works.
Copy the whole snippet from your project's widget settings page rather than typing it out. The right value is already in it.
Only showing it to logged in users
If your WordPress site has member accounts and the changelog is only relevant to them, wrap the hook:
add_action( 'wp_footer', function () {
if ( ! is_user_logged_in() ) {
return;
}
?>
<script
src="https://patchlog.io/widget.js"
data-project="YOUR_PROJECT_ID"
defer
></script>
<?php
} );
When it does not show up
Three causes account for nearly all of it.
A caching plugin. WP Rocket, W3 Total Cache, LiteSpeed and the rest serve a saved copy of your pages, and your new script is not in it. Clear the cache after adding the snippet. If your host has its own caching layer, clear that too.
Script optimisation. The same plugins often have options to defer, combine or
delay JavaScript. Those can mangle a third party script or postpone it
indefinitely. If the widget is missing and you have those enabled, add
patchlog.io to the plugin's exclusion list before assuming anything else is
wrong.
A security plugin. Some block outbound script domains they do not recognise. Check its logs before spending time elsewhere.
To confirm what is actually happening, open your site and look at the browser
console. widget.js should load with a 200, and a request to
patchlog.io/api/widget/YOUR_PROJECT_ID should follow it. If the first is
missing, something on your side is stripping or blocking the tag. If the first
works and the second 404s, the project value is wrong.
It will not fight your theme
WordPress themes style bare HTML elements aggressively, and that is normally where embedded widgets go wrong, either inheriting your button and heading styles or leaking their own into your layout.
The widget renders inside a Shadow DOM, which is a browser level boundary. Your theme's CSS does not cross into it and its styles do not cross out. That holds regardless of which theme or page builder you use.
What this is worth
If you ship updates to a WordPress based product and never tell anyone, the effect is the same as not shipping them. People re-request features you built months ago, and the product reads as abandoned to anyone evaluating it.
The free plan covers one project and 25 updates with the widget and a hosted changelog page, which is enough to find out whether your users read it before you spend anything.