Quantcast
Channel: Issues for Drupal core
Viewing all 293387 articles
Browse latest View live

add a way for form validation to require confirmation rather than changed input

$
0
0

I think it would be useful in a lot of places if there were a way to make form validation ask 'Are you sure about this value?' rather than outright reject it.

Eg:

1. user enters 'kittens' in the field and submits form
2. validation message says: 'Entering 'kittens' here may invalidate your license. Are you sure you want to continue?'
3. Like regular form errors, this gives the user the chance to change the original values they entered in the entire form.
4. if the value remains the same upon submission, the confirmation validation then passes.

From a DX point of view, I imagine this would be done with an analogue function to form_set_error, say form_set_confirm.


Move help topics to core or the correct modules

$
0
0

Problem/Motivation

#2920309: Add experimental module for Help Topics should move the help topics from the experimental module to the correct locations - either core/help_topics or each extension (module/theme)'s help_topics directory.

This can only be done as the last step before going Stable, so it is postponed for the moment.

Proposed resolution

Move the topics to their final spots, and remove the special case that the experimental help_topics module can provide topics for other providers that is in the Discovery class.

Remaining tasks

Postponed on #3037230: Finalize the merge of Help Topics into Help
Make a patch. Don't commit the patch until Help Topics is being made stable.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Update help.help_topic_search to remove mention of Help Topics module

$
0
0

Problem/Motivation

In #3037230: Finalize the merge of Help Topics into Help, we have a sub-task to ensure that Help Topics module isn't mentioned in any other topic. It is mentioned in the help.help_topic_search topic:

Verify that the Search, Help, Help Topics, and Block modules are installed (or install them if they are not already installed).

The problem is that in #3087499: Merge Help Topics classes into Help with BC layer, we are moving all of Help Topics' help topics to the core Help module. So, to avoid a patch or MR that applies to a moved file and inaccurate instructions, let's postpone this change until Help Topics' merge into Help has been completed.

Steps to reproduce

Open the file core/modules/help/help_topics/help.help_topic_search.html.twig (assuming the move is complete, otherwise, look in core/modules/help_topics/help_topics), and see that this topic mentions "Help Topics" (the module).

Proposed resolution

In core/modules/help/help.help_topic_search.html.twig,

Update the following text:

Verify that the Search, Help, Help Topics, and Block modules are installed (or install them if they are not already installed).

To:

Verify that the Search, Help, and Block modules are installed (or install them if they are not already installed).

Remaining tasks

- Wait for #3087499: Merge Help Topics classes into Help with BC layer to be fixed, which moves this help topic to its new location in core/modules/help/help_topics.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Help Topics (which has been an experimental module in Drupal core) has been merged with the core Help module. The instructions for configuring Help search have been updated to no longer require the installation of Help Topics (as it no longer exists as a separate module, but has been merged with Help module).

Merge help topics admin theme test into base class

Move testing of help topic rendering into InstallUninstallTest

$
0
0

Problem/Motivation

As part of #3066512: Add checks for syntax and display of help topic Twig template files, we are adding a test that installs all the modules and themes, and then verifies that all help topics can be rendered. That test class is core\modules\help_topics\tests\src\Functional\HelpTopicsRenderTest.php.

As part of #3037230: Finalize the merge of Help Topics into Help, we should move the test of help topic rendering into InstallUninstallTest, in the assertHelp method
https://api.drupal.org/api/drupal/core%21modules%21system%21tests%21src%...

That method is currently verifying some things about hook_help (which we'll be removing/deprecating), and it should instead verify that all of the help topics for that module can be viewed. We'll need additional tests to do the same for themes and install profiles, which cannot have hook_help but can have help topics. I haven't yet investigated where those should live.

There's a trait from that other issue in core\modules\help_topics\tests\src\Kernel\HelpTopicDiscoveryHelperTrait.php that is helpful for finding help topics in a given directory.

Proposed resolution

I think we need to do the following:

a) As in the current HelpTopicsSyntaxTest, with all the core modules and themes installed, run the syntax checks on all the help topics that exist. This will ensure correct syntax of all of the topics, and also that all the Related topics links exist.

