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: