{"id":385311,"date":"2026-10-14T04:37:51","date_gmt":"2026-10-14T04:37:51","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/atelixo-changelog-digest\/"},"modified":"2026-10-14T04:37:17","modified_gmt":"2026-10-14T04:37:17","slug":"atelixo-changelog-digest","status":"publish","type":"plugin","link":"https:\/\/fur.wordpress.org\/plugins\/atelixo-changelog-digest\/","author":23554989,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.0.0","stable_tag":"1.0.0","tested":"7.1.3","requires":"6.0","requires_php":"7.4","requires_plugins":null,"header_name":"Atelixo Changelog Digest","header_author":"Atelixo","header_description":"Shows the changelogs of all pending plugin updates on a single screen, with security and breaking changes highlighted.","assets_banners_color":"","last_updated":"2026-10-14 04:37:17","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"","header_author_uri":"","rating":0,"author_block_rating":0,"active_installs":0,"downloads":29,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.0.0":{"tag":"1.0.0","author":"nicognito23","date":"2026-10-14 04:37:17","revision":3745282}},"upgrade_notice":[],"ratings":[],"assets_icons":[],"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0"],"block_files":[],"assets_screenshots":[],"screenshots":[]},"plugin_section":[],"plugin_tags":[13434,23893,254139,600,2550],"plugin_category":[54],"plugin_contributors":[277758],"plugin_business_model":[],"class_list":["post-385311","plugin","type-plugin","status-publish","hentry","plugin_tags-changelog","plugin_tags-plugin-updates","plugin_tags-release-notes","plugin_tags-security","plugin_tags-updates","plugin_category-security-and-spam-protection","plugin_contributors-nicognito23","plugin_committers-nicognito23"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/s.w.org\/plugins\/geopattern-icon\/atelixo-changelog-digest.svg","icon_2x":false,"generated":true},"screenshots":[],"raw_content":"<!--section=description-->\n<p>When plugin updates are available, WordPress does not show what they contain unless you open each changelog one by one. So updates are either applied blindly or postponed, security fixes included.<\/p>\n\n<p>Atelixo Changelog Digest adds a <strong>Dashboard \u2192 Changelog Digest<\/strong> screen that lists every pending plugin update with:<\/p>\n\n<ul>\n<li>the installed version and the new version;<\/li>\n<li>only the changelog entries <strong>between those two versions<\/strong> (long ranges show their start, with the rest behind a \"Show full changelog\" toggle);<\/li>\n<li>a red <strong>Requires PHP<\/strong> badge, from the official WordPress.org data, when your server runs an older PHP version than the update requires;<\/li>\n<li><strong>Security<\/strong> and <strong>Breaking \/ Important<\/strong> badges based on keywords found in those entries, each followed by the lines that triggered it, keywords in bold;<\/li>\n<li>a link to the plugin's page on WordPress.org.<\/li>\n<\/ul>\n\n<p>Plugins with a security badge or an incompatible PHP requirement are listed first.<\/p>\n\n<h4>Your consent first<\/h4>\n\n<p>After activation, nothing is requested from WordPress.org. A notice on the Plugins screen (only there) explains what will be sent and offers an <strong>Enable checks<\/strong> button; each user can dismiss it, and the digest screen offers the same button. The notice never appears elsewhere in the admin and disappears for good once checks are enabled. Once enabled, the plugin's row offers <strong>Stop checks<\/strong>, which deletes the cached changelogs and stops all requests until checks are enabled again. Deactivating the plugin does the same.<\/p>\n\n<h4>Read-only<\/h4>\n\n<p>The digest never updates anything. Use the regular Updates or Plugins screen to update.<\/p>\n\n<h4>Safe and lightweight<\/h4>\n\n<ul>\n<li>Changelogs come from WordPress.org as HTML and are always cleaned before display: scripts, event handlers, styles and non-http(s) links are removed, and only basic formatting is kept.<\/li>\n<li>Changelogs are fetched in the background after WordPress finds new updates, and cached per plugin version. Nothing is requested from WordPress.org on the front end or on other admin screens.<\/li>\n<li>No JavaScript, and only a few lines of CSS on the digest screen.<\/li>\n<\/ul>\n\n<p>Premium plugins (updates that do not come from WordPress.org) are listed with \"Changelog not available\".<\/p>\n\n<h3>External services<\/h3>\n\n<p>This plugin connects to the WordPress.org Plugins API (<code>https:\/\/api.wordpress.org\/plugins\/info\/1.2\/<\/code>) to read the changelog of plugins that have a pending update.<\/p>\n\n<ul>\n<li><strong>Consent<\/strong>: no request is made and no background task is scheduled until an administrator (a user who can update plugins) clicks <strong>Enable checks<\/strong>, in the notice shown on the Plugins screen after activation or on the Changelog Digest screen. <strong>Stop checks<\/strong> on the plugin's row (or deactivating the plugin) withdraws this consent: the scheduled task is removed and cached changelogs are deleted.<\/li>\n<li><strong>What is sent<\/strong>: the slug (folder name) of each plugin with a pending update from WordPress.org, one request per plugin, along with the standard WordPress HTTP headers (WordPress version and site URL in the user agent). No personal data is sent.<\/li>\n<li><strong>When<\/strong>: only while checks are enabled: right after <strong>Enable checks<\/strong>, in the background via WP-Cron after WordPress has checked for plugin updates, and when an administrator opens the Changelog Digest screen and some changelogs are not cached yet (at most 2 requests per page view). Each changelog is cached for 7 days for a given version. Never on the front end or on other admin screens.<\/li>\n<li><strong>Not sent<\/strong>: plugins without a pending update, and updates that do not come from WordPress.org.<\/li>\n<\/ul>\n\n<p>This service is provided by WordPress.org: <a href=\"https:\/\/wordpress.org\/about\/privacy\/\">WordPress.org privacy policy<\/a>.<\/p>\n\n<!--section=installation-->\n<ol>\n<li>Upload the plugin to <code>\/wp-content\/plugins\/<\/code> or install it from the Plugins screen.<\/li>\n<li>Activate it.<\/li>\n<li>Click <strong>Enable checks<\/strong> in the notice on the Plugins screen (or on <strong>Dashboard \u2192 Changelog Digest<\/strong>). There is nothing else to configure.<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"can%20i%20trust%20the%20security%20and%20breaking%20badges%3F\"><h3>Can I trust the Security and Breaking badges?<\/h3><\/dt>\n<dd><p>They are hints, not guarantees. They are based on keywords and phrases (for example \"security\", \"vulnerability\", \"XSS\", \"CVE\", \"breaking change\", \"minimum PHP version\", \"no longer supported\") found in the changelog entries of the update. A changelog can mention a security fix without these words, or use them for something harmless. The absence of a badge never means that an update contains no security change: always read the changelog.<\/p>\n\n<p>Each badge lists the changelog lines that triggered it, with the matching keywords in bold, so you can judge for yourself.<\/p>\n\n<p>The <strong>Requires PHP<\/strong> badge is different: it comes from the official WordPress.org data and is reliable. It is only shown when your server's PHP version is too old for the update.<\/p><\/dd>\n<dt id=\"why%20does%20a%20plugin%20show%20%22could%20not%20determine%20the%20exact%20version%20range%22%3F\"><h3>Why does a plugin show \"Could not determine the exact version range\"?<\/h3><\/dt>\n<dd><p>Changelogs have no standard format. When the version headings cannot be recognized (or the changelog only links to an external page), the digest shows the latest entries instead, collapsed.<\/p><\/dd>\n<dt id=\"why%20does%20a%20plugin%20show%20%22changelog%20unavailable%20right%20now%22%3F\"><h3>Why does a plugin show \"Changelog unavailable right now\"?<\/h3><\/dt>\n<dd><p>WordPress.org could not be reached, or returned an unexpected answer. The digest tries again later; other plugins are not affected.<\/p><\/dd>\n<dt id=\"who%20can%20see%20the%20digest%3F\"><h3>Who can see the digest?<\/h3><\/dt>\n<dd><p>Users who can update plugins (<code>update_plugins<\/code>). If your site defines <code>DISALLOW_FILE_MODS<\/code>, nobody has this capability and the digest is not available.<\/p><\/dd>\n<dt id=\"my%20site%20uses%20disable_wp_cron\"><h3>My site uses DISABLE_WP_CRON<\/h3><\/dt>\n<dd><p>Background fetching only runs when WP-Cron runs. Without it, changelogs are fetched when you open the digest, 2 at a time: reload the page to load the next ones.<\/p><\/dd>\n<dt id=\"does%20it%20work%20on%20wordpress%20multisite%3F\"><h3>Does it work on WordPress Multisite?<\/h3><\/dt>\n<dd><p>Multisite is not officially supported in version 1.0 and has not been tested. Use it on single-site installations.<\/p><\/dd>\n<dt id=\"why%20does%20the%20digest%20only%20show%20an%20%22enable%20checks%22%20button%3F\"><h3>Why does the digest only show an \"Enable checks\" button?<\/h3><\/dt>\n<dd><p>The plugin waits for your consent before requesting anything from WordPress.org. Click <strong>Enable checks<\/strong>: changelogs are then fetched and the digest is displayed.<\/p><\/dd>\n<dt id=\"what%20is%20removed%20on%20deactivation%2C%20%22stop%20checks%22%20and%20uninstall%3F\"><h3>What is removed on deactivation, \"Stop checks\" and uninstall?<\/h3><\/dt>\n<dd><p>Deactivation and \"Stop checks\" remove the cached changelogs (a single option), the consent setting, the lock and the scheduled event; after reactivation, checks must be enabled again. Uninstall removes the same data plus each user's \"notice dismissed\" setting.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>1.0.0<\/h4>\n\n<ul>\n<li>First release.<\/li>\n<\/ul>","raw_excerpt":"All the changelogs of your pending plugin updates on one screen, with security and risky changes highlighted.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/385311","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=385311"}],"author":[{"embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/nicognito23"}],"wp:attachment":[{"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=385311"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=385311"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=385311"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=385311"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=385311"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/fur.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=385311"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}