Clarifications, Documentation

First, thank you for this wonderful contribution! Having a simple, unbranded starting point for something like this is a breath of fresh air.

I should preface these requests by noting that this is not a request for support and there's nothing here that can't be figured out already. This is merely a request for some clarification in a few areas, preferably feedback that might make it into documentation for others to benefit from.

Installation

For starters, when following the docs, step 2 says to change the "template name" by opening gulpfile.js and updating the line below "theme name". Let's say I choose "amazeballs" as the value for the themeName const.

Once saved, WordPressify creates:

/src/theme
/src/style/style.css with Theme Name: WordPressify
/build/wordpress/wp-content/themes/amazeballs
/build/wordpress/wp-content/themes/amazeballs/style.css with Theme Name: WordPressify
Function names and hooks prefixed with wordpressify_hook_name

You see the disparity between those naming conventions and where I'm going with this, right?

What was not created, however, is a custom plugin folder with boilerplate code similar to the theme it creates.

So, going back to the docs, I begin to wonder if "Template Name" hints at this possibly being a starting point that currently only accommodates theme development (hence the themeName const in gulpfile.js), and if maybe plugin development is planned for future release.

Naming Conventions

I'm a bit confused about the logic surrounding the /src/plugins|theme directories versus /build/wordpress/wp-content/plugins|themes. I understand why /src exists, how to use it, etc. but perhaps it's the naming conventions that causes me confusion.

For instance, if the /src directory is to be used a place for custom theme and plugin development for a single site, and if plugins placed in /src/plugins/ get symlinked to /build/wordpress/wp-content/plugins/, and if a custom-named theme folder is placed in /build/wordpress/wp-content/themes/, then:

Why isn't /src treated as a custom directory modeled after wp-content with a directory for multiple themes, multiple plugins, and an mu-plugins directory?
Why just "theme" instead of "themes" in /src?

To keep consistency with WordPress' directory logic, I think /src/js and /src/style should be moved up and into a "shared" or "common" directory, able to be used as a set of consistent front-end build tools for multiple themes and multiple plugins.

Under da Hood

Understanding what's providing the runtime for PHP would be really good to know. Many developers will already have a PHP binary somewhere in their path, and once WordPressify is set up, running which php may say /usr/bin/php or /usr/local/bin/php. The version being run may be 5.4, 5.6, even 7.3. There could also be a legitimate need to know if APCu is available, or Memcached, or Redis. So, where is WordPressify's PHP binary and how can its configuration be modified?

With regard to database needs, why are MySQL/MariaDB required? This is local development, and WordPress has long supported SQLite. It'd be great if the memory-intensive and frustratingly confusing installation process for MySql/MariaDB became a thing of the past. SQLite can be used with PHP's PDO extension and PDO's driver for SQLite. I mean, this is local development for one-off site edits, simple theme editing, plugin modifications... SQLite can be used as a throw-away option and its memory footprint is almost nonexistent.

WP-CLI, SSL, and extra helpers...

There's an awesome package on NPM for WP-CLI. A sample wp-cli.yml file which points its path to build/wordpress would be very very helpful!

SSL support would be great. I've found mkcert to be invaluable for that purpose.

The docs could benefit from a note to export a PATH var that points to node_modules/.bin when first starting.

Forking and PR

That's about it. I've made the above changes to a forked version already if interested or if any clarification is needed. Can send a PR.

luangjokaj / wordpressify