Installing WP in a subdirectory with custom table prefix

I’m new to Local, and have been running up against a problem. I like to install WP in a subdirectory, and also use custom table prefixes instead of the default “wp_” I haven’t been able to find a way to do either as part of the Add a Site process, so I did a default installation, then moved the WP files into my desired subdirectory, changing the root’s index.php to reflect that. I also changed wp-config.php so that it had my desired table prefix, then re-ran the WP installation. That worked fine, except for the fact that Local doesn’t recognize that there’s a WordPress installation for that site.

Am I doing something wrong, or is this just not possible to do?


Hi Carlos,

Local doesn’t support creating sites with non “wp_” prefixes or sub-directory installations.

With that said, you can always set it up how you like it then right-click on the site and save it as a Blueprint for re-use later :slight_smile:


I have done exactly what you said—saving my custom setup as a Blueprint. I’m happy to do it that way.

But when I enable live link and view the site, I just get a redirect loop to whatever the ngrok URL is. It’s happening on two different sites that have WP in a subdirectory.

I setup a new vanilla site in Local and ngrok works fine.

Any idea why this is happening when WP is in a subdirectory?

Hi Mark,

When you enable the Live Link it drops a plugin into “mu-plugins” inside the standard wp-content path. Then, when it’s disabled that plugin is removed.

Without that plugin the WordPress URLs won’t be changed accordingly. So, what you can do is enable a Live Link for another site and watch wp-content/mu-plugins for the file to show. Once it does, copy it and move it into wp-content/mu-plugins on your sub-directory site and you should be set.

Thanks for the reply, Clay. I’ll try a blueprint, although, I still think that Local then wouldn’t recognize the WP installation. I’ll have to test it.

Clay, that worked.

Now, I just need to resolve all of the HTTPS mixed content errors. I’ll see what I can do and report back.

1 Like

From my initial attempt, it also seems like Local doesn’t support importing a site with a custom directory structure. I have a site I’ve been using in DesktopServer configured (Hi, Mark!) with only 2 PHP files and 2 directories at the top level. All the stock WordPress files/directories are moved down one level into a wp/ directory. But instead of having a wp-content/ in there, all the plugins & themes are in a subdirectory called app/. The only PHP files are index.php and wp-config.php.

I stuck all this stuff into a directory with a DB backup, zipped it, and imported it. I hoped the import script would somehow use the CONTENT_DIR Definition from wp-config.php and put everything in its place. But when it was done, I got a white screen on the front end. I logged into the admin and it made me upgrade WordPress to 4.8. When that was done, a glance at the dashboard revealed the db had come through, but the front end was a “missing theme” error.

So then I looked at the directory structure and it was stock WordPress with none of my themes/plugins.

My question, then: if I want to actually import this site, should I just rename/move stuff around to stock WordPress, comment out the CONTENT_DIR definition, and import before trying to config things how they used to be? Seems to me like that should work, but I figured it was worth checking in here before trying. Any advice on the best way to import existing sites with WordPress in a subdirectory?

Hi Yoni,

When you say “importing”, do you mean you dropped an archive into Local to have it import? If so, we’ll check into supporting CONTENT_DIR.

Otherwise, you can always add a new site and then wipe out the contents of public and then put your site files in there. You can use Adminer, Sequel Pro, or your preferred database tool to import the database. Finally, a simple WP-CLI search-replace will get the domain switched over to the Local one.

Here’s how to run a WP-CLI search-replace in Local:

  1. Right-click on the site in Local
  2. Go to ‘Open Site SSH’
  3. Enter wp search-replace '//' '//' ( being your live domain and being your Local site domain)
  4. Done!

Yeah, my post was characteristically wordy, but I did zip up my site with a database backup and then went to File > Import to bring it all in. I thought about doing a totally fresh site and then dropping my files in, but I wanted to try this way first since the existing site is on 4.7.x and I haven’t tested 4.8 yet.

I guess I’ll give it a try your way and see if it lets me revert back to 4.8. Thanks for the input. Lemme know if you want to see my wp-config.php. Mark from uptrhead set it up initially, but I’m pretty sure he used the Roots/Bedrock convention to do so.

Update: I was able to manually import a site with a Bedrock-style directory structure by doing the following

  1. Create a fresh site in Flywheel
  2. Get rid of everything but the wp-config.php file
  3. Copy in the lines from my old wp-config.php file that remap the directories
  4. Using Adminer, drop all the tables from the db and import a SQL backup from my old site
  5. Change the table prefix in wp-config.php

I did all the above before trying to access anything via my browser. At this point, everything seems to work on the front end and admin side.

One issue was that WP CLI insisted I wasn’t in a WordPress install. I (sorta) fixed that by just renaming /wp-cli.yml and now it believes me. I think this removes the Flywheel-customized search-replace command, but I can live with that.

Like Carlos was saying, Local also doesn’t recognize that there’s a WordPress install here, but it doesn’t seem to affect the operation of the site.

1 Like

Are there any plans to natively support custom directory and table prefixes?

1 Like

Yes I’m also keen to hear. I think running WordPress from a subdirectory is quite common.

1 Like

Reviving this dormant thread because I see there’s a major new version of Local available. If my sites use a nonstandard directory structure, will they survive a 2.4.5 → 3.0.2 update? Anybody have anything to report one way or the other?