Simplify scaffold

[tobeycodes]

I am starting this issue as a discussion. This scaffold has been used on several client projects and I feel like there is a lot of confusion from engineers on how to use it best. A few things I have noticed using wp-scaffold:

• Assets (css/js) are somewhat duplicated between the theme and mu-plugin. I find engineers don't have enough reasoning for determining where to put their assets and it feels like more a random choice. This leads to more code separation and hard maintenance.
• PHP in mu-plugin vs theme. Similarly to the assets I find engineers also do not have strong reasoning for placing PHP code in either the mu-plugin or the theme. This is more obvious on headless projects where the theme isn't used but code is still added to it. I believe the goal is to keep code that is not part of the presentation layer in the mu-plugin and things directly related to the theme as part of the theme but in reality I don't see this happening. In my opinion unless it's rendering logic the code shouldn't be in the theme and we should discourage this.
• PHP classes vs functions - The scaffold is setup to use a module type system but I find that engineers often will put hooks into the non class based PHP files as functions. There is no problem doing this but I think having the module system we should encourage that all code uses the module and that would include the code that is already in the scaffold. We should convert these to modules. In my opinion we should either adopt an OOP/class based approach or a functional approach but not a mix

These are obviously just my opinions and others might not share these thoughts but I wanted to open up this discussion to see what others think.

[fabiankaegy]

Strong agree from my end on the duplication between the plugin and theme.

I run into so manny projects where the empty JS / CSS files that get loaded in the plugin and theme aren't even getting removed

[darylldoyle]

I also 100% agree with this, but, I don't think it's an easy solve.

My feeling on assets is that if it renders on the front-end it should live within the theme whereas if it only affects the admin, then it should be in the mu-plugin. I also feel that the crux of the issue is highlighted in your message

... engineers also do not have strong reasoning for placing PHP code in either the mu-plugin or the theme ... In my opinion unless it's rendering logic the code shouldn't be in the theme and we should discourage this ...

Whilst I completely agree with this, I don't think it's possible to enforce it. I think this has to be something that's documented and taught, rather than rules that we can set up within the codebase. Perhaps we should put some docs together around how to structure a site setup?

Finally, R.E. the mix of functional and OOP code, I'm with you - we should put together a PR to move this all to OOP code IMO. Then we can get rid of that dreaded $n() function at the same time.

[tobeycodes]

@darylldoyle I agree that it is not an easy solve but I think part of the problem comes from analysis paralysis with so much code duplicated across the scaffold. If we give too many options to solve the same problem they will never be solved in the same way. I don't think documentation is something that can solve this. I think being more opinionated + documentation will help to solve this problem. I think CPT/Taxonomies are a good example here, where we need to be opinionated with a CLI command that will do everything for us

My feeling on assets is that if it renders on the front-end it should live within the theme whereas if it only affects the admin, then it should be in the mu-plugin.

Agreed. Just deleting the frontend folders in the mu-plugin is a small start to moving in the right direction.