How to get access to php.ini file

monterey · February 12, 2019, 11:45pm

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!

gforghetti · February 12, 2019, 11:58pm

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] $

Grzegorz.Dzien · February 13, 2019, 12:11am

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

gforghetti · February 13, 2019, 12:29am

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.

gforghetti · February 13, 2019, 1:14am

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.

gforghetti · February 13, 2019, 1:13am

@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: {}

monterey · February 13, 2019, 3:50am

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

gforghetti · February 13, 2019, 4:08am

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

monterey · February 13, 2019, 2:41pm

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.

gforghetti · February 13, 2019, 2:45pm

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

monterey · February 13, 2019, 3:05pm

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?

gforghetti · February 13, 2019, 3:19pm

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.

monterey · February 13, 2019, 3:40pm

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.

monterey · February 13, 2019, 10:53pm

The final thread with the solution in the form of the YAML file for the composer is here.

gforghetti · February 13, 2019, 11:31pm

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.

I’ll give that a try myself.

gforghetti · February 15, 2019, 5:54pm

@monterey

Hi, I tried the solution that was identified in the GitHub Issue response and it worked for me too.

monterey · February 16, 2019, 3:46am

@gforghetti can you do a little magic and make the reference to this solution appear in the original article (https://docs.docker.com/compose/wordpress/) that led me to get in touch with you and then with the wordpress library folks at https://github.com/docker-library/wordpress/issues/375 ?

amandajames · July 25, 2019, 10:51am

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

upload_max_filesize = 20M
post_max_size = 25M
memory_limit = 30M

Also edit .htaccess file and add this code

php_value upload_max_filesize 20MB
php_value post_max_size 25MB
php_value memory_limit 30MB

Another method is to modify the WordPress file wp-config.php or functions.php files, and paste the following lines of code

@ini_set( ‘upload_max_size’ , ’20MB’ );
@ini_set( ‘post_max_size’, ’25MB’);
@ini_set( ‘memory_limit’, ’30MB’ );

If you still having an issue I will refer you to a guide where you ca easily learn how to increase upload size limit

papinderdocker · February 20, 2020, 8:33am

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

#####################################################################################
version: ‘3.3’

services:

wordpress:

 depends_on:

   - db

 image: wordpress:latest

 volumes:

   - ./html:/var/www/html

   - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

 ports:

   - "80:80"

 restart: always

 environment:

   WORDPRESS_DB_HOST: db:3306

   WORDPRESS_DB_USER: wordpress

   WORDPRESS_DB_PASSWORD: wordpress

db:

 image: mysql:5.7

 volumes:

   - ./database:/var/lib/mysql

 restart: always

 ports:

   - 3306:3306

 environment:

   MYSQL_ROOT_PASSWORD: wordpress

   MYSQL_DATABASE: wordpress

   MYSQL_USER: wordpress

   MYSQL_PASSWORD: wordpress

phpmyadmin:

 image: phpmyadmin/phpmyadmin

 depends_on:

   - db

 restart: always

 ports:

   - 3333:80

 environment:

   PMA_HOST: db

   MYSQL_ROOT_PASSWORT: wordpress  

 volumes:

   - ./uploads.ini:/usr/local/etc/php/conf.d/php-phpmyadmin.ini

########################################################

my uploads.ini file look like that…

file_uploads = On
memory_limit = 500M
upload_max_filesize = 500M
post_max_size = 500M
max_execution_time = 600
max_file_uploads = 50000
max_execution_time = 5000
max_input_time = 5000

fontnelle · June 28, 2020, 4:37pm

I added php.ini inside my wordpress folder and it worked.

    upload_max_filesize = 256M
    post_max_size = 256M
    memory_limit = 256M