b) With a given module, its dependencies, and the core required modules being the only modules installed, verify that all of the module's topics can still be viewed (same for themes). This will make sure that we aren't relying on another module/theme somehow that isn't actually a dependency, such as trying to make a link to a route that doesn't exist unless a certain module is installed... This may not be necessary if #3090659: Make a way for help topics to generate links only if they work and are accessible is taken care of.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add a setting to make description a required field for file items

$
0
0

Problem/Motivation

A site builder is able to allow the user to enter a description for the file field upload. However, in some circumstances, the description may be mandatory. Right now there's no way for a site builder to make the file field upload description mandatory.

Proposed resolution

Add a new setting for file items to require the file description.

Remaining tasks

Updated 5/23/23
See #85

  1. Framework manager review
  2. Add JavaScript test coverage for #states that support the progressive disclosure
  3. Manual testing
  4. Update the upgrade path tests. Is this addressed by f0a74cb? Or is there more work to do here?
  5. Add REST/JSON:API test coverage
  6. Question from manual testing in #100: If the description field is required for a media item, should it be available on file upload when you have a Media field?

User interface changes

A new file field setting that allows to enforce the description.

Site builder perspective

End-user perspective

API changes

None.

Data model changes

New, description_field_required, boolean key in the mapping of code>field.field_settings.file schema.

Release notes snippet

As a site builder, on a file field settings form, after checking Enable Description field, check the Require the Description field setting in order to make the file upload required.

Original report

If I add a file field and check Description, I don't get the option to make Description a required field. This results in the public seeing often-unfriendly file names instead of a meaningful description.

Steps: As admin:
1. Edit basic page
2. Add new file field

Actual result: Description is not prechecked
Expected result: Optionally, Description is pre-checked as the public-friendliest solution

3. Check Description

Actual result: No option to require description appears
Expected result: Check box to require description appears. Optionally, it is pre-checked as the public-friendliest solution.

As editor:
1. Add new basic page
2. Attach file
3. Don't fill in Description field
4. Save and publish

Actual result: No error
Expected result: Error

Form tokens are now rendered lazily, so forms now *can* be cacheable: stop setting max-age=0 on form token

$
0
0

Problem/Motivation

  1. #2559011: Ensure form tokens are marked max-age=0 made sure the form token (a CSRF token) was only set for authenticated users, and ensured it specified max-age=0.
  2. #2571995: GET forms shouldn't have CSRF tokens by default refined this to make sure that GET forms don't get a form token by default, i.e. only POST forms get this.
  3. #2463567: Push CSRF tokens for forms to placeholders + #lazy_builder then moves the rendering of the form token into a #lazy_builder callback, which means the rendered form can actually be cached, because the form token is rendered later, and therefore the rendered form is not always by definition bound to the current user/session, which is what made it uncacheable. But it keeps the max-age=0 that point 1 introduced, because removing that merits further discussion.
  4. This issue is about removing the max-age=0 that point 1 introduced, and having that further discussion.

#2552873-18: node/1 flamegraphs also points out how #2571909: CommentForm selects using the user formatted name caused a very big performance regression. #2571909 made the comment form no longer personalized per user, so we thought we made the form cacheable. But we forgot about the form token setting max-age=0, which then makes the full node display uncacheable!

Proposed resolution

Allow forms to opt-in to be cacheable. This would be done by adding #form_cacheable = TRUE to the top level element of the form. If that key is set and TRUE, the token will not set its max-age to 0.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Asset controller should validate filename prefix

$
0
0

Problem/Motivation

Reported by @Chi to the security team, but decided by me and @larowlan that it should be fine to fix in public as a critical bug.

Steps to reproduce

