Shopware 6 Revocation Form Missing? A MariaDB Version ID Fix

A critical issue has been identified by the Shopware community, affecting online stores running on MariaDB after updating to Shopware 6.6.10.16, 6.7.9.1, and potentially other versions. The problem manifests as an invisible "revocation request form" (Widerrufsformular), which is crucial for legal compliance in many regions. This community insight details the root cause and provides an actionable SQL fix shared by an expert.

The Invisible Revocation Form: A Persistent Update Bug

Users upgrading their Shopware 6 installations, particularly those migrating from older versions like 6.4, 6.5, or 6.6, have reported that the standard CMS page for revocation requests, titled "Standard Shopseiten-Layout mit Formular für Widerrufsanträge" (Default shop page layout with revocation request form), becomes inaccessible or invisible in the storefront. This isn't just a minor display glitch; it impacts legal obligations for merchants.

Understanding the Root Cause: Version ID Mismatch on MariaDB

The core of the problem lies in a discrepancy with the version_id fields within the Shopware database, specifically affecting MariaDB installations. As highlighted in a GitHub issue (#16592), the default version_id value for MariaDB installations (e.g., 0x0f3f1c3f3f6a4bc2be4b3f3f752c3425) 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 the incorrect version_id, rendering it invisible to the storefront.

The Community-Provided SQL Fix

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 if it's a MariaDB instance, and then updating the problematic version_id fields for the revocation request CMS page and its associated components (translations, sections, and blocks) to the correct LIVE_VERSION constant.

Important: This fix requires SSH access to your server and direct database manipulation. Always back up your database before making any direct changes.

# 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

While this script effectively resolves the immediate problem of the invisible revocation form, the original poster notes that it acts as a patch rather than a fundamental solution to the underlying issue of incorrect default version_id values being set in the database. Nevertheless, for merchants facing this critical compliance issue, this provides an immediate and robust workaround.

Conclusion

The Shopware community continues to be a vital resource for troubleshooting and sharing solutions for complex technical challenges. This specific fix for the invisible revocation request form on MariaDB installations after Shopware 6 updates demonstrates the power of collective expertise in maintaining e-commerce operations. If you've recently updated your Shopware store and are experiencing this problem, applying this database patch could restore your crucial revocation form and ensure legal compliance.