allow to enable HTTP headers

[babatundebusari]

allow to enable headers officially

Why?

In the world of microservices, it is best to set response headers right from the source(application)
will be great to be able to add response headers right from running wordpress container so one can troubleshoot at the microservices layer.

How?

just add to Dockerfile

a2enmod headers

[tianon]

Add this would allow for the Apache configuration to add headers (https://httpd.apache.org/docs/current/mod/mod_headers.html), but doesn't enable any functionality within WordPress itself that it doesn't already have.

If folks need this in their own images, they should add it via the trivial command you've specified. Combine that with automated builds (https://docs.docker.com/docker-hub/builds/) and repository links (https://docs.docker.com/docker-hub/builds/#repository-links) and it's reasonably easy to have an up-to-date image built FROM this one with custom functionality included.

[thomashigginbotham]

I know this was closed a couple years ago, but I recently had a need to add headers to disable CORS for files not managed by WordPress (i.e. fonts, style sheets, etc.). Because mod_headers is disabled in this image, that's not possible. For those that want to enable it, here's an elaboration on what @babatundebusari mentioned.

1. Stop your container with docker-compose down.
2. If you are only using a docker-compose.yml file, you will need to add a Dockerfile file in the same directory. Add the following to the Dockerfile:

   FROM wordpress:latest
   RUN a2enmod headers
   

3. Add a build option to your wordpress settings as follows:

   services:
     wordpress:
       build: .
       image: wordpress:latest
       # Remaining settings...
   

4. Rebuild the image with docker-compose build.
5. Start your container with docker-compose up.

Now you can use mod_headers. I still believe that it should already have been enabled in the image, since that's the default in Apache, and what most people would expect.

[mxdpeep]

these modules are active in the default WP docker image:

access_compat alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex deflate dir env expires filter mime mpm_prefork negotiation php7 remoteip reqtimeout rewrite setenvif status

headers should be added to the defaults IMHO

[Maffsie]

Sorry to necro, but I found it quite unacceptable that the closing response was "build your own image" - this approach would require you to re-build the image every time a new parent image was made available. My guess is most people who went this route and are today still using that mechanism, are now running quite old and potentially vulnerable versions of PHP.

In the case that a module is available in /etc/apache2/mods-available but not enabled, as is the case with mod_headers, the supplied docker-entrypoint.sh should support loading additional modules during execution via an environment variable (A2ENMOD_ADDITIONAL=..., for example).

A workaround that does not place the burden of keeping the image up-to-date on the user is to supplant the entrypoint.

Docker Swarm

Create a file, a2entrypoint.sh with the contents:

#!/usr/bin/env bash

a2enmod headers

exec /usr/local/bin/docker-entrypoint.sh apache2-foreground

Run docker config create my_wordpress_service_entrypoint_1 a2entrypoint.sh (your choice of config name and filename, of course, but it's good practice to make configs versioned)

Run docker service update --config-add source=my_wordpress_service_entrypoint_1,target=/usr/local/bin/hooked-entrypoint.sh,mode=0555 --entrypoint hooked-entrypoint.sh my_wordpress_service

Ta-da!

Normal Docker, Podman or other docker-compatible

Create a file the same as above, but run chmod 0755 a2entrypoint.sh to make it executable, then instead of adding it as a config, just mount it like --mount type=bind,src=/path/to/a2entrypoint.sh,dst=/usr/local/bin/hooked-entrypoint.sh. Then do --entrypoint /usr/local/bin/hooked-entrypoint.sh

[mxdpeep]

Sorry to necro, but I found it quite unacceptable that the closing response was "build your own image" - this approach would require you to re-build the image every time a new parent image was made available. My guess is most people who went this route and are today still using that mechanism, are now running quite old and potentially vulnerable versions of PHP.

In the case that a module is available in /etc/apache2/mods-available but not enabled, as is the case with mod_headers, the supplied docker-entrypoint.sh should support loading additional modules during execution via an environment variable (A2ENMOD_ADDITIONAL=..., for example).

A workaround that does not place the burden of keeping the image up-to-date on the user is to supplant the entrypoint.

I went a different route - I've enabled an automatic (not automattic) GNU make manipulation Makefile so if something is missing, I just inject a script into the container, run it and then restart the container - works as a charm

I don't want to build an image for every WordPress combination used in our infrastructure

see it here: https://github.com/GSCloud/docker_wordpress