Problem/Motivation
Themes can now be OOP.
Let's convert Olivero.
Steps to reproduce
Open olivero.theme
Proposed resolution
Use rector to convert
Remaining tasks
Review
Create follow up for organization and DI
Create follow up to replace the remaining functions
_olivero_hex_to_hsl
User interface changes
N/A
Introduced terminology
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|
Issue fork drupal-3575583
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3575583-convert-olivero-to
changes, plain diff MR !14903
Comments
Comment #3
nicxvan commentedComment #4
nicxvan commentedComment #5
smustgrave commentedAssuming the DI will be done in a follow up?
If so this LGTM.
Comment #6
nicxvan commentedYes, DI is a follow up.
Comment #7
smustgrave commentedIn that case, applying hte MR on a standard install olivero is still rendering fine for me.
Comment #8
berdirThere are 10 calls to \Drupal::, including several repeating ones. I think DI would be doable in scope, it's pretty straightforward with autowire and I don't think it would make the MR significantly harder to review. I think we should even consider splitting this into 2-3 different classes, such as all the entity stuff with the entity type manager into one and the rest in a general one? We already have OliveroPagePreprocessHooks from the initial issue as an example.
Leaving at RTBC, just wanted to add my opinion :)
Comment #9
nicxvan commentedI really would prefer not to do DI and follow the pattern we did for module hook conversion. The more manual work I need to apply after running rector the more risky this conversion gets.
As it stands it's basically rector plus codesniffing and phpstan.
Comment #10
nicxvan commentedComment #11
nicxvan commentedComment #12
sivaji_ganesh_jojodae commentedA follow-up issue should be created to add type hints for all variables.
Comment #13
nicxvan commentedA post conversion cleanup issue already exists: #3493453: [meta] Standardize and clean up hook classes in core.
I've linked it here.
Comment #15
catchI think the 2/3 phase approach is still good here. It's easier to be confident about the rector conversion, then splitting etc. individually than all that once.
Committed/pushed to main, thanks!
I wasn't able to cherry-pick this to 11.x, looks like it was accidentally backported already as part of
c03369417f900ee7bbd3bc1235ca304dc7ea8955We could revert that commit, commit the intended bits, then backport this, if we want more explicit git history, or leave things as is. Leaving to be ported to figure out.Comment #19
catchI reverted only the mistaken big of the 11.x commit courtesy of patch -p1 -R and then did the actual cherry-pick. Should be OK now.
Comment #21
nicxvan commentedComment #22
sivaji_ganesh_jojodae commentedFollowing #12, I've created a related issue at https://www.drupal.org/project/drupal/issues/3579922