Adding a direct link to the module landing page. The breadcrumb above the content is often overlooked, making it difficult for users to navigate back to the main documentation landing page for the module, which is where you then find a link to the module landing page.
Tremendous work getting this resolved! Just want to add incase it's of help to anyone else that comes across this:
It's essential to know that while the CKEditor update in Drupal 10.1.3 addresses the fundamental issue with empty inline elements, additional steps may be required for specific configurations.
Go into Text Formats (/admin/config/content/formats), choose text format to edit (ie Full HTML), then under CKEditor plugin settings -> Source editing, manually add HTML elements to the "Manually editable HTML tags" list to ensure their preservation.
For example, to preserve <a id="exampleanchor"></a>, you need to enter <a id>, then save the Text Format.
Explicitly communicating that you're not installing "Drupal concepts" but rather installing Drupal and simultaneously gaining an understanding of important Drupal concepts.
Acknowledging the site-building nature of administering and setting up core modules, I propose exploring a placement under "Administering a Drupal Site" for a more intuitive experience, aligning with non-code aspects of site construction. Your thoughts on this perspective are valued.
from: /docs/develop/core-modules-and-themes
to: /docs/administering-a-drupal-site/core-modules-and-themes
Tried to making the opening intro paragraph start off a little less abrupt and reduce the overall complexity.
Drupal Symfony Mailer
https://www.drupal.org/project/symfony_mailer →
Migrating from swiftmailer
https://www.drupal.org/docs/contributed-modules/drupal-symfony-mailer/mi... →
Might also want to look at Mail System:
Claro content editing layout is still broken in 10.1.5.
Confirming patch in #23 fixed the layout issue.
Fixed
You are right, looks like since this CR was created in '22, the optimal route has become to change base to Stable 9.
Thanks @ressa and @hansfn for all your efforts. This page reads better, especially with the CODE blocks.
An aside, I wonder why the URL page name has a leading underscore.
https://www.drupal.org/docs/official_docs/en/ →
_evaluator_guide.html
I'm not sure what the rules are for the Flag Star Follow block, but it seems like these were specially converted nodes? Reading the note on the landing page of this project seems to be connected to these two pages.
https://www.drupal.org/project/official_docs →
The two pages that were originally maintained via this repository were converted to standard Drupal.org nodes in April 2023. You can edit the pages directly now.
The two currently published pages from this project are:
- Evaluator Guide
- Local Development
@phjou @rimbu002
in `/admin/config/content/embed` Each embed type needs to have an SVG uploaded for their toolbar button icon to show up correctly in ckeditor5.
It's clear to me now that D9 EOL is Nov 1st 2023. When I first visited the page, I was only looking for confirmation of the EOL of D9 but I wasn't confident I understood that previously. As a user, I was trying to determine the definitive EOL for D9, and found myself in the "Core" section of documentation. This page seems to lean more toward Release Cadence (developer/contributor focused), and that makes total sense, but EOL dates have such critical implications for planning and budgeting that I think they might benefit from a central release policy page.
I saw an earlier
comment →
that references a similar page:
https://www.drupal.org/about/core/policies/core-release-cycles/core-supp... →
A couple ideas for possibly separating the info into two pages:
- Release Status and Lifecycle Policy (user-focused)
- Current stable, EOL, and upcoming versions
- Support and maintenance timeframes
- End of life policies
- Links to advisories and announcements
- Drupal Release Cadence (developer/contributor focused)
- Major, minor, patch release frequency
- Release number conventions
- Release planning process
- Commit freezes
- Testing requirements
- Branch management
- Steps for contributing
Based on your experience, you likely have better ideas! I mainly wanted to share some constructive feedback. I greatly appreciate what you've provided maintaining the documentation.
Thank you for clarifying that no security coverage is synonymous with EOL. just wasn't making that connection, but it makes perfect sense to me now. I appreciate your patience helping me understand that.
I think simplifying to "D9" entirely helps, but I'm still confused if it's end-of-life for D9 on November 1st, 2023?
Under Core Development Cycle → it says:
End of security support for Drupal 9 (due to Symfony 4 EOL).
Under Drupal 7 and 9 end-of-life dates → it says:
Drupal 9 reaches end-of-life due to its dependency on Symfony 4.
- Reference: Symfony 4.4 release checker.
Apologies if I am completely misunderstanding the purpose of these tables.
In the "Current development cycle" table, it specifies that November 1, 2023, marks the end of security support for Drupal 9.5.x due to Symfony 4 EOL. This implies that while security updates will cease, it doesn't explicitly state that Drupal 9 as a whole will reach end-of-life.
On the other hand, in the "Drupal 7 and 9 end-of-life dates" table, it states that November 1, 2023, is the date when Drupal 9 reaches end-of-life due to its dependency on Symfony 4.
The wording here might lead to some confusion, as it doesn't explicitly clarify whether "end-of-life" in this context refers to the end of security support or complete cessation of support.