Shopware 6 Revocation Form Missing? The MariaDB Version ID Fix You Need

As an e-commerce expert at Migrate My Store, we understand the critical importance of a fully functional and legally compliant online store. One of the most frustrating issues our clients sometimes encounter after a Shopware 6 update is the mysterious disappearance of essential CMS pages, particularly the 'revocation request form' (Widerrufsformular). This isn't just a minor glitch; it can have significant legal implications for merchants operating in regions with strict consumer protection laws.

Recently, the Shopware community has highlighted a specific, recurring problem affecting stores running on MariaDB after updating to versions like Shopware 6.6.10.16, 6.7.9.1, and potentially others. If your crucial 'Standard Shopseiten-Layout mit Formular für Widerrufsanträge' page has vanished, you're not alone. This comprehensive guide will delve into the root cause and provide an actionable, community-tested SQL fix.

The Invisible Revocation Form: A Persistent Update Bug

Merchants upgrading their Shopware 6 installations, especially those migrating from older versions such as 6.4, 6.5, or 6.6, have reported that the standard CMS page for revocation requests becomes inaccessible or invisible in the storefront. This page is vital for customers to exercise their right of withdrawal, making its absence a serious compliance risk.

Understanding the Root Cause: Version ID Mismatch on MariaDB

The core of this problem lies in a discrepancy with the version_id fields within the Shopware database, specifically affecting MariaDB installations. Shopware uses version_id to manage different versions of content, including CMS pages. As highlighted in a critical GitHub issue (#16592), the default version_id value for MariaDB installations (e.g., 0x0f3f1c3f3f6a4bc2be4b3f3f752c3425) often differs from Shopware's internal LIVE_VERSION constant (0x0fa91ce3e96a4bc2be4bd9ce752c3425).

During certain migrations or updates, the CMS page data for the revocation form is stored with this incorrect, MariaDB-specific version_id. Because Shopware expects the LIVE_VERSION for active content, the page is effectively hidden from the storefront, even though its data still exists in the database.

Who is Affected?

• Shopware 6 installations running on MariaDB.
• Specifically reported in versions 6.6.10.16 and 6.7.9.1.
• Stores that have been updated/migrated from older Shopware 6 versions (e.g., 6.4, 6.5, 6.6).

The Community-Provided SQL Fix: A Step-by-Step Guide

A detailed shell script has been shared by a community member to address this issue directly in the database. This script automates the process of connecting to your Shopware database, identifying the problematic page, and updating the incorrect version_id fields to the correct LIVE_VERSION.

Disclaimer: Manipulating your database directly carries risks. Always perform a full backup of your database and files before proceeding. If you are unsure, please consult with a professional Shopware developer or a migration expert like Migrate My Store.

Prerequisites:

• SSH access to your Shopware server.
• Basic understanding of shell commands.
• Database credentials (usually found in your .env.local file).

The SQL Patch Script:

Save the following code as a .sh file (e.g., fix_revocation_form.sh) in your Shopware root directory (e.g., /var/www/html/).

# Default variables
ENV_FILE=".env.local"

# Connect to db
DB_INITIALIZED=0
init_db_connection() {
    if [ "$DB_INITIALIZED" -eq 1 ]; then
        return
    fi

    if [ ! -f "$ENV_FILE" ]; then
        echo "❌ $ENV_FILE not found"
        exit 1
    fi

    DATABASE_URL=$(grep '^DATABASE_URL=' "$ENV_FILE" | cut -d '=' -f2-)

    # Remove surrounding quotes from .env value
    DATABASE_URL="${DATABASE_URL%"}"
    DATABASE_URL="${DATABASE_URL#"}"
    DATABASE_URL="${DATABASE_URL%\'}"
    DATABASE_URL="${DATABASE_URL#\'}"

    if [ -z "$DATABASE_URL" ]; then
        echo "❌ DATABASE_URL not found in $ENV_FILE"
        exit 1
    }

    # Split URL
    local CREDS_HOST_DB
    CREDS_HOST_DB=$(echo "$DATABASE_URL" | sed 's|.*://||')

    USER=$(echo "$CREDS_HOST_DB" | cut -d: -f1)
    PASS=$(echo "$CREDS_HOST_DB" | cut -d: -f2 | cut -d@ -f1)
    HOST=$(echo "$CREDS_HOST_DB" | cut -d@ -f2 | cut -d/ -f1)
    DB=$(echo "$CREDS_HOST_DB" | cut -d/ -f2)

    # Port optional
    PORT=$(echo "$HOST" | grep -o ':[0-9]*' | tr -d ':')
    HOST=$(echo "$HOST" | cut -d: -f1)
    PORT=${PORT:-3306}

    # Url decode
    PASS=$(printf '%b' "${PASS//%/\x}")
    USER=$(printf '%b' "${USER//%/\x}")
    DB=$(printf '%b' "${DB//%/\x}")

    # Detect and validate the database type (MySQL or MariaDB) and store it in DBTYPE
    DBTYPE=""
    db_versi -h "$HOST" -P "$PORT" -u "$USER" -p"$PASS" -e "SHOW VARIABLES LIKE 'version_comment';" 2>/dev/null | tail -n 1)
    if echo "$db_version_comment" | grep -iq "mariadb"; then
        DBTYPE="mariadb"
        echo "Detected database type: MariaDB"
    elif echo "$db_version_comment" | grep -iq "mysql"; then
        DBTYPE="mysql"
        echo "Detected database type: MySQL"
    else
        echo "$db_version_comment"
        echo "❌ Error: Incorrect db type or db credentials are wrong! Allowed db types are: MySQL and MariaDB"
        exit 1
    fi

    echo "🔌 DB ready: $DB@$HOST:$PORT (User: $USER)"
    DB_INITIALIZED=1
}

