Housing recovery must be an inclusive process where people are able to express their aspirations.

Read the full story →

Akismet: Upgrade to the official Akismet Drupal module
by Derek Springer on 6th October 2026 at 22:13
If your Drupal site still runs the community Akismet module (drupal/akismet), the official Akismet module (drupal/akismet_antispam) can upgrade it in place. You swap the Composer package, run database updates, and your API key and protection settings come along. We built it so you don’t have to uninstall, reinstall, and re-enter everything. This post walks through the steps. Which sites this covers The update needs Drupal 10.3 or later on PHP 8.1 or later. That covers sites on the community module’s 2.0.x releases and its 8.x-1.x dev branch. If you’re on an older setup: 8.x-1.0-alpha2 (Drupal 8 or 9): update the community module to 2.0.0-alpha2 while you update core, then follow this post. 7.x: upgrade Drupal first, then install the official module fresh. Your Akismet account and API key still work. The migration guide on drupal.org has a table for every release if you’re not sure which one you run. Before you start Back up the database. The update only goes one way. Note which roles have “Bypass Akismet protection.” The update removes that permission (more on that below). Plan one deploy for the whole swap. Between the Composer change and drush updb, spam protection is off and some admin pages break, so don’t leave a gap between them. What carries over, and what doesn’t These come along: Your API key Your connection timeout, if it’s between 1 and 60 seconds Your comment, contact and registration protection settings These don’t: Check history. The community module’s akismet table is dropped, so the Spam tab starts empty. Those rows hold submitted content, including author emails and IP addresses, and the official module has no way to erase them later. Per-form settings. The community module could protect some comment types or contact forms and not others. The official module has one toggle per category, and it covers all of them. Per-form “discard spam.” This becomes one site-wide strictness setting. Test mode, custom API endpoints and the “block all submissions” outage policy. The “Bypass Akismet protection” permission. The update removes it from every role that had it. The official module’s equivalent is bypass akismet, and it isn’t granted automatically. Webform handlers. You’ll need to re-attach the Akismet handler to each webform that used it. You don’t have to track any of this by hand. The update prints a report that names every item above that applies to your site. The migration composer remove drupal/akismetcomposer require drupal/akismet_antispam -Wdrush crdrush updb Run them in that order, back to back. composer remove first, and leave the module installed in Drupal. Don’t uninstall it, because the update reads its database state. The official module’s composer.json conflicts with drupal/akismet, so Composer won’t install them side by side. composer require ... -W lets Composer update shared dependencies, like the Akismet PHP SDK or the PSR HTTP packages, if your lock file pins an older version. Without -W, Composer can refuse with “the package is fixed to … (lock file version).” drush cr before anything else. The community module shipped services that no longer exist, and Drupal still has them cached. Until you rebuild, logged-in pages return a 500 and drush commands die on shutdown. drush cr works when nothing else does. drush updb runs the update. Stay off the comment admin screens until it finishes. Read the report. It’s also logged to watchdog, so you won’t lose it if your terminal scrolls away. Then export and commit the new configuration: drush cex On every other environment, rebuild the cache before anything else touches it: drush cr && drush deploy Check that it worked Settings: confirm your protection toggles at /admin/config/content/akismet. Status report: check the Akismet entries at /admin/reports/status. Test submission: post a comment as an anonymous user named akismet-guaranteed-spam. Akismet always flags that name, so the comment should land in the Spam tab. Already on the official module 1.0? Upgrading to 1.1 is one command and a database update: composer update drupal/akismet_antispam -Wdrush updb The -W matters here. Version 1.1 needs Akismet PHP SDK 1.5, and if your lock file still pins 1.4, Composer stops with: drupal/akismet_antispam 1.1.0 requires automattic/akismet-sdk ^1.5 -> found automattic/akismet-sdk[v1.5.0] but the package is fixed to v1.4.0 (lock file version). -W (short for --with-dependencies) lets Composer update the SDK along with the module. Questions If something in the report surprises you, or the update doesn’t go the way this post says, open an issue in the issue queue. The migration guide and the module’s README have the full details.
WordPress.org blog: WordPress 7.1.3 Maintenance and Security Release
by Jake Spurlock on 6th October 2026 at 17:00
This security and maintenance release features 7 security fixes and 4 bug fixes. Because this is a security release, it is recommended that you update your sites immediately. You can download WordPress 7.1.3 from WordPress.org, or visit your WordPress Dashboard, click “Updates”, and then click “Update Now”. If you have sites that support automatic background updates, the update process will begin automatically. Security updates included in this release The security team would like to thank the following people and organizations for responsibly reporting vulnerabilities, and allowing them to be fixed in this release: A stored XSS on the Comments administration page, exploitable via pending comments, reported by Thomas Chauchefoin at Trail of Bits A DoS issue in the WP_Http::make_absolute_url() method, reported by Anthropic A second-Order SQL injection in WordPress WXR export, reported by Anthropic A weakness allowing Author role users to sticky posts, reported by Anthropic Unauthenticated disclosure of comments on private & unpublished posts, reported by Ananda Dhakal from Patchstack Imgur embeds are vulnerable to XSS, reported by Zhengyu Liu, Jingcheng Yang, and Gavin Zhong Forgeable parameters passed to the {status}_{type} hook can lead to action name collision, reported by Alex Concha of the WordPress security team Thank you to these WordPress contributors This release was led by Jake Spurlock. WordPress 7.1.3 would not have been possible without the contributions of the following people. Their asynchronous coordination to deliver maintenance and security fixes into a stable release is a testament to the power and capability of the WordPress community. Aaron Jorbin, Adam Silverstein, Adi Moldovan, Adrian Duffell, Alex Concha, Arkaprabha Chowdhury, Deepak Kumar, donniam, Ehtisham Siddiqui, Jake Spurlock, Jb Audras, Jeremy Felt, Joe Dolson, John Blackbourn, Jon Surrell, Jonathan Desrosiers, Ken Gagne, Khokan Sardar, Lance Willett, lucatume, marcs0h, Peter Wilson, pkevan, RS Software, Rudy Faile, Sergey Biryukov, siliconforks, smerriman, Stephen Bernhardt, Suryakant Upadhyay, vortfu, webVerts, Weston Ruter, Yogesh Bhutkar Backports As a courtesy, the security fixes are being backported, where necessary, to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported. The backports are in progress and will ship as they become ready. How to contribute To get involved in WordPress core development, head over to Trac, pick a ticket, and join the conversation in the #core channel. Need help? Check out the Core Contributor Handbook.
Open Channels FM: Open Source Maintainers Defend Against AI Spam, Linux Data Trends and WordPress Accessibility Challenges
by Bob Dunn on 6th October 2026 at 15:45
AI-driven growth presents challenges in security and accessibility and infrastructure hurdles that technology teams cannot ignore.
Open Channels FM: The Essential Human Touch in Genealogical Research
by Open Channels FM on 6th October 2026 at 10:42
As artificial intelligence becomes more integrated into genealogical research, it is tempting to imagine a future where longstanding mysteries are unraveled with a few keystrokes. AI tools can now scan, transcribe, and sort through centuries of records, but the heart of successful genealogy still depends on something machines cannot replicate: the human touch. No matter
OpenStation Blog: Someone Said “I Hate OpenStation.” That Was Actually Useful.
by Daniel López on 6th October 2026 at 08:54
A few days ago, someone opened a support thread about AllTerrain Forms and, in the middle of otherwise useful feedback, wrote something very direct: “I hate OpenStation.” Obviously that is not the nicest sentence to read when you are working on the product, but at the same time it immediately got my attention because this is exactly the kind of feedback that can be useful if you don’t take it personally. So instead of trying to explain why OpenStation is good, or why we made certain decisions, I asked a very simple question: what exactly makes you hate it? Her answer was actually very good. She works on a laptop, so screen space matters a lot. OpenStation was opening windows too small for her workflow, which meant that one of her first actions was always maximizing them. She also didn’t like losing the visible URL because she regularly copies URLs into emails, project trackers or messages. On top of that, her users are not very technical, and from her point of view OpenStation was adding another layer to WordPress that she would eventually have to explain and support. She basically said that browser tabs already exist, users understand them, they use the whole screen, and they don’t hide the URL. And I think this is exactly where building software becomes interesting, because from our side all of those decisions had reasons behind them, but reasons don’t really matter if the final experience is worse for the person using it. None of these are theoretical product discussions. They are very concrete things that someone hit while trying to use the software for real work. That matters a lot to me. We started discussing these points immediately, and one of them has already made it into the next OpenStation release. Users will now be able to choose how new windows open: using the current default behaviour, maximized, or focused. Focused mode maximizes the new window and minimizes the other windows on the same desk, so people working on smaller screens can have something much closer to the experience they expect. This came directly from that kind of feedback, and the implementation is already merged: PR #964: Preferences: choose how newly opened windows appear And this is really the point. We obviously have our own vision for OpenStation. We believe WordPress can have a much better working environment than the traditional admin experience, and there are many things we still want to explore there. But having a strong idea of where the product should go does not mean pretending every decision we make is correct. Sometimes the most useful feedback is not “great release” or “this looks amazing”. Sometimes it is someone telling you that a window is too small, that they want the URL back, that something scrolls when it shouldn’t, or simply that they don’t see the benefit of what you built. That kind of feedback forces you to look at the product from outside your own head, which is probably one of the hardest things to do when you have been working on it every day for months. For me, OpenStation becoming more mature is not only about adding more apps, more features or more ambitious ideas. A big part of maturity is improving all those small things that make the product feel natural, predictable and less annoying to use. And I think there is also something important here about open source. People can complain, explain exactly what does not work for them, and a few days later they can literally see the code that changes that behaviour. That is a pretty healthy way to build software. So yes, tell us when OpenStation is great, but especially tell us when it sucks. We may not agree with every suggestion, and we obviously cannot build every requested feature, but if there is a real problem behind the feedback, we want to understand it. In this case, someone said “I hate OpenStation.” Fair enough. A few days later, OpenStation got better because of it.