Article view

✅ 1. Stop the project first

ddev stop

✅ 2. Clean the project directory (files)

rm -rf ~/projects/projectname/*

or

rm -rf web/ vendor/ composer.json composer.lock

check if .ddev is still present
ls -a

✅ 3. Extract production files

unzip /mnt/d/drupal/sites/CUST/customer/projectname.zip -d ~/projects/projectname
or
tar -xvzf /mnt/d/drupal/sites/CUST/customer/projectname.tar.gz -C ~/projects/projectname

✅ 4. Start DDEV

ddev start

✅ 5. Import the production database

ddev import-db --file=/mnt/d/drupal/sites/CUST/customer//projectname.sql

✅ 6. Rebuild dependencies (important!)

rm -rf vendor
ddev composer install

✅ 7. Clear Drupal caches (mandatory)

ddev drush cr

The symptom was that the frontpage which only contained the default node view was empty. The nodes themselves were working, all the other parts of the website like main menu, footer etc too.
The problem was related to permission issues with drush. Those showed when executing

ddev drush cr

failed with a respective error.

The way to fix this fast, is:

rm -rf vendor 
ddev composer install

Sometimes drush cr does not work. A possible root for the issue could be the shebang

Check the shebang to confirm if the ^M is there:

ddev exec bash -lc 'head -1 vendor/bin/drush | cat -A' 

You should now see:

#!/usr/bin/env php$

If it shows ^M at the end, use Perl to convert CRLF → LF for the wrapper and make it executable:

ddev exec bash -lc "perl -pi -e 's/\r\n/\n/g' vendor/bin/drush && chmod +x vendor/

After this check the shebang again if the ^M is gone now.
If so try again to clear the cache by

ddev drush cr

✅ Best Practices für die Tab-Reihenfolge (Tab Order) einer barrierefreien Website

Die goldene Regel:
Die Tabreihenfolge muss der logischen, visuellen und semantischen Reihenfolge des Inhalts folgen.
Kurz: So wie du die Seite liest, so soll sie sich auch tabben lassen.

Die wichtigsten Grundsätze:

1. Natürliche Reihenfolge durch HTML-Struktur

Die Tabreihenfolge entsteht automatisch durch:

• den DOM (Document Object Model)
• alle fokussierbaren Elemente (<a>, <button>, <input>, etc.)

➡️ Der Browser macht es automatisch richtig, wenn der Code logisch aufgebaut ist.
Beste Lösung: Nicht eingreifen, sondern den HTML-Aufbau sauber halten.

2. Finger weg von tabindex – außer sinnvoll!

tabindex ist wie Chili:
Ein kleines bisschen ist toll – zu viel ruiniert dir das Gericht.

Gut:

• tabindex="0" → macht ein Element fokussierbar, reiht es aber korrekt in die Tabfolge ein
  (z. B. für Custom Controls)

Schlecht:

• tabindex="1" oder höher → erzwingt eine künstliche Tabreihenfolge
  (führt fast immer zu Chaos)

Verbotene Zone:

• Massive Nutzung von tabindex zum “Umsortieren” der Seite.
  Das bricht Barrierefreiheit komplett.

3. Fokus nur auf Interaktives

Tab folgt nur Elementen, die bedienbar sind:

• Links
• Buttons
• Formulare
• Custom Controls (mit ARIA)

NICHT deberían fokussierbar sein:

• Divs
• Überschriften
• Icons
  … außer sie sind tatsächlich interaktiv.

4. Sichtbarer Fokus ist Pflicht

→ Nutzer:innen müssen sehen, wo sie gerade sind.
(Standard-Fokus nicht entfernen – oder eigenen sichtbaren Stil definieren.)

5. Modale Dialoge oder Overlays

• Beim Öffnen → Fokus springt in das Modal
• Beim Schließen → Fokus zurück zum auslösenden Element
• Elemente außerhalb des Modals → nicht tabbar (durch Focus Trap)

6. Skip-Link am Seitenanfang

Ein “skip to content”-Link ist Standard-Barrierefreiheit.

<a href="#main" class="skip-link">Zum Inhalt springen</a>

🔧 Wie wird die Tabreihenfolge definiert?

1. Durch die Position im DOM (natürliche Reihenfolge)

Der wichtigste Punkt:
Alles, was im DOM steht, wird in dieser Reihenfolge getabbt.

Beispiel:

<a href="/start">Start</a> <button>Login</button> <input type="text">

→ Tab springt genau in dieser Reihenfolge.

2. Durch tabindex (sparsam einsetzen!)

• tabindex="0"
  → Element wird in natürlicher Reihenfolge fokussierbar gemacht
• tabindex="-1"
  → Element ist fokussierbar, aber nicht tabbar
  (z. B. für Fokus per JavaScript)
• tabindex="1" oder höher
  → Tab-Hölle.
  Verschiebt Elemente künstlich nach vorne.

🧪 Perfekter Workflow für barrierefreie Tab-Navigation

1. HTML logisch aufbauen (Header → Nav → Main → Footer)
2. Interaktive Elemente semantisch korrekt nutzen
   („Button bleibt Button“ – nicht „div mit Click-Listener“)
3. Tabindex nur für Custom Controls
4. Fokus-Stile nicht entfernen
5. Keyboard-Test durchführen:
   • Tab vorwärts
   • Shift+Tab rückwärts
   • Enter/Space testen
   • Escape (für modale Dialoge)
6. Screenreader kurz checken (NVDA, VoiceOver)

Und ja, das Keyboard ist gnadenlos ehrlich — wenn es dort funktioniert, ist die Seite meist gut gebaut.

composer require drupal/core-recommended:"11.2.5" drupal/core-composer-scaffold:"11.2.5" drupal/core-project-message:"11.2.5" --with-all-dependencies

ddev composer require drupal/core-recommended:11.2.6 drupal/core-composer-scaffold:11.2.6 drupal/core-project-message:11.2.6 --with-all-dependencies
ddev composer require drupal/core-recommended:11.2.6 drupal/core-composer-scaffold:11.2.6 drupal/core-project-message:11.2.6 --W

ddev composer update drupal/core-* --with-all-dependencies

ddev composer update drupal/core-* -W

unzip /mnt/d/drupal/sites/CUST/projectname/backups/instance/filename.zip -d ~/projects/projectname

or

tar -xf /mnt/d/drupal/sites/CUST/projectname/backups/instance/filename.tar.zip -C ~/projects/projectnam

rm -rfv ~/projects/projectname/*

sass --watch sass:css --style=expanded --source-map