我正试图围绕名称空间、自动加载器和FIG标准，以及最重要的是如何尽可能地实现与WordPress的集成。

这是我的文件结构，是在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.

如何通过名称空间模拟文件结构，同时尽可能友好地模拟文件结构？同时，“应用程序”的“包”应存储在单独的文件夹中，以便composer.json 文件，并由GIT监控。

我尝试了很多选择，但老实说，我几乎没有被可能的解决方案的数量所压倒，也没有一个是非常理想的。

你能告诉我什么对你的情况有用吗？

编辑：完全按照目录结构编辑可能的路由：web\\app\\muPlugins\\CibulkaMuBase 等。

“伪造”供应商目录：cibulka\\MU\\Base, cibulka\\themes\\parentTheme, ...

进一步操纵WP目录结构-选项有限，几乎使其他一切复杂化，兼容性差

anything more clever?