PrestaShop / PrestaShop/docker
installation is triggered at every container start
Nobody has claimed this yet.
- Dominant language
- Dockerfile
- Stars
- 281
- Forks
- 190
- PR merge metrics
- No merged PRs in 30d
Description
Hi I'm trying to use a dockerised prestashop from an existing install.
Since I work on custom theme, modules and probably overrides I would like to persist /var/www/html.
I have my existing database running, but every time I start prestashop it triggers the installer.
The first time is ok I guess because it has to create files.
Then the next times, prestashop will create an install.lock file and will fail to get over the installation because the admin Backoffice directory is not empty.
Then it will run into this Another setup is currently running issue.
I bind /var/www/html to a local directory :
volumes:
- type: bind
source: ./src
target: /var/www/html
environment:
- PS_DEV_MODE=0
- PS_INSTALL_AUTO=0
- TZ
- DB_SERVER=db
- DB_NAME=${MYSQL_DATABASE}
- DB_USER=${MYSQL_USER}
- DB_PASSWORD=${MYSQL_PASSWORD}
- DB_PREFIX=prstshp_
- PS_ALL_LANGUAGES=1
- PS_FOLDER_ADMIN=Backoffice
- PS_ENABLE_SSL=0
Unfortunately the PS_INSTALL_AUTO doesn't seem to do anything.
I don't see what triggers the installation and how to disable it, based on the doc I could find :
https://devdocs.prestashop-project.org/8/basics/installation/environments/docker/
What would be the way to totally disable the installer ?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Docker installation environments documentation linked in the issue, then trace how PS_INSTALL_AUTO, the /var/www/html bind mount, and install.lock are handled at container startup. Reproduce the behavior with the shown volume and environment, and consider the issue complete when an existing install starts without rerunning setup or reporting the Backoffice and “Another setup is currently running” errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100