Active
Project:
Drupal core
Version:
main
Component:
other
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
31 Aug 2013 at 20:29 UTC
Updated:
2 Aug 2024 at 11:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mac_weber commentedHuge patch coming
Comment #2
mac_weber commentedComment #3
mac_weber commentedThere was one missing property that YesCT's script did not catch
Comment #5
mac_weber commentedprotected $validated_viewswas not listed in the meta issue. This the property I added on patch at comment #3Comment #5.0
mac_weber commentedList properties to be changed
Comment #5.1
mac_weber commentedtell which property was not listed at meta issue
Comment #6
yesct commentedlooking at what config files were changed.
trying to see when we should change properties that effect config or not.
147 yml files
23 of those are not for tests
here is a sample
attached is just the changes to the original class file. letting the bot test it so we can see where it causes fails.
and below is just the property definitions with more context lines (got with: git diff -U7)
I'm not sure that entity type change in comments is the same entity type from this views wizard class. Maybe a too wide search and replace was done.
I'm going to try the phpstorm refactor and see what I get.
Comment #7
yesct commenteda) Did just one property the base table property, with the "in comments" option selected in phpstorm refactor rename. http://screencast.com/t/EbrFc12x0
It changed many files.
Here is a snip of a couple:
b) is only a part of that, just in the WizardPluginBase class file (but done from that with comments option checked).
c) Then thought.. hm. let's try it without the comments option, see what files are changed. and compare the two diffs, at least compare the files changed. I think we just want to change the comments that are in files that are changed when we refactor without the comments option. (only change comments in files that are changed, and look at each of those to see if they make sense to change.) http://screencast.com/t/MblkHFeLx
Here is a diff of b (with comments) and c (without comments):
Those are the things I think we should look at.
Comment #8
yesct commentedHere is a easier to read diff of 7b and 7c.
7c might be good. an irc conversation with @tim.plunkett helped me figure out where the ['base_table'] part of the definition array is coming from.
tl;dr
annotation in core/modules/views/lib/Drupal/views/Annotation/ViewsWizard.php
tim also said "we don't use camel case in annotation strings"
---- notes ----
notes from trying to find ['base_table']:
In the WizardPluginBase
it is expecting a definition property, but we are not setting definition here. So it must be set in the parent when the parent::__construct is called.
To find the parent, I looked at the class definition:
abstract class WizardPluginBase extends PluginBase implements WizardInterface {(at first I opened the wrong PluginBase... but then looked in the WizardPluginBase use statements)
use Drupal\views\Plugin\views\PluginBase;in core/modules/views/lib/Drupal/views/Plugin/views/PluginBase.php
it has a definition property
so I looked to see where the ['base_table'] part of definition was set. Its constructor is
So it comes from $plugin_definition or $configuration.
Looking to see where and when in those, I did not see it.
The create is just
I thought maybe from something it extends.
abstract class PluginBase extends ComponentPluginBase implements ContainerFactoryPluginInterface {but could not find ComponentPluginBase. Turns out it is an alias
use Drupal\Component\Plugin\PluginBase as ComponentPluginBase;But did not find 'base_table' in core/lib/Drupal/Component/Plugin/PluginBase.php either.
sooo... where is it coming from? tim pointed to an example that extends WizardPluginBase:
So it is in an annotation.
The annotation comes from core/modules/views/lib/Drupal/views/Annotation/ViewsWizard.php
I wondered how I could know that, besides guessing that I should look for something that extends it...
* We thought adding a @see to all of the base classes to their annotation classes would be a good idea (and needs to be a separate issue).
And, this means that since the annotations are not using camelCase, and this issue is not about core/modules/views/lib/Drupal/views/Annotation/ViewsWizard.php anyway, we should keep it like 7c, because those are parts of the definition array.
Comment #9
yesct commentedforgot the diff. oops. here it is.
Comment #10
_12345678912345678 commented#7: drupal8.views_module-WizardPluginBase_coding_standards-just_baseTable_withoutcomments-2078593-7c.patch queued for re-testing.
Comment #10.0
_12345678912345678 commentedadded file name and link to drupalcode
Comment #11
alansaviolobo commentedreroll
Comment #12
yesct commentedDid you reroll (apply the old patch when it applied and then merge with head) for 7c? Or did you make a new patch from scratch using a IDE to refactor?
Comment #13
yesct commentedunassigning since it's been a while since @Mac_Weber worked on this one. Just comment back, make a new patch, or review to jump back into it.
Comment #14
yesct commentedthese look like unrelated changes to this issue. If those full paths need to be changed it should be done in a separate issue.
Comment #15
yesct commentedSince this is a normal task,
doing https://www.drupal.org/contributor-tasks/update-allowed-beta
to evaluate for https://www.drupal.org/contribute/core/beta-changes
This is not critical,
not one of the unfrozen areas only,
not a prioritized change,
not a major,
which means, this should be done in 8.0.x only *if* it reduces fragility.
This doesn't sound like that...
But it also is not disruptive, since the properties are already protected, and would be isolated to internal to this class.
So I think this would only get in the beta under "not disruptive".
[edit:]
See #1518116-86: [meta] Make Core pass Coder Review for related coding standard postponing discussion
Comment #16
alansaviolobo commentedI tried applying the patch first. but since it conflicted and didn't change all the occurrences, I preferred to start from scratch.
Comment #17
yesct commentedfor the out of scope changes noted in #14:
#2376403: Some full name space paths wrong in comments in WizardPluginBase
--
note this issue needs to have those changes removed from this patch.
when doing that, the instructions for an interdiff will probably be useful https://www.drupal.org/documentation/git/interdiff
Comment #18
alansaviolobo commented@YesCT, thanks for your suggestions. have removed the changes to the file paths.
Comment #19
alansaviolobo commentedComment #20
mac_weber commentedComment #21
alexpottI have just postponed all the rest of #2052421: [META] Rename Views properties to core standards's child issues. This was the only issue at RTBC. I've checked that the properties being changed here are only used in the base class. This change is not disruptive BUT it is not allowable according to the beta rules. It has been worked on since 31 Aug 2013 and maybe I would have committed it if this was @alansaviolobo's, @Mac_Weber's or @YesCT's first commit credit. I'm not enjoying postponing this issue but we've come up with a process and we should stick to it. Sorry.
Comment #25
andypostComment #32
vsujeetkumar commentedAbove patch fail to apply, Need Re-roll.
Comment #33
vsujeetkumar commentedComment #34
vsujeetkumar commentedRe-roll patch created, Please review.
Comment #36
vsujeetkumar commentedFixed the test, Please review.
Comment #37
andypostGreat to see tests pass,, now it needs Deprecated property trait and tests to make sure contrib can catch this rename while backward compatibility is preserved
Comment #43
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #44
quietone commentedThis is a coding standard fix and they are now done by sniff, not file. See #3346468: [meta] Fix class properties violating Drupal.NamingConventions.ValidVariableName.LowerCamelName
Comment #46
quietone commentedComment #47
quietone commented