JPKCom Disable Comments — Guide & Tips
Disable WordPress comments site-wide with JPKCom Disable Comments — installation, requirements and practical tips.
JPKCom Disable Comments disables the WordPress core comments functionality for the entire site. Useful when you simply don't need comments on a corporate or documentation site. Notes in the block editor keep working.
Guide
Requirements
- WordPress 6.9 or newer (tested up to WordPress 7.1)
- PHP 8.3 or newer
Installation
- In your admin panel, go to Plugins → Add New and click Upload Plugin.
- Choose the plugin's ZIP file and click Install Now.
- Click Activate.
How it works
There is no settings page — once active, the plugin disables the core comments functionality globally. Comment and trackback support is removed from every post type, comments and pings are forced closed, and the Comments screen, admin menu entry and admin-bar node are gone.
Beyond that, the plugin closes the routes through which comments otherwise remain visible or reachable:
- The dashboard shows no comment count and no moderation list.
- The comment feeds (
/comments/feed/and<post>/feed/) return 404 instead of serving stored comments, and the feed discovery links are gone. This also applies to the query-string spellings (?feed=comments-rss2,?p=123&feed=rss2): they get the 404 directly, without WordPress' redirect to a pretty URL that would 404 as well. The regular post feed at/feed/stays available. - Every post reports zero comments (since 1.0.11). So
/feed/and the Atom feed no longer carry comment links and counts pointing at unreachable comment feeds, and themes no longer print "N comments". - The REST comment endpoints answer 404 (except for notes, see below), exactly the way WordPress answers a missing route (
rest_no_route). REST post responses reportcomment_statusandping_statusasclosed.
Notes in the block editor
WordPress stores the notes in the block editor (since WordPress 6.9) as comments of type note and reads and writes them through the same REST routes as regular comments. Up to and including 1.0.10, the plugin removed those routes (and from 1.0.9 on also emptied every comment query), taking the notes down with them.
Since 1.0.11 the routes stay registered, and the plugin decides per request: requests for notes — the collection with type=note (listing and creating), or an existing note by its ID — are handed to WordPress, whose own permission checks still decide who may read and write them. Every other request on those routes gets the 404. The check applies to the comment WordPress would actually load: if a request on a note's route names a different comment through an id parameter in the query string or the request body, it gets the 404 as well. So a regular comment cannot be read, changed or deleted through a note's route.
Because the routes stay registered, the REST index at /wp-json/ lists them again.
Existing comments are not deleted — they stay in the database, out of reach of the front end, the feeds and the REST API. Deactivating the plugin makes them visible again.
Tips & Tricks
- Global instead of per post: The plugin works site-wide — you no longer have to disable comments manually on each individual post or page.
- The feeds were the leak: Up to version 1.0.8 existing comments were still publicly retrievable through the comment feeds. Those feeds are built by
WP_Querydirectly via$wpdband bypass the filter the plugin relied on. If you switched comments off on an older version, check/comments/feed/after updating. - Missing your notes? If notes in the block editor didn't work while the plugin was active, the plugin was the cause: only from 1.0.11 on does it let them through.
- Dashboard only clean since 1.0.9: Before that, the comment count in "At a Glance" and the moderation list in the Activity widget were still there.
- REST API covered: Comments are not reachable via the API either — every request on the comment routes that does not concern a note gets a 404. Since 1.0.11 this also applies to
OPTIONSrequests, which used to get an empty 200 from the formerly removed route. The storedcomment_statusin the database is deliberately left alone —closedis what gets reported, and the fields keep their place in the response so the block editor sees the shape it expects. - Reproducible updates: Since version 1.0.2 the plugin uses secure self-hosted updates via GitHub with SHA256 checksums and runs with
declare(strict_types=1). Since 1.0.10 it also carries theUpdate URIheader: the wordpress.org update API then no longer returns updates for this plugin, so a plugin published there under the same slug cannot pose as an update. Since 1.0.12 Dashboard → Updates shows the JPKCom logo next to the plugin. - Updates even while deactivated: Since 1.0.13 the plugin ships updater 1.5.0. A loaded updater 1.5.0 serves all installed JPKCom plugins, active or not, with the update row, icon and “View details” — so while this plugin is active, it does that for your deactivated JPKCom plugins too. When it is deactivated itself, it is offered updates only if another JPKCom plugin with updater 1.5.0 or newer is active, because a deactivated plugin's code does not run. The SHA256 check applies just the same. On multisite at least one JPKCom plugin must be network-active or active on the main site. The stored update list no longer contains JPKCom download URLs; they come back only while a JPKCom updater is loaded. The checksum also applies to a package supplied by another plugin and to every GitHub address of the release file. If the plugin sits in a Git or other version-control checkout, you are told about new releases, but WordPress offers no update (“Automatic update is unavailable for this plugin.”) — the update would delete the checkout, so you update it yourself. The same applies to an active plugin in a renamed folder (such as
jpkcom-disable-comments-main), because the update would delete the folder; while deactivated there, the updater does not find it at all. The updater fetches update information only for accounts that can update plugins, in the update cron and in WP-CLI, never for anonymous visitors. - All in one plugin: JPKCom Harden & Trim has included a "Disable comments" switch since version 1.1.0 that behaves like this plugin in version 1.0.11, plus 40 further settings for security, privacy and performance. Running both does no harm; this plugin should then be at least on 1.0.11, though, or notes in the block editor stay blocked.
Further reading
- Source code on GitHub: https://github.com/JPKCom/jpkcom-disable-comments (opens in a new tab)
- API documentation (PHPDoc): https://jpkcom.github.io/jpkcom-disable-comments/docs/ (opens in a new tab)
- This project's changelog