Share and learn in the Docker community.
That undoes your change.
The docker-compose down removes the containers and you loose your change.
The docker-compose up -d bring up new containers.
Keep the stack up.
Make the change again.
Do not “bring the stack down and back up” with docker-compose.
Refresh your browser to see if it works.
Let me know the outcome.
Then if it works, I’ll show you how to make it “permanent” when you bring up the stack.
Yes, the “down, up” sequence is destructive, so I lost my container with the modified .htaccess file. I did that because trying to run wordpress right after changing the .htaccess file resulted with the server error with some very generic error message.
I suspect that my editing the .htaccess file with nano caused the crash since for some unknown reason I was not able to insert a new line - nano behaved as if it is in the “overwrite mode”.
Would it not be better to create a modified wordpress image before running the “docker compose” and then change the YAML file and run the “docker compose” which uses this modified wordpress image?
This modified wordpress image could be alse created a bit less lean, to include nano editor for example
I think the best place is to put that in the php.ini file. But I don’t see it. So I need to figure out where it should go and then proceed from there. Give me a few minutes.
That was my plan that I did not mention to you as I was also not able to find php.ini. It seems that the https://github.com/docker-library/owncloud/issues/99 addresses this.
Also, the discussion at https://github.com/docker-library/wordpress/issues/10 might offer a complete solution. If you agree, then you may consider adding the “cleaned out” text from that discussion to the page at https://docs.docker.com/compose/wordpress/
Without having read the hole thread:
Sometimes when I deal with broken entrypoint-scripts or configuration files, I tend to copy the broken files from the container to the docker host, fix them and remount them as a volume to the container.
docker cp {containername/id}:/path/inside/the/container/file /hostpath/file
This was one of the approaches in that long thread, which several people criticised. Since the original article is used as the introduction into docker compose and because the wordpress image always ships with the default limit for the upload size, I would think that the 2 solutions proposed by @NaveenKharwar might be a better approach.
Let’s see what @gforghetti comes up with expanding on his message above
I went with the uploads.ini route with a custom Docker image.
Dockerfile
FROM wordpress:latest
RUN touch /usr/local/etc/php/conf.d/uploads.ini \
&& echo "upload_max_filesize = 10M;" >> /usr/local/etc/php/conf.d/uploads.ini
You should change gforghetti to your Docker ID
docker image build -t gforghetti/wordpress:latest .
Then replace the wordpress image in the docker-compose.yml file with the custom image.
Bring up the stack and see if it works.
Final status update
The line docker image build -t gforghetti/wordpress:latest . is incorrect - (the word image should be removed), so the correct version is:
docker build -t gforghetti/wordpress:latest .
(I used a different tag, of course).
When I started this new app via docker compose, I found this situation:
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.
Thanks for all efforts spent on this!
Hi.
Glad to see you got it working.
No idea why your plugins disappeared.
You must be running an old version of Docker. Docker 1.12?
docker image build works fine starting with Docker 1.13 and is the preferred syntax.
docker build still works though.
Docker restructured the commands and added “sub-commands” in Docker Version 1.13.
Look for CLI restructured in the link below.
Then Docker changed it’s versioning scheme and went to yy.mm.
The next version after 1.13 became 17.03. (i.e. 2017 March).
$ docker image build -t gforghetti/wordpress:latest .
Sending build context to Docker daemon 18.43kB
Step 1/2 : FROM wordpress:latest
latest: Pulling from library/wordpress
6ae821421a7d: Pull complete
08f3d19635b0: Pull complete
dc8a54b8000b: Pull complete
b2c1d103db99: Pull complete
edfa752aa38a: Pull complete
583d37cbf2f0: Pull complete
c7846a240c1d: Pull complete
d8f9f0fd02fe: Pull complete
01d43e56770d: Pull complete
dbe439e2caf9: Pull complete
3de30e1f5211: Pull complete
209dd35ef060: Pull complete
3d97847926b1: Pull complete
e2dfaa5afe2c: Pull complete
c39665b60f96: Pull complete
f36ef5821516: Pull complete
c96693ff91d0: Pull complete
2e00dc04ad85: Pull complete
Digest: sha256:3a71e9cc138f936d5eda53b776dff9f2630daeaab023e8ba506faa75fec98073
Status: Downloaded newer image for wordpress:latest
---> 7539ce0f28d0
Step 2/2 : RUN touch /usr/local/etc/php/conf.d/uploads.ini && echo "upload_max_filesize = 10M;" >> /usr/local/etc/php/conf.d/uploads.ini
---> Running in b3319a465fc2
Removing intermediate container b3319a465fc2
---> c92ea6d743fb
Successfully built c92ea6d743fb
Successfully tagged gforghetti/wordpress:latest
🐳 gforghetti:[~/Vagrants/Docker-EE-UCP-Cluster/Docker_Apps/Linux/Wordpress] $
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.
Sincerely,
Grzegorz
I tried that. The directory /usr/local/etc/php is not defined as a volume in the wordpress default Dockerfile so no way to add that.
$ docker image inspect wordpress:latest --format '{{.Config.Volumes}}'
map[/var/www/html:{}]
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.
Yes, Wordpress/PHP stores data in the /var/www/html directory.
I modified my copy of the docker-compose.yml file to add a volume and mount for that directory so it persists.
docker-compose.yml
version: '3.4'
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: gforghetti/wordpress:latest
volumes:
- php_data:/var/www/html
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
db_data: {}
php_data: {}
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 https://www.wpbeginner.com/beginners-guide/beginners-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)?
Yes, that volume is persisting the Wordpress root directory /var/www/html.
Hi @gforghetti
The added data to the YAML file is not sufficient, as the new limit for uploads set as
RUN touch /usr/local/etc/php/conf.d/uploads.ini \
&& echo "upload_max_filesize = 10M;" >> /usr/local/etc/php/conf.d/uploads.ini
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.
upload_max_filesize = 1024M
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
Making sense?
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.
You can open a GitHub issue here -> https://github.com/docker-library/wordpress/issues
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.