The asset aggregate controller validates URLs to prevent invalid ones from generating assets and/or writing to disk, however it doesn't valid the filename prefix (js_ or css_, this allows otherwise valid URLs to write to disk and potentially could be used for a disk-filling attack.

Proposed resolution

Validate the prefixes too.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Drastically improve Drupal's default linking experience in text fields

$
0
0

Problem/Motivation

Drupal is a CMS. Content creation is its strength — or it should be, at least.

It took until Drupal 8 shipping with CKEditor 4 before content creation had good usability out of the box — you'd have had to install https://www.drupal.org/project/wysiwyg plus a lot of manual tweaking before your Drupal 7 site had a good authoring experience.

Drupal 8 and 9 shipped with CKEditor 4 enabled by default. Drupal 9.5 and 10.0 will ship with CKEditor 5 enabled by default. It improves on the authoring experience on many fronts.

One front remains though: even though content creation covers the "C" in CMS, the "M" in CMS is not quite covered yet: Drupal enables you to manage the content through Views, but it makes no effort at all to facilitate linking from one piece of content to another. Even though that's quite literally the essence of the world wide web: web pages (nodes) linked to other web pages (nodes), forming one enormous graph.

Fortunately, there is a Module For That too: https://www.drupal.org/project/linkit. It has matured for twelve years in contrib! 🤩

I think it's high time we bring the essential parts of Linkit into Drupal core: no configuration, just linking:

Proposed resolution

Add the essence of Linkit to Drupal core:

  1. while writing content in CKEditor 5, make it easy to link to other content — links and URL fields are completely different beasts because they have
  2. automatically suggest links based on the host entity type (when writing text on a Foo entity, find Foo entities), as well as entity types marked as common reference targets except User (unlikely to link to) and Media (which has its own optimized CKEditor 5 experience already), which means that by default Nodes and Terms will also be searched
  3. require the (newly added) entity_links filter to be enabled, which is conceptually exactly like \Drupal\editor\Plugin\Filter\EditorFileReference (which handles HTML elements with data-entity-type="file" data-entity-uuid="*" src), but this will instead handle HTML elements with data-entity-type="*" data-entity-uuid="*" href) — this ensures links are always pointing to the latest URL alias 👍
  4. 🚀 improve the responsiveness of the autocomplete by applying the same private client-side caching optimization used by \Drupal\ckeditor5\Controller\CKEditor5MediaController::mediaEntityMetadata() and \Drupal\media\Controller\MediaFilterController::preview().
  5. 🕵️ for every suggestion: automatically list the author if the entity type has one, automatically list the creation datetime if the entity has one, and list both if the entity type has both — this helps remove the need for some of the configuration surface area

