In a slack discussion about ✨ Allow storing telephone number in E164 format Active catch suggested this be re-opened. He said that originally having field types in core meant people didn't have to find and download them. However, now with Project Browser and recipes those reasons are not so important.
I don't know how I made such a basic mistake. I applied the suggestion.
I think the answer to that is yes. This provides the validation that other issues can build on.
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
Now that the code on api.drupal.org is rendered using a four-space indentation and two empty lines are put between functions/methods,
Why is the format of the source changed?
Testing locally the link is displayed on class files but it was displayed on *.api.php.
It has been over 9 years since there was work here. So, checking in here to find out if this is still relevant. Is it?
I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks
It has been over 9 years since there was work here.
Can someone confirm if this is still relevant?
I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks
It has been over 9 years since there was work here. I read the issue and I am not sure what is to be tested here.
In any case, does anyone know if this is still relevant?
I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks
Is this still a problem?
I tested the patch on 11.x and the results was Warning: Undefined array key "field_number_value" in Drupal\views\Plugin\views\filter\NumericFilter->valueForm() (line 271 of core/modules/views/src/Plugin/views/filter/NumericFilter.php).. I don't know Views well enough to take this further.
Can someone confirm that this problem is still valid?
I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Triaged for Bug Smash. I tested on 11.x yesterday and the problem exists. There hasn't been work here in 9 1/2 suggesting that the community is fine with the current behavior.
There are many tags here, so I will not add more now. But this will need an Issue Summary update and conversion to an MR.
And definitely read the first sentence of the issue summary before working on this!
I added the proposal from #11 and the link to the issue summary.
I am not sure what the scope is here. The issue title does not match the issue summary. Ideas?
#8. Added a sentence at the beginning that it will be deprecated and direct to the plugin section. Since we still need to support annotations I left the remainder of the chapter.
#9: Fixed
I also made more conversions from annotation to attribute in core.api.php and entity.api.php.
Actually, this will be resolved in the parent issue.
@shubham_mishra, Welcome to Drupal!
I want to pass on that for Drupal core, it is preferred that contributors add a comment that they are working on an issue instead of assigning it to themselves. See Assigning ownership of a Drupal core issue → .
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
Restoring template. The issue template is used to track progress and various tasks on an issue.
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
Restoring template. The issue template is used to track progress and various tasks on an issue.
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
Restoring template. The issue template is used to track progress and various tasks on an issue.
quietone → created an issue.
quietone → created an issue.
quietone → created an issue.
In the parent issue it was decided to move Field Layout to contrib. That makes this a won't fix.
Thank you to everyone who contributed on this issue.
I reverted the changes to ConfigImportUITest.php and then changed it to a test module instead of Ban.
Just updating the IS to strikeout the recent fixes.
+1 from me as well. For the same reasons as stated above. as well as sharing his knowledge in BugSmash.
In general, adding technical words to the dictionary makes sense. However, do we allow 'words' that are only used in a few files, or a sub system, or CSS or JS? An 'word' unique to a subsystem or language can be a spelling error in an English comment or in a variable, class or method name.
This change has such an example. If 'wdth' and 'wght' are added to the dictionary then those 'words' are available for use throughout core. But in the context of comments and naming variables, methods and classes, they are most likely misspellings of 'width' and 'weight'. So, I think this should not be done.
While reviewing this I learned that 'ital' is now the English dictionary. So, that could be removed and we will have to manually catch where 'ital' is a misspelling.
$ yarn cspell trace ital
...
ital * en_us* node_modules/@cspell/dict-en_us/en_US.trie.gz
Shows that this is now in the English dictionary. So, this could be removed.
quietone → created an issue.
Linting passed, so setting for review.
This issue this was postponed on was fixed 9 years ago. Since, then there has been no discussion here for 9 years. Perhaps this has been resolved?
I am setting the status to Postponed (maintainer needs more info) to find out if this is still needed. If confirmation that this is needed is not given, this may be closed after three months.
There has been no activity here for over 9 years.
Is this Plan still needed?
There has been no discussion here for 9 years. Perhaps this has been resolved?
I am setting the status to Postponed (maintainer needs more info). If confirmation that this is still a problem is not given, this may be closed after three months.
I think this is outdated, possibly finally by #3253148: Remove IE from core's browserlist, remove non-essential CSS importing and recompile assets → .
If there is work to do here, re-open or make a new issue.
theme_feed_icon() was removed from core in 2013. Therefor, closing as outdated.
quietone → created an issue.
quietone → created an issue.
There were no conflicts
Adding related.
quietone → created an issue.
This was discussed by the committers and the DA at a monthly meeting. We all value the work of contributors and want to acknowledge their work through the credit system. We also know first hand that adding credit is demanding and takes time to get right. The people who can add credit are also the committers who already have a backlog of issues in the RTBC queue. In the end, it was decided it in the best interest of the Drupal project that credit is cleared for all open core Drupal 7 issues and then they are closed.
participants: catch, drumm, longwave, Jpoker10 and myself.
This test does need to run as the root user. Migration from the UI must be run as the root user..
I thought I fixed those, I must have forgotten to push. Anyway, fixed remaining instances and updated the CR.
quietone → created an issue.
Since there has been no discussion here for 8 years I am asking if this still needs to be done. Is this still relevant?
Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
The sample code referred to is for Drupal 6.
Since there has been no discussion here for 14 years I am asking if this still needs to be done. Is this still relevant?
Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Since there has been no discussion here for 14 years I am asking if this still needs to be done. Is this still relevant?
Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Since there has been no discussion here for 14 years I am asking if this still needs to be done. Is this still relevant?
Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
are structured around two Organic Groups content types:
Ah, that is the information I lacked. Thanks, for sticking with this until I understood.
That brings me back to not being sure what work is left that needs discussion. The points that catch raised have been addressed.
Changing status in another attempt to get feedback.
I am not sure what is to be reviewed here.
What is the purpose of 🌱 Make views consistent in code, schema, tests, and APIs Needs review
The issue summary needs an update. I had to read all the comments to find that what should be reviewed is a documentation. Let's make it easy for reviewers to know what to do, thanks.
The documentation page is the Drupal 7 documentation. So, it needs to be moved to the Drupal wiki.
@smustgrave, Thanks for taking care of us! I came here to add an issue that I just closed.
As the image shows, this is outdated.
The code change in the patch has been changed since the patch was submitted. The 'h4' is still there but the #suffix has been removed. 🐛 Claro's preprocessing of field multiple value form's table header cell removes potential changes by others Fixed
So, is this still relevant to 11.x? If we don't receive confirmation that the problem is valid, it may be closed after three months.
Checking in on this issue. I can't gather enough information from the issue summary to test this, maybe someone else can.
Anyone know if this is still a problem? If there is no confirmation that this is a problem it may be closed after three months.
Can we agree on using GitLab pages?
Simplify title. No need to refer to the other issue in the commit message. The [regression] informs the reader there is an older issue involved.
https://git.drupalcode.org/project/drupal/-/merge_requests/8417/diffs#note_442553 @alexpott pointed out cases where the new code and the old produce different results. I don't see those test cases. If they are the, add a comment in the code.
To test that the results have not change I removed the changes from breakString and all the long string test cases from testBreakString. I expected the test to pass, it did not. These are the cases that failed.
- HandlerBase::breakString('word:word1+word:word2+word:word3');
- HandlerBase::breakString('word:word1 word:word2 word:word3');
- HandlerBase::breakString('word:word1,word:word2,word:word3');
- HandlerBase::breakString('word:word1');
How will this change of behavior affects sites?
Sorry, the title, and thus the commit message, do not match what is in the MR.
@jwilson3, An Organic Groups page is a Guide? And if so, what does Organic Groups have to do with the documentation?
quietone → created an issue.
Comment #1 refers to discussion in the group but I am not able to find it. That was 15 years ago and there is no discussion here.
Is there interest in pursing this or should it be closed?
This issue is 14 years old and I want to check to see if there is still interest in a new requirements page for email?
If you support this take a moment and add the text that you think should be on the page. Thanks.
@ressa, Thanks. What is an Organic Group page and non-Organic Group page in the context of this discussion?
This issue is RTBC, can someone summarize what exactly still needs to be done?
I reviewed the change and there is nice work here to make sure the 'end group' is in the correct place. Unfortunately, this found a bug in the sniff, Drupal.Commenting.InlineComment.DocBlock. For that, there is a few more steps here. They are in my comment on the MR and I have added that to the issue summary.
Each of the steps are suitable for the 'Novice' tag, so I am leaving the tag.
I also was to pass on that it is not necessary to open a NR to run tests. Tests can be re-run using the GitLab UI.
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
Drupal 10 is now an LTS, or in maintenance mode, and there are limited allowed changes for a maintenance minor release → .
Thanks for the explanations and the prompt updates. Also kudos to @nicxvan for understanding my intent despite my typos.
I focused on just resolving comments and ignoring minor problems that don't effect meaning. Next, for me, is to think about adding this to module.api.php.
I recall using my list and moving some issues back to D8 and assigning credit for the commit. It was tedious and time consuming work to fix mistakes made in the past about issue management. I actually think my time for working on is better spent on current issues and discussions.
I thought it prudent to look at my list and to determine how many issues are left to check. Turns out I can't find it. All I know is that the issues to check are less than 113.
I started to review the comments here and have not finished. The main conclusion I have reached is that documentation for this should be in module.api.php. Then, the many references to the change record(s) should direct to the relevant section in module.api.php.
Un-assigning per Assigning ownership of a Drupal core issue → .
Trying for a better commit message. See List of issue fields → .
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .