I am happily running WordPress on my Windows 10 machine, using Docker Compose as described in https://docs.docker.com/compose/wordpress/ article. However, installing some plugins results with the error message The uploaded file exceeds the upload_max_filesize directive in php.ini..
The question is how to access the php.ini files in this context. Most likely I need to modify the YAML file so that I get hold of the console in the running container where I could use the nano editor modify the php.ini file.
Is anyone willing to explain the details, please?
Discovered the explanation in https://forums.docker.com/t/run-docker-exec-in-compose-file/68944 written by @gforghetti, a few minutes after I wrote my post. It seems that it can be used in the context of my issue as well. @gforghetti is this true?
đł gforghetti:[~/Downloads] $ docker container ls --filter name='_wordpress'
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9ddd9bded663 wordpress:latest "docker-entrypoint.sâŠ" 27 minutes ago Up 26 minutes
0.0.0.0:8000->80/tcp downloads_wordpress_1
Run the command below, replace the 9ddd9bded663 with your wordpress container ID.
Thanks, @gforghetti for such instant response (I am still amazed )
You got me going, as I had to make a few adjustments:
The name of my container is wordpress_wordpress_1 so your suggested filter failed. I believe that Docker created the name using the name of the âcurrent directoryâ (being wordpress) as the prefix, and for some reason added the suffix _1.
As I was worried that using the approach of writing to .htaccess file may cause some damage (clearly showing my feeble command of Linux), I installed the nano editor instead, so I am now able to edit the .htaccess file. Itâs current content is
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Can you tell me where to add the string âphp_value upload_max_filesize 256Mâ to the .htaccess file using the editor" - or should I edit the php.ini file, which by the way is not in the /var/www/html folder ?
Editor the .htaccess file to as shown above
Run docker-compose down
Run docker-compose up -d
At this point, I invoked the wordpress again and tried to install the plugin that gave me the problem before. It still fails with that exceeded size error.
As I inspected the .htaccess file at this point, I saw that it does not include the php_value upload_max_filesize 256M line.So, this âpatch on the flyâ does not seem to work, or I am not understanding your advice.
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.
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.
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
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)?