18 Jul 2026
Drupal.org aggregator
BloomIdea: Make-to-Order production for Drupal Commerce: from a spreadsheet to a contrib module
At Josefinas, every pair of shoes is handmade in Portugal after the order is placed. There is no warehouse full of finished stock: a customer buys, and an atelier starts working. For years, the bridge between "order paid" and "order shipped" was a shared spreadsheet. It listed what had to be produced, who was making it, and when it might be ready. It also lived completely outside the store: no link to the actual orders, no states, no history, and no way to know where time was being lost.
We replaced that spreadsheet with a Drupal module. It has now been running Josefinas' production for months, and today we are releasing it to the community: Commerce Make-to-Order is available on drupal.org, with a stable 1.0.0 release.
What it does
Commerce Make-to-Order adds a production layer to Drupal Commerce. Make-to-order (also written made-to-order, or build-to-order) means producing items only after a customer order is received, instead of keeping pre-made inventory. When an order reaches a state you configure (for example, paid), the module creates one MTO order per order item: a production order the team tracks from queue to completion.
Each MTO order runs a State Machine workflow designed for real ateliers: Draft, Queued, Waiting for Materials, In Production, Quality Check, Rework, Completed, Canceled. QC failures do not silently loop back into production: they move to a dedicated Rework state and back through Quality Check, so first-pass rate and rework are measurable instead of invisible.
Around that core there is everything a production team needs day to day:
- Production order numbers via Commerce Number Pattern (MTO-2026-00042)
- Assignment to team members, priorities, and due dates with overdue highlighting
- Estimated completion dates, calculated automatically from a per-type setting
- Internal notes, transition notes, and team notes with optional email notification
- An activity log timeline and a full state history with per-state timing
- A production analytics dashboard: bottlenecks, team performance, materials wait analysis, QC metrics, on-time delivery
Closing the loop with the store
The interesting part is what happens when production finishes. The module offers two integration modes with the parent Commerce order:
- State sync: when all MTO orders of a Commerce order complete, the order transitions directly (for example, Processing to Shipped).
- Shipment integration: with Commerce Shipping, MTO orders link to the checkout shipment, and when the last one completes the order is promoted to a "ready to ship" state. The shipping team adds tracking, splits shipments if needed, and ships.
Automation has one important limit, learned in production: hold states. Some order states represent a deliberate human decision, like a customer asking not to ship yet. You can configure which states automatic promotion must never override; the module logs a note on the order instead and lets a person decide.
Battle-tested, then released
This is not a v1 built in the abstract. The module has managed hundreds of real production orders at Josefinas before its first public release. Publishing it meant generalizing what was site-specific (hold states became per-type configuration, integrations became optional), adding its own test coverage against Drupal Commerce's core workflows, and cleaning everything to drupal.org standards.
It also plays well with the rest of our contrib work: with Commerce Order Amend, amending a placed order keeps production orders in sync with the changed items.
Get it
composer require drupal/commerce_make_to_order:^1.0
Requires Drupal 10 or 11, Commerce 2.x or 3.x, and State Machine. Commerce Shipping is optional, for the shipment integration mode.
If you run a store where things are made after they are sold (furniture, fashion, print on demand, anything artisanal) we would love to hear how it fits your workflow. The issue queue is open.
18 Jul 2026 11:22am GMT
17 Jul 2026
Drupal.org aggregator
Drupal.org blog: Migrating issues from security.drupal.org to git.drupalcode.org
All security issues have been migrated from the older security.drupal.org site to our GitLab instance at git.drupalcode.org. This is the latest in a series of steps to improve Drupal's coordinated vulnerability disclosure tools. We hope this will help in a few ways:
Merge requests for security issues will get automated testing to increase the quality of the releases. (Previously, tests for core security issues had to be triggered manually, and contrib testing was not available.)
GitLab has more automation to help with advisory creation, reducing manual work.
Powerful features like labels, commenting, and thread reviews on merge requests are now possible for security issues as well.
Here are some of the key steps we took:
- We started by evaluating a few solutions. We decided to use the GitLab instance on drupalcode.org.
- We planned how to remap and improve the current features from security.drupal.org and added some labels and automation to private issues on drupalcode.org.
- We made new security issue reporting default to git.drupalcode.org for several months. This helped us could gain confidence in the system, fix bugs, and make improvements.
- While that happened, Neil Drumm worked to create the migration process.
- The migration finally ran from July 9th to July 12th.
This work is possible because of support from the Drupal Association and is very appreciated.
We suppressed most emails during the migration, but a small number of people did get extra notification emails about issues, including old issues. We apologize for any resulting confusion.
How do I use GitLab to submit and manage security issues?
As before, security reports should be submitted by clicking the "Report a security vulnerability" link on the project page. If a project has already migrated public issues to git.drupalcode.org, you may also mark an issue confidential as you open it. The Security Team triages confidential issues for all covered projects.
For more information about how Drupal.org's GitLab instance works, read our documentation.
You can read about the Security Team's process in general. There is also a page dedicated to managing security issues on git.drupalcode.org. Those pages likely need updates, so please report any documentation issues in the Security Team Queue..
What do you think?
Let us know your thoughts. If you have feedback about how to further improve the Security Team process, you can file them in the Security Team Queue. If you have issues to report about the GitLab tooling itself on git.drupalcode.org, you can file them in the Drupal.org queue.
The old site does a redirect to the new location for issues and members of the Security Team can get content out of it if anyone notices items missing from the migration.
Thanks to longwave, hestenet, dokumori, drumm, and xjm for help in writing this post.
17 Jul 2026 9:50pm GMT
The Drop Times: Three Providers Complete IRAP Assessments for Rules as Code Delivery
Panel access simplifies procurement but does not authorise a deployment. Agencies still need to review the assessment scope, findings, and residual risk against their intended use.
17 Jul 2026 4:06pm GMT
15 Jul 2026
Symfony Blog
SymfonyCon Warsaw 2026: The first 4 speakers are live! 🔥
SymfonyCon Warsaw 2026, our next annual international Symfony conference, will take place on: November 24 & 25 with two days of hands-on workshops to learn, practice, and enhance your skills in small groups. November 26 & 27 with three English-speaking…
15 Jul 2026 8:00am GMT
Symfony UX 3.3.0 released
Symfony UX 3.3.0 is out. This release brings first-class support for Symfony Reprise in StimulusBundle, two new Shadcn components for the Toolkit (Sonner and Combobox), and a batch of quality-of-life improvements to the ux:install command and to how component…
15 Jul 2026 6:17am GMT
13 Jul 2026
Symfony Blog
New SymfonyCasts Course: Upgrading to Symfony 8
One of Symfony's greatest strengths is its upgrade process. Thanks to the backward compatibility promise and deprecation system, major upgrades are smooth, predictable, and, dare I say it, enjoyable! Our newest tutorial is now available - and completely…
13 Jul 2026 7:40pm GMT
01 Apr 2004
Planet PHP
ezSystems are classy folks

Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.
Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!
On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.
01 Apr 2004 6:53pm GMT
PHP april fools...
1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:
1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.
2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.
3. The first PHP virus has been seen.
Wasn't there one last year, too?
4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...
5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!
I guess I missed some, so feel free to comment on this entry, if you found another!
01 Apr 2004 5:49pm GMT
PHP Virus Attacking Web Hosts
Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...
01 Apr 2004 12:19pm GMT