<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Composer on Digital Archive Systems Tech Blog</title><link>https://tech.ldas.jp/en/tags/composer/</link><description>Recent content in Composer on Digital Archive Systems Tech Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 02 May 2026 06:00:00 +0900</lastBuildDate><atom:link href="https://tech.ldas.jp/en/tags/composer/index.xml" rel="self" type="application/rss+xml"/><item><title>Why Drupal's Automatic Updates Wasn't Running: `Unattended background updates` Is Disabled by Default</title><link>https://tech.ldas.jp/en/posts/drupal-automatic-updates-unattended-default-disabled/</link><pubDate>Sat, 02 May 2026 06:00:00 +0900</pubDate><guid>https://tech.ldas.jp/en/posts/drupal-automatic-updates-unattended-default-disabled/</guid><description>&lt;blockquote>
&lt;p>This article is co-authored with generative AI. While I have cross-checked facts against official documentation where possible, errors may remain. Please verify primary sources before making important decisions.&lt;/p>&lt;/blockquote>
&lt;p>A red banner kept showing up in a Drupal admin UI: &amp;ldquo;A security update is available.&amp;rdquo; The site already had the &lt;code>Automatic Updates&lt;/code> module installed, but no automatic update had ever applied. The naive question — &amp;ldquo;doesn&amp;rsquo;t installing the module mean updates just happen?&amp;rdquo; — turned out to have a very plain answer: the cron-time apply policy is shipped disabled, so the module is essentially idle until you turn it on. The fix is small, but the failure mode is easy to miss because the module name implies behavior that is gated behind a separate setting.&lt;/p></description></item></channel></rss>