Setting up Dev environment locally from Production Shopware 6.6

Shopware 6 (English)
1

Hi Everyone,

I just took over a shopware 6.6 project,
since I was tasked to make some visual changes (new css, new component) on the a custom-theme, I need to make a copy of my production shopware 6.6 (self-hosted)
So I can do the development locally, and push to staging and later to prod easily.

I followed the normal steps

  • Download all files
  • Export .sql file

The problem is,
when I tried to import it I always issue with the
'json_object() CHECK (json_valid ...
and the whole sql import failed because of that

I have tried:

  • installing the same db specification locally (I am using mariadb on prod, and the same mariadb version locally) same error persisted.
  • trying to manually remove the CHECK from each of 'json_object() CHECK (json_valid ...
    but still same issue re-appear

As a context

  • I am using OSX, and manage all the library using homebrew (so no docker)
  • my production server is Ubuntu from ALL-INKL and using MariaDB 10.11.
  • the production shopware was installed on the cloud manually, no git repo etc, so I will set it up later.

It’s been quite some hours to fix this import issue, but I couldn’t find a way to solve this.

I was thinking about switching to container-based local installation, but since my experience on using docker is limited, I still try to use my regular development setup.

  • Does anyone know how to fix the import issue with Json type column?
  • is there any more practical way to setup dev environment from production environment?

p.s.
I came from Laravel ecosystem, with some Symfony experience.
which dev environment setup is pretty much straight-forward
So, I still need to adapt with development workflow with symfony-shopware development.

2

ChatGPT tells me:

The error you’re encountering is likely due to a CHECK constraint using JSON_OBJECT() in a MariaDB version that doesn’t support it properly within constraints.

  • In MariaDB , unlike MySQL, CHECK constraints are parsed but not enforced before 10.2.1 , and only partially supported in later versions .
  • JSON_OBJECT() is a function, and many MariaDB versions (even ≥10.4) do not allow functions inside CHECK constraints.

Did you check the MariaDB version?

3

I tried some recommendation from copilot (chatgpt and claude)
both didn’t resolve the SQL import issue really, but I might need to make another attempt

my local is:

  • mysql Ver 15.1 Distrib 10.11.13-MariaDB, for osx10.20 (arm64)

and my production

  • Server type: MariaDB
  • Server version: 10.11.13-MariaDB-0ubuntu0.24.04.1-log - Ubuntu 24.04

Do you work with dev environment locally?
if yes, can you please share your setup and workflow briefly?

4

The SQL problem is less a Symfony/Shopware problem, it is more a database problem in general.

Changing between database manufacturer (MariaDB/MySQL) and/or versions can always be challenging.

I do not work with a „production“ database locally, thus I never had an issue.

Here are the recommended setups: Installation Overview | Shopware Documentation

The solution to your problem: you might could remove the CHECKS from the queries before importing it. Then MariaDB should not fail anymore. Or maybe Shopware CLI | Shopware Documentation

5

I’ve tried remove all the CHECKS, although it fixed the json() type column import, but it led to different error, and it kinda quick-fix and I want to avoid that,

The only thing I would like to reproduce locally is the layout of my production site,
So I can make some new component/css, etc locally before I can push the change to production environment

I could install a fresh shopware 6.6
but how can I get the data for the CMS layout, media, etc?

can I export it via export feature? and import it manually to development database?

Is there anyway to export only the CMS layout data and the product from production site (from admin page for example)

6

I do not know any tool for export and import CMS pages. There is a plugin in the store to copy them, but I guess it is only for the same installation.

Maybe you could dump the database in an older safe sql query without all the new implementations? Or install the exact same database on your local environment.