WordPress troubleshooting
Firewalls, security plugins, and the other reasons events sometimes fail to arrive.
WordPress problems almost always fall into one of two categories: Nodest can't reach your site, or your site can't reach Nodest. Working out which one you have narrows the cause down quickly.
Nodest can't reach your site — connecting fails, actions on the site fail, testing a trigger returns nothing.
Your site can't reach Nodest — everything looks connected, but automations never start when they should.
The second is the more confusing one, because nothing appears broken.
Events never arrive
The connection is fine, the trigger is configured, but nothing happens when you place an order or publish a post.
The plugin sends events to Nodest as outgoing requests from your server, so anything blocking outbound traffic breaks this silently.
Security plugins. Wordfence, iThemes Security and similar tools can block outgoing requests. Look for outbound request or firewall rules and allow requests to the Nodest API.
Server or host firewall. Some hosts restrict outbound connections by default. This is common on managed and hardened hosting, and usually needs a support ticket to change.
The plugin isn't active. Deactivating the plugin — or a bulk plugin update that switches it off — stops everything with no other symptom.
The source plugin isn't active. WooCommerce triggers need WooCommerce active. If the plugin providing the event was deactivated, its events stop.
The event genuinely didn't fire. Some plugins bypass the standard WordPress hooks when records are created programmatically — imports, bulk tools, and some payment gateways do this. If the event only fails for imported or automated records but works when you do it by hand, this is why.
Only some events arrive
Usually a caching or object-cache interaction, or an event firing in a context the plugin isn't running in.
Check whether the failing cases share something: created by a specific gateway, imported in bulk, made by a particular user role. That pattern is the fastest route to the cause.
The site can't be connected
It isn't publicly reachable. Nodest calls your site over the internet, so localhost, a local development domain, or an IP-restricted staging site can't be connected.
HTTP authentication is on. Staging sites behind a browser password prompt reject Nodest's requests. Remove it or allow the Nodest API through.
Maintenance mode. A maintenance plugin returns an error page to everything, including Nodest.
The credentials are rejected. Use an application password, not the login password, and copy it in full. Application passwords also require the site to be on HTTPS — WordPress disables them otherwise.
The URL is wrong. Include the protocol, and use the address WordPress itself considers canonical. A site that redirects www to non-www should be connected on the address it redirects to.
The plugin couldn't be installed automatically
Two usual causes:
The account can't install plugins. Installing requires administrator permissions. A shop manager or editor account connects fine but can't install.
The host disallows it. Some hosts disable plugin installation from within WordPress entirely.
Either way, install the plugin manually and then connect — Nodest detects it and skips the install.
Everything broke at once
When every automation on a site fails together, it's the connection rather than the automations.
Most likely: the application password was revoked, the account was removed or demoted, or the site moved to a new URL. Reconnect with current details — automations pick it up with no editing.
Working out where it went wrong
The run history tells you which side failed.
No run at all — the event never reached Nodest. Look at the site: plugin active, outbound requests allowed, event actually firing.
A run exists but a step failed — the event arrived fine. The problem is in the step, and the error message comes from the tool it was calling.
That distinction saves the most time, so check it before anything else.
