-
Notifications
You must be signed in to change notification settings - Fork 51
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't this supported a while ago? https://make.wordpress.org/core/2023/07/14/registering-scripts-with-async-and-defer-attributes-in-wordpress-6-3/
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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 👍
themes/10up-block-theme/package.json
Outdated
}, | ||
"paths": { | ||
"blocksDir": "./blocks" | ||
} |
There was a problem hiding this comment.
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
/** | ||
* Can this module be registered? | ||
* | ||
* @return bool | ||
*/ | ||
public function can_register() { | ||
return true; | ||
} |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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() { | ||
|
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
"block-editor-script": "./assets/js/block-editor/block-editor-script.js" | ||
}, | ||
"paths": { | ||
"blocksDir": "./blocks" |
There was a problem hiding this comment.
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
/** | ||
* 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 | ||
); | ||
*/ |
There was a problem hiding this comment.
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...
themes/10up-theme/src/Assets.php
Outdated
* @return void | ||
*/ | ||
public function admin_styles() { | ||
|
There was a problem hiding this comment.
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' ] ); | ||
} | ||
|
There was a problem hiding this comment.
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
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:
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: