quietone → created an issue.
I migrated the Organic Groups documentation for the latest D7 version to the new system. This is a good test case due to the size.
The problems I found are
- Because the hierarchy is lost I had to create new Guides to keep the organization. Then when putting pages into the newly created guide, I would get an error about something not being in the guide. Sorry, I didn't save the error. That meant re-saving every page at least twice. 2) 15-30 seconds it takes for a page to load on edit.
- For each top level page I had to created a guide. Since the top level page is also migrated, that meant that the top level page is now obsolete.
- I can't delete the obsolete pages, so there is more work for someone else.
- The link on the project page is still a URL instead of nice text. In this case, perhaps because that top level page still exists for the D6 and earlier D7 version docs.
- This is the responsibility of the project maintainers and they should be involved.
What I am think now is that we should have an issue generated for each project to alert the maintainers that the docs are leaving. The issue should be Critical and an expected date of documentation deletion given. This is a related issue I made for the Tour module, 📌 Add link to module documentation on project page Active . Not quite the same as it does involve migrating old documentation.
Add content from original top page. Trim to fit 1000 character limit
Drupal 11 is in the title, so dropping the first 11.x
Really put statistics in the correct heading and add information about .htaccess change
I still disagree with this.
As stated in the Issue Summary the Drupal Style Guide does not have an example for the word 'canceled'. There is no evidence on this issue that the version 'canceled' is a standard. The recommended resources to use are provided on Content style guide → . When searching those resources both the American Heritage Dictionary and the American Oxford shows both 'canceled' and 'cancelled' as acceptable.
I see no reason to change something that the dictionaries accept. And, especially, when there are many misspelled words in dictionary.txt that need to be fixed.
I think this is a won't fix.
quietone → created an issue.
@shivamsen_12579 and @ravi kant, there is no agreement on the solution here, see #5. We should decide if the change should be made first.
Adding to parent.
Yes, let's disable comments on change records. They are simply to record a change that occurred at a given time. I agree that If a change is needed to the change records itself, then someone should just edit it. If the change caused a problem then an issue should be opened in the relevant issue queue so that maintainers and the community know about it. For me, this part is crucial because I would guess that most maintainers monitor their issue queues and not the change records for.
And for other discussion or information sharing there is Drupal Slack and blog posts.
In regard to cleaning up existing comments, I don't see the need to do that. I think they can stay as is.
So, while I was writing this I was interrupted by a call that was demanding. When I came back I missed alexpott's comment about changing to typed properties. That's a good point to consider. I'll ask the other committers.
I have read the issue summary and comments. There is nice work here on keeping the issue summary update as well as figuring out how to do the deprecation. All of which is much appreciated!
What I can't find is a reason for changing the third party code. Looking into the history here, the original version of this issue summary questioned fixing the coding standards by using a simple statement, "Fix Coding Standards?". In #16 I stated that I confirmed that we don't change third party code, and this point is again confirmed alexpott in #46. Changing the code for coding standards was then questioned in #29 but then there is no discussion on that topic before it was added to the issue summary in #35. It is unfortunate that I didn't update the issue summary at the time on #16.
So, what to do here? We should remove the @todo but only that line. And keep the line that excludes the directory from coding standard checks.
And I did some research. The @todo was introduced in #2887052-22: Ignore Diff component files in phpcs coding standards → . It seems there was a misunderstanding about what files were going to be to changed,
I am not so sure about this. The word 'cancelled' is in the cspell American dictionary, yarn cspell trace cancelled. And this article from Merriam Webster explains the history and why both are acceptable in American English.
Adding parent.
Create a Guideline section and move all the over arching concepts to the new section.
Move experimental extensions to separate heading
In 🐛 Adding media library openers use autoconfigure and tags in 10.3.x has BC consequences Active alexpott noted that this needs a change record.
Took a minute before I remembered how to update jquery but I got there. I did this locally and the resulting changes matche the changes in the MR. And it applies to 110.0.x as well.
That is the first time I recall having a failure on the test and it is not listed on 🌱 [meta] Known intermittent, random, and environment-specific test failures Active . I've added a comment over there.
Tests passing now. This is still RTBC
I've only seen this once and noting it here.
Drupal\Tests\layout_builder\Functional\LayoutBuilderBlocksTest::testBlockPlaceholder
Behat\Mink\Exception\ResponseTextException: The text "Placeholder for the
"The block label" block" appears in the text of this page, but it should
not.As I went to bed last night I realized that I didn't run PHPStan on all files. Once I did, I get errors, including the one above. So, yes rebuilding the baseline makes sense.
There is a failing test, core/modules/layout_builder/tests/src/Functional/LayoutBuilderBlocksTest.php, on MR8085. I've started a retest
There is a failing test which is easy to fix. Otherwise this is correct.
I was thinking the same thing, so tagging for a followup. It's too late to do that now.
But why are changes needed to the baseline? There were no errors before they were added.
I applied the diff to 11.x and searched for 'removed from drupal:11.0' and get two results, in
- \Drupal\KernelTests\Core\Render\Element\DeprecatedElementTest::testBuildInfo
- \Drupal\element_info_test\Element\Deprecated
That is for testing that the deprecation process works for a deprecated render element.
@hansfn, thanks. Even the latest D7 documentation is over 30 nodes. :-(
I did start on migrating 'Organic Groups' and got this message
Hierarchy will not be saved! All child pages will be on the same level with the parent page in relation to the documentation guide.
So, this will take more work than I expected. It seems like I should do 1) migrate a set of pages, say Setup → 2) Create a Guide, 'Setup', in OG 3) Move all the pages just migrated to the new guide. And then repeat that for each part of the OG documentation.
The only question I have here is why are there comments added to the the phpstan baseline?
I updated locally on both 11.0.x and 11.x and got the same results.git
Fix formatting in IS
Add what core version the contrib extension must support.
@FeyP, thanks for adding 'class properties'! It has taken one thing off my list.
I modified the section to be consistent in style and content with the rest of the document. That included removing the examples of when to use this deprecation. Like all deprecations, when to use them is in the BC policies and are not listed in this 'how to' document.
@andypost, I think we can skip the change record and add this to the release notes
It is going on 10 years and there has been no further discussion here or an update to the issue summary. The function mentioned in the issue summary was removed in 2014, #2326891: Convert system_element_info() to Element classes → . And comment #2 was sure this was still relevant. Based on that I am closing this is outdated. I trust someone will correct that if it is wrong and there is work to do here.
Tagging to add the removal of the dependency to the release notes.
Trying to remove the 'See more' from the snippet
quietone → created an issue.
This was fixed in Drupal 8