Troubleshooting
A route for diagnosing plugin problems, from the cheapest check to the most involved.
1. Rule out the obvious
- Pending updates — WordPress, theme and plugins (ours included) on their latest versions.
- Plugin or theme conflict — deactivate the other plugins and switch to a default WordPress theme. If the problem disappears, reactivate one by one until you find the culprit.
- Cache — LiteSpeed, WP Rocket, WP Super Cache, W3 Total Cache and friends hold on to old versions of your pages. Clear the cache whenever you change layout or settings.
2. Check the plugin's queue and history
Before reaching for external tools, the plugin already answers two questions:
- Joinotify → History shows what was sent, to whom, and with which status.
- Joinotify → Processing queue shows what is pending and what failed. Temporary failures are retried; configuration errors — invalid token, closed 24-hour window, missing template — stay put, because insisting would not change the outcome.
A message that never leaves and never shows up in the queue is usually an inactive workflow or a trigger that did not fire. A message that shows up in the queue and does not leave is a credential, window or WP-Cron problem — see Minimum requirements.
3. Debug with Query Monitor
Query Monitor is the fastest way to see what happens on a specific screen. Use it while you still have dashboard access.
Install it under Plugins → Add new, activate it, and open the bar that appears at the top of the dashboard:
- PHP errors — warnings and fatals on the current page.
- Database queries — slow or failing queries.
- Hooks and actions — what is running, useful for tracking down conflicts.
- HTTP requests — calls to external services, Joinotify's included. This is where a failed API connection shows up.
Errors that happen in AJAX or REST calls never reach the screen. Open the browser console, or the Network tab, click the request marked in red and read the response.
4. Turn on WordPress debug mode
Use it when you have no dashboard access. Edit wp-config.php, in the For developers:
WordPress debugging mode section:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Errors are then written to wp-content/debug.log.
WP_DEBUG_DISPLAY in productionLeaving WP_DEBUG_DISPLAY as true shows errors to your visitors, server file paths included.
On a live site, keep it false and read the log file.
For problems involving WooCommerce, the WooCommerce → Status → Logs page also records fatal errors and the plugin's own entries.
5. Common problems
Error 500 — internal server error
The server failed but will not say where. The most frequent causes are a PHP error, an invalid
.htaccess, a file permission, a server resource limit or a conflict between plugins.
How to investigate: turn on debug mode (step 4) and read debug.log. If the error only
happens on one screen, Query Monitor points at the line.
Blank page
A PHP fatal with error display turned off. Same route: debug mode and read the log.
CSS or JavaScript not loading
Check the browser console and, in Query Monitor, whether any asset requests are failing. Optimisation plugins that combine or defer scripts are the usual cause — test with the optimisation disabled.
The message never reaches the recipient
Check, in this order: the number is correct and includes the country code; the workflow is active; the trigger actually fired (check the history); the Joinotify API key is saved; and, on the Cloud transport, whether the 24-hour window is open. See Delivering through Joinotify Cloud.
6. Contacting support
If none of the above solved it, report the problem. Include:
- What you were doing when the problem happened.
- Screenshots of the error.
- Query Monitor errors or excerpts from
debug.log. - Versions of WordPress, the theme, Joinotify and the plugins involved.
The more complete the report, the fewer round trips. We do not provide support for third-party plugins or themes.