WordPress-Skeleton: A Git Layout for WordPress Sites

Why WordPress-Skeleton Splits Code, Content, and Uploads

WordPress-Skeleton addresses a recurring repository problem: WordPress core, project-specific files, secrets, and user-uploaded data do not have the same update or retention rules, but they often end up mixed in one tree. This skeleton gives each category a defined location. WordPress itself belongs in `/wp/` as a Git submodule. Project-specific content belongs in `/content/`, which the README explains cannot live inside `/wp/`. Root-level configuration stays in `wp-config.php`, also outside the WordPress directory.

Writable directories are redirected through symlinks to corresponding locations under `/shared/`. This design is aimed primarily at repository owners who want Git-managed application code to remain distinct from data generated at runtime. The repository description explicitly presents the project as a base for creating a new Git repository, not as a complete WordPress distribution. That distinction matters because adopting it means accepting and adapting a directory scheme, not installing a finished site.

The target user is therefore a developer creating a WordPress site repository. The project may reduce ad hoc decisions about where custom content and uploaded files belong. It does not remove the need to configure the environment, connect a database, maintain WordPress, or design a deployment process.

The Repository Architecture Behind /wp/, /content/, and /shared/

The central mechanism is the separation of roles across several paths. `.gitmodules` records the WordPress submodule relationship, while the top-level `wp` entry represents the WordPress directory. The `content/` directory sits outside that submodule so project-specific content can be managed independently. This avoids placing custom site files under a directory associated with upstream WordPress code.

Configuration follows the same separation rule. `wp-config.php` remains at the repository root because it cannot reside under `/wp/`. For local development, `local-config.php` can override environment-specific choices such as MySQL credentials, query saving, or debug mode. The README states that `local-config.php` is ignored by Git and should not exist in production. If it is absent, WordPress uses database credentials defined in `wp-config.php`.

The writable-data layer is different. Local development can keep that data in `/shared/`, while production can point the symlink to storage outside the repository, with an NFS shared directory given as an example. This prevents uploads from becoming Git-managed repository content. The design does not document deployment commands or a production-ready symlink script, so the deployment mechanism remains the adopter's responsibility.

Cloning the Skeleton and Establishing a First Site Workflow

The README says to clone the repository as a starting point or fork it for customization. It does not provide a complete command sequence for initializing the submodule, creating `/shared/`, editing configuration, or starting WordPress. For that reason, this tutorial does not invent commands beyond the documented acquisition method.

After obtaining the repository, the documented sequence is to inspect the submodule declaration in `.gitmodules`, initialize WordPress in `/wp/` using the Git tooling appropriate for that setup, and create `/shared/` for local writable data. The directory is ignored by Git according to the README. Next, copy or adapt `local-config-sample.php` as a local configuration path, then replace the example values with local MySQL settings if needed. The exact operation for copying the file is not documented.

A developer should also decide whether `/shared/` needs to mirror the writable locations expected by the checked-in links. The top-level `.htaccess`, `index.php`, `wp-config.php`, and `wp-cli.yml` indicate that the repository includes web and command-line integration points, but their detailed settings are not included in the README. This makes repository inspection a necessary first step. There is no documented first-run URL, database creation procedure, cache setup procedure, or WP-CLI command in the available instructions.

Local Configuration, Object Caching, and Production Boundaries

Local configuration is treated as an optional layer rather than a committed deployment file. According to the README, `local-config.php` may contain different MySQL credentials and development options such as query saving or debug mode. Because it is ignored by Git, local credentials and development settings are not intended to enter the repository accidentally. Production falls back to the database credentials in `wp-config.php` when the local file is absent.

Object caching is optional too. The README describes `memcached.php` as configuration for people using Memcached as an object-cache backend. Its expected shape is an array of server addresses, with `server01:11211` and `server02:11211` shown as examples. The author recommends generating this file programmatically. The project does not state that Memcached is installed, configured, or enabled by the skeleton. Without additional application configuration, placing a server list in `memcached.php` does not by itself establish a working cache.

These boundaries reduce the chance that local credentials, cache server details, or uploaded files become versioned content. They also make adoption less automatic. A team must determine which settings belong in `wp-config.php`, which belong in `local-config.php`, and how production storage will be attached.

WordPress Updates, Multisite, and the Limits of Automation

The skeleton states that its submodule tracks the latest stable WordPress release and should update automatically within six hours after a stable release. This is a documented expectation for the submodule arrangement, not a guarantee about every hosting environment. The README also instructs users to open an issue if that update does not occur.

WordPress multisite is supported according to the README, with support described as available since WordPress 3.5. The documentation does not explain the required configuration steps for a multisite installation, so the support statement should not be interpreted as a complete multisite deployment guide.

There are no GitHub releases for this repository. Consequently, adoption is tied to repository state and commits rather than a published release history. The submodule update claim also leaves local changes, hosting constraints, and deployment scripts outside the documented process. A developer cannot infer from this README whether upgrades are safe for an already customized production site or what rollback procedure applies. The repository does not document rollback.

Maintenance Signals, Licensing Gaps, and Adoption Trade-offs

The repository is not archived, and its last push was on 2026-10-07. That is the available maintenance signal, but it does not establish release cadence or long-term support. There are no GitHub releases, and the README asks whether pull requests will be accepted with the answer, "Maybe, if I think the change is useful." The author also says the project was made primarily for personal use and suggests maintaining a customized fork when taking it in another direction. That makes the repository a foundation with contributor policy left to the maintainer's discretion.

The license is listed as unknown. The available repository information does not identify a license text or grant permissions for copying, modification, or redistribution. This uncertainty should be resolved directly in the repository before the skeleton is reused in another project. This review does not interpret the absence of a stated license as permission.

Compared with a managed WordPress host or a generated project such as Bedrock, this repository is much smaller in scope. Managed hosting supplies an operating environment rather than asking the adopter to define this particular Git, configuration, and storage split. WordPress-Skeleton's distinguishing choice is its simple Git submodule and symlink model. Its drawback is equally concrete: the repository leaves database setup, production deployment, rollback, and most update handling to the adopter.

Editorial conclusion

Developers who want WordPress core in a Git submodule, custom code in `/content/`, and uploaded data outside the repository may find this skeleton useful. It is a poor fit for users expecting a turnkey site, managed WordPress installation, or documented deployment pipeline. Before adopting it, inspect `.gitmodules`, `.gitignore`, `.htaccess`, `wp-config.php`, `local-config-sample.php`, and `wp-cli.yml`, then confirm that the production environment can provide the required `/shared/` storage and symlink targets.

Frequently asked questions

Official sources

1. Issues
2. markjaquith/WordPress-Skeleton on GitHub
3. README