WordPlate moves WordPress into Composer, with a public directory, a .env file and wp-plugin packages

composer update is how WordPress itself gets upgraded

WordPlate treats the WordPress core as a Composer dependency. The README's pitch is that WordPress can be installed and updated with Composer, and that updating means running composer update. There is no zip download and no dashboard upgrade button in that workflow.

Starting a project is one command:

composer create-project --prefer-dist vinkla/wordplate example-app

Before running it, the machine needs PHP 8.4, MySQL 8.0 and Composer, the PHP package manager. Those are stated requirements, so a shared host stuck on an older PHP cannot run the current line.

The repository is not archived. The recent releases are 12.11.2 on 2026-08-20, 12.11.1 on 2026-08-07 and 12.11.0 on 2026-05-22, and the last push was on 2026-10-14. The top-level files, composer.json, composer.lock, package.json, vite.config.js, wp-cli.yml and a src directory, show a project that is closer to an application skeleton than to a plain WordPress folder.

Database credentials live in .env, and Composer renames .env.example for you

Like Laravel, WordPlate keeps environment-specific values such as database credentials in an .env file, loaded through the vlucas/phpdotenv package. A .env.example file ships in the root directory. When you install through Composer, that file is renamed to .env automatically, and otherwise you rename it by hand.

After installing you edit the database lines:

DB_NAME=database
DB_USER=username
DB_PASSWORD=password

The shipped .env.example is more specific. It sets WP_DEBUG=true, WP_DEFAULT_THEME=wordplate and WP_ENVIRONMENT_TYPE=local, a database host of 127.0.0.1 with user root and an empty password, and a block of MAIL_ values pointing at 127.0.0.1 port 2525. Those local defaults are the first thing to change before a deploy, especially WP_DEBUG.

The .env file must not be committed. Each developer or server may need different values, and committing it would expose credentials to anyone who gets into the repository. For deeper detail the README sends you to Laravel's documentation on environment variable types and retrieving environment configuration.

Eight salt keys ship empty and the README sends you to a generator

The same .env.example holds eight blank values: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT. These are the keys WordPress uses to encrypt sensitive data such as user sessions.

Leaving them blank is a security problem. The README says that without salt keys, user sessions and other encrypted data may be vulnerable to attacks. The project links its own salt key generator at vinkla.github.io/salts. You copy .env.example to .env if the installer has not already done so, open the generator, and paste the randomly generated keys into the file.

Nothing in the excerpt of the README describes a check that stops the site from running with empty salts. The responsibility is yours. Generate unique keys for each environment, so a leaked staging file does not weaken production.

The web root must be public, and WordPress itself sits under /wordpress

Serving locally uses PHP's built-in web server, pointed at the public directory:

php -S 127.0.0.1:8000 -t public/

Two URLs then confirm the install. The site is at http://127.0.0.1:8000/ and the dashboard is at http://127.0.0.1:8000/wordpress/wp-admin. The /wordpress/ prefix is a visible difference from a stock WordPress install, where wp-admin sits at the site root, and it is worth knowing before you share a login link with a client.

On a real server, the document root has to be the public directory. That is where index.php, the entry point, lives. With public as the root, every HTTP request goes through the front controller, and files outside public cannot be reached directly. The README presents this as a security and performance improvement.

The consequence for hosting is concrete. Cheap shared hosting that fixes the document root at a folder you cannot change will not work with this layout, because the project directory above public would become web-accessible.

Plugins arrive through wp-plugin packages and land in public/plugins

WordPlate integrates with WP Packages, a Composer repository that mirrors the WordPress plugin and theme directories. To require a plugin you use wp-plugin as the vendor name and the plugin slug as the package name:

composer require wp-plugin/clean-image-filenames

The installed packages end up in the public/plugins directory, and the entry in composer.json looks like this:

"require": {
    "wp-plugin/clean-image-filenames": "^1.5"
}

Plugin versions are therefore pinned in composer.json and composer.lock, which makes a plugin update a reviewable diff. A client who installs a plugin through wp-admin does not change those files, so the repository and the live site drift apart. A team that adopts this workflow has to forbid or at least track dashboard installs.

Must-use plugins, also called mu-plugins, sit in a special directory inside the content folder and are enabled automatically across the installation. The README pitches this as the answer to clients deactivating plugins. To install one, you add the plugin name to the installer-paths section of composer.json, and the README gives the exact entry in the portion that this article does not reproduce.

Vite and Tailwind replace the usual theme asset pipeline

The front-end tooling is Vite with Tailwind CSS. The package.json is short. It defines two scripts, build as vite build and dev as vite, and three dependencies: @tailwindcss/vite and tailwindcss at ^4.3.3, and vite at ^8.3.5. A vite.config.js sits at the top level next to it.

That means Node and npm are needed in addition to PHP and Composer. The Vite setup lets you start building and minifying CSS and JavaScript quickly, and Tailwind is included by default so custom designs need no extra install.

WordPlate also adds debugging helpers. dump() and dd() are integrated, in the style Laravel developers know. The README's Clean UI feature adjusts the WordPress dashboard to improve the experience for clients.

The Tailwind and Vite choices are defaults, not options the README shows how to remove. A project that prefers another build tool has to unpick these files itself.

No license is stated in the repository metadata or the top-level files

The repository metadata lists the license as unknown. The top-level entries are .editorconfig, .env.example, .gitattributes, .github, .gitignore, README.md, composer.json, composer.lock, package.json, public, resources, src, vite.config.js and wp-cli.yml, and none of them is a LICENSE file. The README has a License heading in its table of contents, but the text of that section is not in the excerpt this article draws on.

For a boilerplate that you copy into client projects, this matters. A procurement or legal check will ask what terms the starter code comes with, and a missing LICENSE file means you have to look at the full README or ask the maintainer. Check composer.json as well, since Composer packages normally record a license field there.

The README also has Mail, FAQ and Upgrade Guide sections listed in its contents, with MAIL_ variables in .env.example, but the text of those sections is cut off. Read them in the repository before relying on a mail or upgrade procedure.

Editorial conclusion

Choose WordPlate if you build WordPress sites as a developer, already work with Composer, and want .env configuration, plugins in composer.json and a public web root. Avoid it if the site is edited through the admin by people who install plugins by hand, or if your legal review needs a stated license, since neither the repository metadata nor the top-level files show one. Before starting, confirm your host runs PHP 8.4 and MySQL 8.0, because both are stated minimums.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vinkla/wordplate on GitHub