🤔 What does https://www.drupal.org/project/linkit have that this merge request does not?

  1. "substitution" plugins: \Drupal\linkit\SubstitutionInterface (introduced in #2786049: Make entity URL substitutions pluggable to support a wider variety of use cases. and the accompanying data-substitution attribute — I don't think it's necessary in 99% of cases — if you need this advanced feature, just use contrib Linkit 🤓
    ✅ @Berdir and others made the case that we need functionality like this. Solution: introduce link_target handlers for entity types. See #39 for details. CR: https://www.drupal.org/node/3350853.
  2. "matcher" plugins: \Drupal\linkit\MatcherInterface, \Drupal\linkit\ConfigurableMatcherInterface, etc. — just using an entity query to match the entity label is sufficient for ~90% of cases — if you need this advanced feature, just use contrib Linkit 🤓
    ✅ @Berdir in #18 and #21 articulated why using entity queries is problematic, and why we should use Drupal core's existing EntityReferenceSelection plugins instead! 👍
  3. "linkit profiles" config entities: \Drupal\linkit\Entity\Profile— to be able to choose exactly which entity types to match and how, use tokens to generate customized suggestion descriptions, et cetera. I believe point 5 above covers the 99% case — if you need this advanced feature, just use contrib Linkit 🤓
  4. (optionally) setting the title attribute on links based on the linked entity's label — if you need this advanced feature, just use contrib Linkit 🤓 → furthermore, on this issue this was reported to be problematic for accessibility in #51, #55 and #56

🫣 Which contrib modules does this partially or completely replace?
(Usage stats on March 30, 2023.)

  1. https://www.drupal.org/project/linkit (~128,000)
  2. https://www.drupal.org/project/media_entity_download (~7,000)
  3. https://www.drupal.org/project/ckeditor_entity_link (~5,200)
  4. https://www.drupal.org/project/media_entity_file_redirect (~500)
  5. https://www.drupal.org/project/ckeditor_link (~37,200 — D7-only)
  6. https://www.drupal.org/project/ckeditor_link_file (~2,100 — D7-only)
  7. https://www.drupal.org/project/ckeditor_link_user (~200 — D7-only)

And if this functionality is adopted by a site, then arguably most of the functionality in the following modules becomes obsolete:

  1. https://www.drupal.org/project/pathologic (~46,500) — in combination with the pre-existing editor_file_reference filter in core
  2. https://www.drupal.org/project/insert (~38,000) — in combination with the pre-existing editor_file_reference filter in core

🙏 I want to use this but I'm currently using Linkit, how do I switch?
Glad you asked!

https://www.drupal.org/project/linkit used the same data-entity-type and data-entity-uuid that \Drupal\editor\Plugin\Filter\EditorFileReference introduced >8 years ago. It's specifically designed for portability. And it makes the transition from the contrib module to this core feature trivial:

  1. Disable the linkit filter
  2. Enable the entity_links filter

That's it 😊

Remaining tasks

TBD

User interface changes

The CKEditor 5 linking experience becomes vastly better!

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

[meta] Tasks to deprecate Action module

$
0
0

Problem/Motivation

Track the steps needed to remove extension Action from core to contrib. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of extension Action was approved in #3266458: [Policy] Deprecate Action (UI) module in D10 and move to contrib in D11.

Remaining tasks

  1. Begin finding someone to maintain the contrib version of the extension.
  2. Move integrations implemented by other modules to the extension.
    Create child issues or child meta issues, as needed, to address the following points. Not all points will apply to all extensions.
  3. Do a thorough search of core for any remaining references to the extension. If references are found, outside of the extension, then create issues to remove the references.
  4. Create the contrib project with a stable release.
  5. Deprecate the core extension. Use the Issue Summary template or core extension deprecation. #3369912: Final steps to deprecate Actions module

Completed tasks

Enable bookmarking of AJAX views

$
0
0

Currently we don't track the state of AJAX views. Users trigger reloads, but no state information is logged. Specifically, it is not possible for users to return to a particular state, short of repeating the steps to get there (e.g., load page, click a particular pager link).

Ideally we'd have full browser history support, but that's difficult given the state of jQuery history plugins (sketchy).

An interim approximation would be:

* set a URL fragment when loading by AJAX
* on initial page load, look for a fragment and, finding one, load it.

Regexp matching in routes fails to evaluate Unicode regular expressions

$
0
0

Problem/Motivation

When defining a route, we can define a requirements clause, which may contain a regexp to match a route parameter, like:

g2.initial:
  path: '/g2/initial/{g2_initial}'
  defaults:
    _controller: '\Drupal\g2\Controller\Initial::indexAction'
    _title_callback: '\Drupal\g2\Controller\Initial::indexTitle'
  requirements:
    _permission: 'access content'
    g2_initial: '[\p{Ll}\p{Lm}\p{Lo}\p{Lt}\p{Lu}\p{Mc}\p{Nd}\p{Nl}\p{No} _-]'

Since Symfony 4.3 (included), these regular expressions are documented as supporting Unicode classes https://symfony.com/doc/4.3/routing.html#route-parameters which means the regexp matching needs to add the u modificator at the end of the regexp, as per https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php

However, in UrlGenerator::doGenerate we use this line to match requirements:

          if (!preg_match('#^' . $token[2] . '$#', $mergedParams[$token[3]])) {

which means we do not enable full Unicode matching beyond basic PCRE, unlike Symfony ≥ 4.3.

As a consequence, any route receiving a parameter matching one of these classes will throw an InvalidParameterException when invoked with a character like é.

Steps to reproduce

  • Define a route like the one above.
  • In some code, e.g. using drush core-cli try to generate a link to /g2/initial/é, like:
    $ug = \Drupal::urlGenerator();
    $ug->generateFromRoute('g2.initial', ['g2_initial' => 'a']);
    $ug->generateFromRoute('g2.initial', ['g2_initial' => 'é']);
    
  • Observe how the first case succeeds while the second throws the exception

Note that the problem does not exist when routing incoming requests, as symfony/routing handles the regexp correctly for us.

Proposed resolution

Append the u modificator to support full Unicode matching.

Rerun the example above: now both calls work normally, generating:

"/g2/initial/a""/g2/initial/%C3%A9"

As expected.

Remaining tasks

Implement change.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

The UrlGenerator can now correctly generate URLs to routes using full Unicode character matching with parameters outside the ASCII range.

Improve \Drupal\Tests\TestFileCreationTrait::generateFile() for PHP 8.3

$
0
0

Problem/Motivation

The test FunctionalJavascript/MaximumFileSizeExceededUploadTest started to hang in CI for PHP 8.2 alpha 1 and 2
It was caused by regression https://github.com/php/php-src/issues/11507
Ref #3366843-28: Fix tests broken on PHP 8.3

But the issue in that post_max_size could be hundreds of megabytes and generating such a big file char-by-char could be very time consuming for no reason

Steps to reproduce

check implementation https://git.drupalcode.org/project/drupal/-/blob/11.x/core/tests/Drupal/...

Proposed resolution

- use random generator to get sequence of bytes instead of char by char
- set limit on number of iterations
- refactor test as it does not require random file as testing controller's behavior

Remaining tasks

- discuss
- patch/review/commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Hux-style hooks, proof of concept

$
0
0

Problem/Motivation

In #3366083: Method attributes to implement hooks (hux style) we proposed to provide a new way to implement hooks, using object methods with attributes.
A similar system already exists in contrib: https://drupal.org/project/hux

In this issue we will do proof-of-concept implementation and experiments.

Once this is done, we can split out real implementation issues that can then be developed and merged one by one.
E.g. perhaps there will be separate refactoring issues as preparation for the new system.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Call to a member function transformDimensions() on null in template_preprocess

$
0
0

Problem/Motivation

Migrating node content from older Drupal system to Drupal 8 may carry some contents that have image with image_style that doesn't exist in the Drupal 8 system. In our case, image styles (Default, Preview) are exists in Drupal 7, but not in Drupal 8.

After migrating such content, and viewing it, the image module throw an error and preventing the node page render.

Call stack:
<strong>Call to a member function transformDimensions() on null in template_preprocess</strong>
template_preprocess_image_style(Array, 'image_style', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('image_style', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 490)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 54)
__TwigTemplate_b990021d9c53bb62452fd087f46528a41d0dcfebc30a9afe45ba263b28f82647->doDisplay(Array, Array) (Line: 432)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403)
Twig_Template->display(Array) (Line: 411)
Twig_Template->render(Array) (Line: 64)
twig_render_template('core/themes/classy/templates/field/image-formatter.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('image_formatter', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 154)
Drupal\entity_embed\Plugin\Filter\EntityEmbedFilter->Drupal\entity_embed\Plugin\Filter\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 155)

One way to solve this is to recreate the missing image style in the new system. But in case someone doesn't want that, at lease the page rendering should failed gracefully.

Instead of throw error upfront and prevent the entire page from rendering. I suggest it should "Inform the site builders why their image didn't work." Part of the image module has done that, but not in above senario.

Attached is the patch, open for suggestion.

Steps to reproduce

TBA

Proposed resolution

TBA

Remaining tasks

Add test

User interface changes

API changes

Data model changes

Release notes snippet


Allow persistent caching to be selectively skipped depending on cache backend

$
0
0

Attached patch fixes up some of the excessive caching we added during D7. In our zeal to avoid mysql load, we cache even fast queries because it is faster and more reliable to fetch from memcache, mongo, etc.

The patch creates cache_get_memory() and cache_set_memory() which no-op unless an in-memory cache backend is in use. Core won't set its DB backend to in-memory but memcache and others will. Setting this flag is all they have to do to gain these advantages.

You can see the node.module hunk of the patch that only a tiny change is needed at call time. This hunk refines the persistent caching added at #898360: Cache node types such that it only happens for memcache and similar backends. Upon positive feedback, I will add similar changes in other parts of core.

I think this is a good compromise. Open to other ideas.

Order of alter hooks is not always respected by ModuleHandler

$
0
0

Problem

The module handler does not respect the configured weight for extra hooks. I bumped into this issue when I tried to increase the weight of MY_MODULE in MY_MODULE_module_implements_alter() and run a hook_form_user_register_form_alter() and hook_form_user_form_alter() implementation after the ZZZ module's implementations. MY_MODULE's hooks were always run before the ZZZ module's hook implementations, although they should have been the last ones. (Your first guess would be that it caused by the alphabetical order, and you would not be wrong...)

This problem caused by the current impementation in \Drupal\Core\Extension\ModuleHandler::alter() which I beleive is overly complicated. In case of the described problem, it collects all base hook (hook_form_alter()) and all extra hook (hook_form_FORM_ID_alter() ) implementations, properly ordered by weights set by hook_module_implements_alter() implementations, then threw those ordered lists away and re-order the list alphabethically by doing this: $modules = array_intersect(array_keys($this->moduleList), array_merge($modules, $extra_modules));, then it calls hook_module_implements_alter()-s again only for the base hook (form) and re-orders the list. If your module's hook_module_implements_alter() does not change the weight of form_alter 's too - and for that the MY_MODULE_form_alter() function must exists, otherwise you get a RuntimeException - then your module's form id alters are not going to be called in the correct order.

Solution

Simplified the logic in the alter() function to do less magic but still call the base hook implementations first and if there is any implementation for the extra hooks, call them in the expected order too.

Centralize permission checks in a service

$
0
0

Problem/Motivation

Currently, all permission checks go through:

  • User::hasPermission()
  • UserSession::hasPermission()

Both check for UID1 and then call the role storage's isPermissionInRoles() method. This means that all of the code is contained in a class we can't alter and a handler we can't easily alter (only one module can swap it out). The upside is that all of core's permission checks eventually make it to either of those functions.

So why don't we move these checks to a service? If we make sure all permission checks happen in for example a permission_checker service, then we can more easily intervene in permission checks by decorating said service and doing our thing.

I'm asking this because we currently have 2 types of access checks:

  • Permission checks, which is Role Based Access Control (RBAC)
  • Entity access, where we use Attribute Based Access Control (ABAC) mixed with RBAC

The latter we can easily interact with using hook_entity_access, the former we can't. Modules such as Group, Domain, etc. could be significantly more powerful if we could also interfere with the former. We could have a proper Policy Based Access Control (PBAC) system like this, e.g.: Editors can only edit when on certain machines or during office hours.

Furthermore, if we combine Flexible Permissions with this patch, the Domain module could become insanely simple in architecture. Words cannot describe how awesome this could be.

Proposed resolution

  1. Move the code from User(Session)::hasPermission() to a new service and that's it.
  2. Potentially mark the old methods as deprecated in a future Drupal version and force people to properly inject said service.

Remaining tasks

Review, discuss and potentially adjust the PoC

User interface changes

None

API changes

New service, no BC break

Data model changes

None

Release notes snippet

TBD

Help Topics module roadmap: the path to beta and stable

$
0
0

Problem/Motivation

Once #2920309: Add experimental module for Help Topics has landed this issue will track the necessary work to get the module to beta and then a stable state (at which point it should be merged into the core Help module)

Proposed resolution

Current status

- Currently (as of Drupal 10.1.x), Help Topics is a core module with experimental status and located in core/modules/help_topics (few deprecated modules has topics moved in).
- We have 1 issues remaining in our roadmap to stable. (Plus 1 in the "needs discussion" section remaining, which is not well supported by frontend)
- Drupal 10.1 release is scheduled for the week of May 8, 2023. Help topics is not a high priority, so it would be best to target mid-April 2023 (at the latest) to RTBC all remaining path-to-stable issues, if Help Topics has a chance of being marked as stable in Drupal 10.1

Release Plan

In terms of the release schedule for Drupal 10, if this module is not stable by May 2023 (when 10.1 will be released), then it will need to wait until 10.2 at a minimum to become stable.

Normally for Experimental modules, the module gets to Beta, which triggers including it in a release as an Experimental module. Then at a later date, it becomes Stable and gets the Experimental status removed. But in this case, the plan is to merge the code into the existing core Help module, so that won't really work -- we won't really have an Experimental release of the module. Nonetheless, it is helpful to talk about getting to "beta" quality and then "stable" quality.

An alternative plan would be to ensure that all service names and other machine name patterns have the proper core namespace, and plan to have Help Topics eventually wrap the Help module code (whereupon the beta module would be hidden from the core UI, but not removed before 10.0.x). This paragraph is not the current plan, but we could change to this alternative plan at some point if we decide to on this issue.

[DONE] Roadmap for Beta (experimental status)

Once this is in Core as an alpha experimental module, we'll open a Meta issue to get this to Beta quality (which will be necessary to keep it as a live Experimental module in a full Drupal release). Here is a list of sub-issues that we currently have for that phase, all of which are must-haves to make "Beta" quality:

Tasks originally proposed for this phase that made it into the patch before initial commit, or have since been finished:

  • [DONE] Tests for translatability
  • [DONE] Enforcement of provider.string format for plugin IDs
  • [DONE] Addition of ability to scan core for plugins (besides themes and modules)

Roadmap for Stable

To get this module to be ready for a stable release, here are some issues we'll need to resolve/finish, all of which are must-haves to make "Stable" quality:

Needs discussion: maybe needed for stable

For full release, the plan is to move the functionality of this experimental module into the core Help module. Some questions to be thought about and resolved These are "maybe" needed for release -- should be discussed on the individual issues and decided there:

Once all of the required issues above have been resolved, and all the questions answered, this is the issue about the final steps to releasing:
#3037230: Finalize the merge of Help Topics into Help

This has several sub-issues:

  1. #3087499: Merge Help Topics classes into Help with BC layer
  2. #3025577: Move help topics to core or the correct modules
  3. #3144933: Merge help topics admin theme test into base class
  4. #3074040: Move testing of help topic rendering into InstallUninstallTest

Not part of the roadmap

These are things that were proposed or discussed, but aren't required as part of the Roadmap.

Note about deprecated/moved core modules with help topics

For core modules with help topics that have been deprecated in Drupal 9 and are planned for removal in Drupal 10, the 9.x policy is to move their help topics out of core/modules/help_topics/help_topics (here because of help_topics' experimental status) and into core/modules/MODULENAME/help_topics (making the module easier to remove in Drupal 10).

- #3264945: Move quickedit help topics to quickedit module and related #3265492: Fix inaccuracies in quickedit help topic (after the split from settings_tray)
- #3267052: Move aggregator help topics to aggregator module
- #3270905: Move Color help topics to Color module

Update Maintainers for the Help module

$
0
0

Problem/Motivation

Part of #3037230: Finalize the merge of Help Topics into Help

As help topics are merged let's move maintainers to help module

Proposed resolution

Move maintainers of help topics to help module

Remaining tasks

agree/patch/commit

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 293387 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>