web-dev-qa-db-ja.com

FIG標準に準拠した名前空間付けWordPressプロジェクト

私は私の頭をネームスペース、オートローダ、そして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ディレクトリ構造のさらなる操作 - 制限されたオプション、他のほとんどすべてを複雑にする、互換性が悪い、...
  • 何かもっと賢い？
phpdirectoryparent-thememu-pluginscomposer
4
Petr Cibulka

あなたはこれをひっくり返しています。名前空間構造は個々のパッケージのレベルで適用されます。サイト全体をこのようなパッケージとして扱う必要はありません。

また、最初からautoloadを使用する利点の1つは、ファイルシステム内のクラスのlocationがほとんど無関係になることです。

したがって、単純で実用的なアプローチは次のとおりです。

  1. 個々のパッケージ（プラグイン/テーマ）レベルで名前空間を扱います。
  2. 過度のフォルダレベルなしで、パッケージ内の単純なディレクトリ構造のためにComposerで PSR-4 サポートを使用してください。
2
Rarst