Feature Request: Support for Non-WordPress Sites

Feature requests
1

Context:

I regularly use LocalWP for non-WordPress projects alongside WordPress sites. These non-WP sites often run on their own subdomains in production, and I need/want to replicate this setup locally. My current workaround involves:

  1. Creating a new WordPress site in LocalWP.
  2. Removing the database tables.
  3. Deleting almost all^ files from the /app/public/ folder.
  4. Saving this setup as a Blueprint for future non-WP site deployments in LocalWP.

While this method works, I believe LocalWP could natively support non-WordPress sites with a few improvements.

Feature Suggestions:

  1. Introduce a no-wp-config.php File:
  • This file would act as a flag indicating that the site is a non-WordPress site.
  1. Update Site Overview Interface Based on no-wp-config.php:
  • When no-wp-config.php is detected:
    • Hide WP Admin Button: The WP Admin button should disappear.
    • Change WordPress version Label: The WordPress version label should change to App version.
    • Extract Version Info: The version should be obtained from the no-wp-config.php file, specifically from a variable like $version.
    • Remove “Multisite” Line: The Multisite line should be removed or hidden to streamline the information on screen.
  1. Built-In Blueprint for Non-WP Sites:
  • Implement a built-in Blueprint that streamlines the creation of non-WordPress sites, eliminating the need for manual Blueprint setup the first time.
  • The no-wp-config.php can be as straightforward as:

<?php

$version = ‘0.1’;

define( ‘DB_NAME’, ‘local’ );
define( ‘DB_USER’, ‘root’ );
define( ‘DB_PASSWORD’, ‘root’ );
define( ‘DB_HOST’, ‘localhost’ );
define( ‘DB_CHARSET’, ‘utf8’ );
define( ‘DB_COLLATE’, ‘’ );

$table_prefix = ‘no_wp_’;

^ Current Workaround:

To avoid issues such as endless spinners in the LocalWP interface, I currently leave a blank index.php and trimmed versions of wp-config.php (with just the database details) and /wp-includes/version.php (with only the $wp_version variable) in place. This helps LocalWP recognize the site structure, but a more robust solution would be greatly beneficial.

Conclusion:

These enhancements would allow LocalWP to cater beautifully to non-WordPress projects, making it a more versatile tool for developers who manage a variety of web environments. I believe these changes could significantly improve the workflow for many users.

Thanks for your consideration, and I already love using LocalWP in it’s current form! :slight_smile:

2

Thank you for the feature request and write up here @gooos! :green_heart:

3

You’re welcome. Hopefully it can be included to the roadmap of LocalWP at some point in time :slight_smile:

4

I was trying to search because I thought we had another feature request for this before but it might just be that I’ve seen other users ask about set ups for doing this. Either way I know there are other interested users. We’re always keeping our eye on our requests for future road map items so this will be good for others to come follow, vote and comment :sunglasses:

1 Like
5

Yes. There are many developers that love Local but want to be able to use it for Non-WordPress projects. The features like native, OS-level PHP, MySQL, NGINX and Apache, Virtual host management, hot-swapping between NGINX or Apache and PHP versions is awesome.

But, developing non WP sites is a hassle since it requires workarounds. And switching between WP projects and other projects is also tedious since you must start/stop apache/nginx manually when moving between Non-WP projects and WP projects that run on local.

This is the main reason stoping me and many other developers from using local.

We should really have a “Non WordPress” checkbox

6

Hey Adam,

I had never really thought of this before. Would you mind walking through a scenario you’ve used it for non-wp work? Sort of a set by step guide of what you are doing?

It might be helpful for other like myself to see the possibilities.

1 Like
7

Sure! It can be any site/app/project that is not WordPress and/or doesn’t need a database.

For example. If I’m developing a dashboard app to pull data from an api and display it in a web app I would manually set up a virtual host in Apache (dashboard.local for example) and use JavaScript, php and html to build the app.

Or if I wanted to build an SPA using prostgress/Supabase and React I would do the same.

Switching between different web servers (Apache/Nginx) or different versions of PHP for a specific project is tedious manual work.

Then, if I wanted to work on a WordPress site I would have to stop my current running web server (to stop collisions) and start Local.

Since Local already has great features for switching between different stacks and versions it would save a lot of time if I could use it for all my projects instead of only WordPress.

When you start a new project in Local you should be able to select “non WordPress site” and if you wanted to use a database for your project or not.

If you choose “non WordPress site”, no WP core files would be downloaded and a an empty database would be created (if you wanted it).

Local is an awesome app with an easy setup for stacks and virtual hosts but its “WordPress only” stance really holds it back from being the industry standard for local development environments.