Problem/Motivation

Look at this code, it's an inconsistent mess of title_prefix, title_attributes and label!

<div{{ attributes }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}

  <div{{ content_attributes }}>
    {{ content }}
  </div>
</div>

Proposed resolution

The fix: The variables printed in a template file for a title of a block should to be called title.

User interface changes

- none

API changes

- none

Related Issues

#1591806: Change block "subject" so that it's called a (admin_)label like everything else on the theme layer
#1591830: Change comment "subject" so that it's called a title like everything else in the template file (and all other template files)
#1825216: Name variables consistently across all templates (preprocess)
#1939234: Change node "label" so that it's called a title like everything else in the template file (and all other template files)

Beta phase evaluation

What is the problem to solve?

Frontend developers not coming from Drupal usually do not know Twig. By providing support for multiple frontend frameworks we could provide support for modern JavaScript frameworks like React, Vue or Astro besides Twig. This would make Drupal a much more attractive option for those developers and evaluators, since it's not necessary to re-train frontend developers on Drupal.
The modern frontend option would allow building sites with high-interactivity with modern JavaScript frameworks without a fully decoupling, like inertia.js does for Laravel.

Who is this for?

Frontend developers not familiar with Drupal, evaluators.

Result: what will be the outcome?

Re-architect Drupal such that the frontend rendering process is not coupled with the rest of Drupal. Make Drupal render into a tree of high-level components and add page metadata, then let the frontend take care of rendering those. The tree must be pure data (e.g. JSON) and provided via some HTTP API by page, e.g. /page-api/{path}. Frontends fetch this API and render the result, either server or client-side.

By default, Drupal core could ship with a twig-based frontend which uses symfony request/responses to internally resolve http requests without network overhead. The rendering happens de-coupled from the rest of the application, thus any lazy-rendering would have to trigger another (internal) http request.

Next to twig, we could provide one or two JavaScript based frontend frameworks which are officially supported, while the community could add more. CMS builders working with core could choose their preferred frontend framework or even allow site-builders to choose from supported options.

Implementation example

Lupus Decoupled Drupal already follows that model, but does not implement a twig-based frontend. Still, it can serve as some example that a core implementation could learn from. Here is some documentation about its page API and here is real-life example of it. Read about it here: https://drunomics.com/en/blog/inertiajs-style-development-drupal-lupus-d...

Implementation strategies

a) Follow the approach of the Semi-Coupled theme engine of XB: Make a mapping of render array to components.
b) Propagate a clear cut and build a new render API that only supports the desired component model (and simplify as much possible). Add a compatibility layer for rendering render arrays into the component model like in a). Slowly phase the current render API out, after long deprecation.

Lupus Decoupled Drupal implements a new component model via the https://www.drupal.org/project/custom_elements module. https://lupus-decoupled.org/get-started/how-it-works describes how it works.

Pros/Cons

Advantages that come with this approach:
- Drupal backend and frontend can be developed and tested separately
- Drupal stays in the driving seat, pages are composed by Drupal
- A HTTP-endpoint for the page API allows frontend-developers to easily introspect what is there to render. Great dev-tools could be built on top of that.
- Allows frontend developers to bring modern frontend (templates, components and tooling) to Drupal

Disadvantage:
- JSON-API / API-first is not required. Still developers it's an important addition, such that it's easy to fully decouple parts (or the full) application when preferred.
- Frontend stacks might have to support lots of components to be complete. A fallback mechanism would be great.

How can we know the desired result is achieved

* Drupal core provides an HTTP API for fetching the component-tree of a page
* Drupal core provides a twig/sdc-based frontend based on the component-tree
* Drupal core provides at least one modern JavaScript frontend option, that allows for either server or client-side rendering.

What is the problem to solve?

Drupal Core's JSON:API module and the related JSON:API module ecosystem has experienced strong adoption among those building decoupled Drupal sites. There has also been substantial growth in JavaScript community projects that depend on Drupal's JSON:API implementation. While those projects differ in a variety of ways, they all share at least one common need - easily interfacing with Drupal's JSON:API endpoints. This has resulted in many different implementations solving this need with large amounts of overlap, and very few shared solutions.

A non-exhaustive list of projects that include some form of client-like functionality for interacting with JSON:API includes:
- Druxt - https://www.npmjs.com/package/druxt
- Next For Drupal - https://github.com/chapter-three/next-drupal
- Drupal State - https://www.npmjs.com/package/@gdwc/drupal-state
- Drupal JS SDK has https://www.npmjs.com/package/drupal-js-sdk
- https://www.npmjs.com/package/nuxtjs-drupal-ce
- https://github.com/jsdrupal/js-client
- https://gitlab.com/VoidE/drupal-sdk
- Almost certainly more - please add your project in the comments :)

And this list doesn't even include specific decoupled site builds, many of which have at least some custom code to interact with JSON:API.

There have been previous attempts to solve this problem, and semi-recent discussions about renewing efforts to address this (much of this proposal is inspired by previous discussions with @deciphered.) I believe it is time to make new concrete steps to solve this problem.

Who is this for?

There are two primary audiences:
1. JavaScript developers who are consuming Drupal's JSON:API endpoints and would prefer to use a sanctioned Drupal solution to make this process easier. Of specific note within this audience are JavaScript developers who may not have deep existing experience with Drupal or the JSON:API spec.
2. Project maintainers within the Decoupled Drupal ecosystem who would prefer to spend less time re-solving common problems and more time pushing Decoupled Drupal forward.

The Result

Assemble a team of interested contributors who commit to developing a JSON:API client will be published under the @drupal namespace on NPM. This project will be able to be used as a dependency both for specific decoupled builds, and other decoupled ecosystem projects that interface with Drupal's JSON:API.

How will we know the desired result is achieved?

Downloads of this package reported on NPM would be a metric that indicates adoption. Strong adoption would also hopefully result in this package being listed high in the results when searching for Drupal on NPM. If this project is successful, there should be a reduction in projects that develop bespoke solutions to communicate with JSON:API, although this will likely be a more difficult metric to measure.

Why Now

I believe there are a number of reasons that make now the right time to renew these efforts.

- Accelerating innovation in the Decoupled Drupal JS ecosystem - If this effort can provide a desirable solution for interfacing with JSON:API, developers can focus more time and effort on the things that make their particular project unique.
- Prior art - reaching consensus on the functionality and format for this client will be difficult, but common patterns in projects that implement client-like solutions should help support decision making.
- Developing a repeatable pattern for 'official' JavaScript projects maintained by the Drupal community. The decoupled menus initiative and specifically the creation of the general project type has has an important impact on the the ability to create Drupal-adjacent community projects, but the path to any of these becoming 'official' Drupal projects (think more core, less contrib) still feels undefined. Most projects that fit this classification are either used by, or directly related to Drupal Core. A clearer path here could inspire more formal community efforts. Imagine an official collection of React utilities, or an official GraphQL client, etc.
- Sending a strong signal to the JS community - I continue to worry that Drupal has a perception problem with the JS community at large. While it is clearly not the only indicator, I think that searches on NPM tell a story here. Searching for Drupal results in a somewhat confusing set of packages, and it is unclear what if any are provided by the Drupal project. Those who know to look for the Drupal organization will only see two narrowly focused packages. A search for WordPress results in a client, and many packages under the @wordpress namespace. I'd imagine much of this is driven by the block editor, but it still could provide the perception that WordPress is serious about JS. Searching for Contentful provides a clear set of utilities, including packages to help consume data from Contentful. Contentful may not be a fair comparison here, since it is a completely headless CMS, but that doesn't change the fact that JS developers familiar with Contentful may have the expectation that any CMS they work with should have an official set of packages for them to take advantage of. I believe that offering more packages under the Drupal NPM namespace will help provide the signal that Drupal is JavaScript friendly.

Thoughts on potential approach

Determining the approach would primarily be the responsibility of the initiative if this moves forward, but here are a few concepts that I consider important:

- This package should be framework agnostic so that it can be used with any JavaScript framework or none at all.
- It should be possible to use both on the client and server.
- It should make underlying utilities available so that they can be adopted individually or incrementally without requiring the entire client.
- The client should provide a default solution for fetch, but it should be possible to provide a compatible alternative.
- The client should provide a default solution for storage / state management, but it should be possible to provide a compatible alternative.
- The client should be written in TypeScript, but it should be possible to use the client without using TypeScript.

Problem/Motivation

Separating this from #3436146: Introduce a list of "frequent cache tags" to reduce lookup query amount

