Early Bird Registration for DrupalCon Atlanta is now open! By registering during our Early Bird Registration window, you’ll save $100. This window ends on 19 January 2025 and will go by quickly, so don’t wait!
Problem/Motivation
Right now in our in our validators we have logic like this
if ($stage instanceof ConsoleUpdateStage) {
to allow determining the stage is regular or console. If others do this our stage classes aren't really internal
Steps to reproduce
Proposed resolution
Add getType method to stagebase
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork automatic_updates-3404429
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:
Comments
Comment #3
tedbowComment #5
phenaproximaI'm pretty much happy with this, although it occurs to me that we could make
type()
a protected property or class constant, rather than a method, and still keep our rules about subclasses overridding it (\ReflectionProperty
and\ReflectionClassConstant
both have thegetDeclaringClass()
method).The only downside is that it would no longer have any dynamism, but I'm honestly not sure if we really need that anyway.
Comment #6
tedbow@phenaproxima re #5 I changed this to protected string. I agree it simpler.
As long as it is not a constant it can still be somewhat dynanmic.
for instance we could have have our attended and unattended stages be one class with 2 different services using this class. Just add a
$more
property to the constructor and in the constructor set the$this->type
value.Comment #7
phenaproximaCouple of small things but this otherwise looks good to me.
Comment #8
tedbowAccepted suggestions and 1 more cleanup
Comment #9
phenaproximaOne suggestion but RTBC overall.
Comment #11
phenaproximaComment #12
tedbowugh the test failure I think is #3397228: Possible random failure in build tests for cron updates. 3.0.x is passing after the merge