You know the drill; you add a couple of Header directives to your .htaccess (a cache-control here, an X-Frame-Options there) you reload the page, you check the response headers and… nothing. No error, no warning, no headers. Just… nothing.

Welcome to debugging something that isn’t broken. My favorite pastime! (It is not.)

The Problem

Local ships a perfectly fine Apache, but it does not load mod_headers. So every Header directive in your .htaccess is silently skipped. Not an error in the log, not a notice, nothing. Apache just shrugs and moves on. And it’s not just mod_headers; deflate, expires, brotli; if it’s not in Local’s hand-picked list, it’s not there. Your production server has it, your Local site doesn’t, and you find out the hard way.

For years my workaround lived in a shell script that manually patched the Apache config of a site. Works for me, but, I’ve been asked many times; can we make this easier?

What, Where, How?

So where does Local keep its Apache config? Every site has its own template at conf/apache/modules.conf.hbs. A Handlebars file that Local recompiles into the actual config on every site start. And in that template you’ll find a long list of LoadModule lines… most of them commented out. The modules are all right there, on your disk, in Local’s own bundled Apache — about a hundred of them — they’re just never loaded.

In other words; the fix was never “install something”. The fix is “remove a # from one line in one file”. Which is exactly the kind of fix nobody remembers how to do six months later.

And when everything can be done from a GUI, why should we resort to the terminal for this? (Well, not me, I like the terminal, but I do appreciate that not everybody does, or aspires to).

So;

The Solution

I built Apache Modules for Local: an addon that gives every Apache site a Tools → Apache Modules panel. It shows which modules are loaded and which are merely available, and every one of them is a checkbox. Tick it, restart the site (there’s a button for that right in the panel, because changes only apply when Local recompiles the config), done.

Some implementation notes, because the devil lives in the details;

• Enabling a module uncomments the existing LoadModule line, or adds one if it isn’t there. Disabling comments it out. Nothing is ever deleted, so re-enabling restores the file byte-for-byte.
• Lines inside Handlebars conditionals ({{#if shouldUseFcgid}} e.t.c.) are template-managed and are left alone. I’m reckless, not stupid :)
• Modules Local itself depends on (rewrite, mime, proxy_fcgi, …) are marked required by Local and can’t be disabled — because yes, I tried, and no, you don’t want a site that doesn’t work, or worse, LocalWP no longer starts up and you have to go digging for Log files to figure it out.
• nginx sites don’t get the menu item. Obviously. It says Apache Modules on the tin.

Get it

The code lives on GitHub: rmpel/Local-Apache-Modules.

Install from source (macOS, Linux);

git clone git@github.com:rmpel/Local-Apache-Modules.git
cd Local-Apache-Modules
./scripts/install.sh # symlinks into Local's addons dir + npm install

Restart Local to make it visible in the Installed addons list, toggle on as usual.

Install from a dist file (Any OS); grab the latest .tgz from the dist folder, or build it with ./scripts/build.sh, and use the “Install from disk” feature in LocalWP.