Namespacing WordPress project according to FIG standards

by

I am trying to wrap my head around the namespaces, autoloaders and FIG standards and most importantly how to achieve their integration to WordPress as close as possible.

Here is my file structure, created with help of awesome roots/bedrock WordPress stack.

|-- /web
|   |-- /app
|   |   |-- /mu-plugins
|   |   |   |-- autoload.php
|   |   |   |-- /cibulka-mu-base                 // abstract classes, traits, ... for features
|   |   |   |-- /cibulka-mu-feature-1            // features as custom post types, theme support, forms, ...
|   |   |   |-- /cibulka-mu-feature-2            // features as custom post types, theme support, forms, ...
|   |   |-- /themes
|   |   |   |-- /cibulka-parent-theme
|   |   |   |   |-- functions.php                // plays with MU plugins, sets default config
|   |   |   |-- /cibulka-child-theme
|   |   |   |   |-- functions.php                // plays with MU plugins, overrides default config
|   |   |-- /plugins
|   |   |   |-- /akismet
|   |   |   |-- /other third party software
|   |-- /wp
|   |   |-- /wp-admin
|   |   |-- /wp-includes
|   |   |-- etc.

How to mimic the file structure by namespaces and in the same time, by as much FIG-friendly as possible? In the same time, “the packages” of “the app” should be stored in separate folders, so they can be required by composer.json files and monitored by GIT.

I’ve tried a lot of options, but to be honest, I am little overwhelmed by the number of possible solutions and by the fact, that none of them is very ideal.

Can you tell me what was useful in your cases?

Edit: Possible routes

  • fully following the directory structure: web\app\muPlugins\CibulkaMuBase etc.
  • “faking” vendor directory: cibulka\MU\Base, cibulka\themes\parentTheme, …
  • further manipulation of WP directory structure – limited options, complicating pretty much everything else, bad compatibility, …
  • anything more clever?

1 Answer
1

You are overthinking this. The namespace structure applies at the level of individual package. There is no need or push to treat the whole site as such package.

Also one of the benefits of using autoload in first place is that it makes location of classes in file system largely irrelevant.

So the simple and practical approach is to:

  1. Handle namespaces at individual package (plugin/theme) level.
  2. Use PSR-4 support in Composer for simple directory structure inside packages, without excessive folder levels.

Leave a Comment