Existing database being modified by initialisation
tomnason opened this issue · 12 comments
When bringing the container up for the first time it always initialises the database, even if already present.
On initial docker-compose up:
I import a database structure, posts, settings etc when mariadb initialises via /docker-entrypoint-initdb.d
The wordpress container then comes up and connects to mysql, finds the database, sets up its own user, creates "hello world" posts and reverts many of the settings I'd provided in the sql dump above. The posts remain in place (plus the new hello world one), and the correct theme is active, but other than that it's largely broken as it changes
This occurs even regardless of whether I pass in existing credentials to:
WORDPRESS_USERNAME
WORDPRESS_PASSWORD
Is this intentional?
What triggers the initialisation sequence, and is there a way to stop it?
The readme implies that use of an existing database is possible.
Hi,
I the readme is not well explained. The first time the container it is initialized, it would try to do the following:
- Initialize database
- Enable the memached extension
- Set permalinks
- Enable the admin user
- Configure SMTP (if necessary)
- Configure opcache
- Execute the Wordpress initialization
After that, it will create a .initialized in /bitnami/wordpress. The container, when initializing for the second time, will check if that file exists. If it does, then just execute the upgrade logic.
So, in your case, even if you have a database with the WordPress data already set, it will do the initialization because the initialized file is not in /bitnami/wordpress. I think it would be interesting to allow use cases like yours (maybe with an environment variable). For the time being, what you could do is perform the migration after the initialization of WordPress is completed. This is how I currently do in my WordPress deployments. In any case, we will study your use case and consider it for future releases of the image.
So, when we say that an existing database can be used, we mean an existing MariaDB/MySQL instance (so you don't have to create one using the docker-compose file). However, if there was a WordPress DB inside the instance, it would be overwritten.
This makes sense. I'll work around it for now.
Moving forward I think an environment variable to prevent DB initialisation would be great.
Something like:
MARIADB_HOST
MARIADB_PORT_NUMBER
WORDPRESS_DATABASE_NAME
WORDPRESS_DATABASE_USER
WORDPRESS_DATABASE_PASSWORD
WORDPRESS_DATABASE_INIT=false
And this would then ignore the following and just connect to the existing db, bypassing the usual database initialisation, user creation, permalink settings etc.
WORDPRESS_USERNAME
WORDPRESS_PASSWORD
WORDPRESS_EMAIL
WORDPRESS_FIRST_NAME
WORDPRESS_LAST_NAME
WORDPRESS_BLOG_NAME
Hi,
Thanks for the feedback! :) We will evaluate for future releases
Same problem here, it is quite strange that such a common scenario is not handled by default.
Thanks for the feedback @paolomainardi, as mentioned, we will evaluate it for future releases. Could you elaborate more about the use case in your company?
A migration of an existing application to Kubernetes, where the Mariadb docker image contained into /docker-entrypoint-initdb.d the db dump to be loaded at the first run, which is then erased by bitnami wordpress container, this scenario can be also applied in a CI/CD enviroment of developments apps where the database is the result of a wordpress automated build and you want to deploy it in a review environment in automatic fashion.
Thanks @javsalgar i hope to have cleared a bit the possible use cases.
Thank you very much for your feedback, we'll work on figuring out the best approach for this use case.
I created a PR that covers your use case helm/charts#12948
This PR must be on hold until we release the container with the new variable.
Thanks a lot @javsalgar i saw that has been already merged, I’ll try it soon!
Please let us know if you find any issue. I'm closing this for the time being. Do not hesitate to reopen if something goes wrong