It would be useful to have a test to assert how a page request performance after a cache invalidation of a cache tag used in page/dynamic page cache.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Several methods on EntityDisplayRepositoryInterface - all the get*Modes() - have @return docs that say something like this:

   * @return array
   *   The view mode info for all entity types.

What is the 'info'? What is the array keyed by? The docs should say this.

Steps to reproduce

Proposed resolution

Complete the documentation.

It's probably fine for the entity type-specific flavours to refer to the general method for docs, to avoid repetition.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow up to #3501375: Implement PSR-20 in datetime.time service where we added a new \Psr\ClockInterface service we can inject.

We should switch from using \Drupal\Component\Datetime\TimeInterface::getCurrentTime() and instead use the PSR-20 \Psr\ClockInterface::now()->getTimestamp() for PHP interoperability.

We can also add a \Drupal::clock() method to help with non-dependency injected code.

Steps to reproduce

Proposed resolution

• Deprecate \Drupal\Component\Datetime\TimeInterface::getCurrentTime()
• Add a code>\Drupal::clock() method
• Replace instances of \Drupal\Component\Datetime\TimeInterface::getCurrentTime() with \Psr\ClockInterface::now()->getTimestamp()

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

PathAliasTest::testPathCache seems to contain a random fail, I've seen it a few times but most recently here
https://git.drupalcode.org/issue/drupal-3426302/-/jobs/4324922

Drupal\Tests\path\Functional\PathAliasTest::testPathCache
Cache entry was created.
Failed asserting that a boolean is not empty.

core/modules/path/tests/src/Functional/PathAliasTest.php:84

Steps to reproduce

?

Proposed resolution

Use key/value instead of state in WaitTerminateTestTrait.

Problem/Motivation

The feature added in #2205271: Project namespace for dependencies was missing some documentation of the new 'project' key. Let's add it here.

Steps to reproduce

Proposed resolution

In \Drupal\Core\Extension\InfoParserInterface::parse change
* - (versions): Version information, consisting of one or more
to
* - (versions): (optional) Version information, consisting of one or more

Remaining tasks

MR with the recommended change
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Hi,

I facing a error when I enable ImageMagick image toolkit. After that I try to edit Image Style then I faced following error.

