Make extension hook methods protected - part 2

[emteknetnz]

Follow up to this comment

There's a list of of $doNotMakeHookProtected in the extension-protector script created for this issue

Methods that matches this name were left public because there are currently being called directly

Notes

• The 6.0.0 changelog has already been updated to broadly mention that extension hook implementations have been changed from public to protected, so no need to update changelog

Acceptance criteria

• Go through the list of these of $doNotMakeHookProtected methods and where possible and appropriate, update code so they are not being called directly
• If it's not sensible to stop calling the method directly, look for where the extend() call is and evaluate whether this should be
  • Changed to call the method directly
  • Removed
  • Updated so the method in the call to extend() is not the same name as the one being called directly
• Change visibility on remaining extension hook methods that aren't called directly from public to protected

CMSEditLink() PRs

Kitchen sink CI run
Recipe reporting job failing because we're forking framework

• NEW Provide a standardised CMSEditLink method #11338
• API Change public CMSEditLink to protected updateCMSEditLink silverstripe-admin#1809
• API Remove CMSEditLink implementation, rely on superclass instead. silverstripe-assets#628
• API Remove CMSEditLink implementation, rely on superclass instead. silverstripe-cms#2987
• API Update method signature for CMSEditLink silverstripe-siteconfig#173
• API Update method signature for CMSEditLink silverstripe-versioned#463
• API Update method signature for CMSEditLink silverstripe-elemental#1236
• MNT Update method signature for test class silverstripe-reports#191
• MNT Update method signature for test class silverstripe-versioned-admin#357
• ENH Remove unnecessary condition symbiote/silverstripe-advancedworkflow#546
• API Update method signature for CMSEditLink silverstripe-frameworktest#199
• DOC Document standardised CMSEditLink method developer-docs#557

Other PRs

Kitchen sink CI run
Recipe reporting job failing because we're forking framework

Note these can be merged independently of the CMSEditLink PRs

• API Standardise extension hooks silverstripe-admin#1810
• API Standardise extension hooks silverstripe-assets#629
• API Standardise extension hooks silverstripe-asset-admin#1485
• API Standardise extension hooks silverstripe-auditor#88
• API Standardise extension hooks silverstripe-campaign-admin#321
• API Standardise extension hooks silverstripe-contentreview#249
• API Standardise extension hooks silverstripe-cms#2989
• API Standardise extension hooks silverstripe-elemental#1237
• API Standardise extension hooks silverstripe-errorpage#118
• API Standardise extension hooks #11339
• API Standardise extension hooks silverstripe-frameworktest#202
• API Standardise extension hooks silverstripe-graphql#597
• API Standardise extension hooks silverstripe-ldap#86
• API Standardise extension hooks silverstripe-mfa#559
• API Standardise extension hooks silverstripe-realme#154
• API Standardise extension hooks silverstripe-session-manager#209
• API Standardise extension hooks silverstripe-sharedraftcontent#251
• API Standardise extension hooks silverstripe-subsites#591
• API Standardise extension hooks silverstripe-testsession#91
• API Standardise extension hooks silverstripe-userforms#1317
• API Standardise extension hooks silverstripe-versioned#465
• API Standardise extension hooks symbiote/silverstripe-advancedworkflow#547
• API Standardise extension hooks bringyourownideas/silverstripe-composer-update-checker#93
• API Standardise extension hooks tractorcow-farm/silverstripe-fluent#873
• DOC Document standardisation of extension hooks developer-docs#558

[emteknetnz]

There's a bit too much going on here to give me confidence, could we resolve and merge the (get)CMSEditLink() PRs first, rebase any of the non-(get)CMSEditLink() PRs and then redo the kitchen sink build

[GuySartorelli]

They're entirely separate sets of PRs which don't depend on one another in any way, but we can handle them that way if that's what you prefer.

[emteknetnz]

@GuySartorelli Now that we're using getCMSEditLink() - could you please redo the kitchen-sink CI run with the updated PRs

[GuySartorelli]

Sure, but all we did was change the name of things so it'll be the exact same result. With maybe some need to rebase the PRs just to make the sink run go green even though that doesn't change the result of merging them 😅

[emteknetnz]

Please update the sink run, it's unlikely though there may have been a small regression accidentally introduced. It should just a matter of:

• running composer update -W --no-install on the branch of recipe-kitchen-sink
• pushing the updated composer.lock file
• updating the link in the issue

[GuySartorelli]

Please update the sink run

I'm going to, gimme some time lol

It should just a matter of

I have to rebase some of the PRs as well most likely, as I mentioned above. This isn't the card I'm currently working on, so you'll need to wait til I'm ready to do this.

[GuySartorelli]

@emteknetnz You've approved #11338 but not merged it, but then you assigned the issue to me? Did you forget to hit merge?

[GuySartorelli]

I've rebased the PRs that had cmseditlink changes and rerunning sink.
Likely I'll have to rebase others too, but I'm letting it run as-is before I do that.