Once I added all missing plugins, I was also able to add the plugin that previously would not load (because of the 2M limit).
In summary, your last solution works just fine and I am not sure why all of my plugins disappeared. If you have any explanation for this, it would make me very happy.
I think the best thing for you would be to mount that file from outside of the container.
I would do t he same with plugin directory, so you won’t loose those either.
You can find more details about mounting files from outside of the container in “volumes” section of compose documentation.
I tried another method of modifying the uploads by a config file addition to the /var/www/html directory with a volume mount of the file. The directory was overwritten by the PHP initialization and the file was gone.
I think I might know what happened to your Plugins.
The Plugins were installed in a file system in the PHP container file system I’m thinking.
PHP might have set some entries in the MySQL database indicating the Plugins were installed.
You brought down the stack with docker-compose down but you did not specify the -v argument which tells docker to remove the persistent volume (for the MySQL database). So the MySQL database was not deleted. You brought the stack back up with docker-compose up. The MySQL server will use the same database as it’s still on the persistent volume. Wordpress came up, queried the MySQL database, found out that Plugins were previously installed but were no longer in the wordpress container filesystem as a brand new container was launched. The Wordpress docker image does have a volume for /var/www/html but unless it is mounted in the docker-compose.yml file, that directory does not persist.
That is the same conclusion I came up with before reading your post. The added plugins (added after the wordpress image was built) are indeed stored on the file system (see Beginner's Guide to WordPress File and Directory Structure) and will be lost on each “docker compose” run. This same article mentions the following very relevant facts:
Some of these folders may contain important files. Like the gallery folder may contain your gallery images. You should always backup such folders to avoid losing important data.
Other folders may contain files that you can safely delete. For example your caching plugins like W3 Total Cache or WP Super Cache may store cached files in their own folders.
So, my question is this: does the modified docker-compose.yml with added
volumes:
- php_data:/var/www/html
cover all cases of modifyng the running containers (adding plugins, themes, etc)?
which you introduced above is not taking care of the /usr/local/etc/php/conf.d folder.
Note that I am not nitpicking here - my intent is to finish this discussion in a way that will provide the good solution for anyone who decides to use Docker to install wordpress.
Try increasing the value to what you think you want the maximum to be for your Wordpress site.
Below is for 1024M. I’m pretty sure the value has to be in megabytes.
I believe that you misunderstood my today’s remark, so I will restate it this way: the file /usr/local/etc/php/conf.d/uploads.ini should also be persisted the same way as the folder /var/www/html
I think for the /usr/local/etc/php directory, the better wording is to have it exposed as a volume so you can do a bind mount and specify overrides. Nothing in that directory is modified at run time so no need for you to define it on an external volume and make it persistent.
Tell them you want the Docker Official Wordpress Docker Image to expose the /usr/local/etc/php directory as a volume mount point so you (and other users) can bind mount your own customization files at container run time.
Very good observation (Nothing in that directory is modified at run time), @gforghetti
I stand corrected and grateful for your time spent helping me to resolve my problem. The good side-effect is that this solution will help many other folks that undoubtedly follow.
I created this issue at the suggested GitHub repo and will update this thread once that issue gets resolved.
Yes, that looks good and no need for you to build a custom docker image. I had tried that previously and it did not work for me. I probably had a typo on the target side of the mount.
Find the PHP.ini file in root directory.If you not see the file select the option “Show hidden files” then the PHP.ini file will be visible. After that add this code in PHP.ini
Hi gary use this docker-compose.yml file and in same folder create two folder with name “database” and “html” and one file name “uploads.ini”
fire up the compose file