# Fix for revocation request form: 6.6.10.14 to 6.7.0.0 and from 6.7.9.0
init_db_connection
if [ "$DBTYPE" == "mariadb" ]; then
    echo "🩹 Patch db because of maria db problem with revocation request form"
    VERSI # Constant LIVE_VERSION from /var/www/html/vendor/shopware/core/Defaults.php

    # Get cms_page_id for the desired page
    SQL_SELECT="SELECT cms_page_id FROM cms_page_translation WHERE name = 'Standard Shopseiten-Layout mit Formular für Widerrufsanträge';"
    PAGE_ID=$(mysql -h "$HOST" -P "$PORT" -u "$USER" -p"$PASS" "$DB" -N -B -e "$SQL_SELECT")
    if [ -z "$PAGE_ID" ]; then
        echo "❌ No cms_page_id found for the desired page."
    else
        SQL_UPDATE="
        UPDATE cms_page SET versi WHERE id = '$PAGE_ID';
        UPDATE cms_page_translation SET cms_page_versi WHERE cms_page_id = '$PAGE_ID';
        UPDATE cms_section SET versi cms_page_versi WHERE cms_page_id = '$PAGE_ID';
        "
        mysql -h "$HOST" -P "$PORT" -u "$USER" -p"$PASS" "$DB" -e "$SQL_UPDATE"
        # Get cms_section_id for the desired page
        SQL_SELECT="SELECT id FROM cms_section WHERE cms_page_id = '$PAGE_ID';"
        SECTI -h "$HOST" -P "$PORT" -u "$USER" -p"$PASS" "$DB" -N -B -e "$SQL_SELECT")
        if [ -z "$SECTION_ID" ]; then
            echo "❌ No cms_section_id found for the desired page."
        else
            SQL_UPDATE="UPDATE cms_block SET versi WHERE cms_secti;"
            mysql -h "$HOST" -P "$PORT" -u "$USER" -p"$PASS" "$DB" -e "$SQL_UPDATE"
            echo "✅ Patch applied successfully."
        fi
    fi
fi

How the Script Works:

1. Database Connection: It reads your DATABASE_URL from .env.local to establish a connection to your MariaDB instance.
2. MariaDB Detection: It verifies that your database is indeed MariaDB, as this fix is specific to that environment.
3. Page Identification: It queries the cms_page_translation table to find the cms_page_id for the page named 'Standard Shopseiten-Layout mit Formular für Widerrufsanträge'.
4. Version ID Update: If the page is found, it updates the version_id fields in cms_page, cms_page_translation, cms_section, and cms_block tables for that specific CMS page to match Shopware's LIVE_VERSION constant (0x0fa91ce3e96a4bc2be4bd9ce752c3425).

Executing the Fix:

1. Upload the fix_revocation_form.sh file to your Shopware root directory via SSH/SFTP.
2. Connect to your server via SSH.
3. Navigate to your Shopware root directory (e.g., cd /var/www/html/).
4. Make the script executable: chmod +x fix_revocation_form.sh
5. Run the script: ./fix_revocation_form.sh
6. Monitor the output for success messages or errors.
7. After successful execution, clear your Shopware cache: bin/console cache:clear
8. Verify in your Shopware admin panel and storefront that the revocation form is now visible and functional.

Beyond the Fix: Understanding the Underlying Issue

While this script provides an effective patch, it's crucial to understand that it addresses the symptom rather than the root cause. The community discussion indicates that the fundamental problem lies with incorrect default values for version_id fields being set in the database during certain migration processes on MariaDB. This suggests a deeper issue within Shopware's migration scripts or database schema definitions for MariaDB environments.

We recommend monitoring the official Shopware GitHub repository and release notes for a permanent fix from Shopware itself. Until then, this community-provided script remains a vital tool for merchants facing this specific challenge.

Preventative Measures and Best Practices

To minimize the risk of encountering such issues during future updates:

• Always Backup: Before any major update or migration, perform a full backup of your Shopware installation (files and database).
• Staging Environment: Test all updates in a dedicated staging environment that mirrors your live setup. This allows you to identify and resolve issues without impacting your customers.
• Stay Informed: Regularly check the Shopware forums, GitHub issues, and official documentation for known bugs and solutions.
• Professional Assistance: For complex updates or migrations, consider engaging with experienced Shopware developers or migration experts. Services like Migrate My Store specialize in ensuring smooth transitions and resolving post-update challenges.

Conclusion

The invisible revocation request form bug in Shopware 6 on MariaDB can be a significant headache for e-commerce businesses. By understanding the version_id mismatch and applying the provided SQL fix, you can restore this critical functionality and maintain legal compliance. While this patch is effective, staying vigilant and adopting best practices for updates will safeguard your store against future unforeseen issues.

If you're struggling with this or any other Shopware migration or update challenge, don't hesitate to reach out to the experts at Migrate My Store. We're here to ensure your e-commerce platform runs flawlessly.