The website encountered an unexpected error. Please try again later.
DivisionByZeroError: Division by zero in template_preprocess_image_style_preview() (line 51 of core/modules/image/image.admin.inc).
template_preprocess_image_style_preview(Array, 'image_style_preview', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('image_style_preview', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 64)
Drupal\image\Form\ImageStyleEditForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 531)
Drupal\Core\Form\FormBuilder->retrieveForm('image_style_edit_form', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

In NodeForm we put the currently changed timestamp in the form and sent it to the client, for later overwrite error checking, so that we prevent the current user from saving the node, if the node got saved by another user in the meantime.

The problem is, we set the changed in the form as hidden default_value, which means the user might manipulate it.

More importantly, EntityChangedConstraint seems to rely solely on this element existing which it doesn't for other entity types. For example Block Content has the constraint but does not throw an error in the same circumstances listed below. This could lead to data loss.

Steps to reproduce:

1. Create a node.
2. Go to node/{node}/edit.
3. Save the node in the background to cause the entity changed constraint validator to raise an error.
4. Submit the form.
5. As a result you get the validation error message " The content has either been modified by another user, or you have already submitted modifications. As a result, your changes cannot be saved.".
6. Now manipulate the changed timestamp and set it to the current time in the DOM using Firebug or whatever...
7. Submit the form again.
8. Watch how you succesfully overcome the entity changed constraint validator.

The attached test shows the problem.

Proposed resolution

None at the moment.

Remaining tasks

Find a solution of the problem.

User interface changes

none

API changes

none

Data model changes

none

Motivation

Some users go to the content section, rather than the structure section, looking for options to edit content types.

Proposed resolution

On the node/add page, add links to edit the content types as well, for users who have the right permissions. This provides another way of navigating to admin/structure/types/manage/[node-type]

Remaining tasks

Summary of API changes
Needs usability review; see #59

User interface changes

Adds links to admin/structure/types/manage/[node-type] for each node type on the node/add page

Screenshot of UI before patch:

Latest screenshot of UI after patch (from comment #50):

Latest screenshot of UI after patch (from comment #61):

Proposed by YesCT in #384150-59: Cross-link content type settings from node add/edit form

Related Issues

• #1440678: New users have difficulty finding where to adjust the content model
• ?

Original report by catch

Many users go to the node/add and node/edit forms looking for settings (submitted information, input formats). We should consider adding links there to the admin screens for those form elements when users have the relevant permissions.

Problem/Motivation

When visiting the admin/content page with multiple language variations on the same node, the default list is no longer very useful. I could filter by a single language, but this is not ideal in the case I want to have easy accessibility to all the translated nodes at a glance.

Additionally, with translated nodes the titles are usually different making it harder to identify the related default language node.

Proposed resolution

When the list is unfiltered, the default language node should show as the section head of a collapsible list that shows the translated node variations tied to this. I think this would also improve searchability. If you search for a node title in a different language, you would see a grouped list of the related nodes.

User interface changes

Here is a view of what this could look like:

Problem/Motivation

CoreServiceProvider currently provides services that are only applicable to tests. We should separate test from runtime code.

Steps to reproduce

Proposed resolution

Register middleware in FunctionalTestSetupTrait instead

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

In my dream (where unicorns also roam) DBTNG goes out of its way to prevent SQL injections due to silly mistakes, or a moment of carelessness.

orderby() doesn't escape fields / aliases and does not check $direction, allowing SQL injection when developers pass usersupplied data.

idem for group by, though that needs further study.

Problem/Motivation

When creating a new content type, the default value for the "Promoted to front page" checkbox should be FALSE.

Beta phase evaluation

So this normal task is allowed in the drupal 8 beta since it is a prioritized usability improvement with no/very little disruption.

Proposed resolution

Write patch to Drupal 8 to change this behavior for new version of Drupal

Remaining tasks

Most recent patch failed testing, need to be fixed and resubmitted

Problem/Motivation

Currently, file and image field's field formatter doesn't have support to render/display absolute URL.
ImageUrlFormatter and UrlPlainFormatter classes doesn't have flexibility to display absolute url.

Steps to reproduce

Configure the field formatter and check that we don't have flexibility to render absolute url.

Proposed resolution

- Add an option to both the field formatters.
- Validate option value in viewElements() method and display URL accordingly.
- Add test cases to validate newly added options.

Remaining tasks

Contact Usability for wording of new text in the UI.
- Review MR https://git.drupalcode.org/project/drupal/-/merge_requests/5882 which represents further changes since patch #122

User interface changes

- New option is added on both the field formatters.

File field:

Image field

API changes

- N/A

Data model changes

- N/A

Release notes snippet

Problem/Motivation

JavaScript theme functions are defined on each library and Drupal.theme() checks property existence. But, a type of property value is not checked so that if a JavaScript theme function is defined other than function, tries to execute as function and occurs an error.

Drupal.theme.test = true;

Drupal.theme.test2 = function() {
	// Try to execute Drupal.theme.test() as a function but an error is occurred.
	return Drupal.theme('test', false);
}

Proposed resolution

Checks property value type using typeof operator.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

It turns out more and more, that node and media behave in the same way in many cases. When i worked on #2911977: Add Media revision UI, i saw that node implements its own NodeController to show the add/edit page. This could be simplified if node would use AdminHtmlRouteProvider.

Proposed resolution

Remove all the addPage stuff from NodeController and let AdminHtmlRouteProvider do the work.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

For media item labels to be positioned correctly, the enclosing <article> needs to be position: relative;. If the page includes the contextual module libraries then the <article> will have the .contextual-region class and be styled by this bit in contextual.module.css

.contextual-region {
    position: relative;
}

There are legit scenarios such as this one with Experience Builder where the media library is used without contextual present -- even on sites with that module enabled.

It winds up looking like this, with the labels under the images out of place (not hugely so, but still not a great look)

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

I think the Node module's "use_admin_theme" setting has an inaccurate developer-facing name, since the code (see for example https://api.drupal.org/api/drupal/core%21modules%21node%21src%21EventSub...) uses it to determine if node-related paths are considered "administrative"in general. Whether or not they use the admin theme is simply one part of that.

For more background, see #2139341-1: path_is_admin() is abused by "use_admin_theme" and other discussion in that issue.

I propose that this setting be renamed to something else, maybe something like "node_edit_is_admin".

The user interface could probably stay the same (and continue to refer to this setting as being about the administration theme only), but it could potentially change also if there is a good way to explain this distinction to site owners.

I am filing this against Drupal 8 for now, although I'm not really sure there's a good way to make this change in a backwards-compatible manner.