上書きしないといけなくなったりすることがありストレスでした。付けるべきだったなと反省。いうディレクトリに格納されています。いうディレクトリを作ってパーツを保存すると、既存のパーツと名前がダブっていて上書きされちゃう、ということが起きやすいかなと思いました。付けたほうが良かったなと反省。付けておいたほうが良かったなと思いました。同名の処理が消えちゃうっていうのが結構ありそうなんですよね。付けておけば良かったなと反省。考えずにやってしまった問題ここまで上げたのも「あまり考えずにやってしまった」と言えばそうなんですけど。いった構成が一般的かとか調査せずに決めてしまったので、今となっては結構違和感がある構成だな...と。みたいなディレクトリを作ってまとめれば良かったなと反省。同じ階層にあったりして、何かそれが微妙に違和感があるので、良い案はまだ無いのですが、読み込まれるテンプレートの階層にあわせてディレクトリも良い感じに階層化できれば、わざわざコードを追わなくても階層が把握しやすくテンプレートを上書きする場合も探しやすいと思うので、同じような構成でこんな風にしているよーとかあればぜひ教えてほしいです。わけるのとかすごく微妙でした。(結局あまり効果的に指定できない)。名で構造化する」というのはデザインやマークアップに影響されやすかったりして良くないなと思いました。構造化したほうが良いと思います。切り離されているということを考えるとプラグインでやるべきことのような...。ベーシックなテンプレートからget_template_part()で呼び出しているので、もしそのパーツが不要となった場合は子テーマでそのパーツと同名のパーツを作り、中身を空で保存する、ということになります。何か直感的では無くダサいですし、そこでは不要だけど別の場所に出したいということができません。ような大元のテンプレート自体を上書きすることになってしまい良くありません。いったテンプレートパーツの呼び出しもアクションフックで呼び出す形にしておけ良かったなと反省。remove_action()するだけで良くなるので。いうことでと色々良くないなと思うところがあるのですが、前にも書きましたがテーマのアップデートって既存ユーザーさんへの影響が大きすぎるので後で気付いてももはや変更できないということが多いです。リリース前に入念に、本当にこれで良いのか、絶対に問題ないか、よーく慎重に検討してからリリースしたほうが良いと思います。フレームワークを細々と開発中だったりします。薄い構成にしています。主流になっているだろう、ということで。勉強になるので一度やられてみるとおもしろいと思います。使い方を勉強できました。僕のフレームワークよりたくさん機能あるのにめちゃ軽いのでなんでや!と思って調べたり(僕のはグリッドシステムを柔軟にしすぎたのでその分サイズが少し大きい)。マスターの方々にはぜひプルリク頂きたく...。カスタマイザーで色々できますよ、ということを何度か書きました。子テーマ前提のテーマということで、今回は子テーマに関する記事です。さんの「最近Habakiriのテーマをいじって勉強したのでその時の感想など。