I built a CLI tool to manage DDEV projects — started as a few lines of bash, ended up as something I'm actually proud of

A while ago I started writing a small bash script to avoid retyping the same DDEV commands over and over. It was maybe 50 lines, just a simple menu to start and stop projects.

Over time it grew. Then I decided to push it properly and turn it into something worth sharing.

The result is ddm (DDevManager) — a bash CLI tool that manages DDEV environments with one-click installations for 25 platforms: WordPress, Drupal, Joomla, TYPO3, Laravel, Symfony, CakePHP, PrestaShop, Moodle, and more.

What it does: - One-command install for 25 CMS/frameworks (fully automated, browser-ready) - Smart dependency checks on startup — Docker, DDEV, and required CLI tools - Docker group and service setup in a single pass - Auto-update system (checks weekly, updates ddm and DDEV) - Project management: start, stop, restart, SSH, wipe DB, delete - Optional Adminer or phpMyAdmin per project - Tools menu: Docker cleaner, delete all, nuclear reset - Works on Arch, Debian/Ubuntu, Fedora/RHEL

Install and run: curl -fsSL https://raw.githubusercontent.com/SalvatoreNoschese/ddm/main/ddm -o ddm && bash ddm No root required. On first run it sets up PATH and everything else automatically.

Honest notes: I'm not a professional developer — this is a personal tool that got out of hand in the best way. I got a lot of help from Claude (AI) during development, especially for bash patterns, edge cases, and code organization. The banner image was generated by Gemini. The code is mine, the ideas are mine, but I'd be lying if I said I did it all alone.

If you use DDEV regularly and are tired of repeating the same setup steps, give it a try.

Repo: https://github.com/SalvatoreNoschese/ddm

Feedback and contributions welcome.

Hi everyone,

I'm testing Drupal CMS 2 (currently in beta) with the Byte theme, but I can't get comments to display on blog posts.

I've already checked: - Content type comment settings (enabled and set to "Open") - User permissions (view/post comments enabled) - Display management (comments field not hidden) - Cleared all caches

With Drupal Core everything works out of the box, but with CMS 2 I'm running into issues that are difficult to troubleshoot.

Questions: - Has anyone managed to get comments working in Byte theme? - Is this a known bug in the beta version? - Is it worth waiting for stable release, or better to stick with Core and customize it?

I was hoping CMS 2 with Canvas would be a game-changer, but so far it's not meeting expectations. That said, the overall approach seems very promising as a starting point for projects.

Thanks for any help!

Update: Today I tried CMS 2 RC1 with both Byte and Starter themes.

Tried to remove Canvas and install Olivero, but it's far from simple.

At this point, I believe it's better to start with Drupal Core and just install a few useful recipes (like admin_ui and media) to replicate what worked in CMS 1.

CMS 2 remains too opinionated and ironically limited: even though it includes a Blog content type, the comment system still doesn't work properly out of the box.

My conclusion: For a functional, flexible blog with multilingual support and working comments, Drupal Core + selective recipes is the most reliable path forward ATM.

Update 2: The issue has been officially acknowledged by Drupal staff!

A core maintainer (@catch) opened an official issue on Drupal.org referencing this discussion: https://www.drupal.org/project/canvas/issues/3568579

Key findings: - Confirmed: Canvas has no SDC component for comments, making them unsupported - The problem is that there's no way to know comments aren't available except by trial and error - Proposed solution: Add support for Field Blocks as an "escape hatch" for use cases like comments

At least the issue is now officially documented and being tracked. However, no immediate fix or timeline yet.

🤞🤞🤞

Hi everyone,

I'm trying to migrate content from a WordPress site to a fresh Drupal 11 installation using the contributed wordpress_migrate module (the UI/GUI process).

I'm running into an issue where the module's setup UI fails to detect my destination fields, likely because my Drupal structure uses modern, non-standard field types (Media Entity Reference) and custom machine names, while the module expects the old default settings.

I need advice on the correct YAML configuration to manually map these fields.

1. 📝 Body Field Issue

The WordPress content body (content:encoded) is not being recognized for import.

• Drupal Destination Field Name: field_content
• Drupal Field Type: Text (formatted, long)
• Expected Field Type (by Module): Likely the standard body field with type Text (formatted, long, with summary).

Goal: How should I structure the process: section in my migrate.migration.wordpress_post.yml to map content:encoded to my existing field field_content?

2. 🖼 Featured Image Issue (Crucial: Media Entity)

I cannot map the WordPress Featured Image because my Drupal setup uses the modern Media Entity reference approach.

• Drupal Destination Field Name: field_featured_image
• Drupal Field Type: Entity reference (Referencing Media Entity of type Image).
• Expected Field Type (by Module): Likely a basic Image file field type.

Goal: What is the recommended multi-step process: pipeline (using file_copy, entity_generate, or migration_lookup) to take the WordPress image URL, create a Media Entity in Drupal, and reference it in my field_featured_image field? Working YAML examples for migrating WXR attachments to Media Entities would be highly appreciated!

3. 💬 Comments Migration

The WXR file contains comment data. Is there any hope to migrate comments (users, body, timestamps) to the native Drupal comments using the wordpress_migrate module or does this typically require another separate migration definition?

Thanks!