How to get access to php.ini file

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?

Hi.

Try this it might work, if not respond back.

List the wordpress container and get it’s ID.

🐳  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.

🐳  gforghetti:[~/Downloads] $ docker container exec -it 9ddd9bded663 bash -c "echo 'php_value upload_max_filesize 256M' > '/var/www/html/.htaccess'"

Refresh the web page and try again.

2 Likes

Thanks, @gforghetti for such instant response (I am still amazed :grinning:)

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 ?

Hi.

Try adding it right after the # BEGIN WordPress statement.

# BEGIN WordPress
php_value upload_max_filesize 256M

No cigar :weary: - here is precisely what I did:

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.

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!

1 Like

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.

@monterey

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 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)?

Yes, that volume is persisting the Wordpress root directory /var/www/html.