Start projects with more functionality - #207
Conversation
jessicamgoddard
left a comment
There was a problem hiding this comment.
I started a "things I shouldn't have to do in a new project" list and you hit a few of them!
I only did a high-level review of this work to understand the changes being proposed. A couple of things to consider:
- Should any of the features be put into sub-directories for better organization?
- How can these best be documented so that devs and AI agents understand the functionality and don't duplicate efforts?
kaitlinbolling
left a comment
There was a problem hiding this comment.
🍋 Looks good to me!
On FIT, we haven't generally felt the need to do that, at least not in any way that I think is worth encoding in the starter project. Once in a while, we do, and once in a while, I wish we had 😄. The structure in
An excellent question. I left out docs only because we're just beginning to approach this question in an AI-forward way on FIT, and so we don't have much prior art to offer. But maybe something to start with is better than nothing? I'll see what Claude comes up with and maybe include that. |
|
@jessicamgoddard I added some documentation in 5723c90 with the help of the grill with docs skill, which comes with opinionated approach to how to organize the files. Do these seem helpful? Is there anything you'd consider adding, or maybe another skill to try instead? |
|
(This link actually explains the skill: https://www.aihero.dev/grill-with-docs) |
|
@dlh01 I think the docs are a nice addition! It's a lot to digest, but I think it gives a good overview of where this project is and how we want to view it in the future. I especially appreciate |
|
Thank you for reviewing! I reviewed the files you called out and cut down on some of the duplication. I left a bit of it because the grill-with-docs skill describes its output as being intended for agents as well as humans, and I thought that some repetition might be useful if an agent doesn't read all the docs or in the expected order (same for humans!). |
# Conflicts: # configure.php # mu-plugins/plugin-loader.php # plugin-templates/features.txt
The goals of this PR are to:
All of these changes are biased towards FIT's experiences, and I welcome feedback rooted in other teams' experience.
Fixes #193. Fixes #188. Fixes ##206.
Common dependencies
Commonly used dependencies are now set up in
main(). More Composer packages are also installed by default to accommodate these. Some of these are dead code by default, but we have found that they eventually get used, so I opted to have them ready consistently. New projects could delete the lines if they didn't want them.More features
This PR adds many features (plus a few non-features) to the
plugin-templatesdirectory. These are (almost) all classes that FIT has implemented project-by-project more than once. With this PR, they would be available out of the box.Side note: Yes, this would result in duplication across projects. I have not found that the benefits of attempting to put these into a single shared repo outweigh the costs of higher maintenance effort and less flexibility for us to customize these features for their clients' needs. See alleyinteractive/wp-type-extensions#40.
Loading plugins
Plugins are now loaded in
main(), which allows for integration features to be colocated with their plugins and for load order to be expressed declaratively. We generally find it useful to be able to instantiate a plugin loader multiple times, such as on a multisite where only some sites need specific plugins, and this requirement can be expressed inmain()usingEffectand other decorators.create-wordpress-plugin compat
The approach to setting up
main()in the configure script is updated, and blockindex.phpfiles are also updated to catch up with block registration in bulk as happens now in the plugin.TODO