Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update/oop all the things #273

Merged
merged 19 commits into from
Feb 17, 2025
Merged

Update/oop all the things #273

merged 19 commits into from
Feb 17, 2025

Conversation

darylldoyle
Copy link
Collaborator

Description of the Change

This PR moves the wp-scaffold to use a OOP approach that more closely aligns with industry standards. Currently we have classes containing actions/filters, but we also have functional PHP files containing actions/filters. The issue with mixing them is that:

  • We end up with poorly organised code because engineers disagree about where the best place to put them is.
  • Mixing functional and OOP code can be confusing when we could use OOP for everything.
  • Having one or the other would make it easier to implement tests across projects/the scaffold as we'd need less manual loading.

Closes #251, #247

How to test the Change

Ensure everything still works as expected

Changelog Entry

Developer - Moved to a more OOP structure.

Credits

Props @darylldoyle, @tobeycodes

Checklist:

@darylldoyle darylldoyle self-assigned this Jan 30, 2025
Copy link
Member

@tobeycodes tobeycodes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the top of this file we should throw an error if \TenUpPlugin\PluginCore does not exist telling the developer to do a composer install

*
* @return bool
*/
public function can_register() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be the default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That change would need to be made in the framework, but I don't think it's a bad idea 🤔

* @param string $handle The script handle.
* @return string|null
*/
public function script_loader_tag( $tag, $handle ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really hope we can remove this as well.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I don't think this is the right place to do that though. This is primarily around changing the structure of the scaffold, so I'm trying to move things 1:1. Let's spin up an issue to do this though!

* @param string $stylesheets Comma-delimited list of stylesheets.
* @return string
*/
public function mce_css( $stylesheets ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still needed? When do projects not use guteneberg?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please please please remove this code. I don't know a single person who uses this functionality.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, let's spin up an issue to remove this. This PR is about the structure

*
* @return void
*/
public function register() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love to see us automate enqueueing scripts/styles. we can find all the scripts/styles in the dist folder and should be able to infer their context (or add it easily)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be an amazing enhancement. CC @fabiankaegy Toby gave me some thoughts on this in Slack too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd move this to the framework. For the variables such as tenup-plugin move these to constants the theme controls. The plugin itself can extend the class and override things when needed e.g. register

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not against this as an enhancement, but I'd love to understand your thinking around overrides etc.

*/
class Overrides implements ModuleInterface {
class Emoji implements ModuleInterface {
Copy link
Contributor

@claytoncollie claytoncollie Jan 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this to the framework and register it by default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you open that as an issue on the wp-framework repo, please? I think that's a great idea, but this PR isn't the right place.

*
* @package TenUpPlugin\Core
*/
class HeadOverrides implements ModuleInterface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this to the framework?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, can you open that as an issue on the wp-framework repo, please? I think that's a great idea, but this PR isn't the right place.

@darylldoyle darylldoyle marked this pull request as ready for review February 6, 2025 16:54
Copy link
Member

@fabiankaegy fabiankaegy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few small questions / comments but overall looking forward to the new stricture :)

Also lets make sure we add the one place for utilities as discussed in the internal projects call 👍

Comment on lines 34 to 37
},
"paths": {
"blocksDir": "./blocks"
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: It seems the indentation here is of

Comment on lines +24 to +31
/**
* Can this module be registered?
*
* @return bool
*/
public function can_register() {
return true;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stupid question:

Would it not be better to have this return true by default in the ModuleInterface base class? In 90% of cases that is what we want. And when we don't we can override it. But it seems redundant to always have to add this to every single file 🤔 (very loosely held opinion)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, though that's a change we'll need to make in the Framework and then update here 🙂

* @return void
*/
public function scripts() {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: to stay consistent lets remove this empty line

*/
class Blocks implements ModuleInterface {

use Module;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stupid question:

Why do we need to add use Module here? Isn't that already coming from the implements ModuleInterface?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a stupid question! The ModuleInterface tells the class what methods it needs to implement, the Module trait does the actual implementation.

The Interface/Trait approach do the same thing as the old Module abstract class used to, without the downside of everything having to inherit a single class. This makes it more flexible for engineers to change those methods when they have things they actually want to do.

Comment on lines +33 to +36
"block-editor-script": "./assets/js/block-editor/block-editor-script.js"
},
"paths": {
"blocksDir": "./blocks"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Indentation here is of

Comment on lines +70 to +84
/**
* Enqueuing shared.js is required to get css hot reloading working in the frontend
* If you're not shipping any shared js wrap this enqueue in a SCRIPT_DEBUG check.
*/

/*
* Uncoment this to use the shared.js file.
wp_enqueue_script(
'shared',
TENUP_THEME_TEMPLATE_URL . '/dist/js/shared.js',
$this->get_asset_info( 'shared', 'dependencies' ),
$this->get_asset_info( 'shared', 'version' ),
true
);
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't need to be in this PR but I'm in favor of removing all the "shared" stuff here also...

* @return void
*/
public function admin_styles() {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: remove empty line

add_action( 'init', [ $this, 'register_theme_blocks' ] );
add_action( 'init', [ $this, 'register_block_pattern_categories' ] );
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: remove additional empty line

@darylldoyle darylldoyle merged commit 77d7aaf into trunk Feb 17, 2025
7 checks passed
@darylldoyle darylldoyle deleted the update/oop-all-the-things branch February 17, 2025 11:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Organize PHP classes folder
4 participants