按FIG标准命名WordPress项目

Question

我正试图了解名称空间、自动加载程序和FIG标准，最重要的是如何实现它们与WordPress的尽可能紧密的集成。

这是我的文件结构，它是在根/基岩WordPress堆栈的帮助下创建的。

|-- /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.

如何通过名称空间来模拟文件结构，同时尽可能地通过FIG友好地模拟文件结构？同时，“应用程序”的“包”应该存储在单独的文件夹中，这样composer.json文件就可以要求它们，GIT也可以监视它们。

我尝试了很多选择，但老实说，我对可能的解决方案的数量以及它们都不是很理想这一事实并不感到不知所措。

你能告诉我什么对你的案子有用吗？

编辑:可能的路由

• 完全遵循目录结构：web\app\muPlugins\CibulkaMuBase等。
• “伪造”供应商目录：cibulka\MU\Base，cibulka\themes\parentTheme，.
• 进一步操作WP目录结构-有限的选项，使几乎所有事情复杂化，兼容性差，.
• 还有什么更聪明的吗？

Answer 1

你想得太多了。命名空间结构适用于单个包的级别。没有必要或推动将整个网站作为这样的包。

另外，首先使用autoload的好处之一是，它使得文件系统中的类的位置在很大程度上无关紧要。

因此，简单和实际的办法是：

1. 在单个包(插件/主题)级别处理名称空间。
2. 在Composer中使用PSR-4支持包中的简单目录结构，而不需要过多的文件夹级别。