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

Backport D8 html_tag element changes

$
0
0

Hello,

One year ago, the Drupal 8 html_tag has been updated and it's now able to render nested tags, see the CR here #2887146.

I backported the functionnality to Drupal 7 so no, we can render this render array properly, including the children.

To test the functionnality, run this code before and after applying the patch in /devel/php:

$render_array = array(
  '#type' => 'html_tag',
  '#tag' => 'h1',
  '#attributes' => array('class' => 'title'),
  'children' => array(
    array(
      '#type' => 'link',
      '#title' => 'Link title',
      '#href' => '/',
      '#attributes' => array('class' => 'inner'),
    ),
    array(
      '#theme' => 'link',
      '#text' => 'Link title',
      '#path' => '/',
      '#options' => array(
        'attributes' => array(),
        'html' => FALSE,
      )
    ),
  )
);

$html = render($render_array);

debug($html);

Without the patch: <h1 class="title" />

With the patch: <h1 class="title"><a href="/" class="inner">Link title</a><a href="/">Link title</a></h1>

Another example:

$render_array = array(
  '#type' => 'html_tag',
  '#tag' => 'h1',
  '#attributes' => array('class' => 'title'),
  '#value' => 'value',
  'children' => array(
    array(
      '#type' => 'link',
      '#title' => 'Link title',
      '#href' => '/',
      '#attributes' => array('class' => 'inner'),
    ),
    array(
      '#theme' => 'link',
      '#text' => 'Link title',
      '#path' => '/',
      '#options' => array(
        'attributes' => array(),
        'html' => FALSE,
      )
    ),
  )
);

$html = render($render_array);

debug($html);

Without the patch: <h1 class="title">value</h1>

With the patch: <h1 class="title">value<a href="/" class="inner">Link title</a><a href="/">Link title</a></h1>

Change record

Proposed change record: https://www.drupal.org/node/2982025


Improve documentation for Datetime and Datelist #date_timezone property

$
0
0

Problem/Motivation

With #2799987: Datetime and Datelist element's timezone handling is fragile, buggy and wrongly documented we improved and enforced timezone handling for Datetime and Datelist through the #date_timezone property. We should now make sure its documentation reflects the changes.

#3015647: $element['value']['#date_timezone'] is not a string fatal error. is an example of how #date_timezone has been (ab)used before, and after the new change a fatal error is raised due a string being expected rather than a \DateTimeZone object.

The current documentation for #date_timezone reads:

#date_timezone: The local timezone to use when displaying or interpreting dates. Defaults to the value returned by

Without specifying *a string* is expected.

Proposed resolution

Update the documentation.

Remaining tasks

  • Update the #date_timezone documentation, specifying a timezone name string is expected
  • Understands if more documentation improvements are needed

User interface changes

Nope.

API changes

No, however change record https://www.drupal.org/node/2880055 doesn't specify a timezone name string is expected so although this changes doesn't change the API it does affect its usage as well as documentation.

Data model changes

No.

drupal_add_html_head_link() needs to allow multiple hreflang tags to point to one URL.

$
0
0

Problem/Motivation

Per i18n, hreflang tags are allowed to have more then one translation point to the same link. However, using the core (includes/common.inc) drupal_add_html_head_link() function, this is not possible. Currently, drupal_add_html_head_link() function considers the same rel and href values to be duplicates and removes all but one, breaking attempts to add multiple hreflang links pointing to the same href.

See Google write-up of this i18n consideration for hreflang uniqueness: https://www.rebelytics.com/multiple-hreflang-tags-one-url/

Proposed resolution

Add hreflang value as part of the uniqueness check (if hreflang attribute is provided). Rather then just checking rel / href, a unique link tag would consider the 3 attribute values of rel / href / hreflang as a unique link.

API changes

Modify the drupal_add_html_head_link() function in includes/common.inc to included hreflang as part of it's check for a unique link tag in order to prevent removal of duplicate link tags that have different hreflang attribute values but the same rel/href attributes.

Configure block to show/hide for specific media type(s)

$
0
0

Duplicate the existing functionality for show/hide based on Content type(s) but for Media type(s).

Bump typo3/phar-stream-wrapper library version to v2.1.2 to remove fileinfo extension dependency

$
0
0

Problem/Motivation

The recent 8.6.16 security update added a dependency on PHP's fileinfo extension.

Error: Class &#039;finfo&#039; not found in TYPO3\PharStreamWrapper\Phar\Reader->determineFileType() (line 155 of /home/xxxx/public_html/vendor/typo3/phar-stream-wrapper/src/Phar/Reader.php).
Drush command terminated abnormally due to an unrecoverable error.                                                                                                            [error]
The external command could not be executed due to an application error.                                                                                                       [error]
The command could not be executed successfully (returned: Error: Class &#039;finfo&#039; not found in TYPO3\PharStreamWrapper\Phar\Reader->determineFileType() (line 155 of   [error]
/home/xxxx/public_html/vendor/typo3/phar-stream-wrapper/src/Phar/Reader.php).
, code: 255)

After that Drush stops working.

I had to restore a backup with the insecure 8.6.15 version.

Proposed resolution

The changes upstream are: https://github.com/TYPO3/phar-stream-wrapper/compare/v2.1.1...v2.1.2

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Create "Media ID from URL" argument for contextual filters

$
0
0

Duplicate the "Content ID from URL" argument for contextual filters but for Media.

Replace drupal_get_user_timezone with a date_default_timezone_get() and an event listener

$
0
0

Problem/Motivation

As part of removing procedural code in includes, we should move drupal_get_user_timezone() from bootstrap.inc to a service in system module.

This process has uncovered the following:

  1. There is a dependency of core on system module in Drupal\Core\EventSubscriber\AuthenticationSubscriber and Drupal\Core\Session\AccountProxy
  2. There is a circular dependency in 'current_user' service: AccountProxy::setAccount() -> drupal_get_user_timezone() -> \Drupal::currentUser();
  3. In AccountProxy::setAccount() we are calling date_default_timezone_set(drupal_get_user_timezone()) which relies on a kind of global state that other code relies on.

Proposed resolution

  • Create an event listener in system module which sets the timezone based on site and user configuation using the standard date_default_timezone_set().
  • Replace usages of drupal_get_user_timezone() with date_default_timezone_get().
  • This also includes a fix for a timezone bug that was exposed by having a more reliable active-timezone switch that did not work in some cases before and was therefor almost impossible to test and now the tests simply failed. See #68 and #2861986: Plus one day on Date only fields with custom display widget for pacific/auckland timezone

Remaining tasks

Do it

User interface changes

none

API changes

drupal_get_user_timezone() is deprecated.

Constructor and implementation changes for AccountProxy that are very hard to have 100% BC because there was previously no constructor and we know of at least one contributed module that completely overrides several methods and that will either break or cause broken timezone behavior. The maintainers were notified and plan to rewrite their code: https://github.com/acquia/commerce-manager/issues/117.

Data model changes

none

Release notes snippet

Drupal no longer uses its own function for getting the default time zone, and now relies on the PHP function date_default_timezone_get().

The logic for setting the default timezone has been moved to events that is handled by the TimeZoneResolver which uses date_default_timezone_set().

The events are:

  1. A request via KernelEvents::REQUEST
  2. When time zone config changes, via ConfigCrudEvent
  3. When a user is set via a a new AccountSetEvent

The TimeZoneResolver handles these events and uses the same fall back logic prior to 8.7.0:

  1. Use the user-specified timezone, or if not set
  2. Use the site default configured timezone, or if not set
  3. Use the system default timezone

More link disappears when time-based views cache is enabled

$
0
0

When I enable views built-in timebased cached, the "more" which links to the full page disappears.

Any ideas? I am also happy to provide more infos, but please tell what you need.


[META] Roadmap to stabilize Media Library

$
0
0

Problem/Motivation

For Drupal 8.6, we shipped with an experimental media library that:

  1. Provides a nice visual interface for browsing through all the media items in your site
  2. Can be opened from a node form (or similar author-facing context) in order to visually select media items to reference in a field
  3. Provides a way to upload several media assets into Drupal, quickly enter metadata for them, and reference them in a field -- all without having to leave the page you're on

This is the roadmap issue for how we will get this module to "stable" status. The path to stable lies through this jungle of issues:

Must-have

Todo after the module becomes stable

Should-have

Could-have

Questionable

Done

Upgraded from 8.6.16 to 8.7.1 but the database updates are failing with Error: Unsupported operand types in Drupal\Core\Routing\RouteBuilder->rebuild()

$
0
0

I've been trying to upgrade from 8.6.16 to 8.7.1... After issuing "composer update drupal/core --with-dependencies," everything minus the database seemed to get upgraded but I still had to apply the database updates. So after trying both "drush updatedb"and using the update.php approach, I keep running into a wall with applying the database updates.

Here's where everything stands right now:

  • The Drupal 8 status page shows version 8.7.1 (on a PHP 7.1.9 server).
  • Composer Version 1.8.5
  • Drush Version 9.7.0-dev
  • Also on the status page, I see the following (which I believe coincides with the pending database updates):
  • Mismatched entity and/or field definitions
      The following changes were detected in the entity type and field definitions.
      Custom menu link
      The Custom menu link entity type needs to be updated.
      The Revision ID field needs to be installed.
      The Revision create time field needs to be installed.
      The Revision user field needs to be installed.
      The Revision log message field needs to be installed.
      The Default revision field needs to be installed.
      The Revision translation affected field needs to be installed.
  • The update.php UI shows the following pending updates:
      - system module
        = Initialize 'expand_all_items' values to system_menu_block.
        = Change plugin IDs of delete actions.
        = Clear the menu cache. @see https:www.drupal.orgprojectdrupalissues3044364
        = Update all entity displays that contain extra fields.
        = Clear the library cache and ensure aggregate files are regenerated.
        = Force cache clear for language item callback. @see https:www.drupal.orgnode2851736
        = Force cache clear to ensure aggregated JavaScript files are regenerated. @see
       https:www.drupal.orgprojectdrupalissues2995570
      - block_content module
        = Adds a 'reusable' filter to all Custom Block views.
      - contextual module
        = Ensure new page loads use the updated JS and get the updated markup.
      - image module
        = Add 'anchor' setting to 'Scale and crop' effects.
      - menu_link_content module
        = Update custom menu links to be revisionable.
      - node module
        = Clear caches due to updated views data.

...but when I try to apply the database updates via clicking the "Apply pending updates" button using the update.php approach, I eventually see the following AJAX error:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /projects/sandbox_d8/update.php/start?id=24&op=do_nojs&op=do
StatusText: OK
ResponseText:

...and if I try to access Watchdog at that point, the only thing I get is a blank white page with the words "The website encountered an unexpected error. Please try again later" at the top.

So I then move on to trying to apply the updates with Drush. Over in a command prompt, I issue "drush updatedb". This results in showing me a list of available updates beginning with block_content and ending with a few from the system module (see attached "pending updates" file for the actual list).

I enter "yes" to apply all the updates.

After a few seconds, Drush chokes with the following notice / errors:

  1. [notice] Update started: block_content_post_update_add_views_resusable_filter
  2. [error] The "view" entity type does not exist.
  3. [error] Update failed: block_content_post_update_add_views_resusable_filter
      In ProcessBase.php line 184: Unable to decode output into JSON.

Below is my composer.json contents:

{
  "name": "drupal/drupal",
  "description": "Drupal is an open source content management platform powering millions of websites and applications.",
  "type": "project",
  "license": "GPL-2.0-or-later",
  "require": {
      "composer/installers": "^1.0.24",
      "wikimedia/composer-merge-plugin": "^1.4"
  },
  "replace": {
      "drupal/core": "^8.7"
  },
  "minimum-stability": "dev",
  "prefer-stable": true,
  "config": {
      "preferred-install": "dist",
      "autoloader-suffix": "Drupal8"
  },
  "extra": {
      "_readme": [
          "By default Drupal loads the autoloader from ./vendor/autoload.php.",
          "To change the autoloader you can edit ./autoload.php.",
          "This file specifies the packages.drupal.org repository.",
          "You can read more about this composer repository at:",
          "https://www.drupal.org/node/2718229"
      ],
      "merge-plugin": {
          "include": [
              "core/composer.json"
          ],
          "recurse": true,
          "replace": false,
          "merge-extra": false
      },
      "installer-paths": {
          "core": ["type:drupal-core"],
          "modules/contrib/{$name}": ["type:drupal-module"],
          "profiles/contrib/{$name}": ["type:drupal-profile"],
          "themes/contrib/{$name}": ["type:drupal-theme"],
          "drush/contrib/{$name}": ["type:drupal-drush"],
          "modules/custom/{$name}": ["type:drupal-custom-module"],
          "themes/custom/{$name}": ["type:drupal-custom-theme"]
      }
  },
  "autoload": {
      "psr-4": {
          "Drupal\\Core\\Composer\\": "core/lib/Drupal/Core/Composer"
      }
  },
  "scripts": {
      "pre-autoload-dump": "Drupal\\Core\\Composer\\Composer::preAutoloadDump",
      "post-autoload-dump": "Drupal\\Core\\Composer\\Composer::ensureHtaccess",
      "post-package-install": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
      "post-package-update": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
      "drupal-phpunit-upgrade-check": "Drupal\\Core\\Composer\\Composer::upgradePHPUnit",
      "drupal-phpunit-upgrade": "@composer update phpunit/phpunit phpspec/prophecy symfony/yaml --with-dependencies --no-progress",
      "phpcs": "phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --",
      "phpcbf": "phpcbf --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --"
  },
  "repositories": [
      {
          "type": "composer",
          "url": "https://packages.drupal.org/8"
      }
  ]
}

I'm also seeing the following stack trace in my PHP error log after trying all this:

Error: Unsupported operand types in
Drupal\Core\Routing\RouteBuilder->rebuild() (line 163 of C:\www\projects\sandbox_d8\core\lib\Drupal\Core\Routing\RouteBuilder.php)
#0 C:\www\projects\sandbox_d8\core\lib\Drupal\Core\ProxyClass\Routing\RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
#1 C:\www\projects\sandbox_d8\core\includes\common.inc(1170): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
#2 C:\www\projects\sandbox_d8\core\modules\system\src\Controller\DbUpdateController.php(650): drupal_flush_all_caches()
#3 C:\www\projects\sandbox_d8\core\includes\batch.inc(454): Drupal\system\Controller\DbUpdateController::batchFinished(false, Array, Array, Object(Drupal\Core\StringTranslation\TranslatableMarkup))
#4 C:\www\projects\sandbox_d8\core\includes\batch.inc(98): _batch_finished()
#5 C:\www\projects\sandbox_d8\core\modules\system\src\Controller\DbUpdateController.php(186): _batch_page(Object(Symfony\Component\HttpFoundation\Request))
#6 [internal function]: Drupal\system\Controller\DbUpdateController->handle('start', Object(Symfony\Component\HttpFoundation\Request))
#7 C:\www\projects\sandbox_d8\core\lib\Drupal\Core\Update\UpdateKernel.php(115): call_user_func_array(Array, Array)
#8 C:\www\projects\sandbox_d8\core\lib\Drupal\Core\Update\UpdateKernel.php(76): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request))
#9 C:\www\projects\sandbox_d8\update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#10 {main}.

Any insights into this would be appreciated. At this point, I'm just needing to get the database updates applied but it's getting hung up on something and I can't figure out what it is. Since I couldn't find anything about any of this anywhere, I thought posting about this here might help in case anyone else comes across this. (I've posted about this in the forum, too, so if I see any responses to that which result in a solution, I'll update this with it.) But I thought this might be a bug, so if anyone has any insight into this, it would be appreciated.

No version key/value pair in jsonapi.info.yml

$
0
0
  1. Install 8.7.1
  2. Go to /admin/modules
  3. Expand the Description for JSON:API

Notice there is no Version: 8.7.1 listed with the other requirements/details.

Adding "version: VERSION" to jsonapi.info.yml solves the problem.

Incorrect use of UnprocessableHttpEntityException in EntityResource::deserialize()

$
0
0

The EntityResource controller class has a deserialize() method which takes care of building the entity object from the submitted request data.

At some point, if either UnexpectedValueException or InvalidArgumentException are thrown by the underlying serialized, it is catched and an UnprocessableHttpEntityException is thrown by the method itself.

    try {
      ...
    }
    // These two serialization exception types mean there was a problem with
    // the structure of the decoded data and it's not valid.
    catch (UnexpectedValueException $e) {
      throw new UnprocessableHttpEntityException($e->getMessage());
    }
    catch (InvalidArgumentException $e) {
      throw new UnprocessableHttpEntityException($e->getMessage());
    }

The issue here is that, per its signature, UnprocessableHttpEntityException first argument should be an Exception object, not a string. When one of this situation occurs, a TypeError is thrown by PHP, breaking the execution flow and leading to a 5xx error instead of a JSON:API managed 4xx error.

X-CSRF-Token request header is missing when using Bearer authentication

$
0
0

We have an App using simple_oath with Bearer tokens to authentication method. After updating core from 8.6.15 to 8.71 we started getting "X-CSRF-Token request header is missing" when doing something other than GET requests to REST or JSONAPI endpoints.

So why Drupal started to require X-CSRF-Token if the authentication is done by Bearer token which is not a browser? Also I am not sure if is the job of contrib simple_oath module to deal with CSRF-Token because of [1]?

Screenshot explains the issue.

Maybe related issues:
[1] https://www.drupal.org/project/drupal/issues/2753681
[2] https://www.drupal.org/project/drupal/issues/2730351

ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved

$
0
0

Problem/Motivation

\Drupal\views\EventSubscriber\ViewsEntitySchemaSubscriber::onEntityTypeUpdate() re-saves all the existing views of a site if an entity type was updated by the entity definition update manager.

This is causing a lot of problems in real-world sites because a lot of views handlers don't define their config dependencies properly, which means that some views can not be re-saved without user intervention.

Proposed resolution

Don't re-save views that weren't changed by an entity update process and catch any exception thrown while saving to avoid making the update process to fail. If an error occurs on save, it most certainly means that the view was not set up correctly or that it does not support the entity schema changes. In both cases there's no point in making the update fail because the view will need some (likely manual) tweak anyway.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Allow tokens for url of the Link field

$
0
0

The link text of the link field does allow to use tokens, but the url does not.

A use case example is using the link for a sharing function where the link is

http://twitter.com/share?url=[current-page:url:absolute]&text=[current-page:title]

and the link text "Twitter".

It does not appear logical why I can use tokens for the link text and not for the title. Therefore I marked this as a bug.


Create a tool to convert a non-Composer-based Drupal to a Composer-based one

$
0
0

This is a child issue of #2982674: Add composer build support to core

Problem/Motivation

Given a normalization to Composer-based site building, we need a tool to convert non-Composer-based sites into Composer-based ones.

We're targeting 'tarball' style installs, which have downloaded Drupal from the download page of drupal.org, and have then installed in place.

We want a core-native tool which can be easily used to reliably make a composer.json file, ideally without much user intervention.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Entity query alter with cacheable metadata leaks and triggers LogicException

$
0
0

I have an entity query_alter that was adding a cacheable metadata to a jsonapi response and before it was working and now I get: `LogicException: The controller result claims to be providing relevant cache metadata`, any ideas? I am altering the json query by a passed argument on the url and I want that resource to be be varied by that url argument, but it seems I should not be adding it on the query alterer now, which would be the proper way?

I am/was doing this on

function microsite_query_entity_query_alter(Drupal\Core\Database\Query\AlterableInterface $query) {
  $request = \Drupal::requestStack()->getCurrentRequest();
  $renderer = \Drupal::service('renderer');
  if ($request->isMethodCacheable() && $renderer->hasRenderContext()) {
    $build = ['#cache' => ['contexts' => ['url.query_args:microsite_site']]];
    $renderer->render($build);
  }
}

This stopped to work after recent upgrades to core/jsonapi.

@wimleers asked

What code path in JSON:API is triggering your code to be executed? JSON:API should have the appropriate “run entity queries in a render context so it can detect bubbled cacheability and associate it with the resulting response” logic in place. If it doesn’t, that’d be a bug.

I answered: Does this answer your question https://pastebin.com/T0RvpbX3? The first path I actually now see that it’s captured and bubbled up, however the others (one per media entity) are not. Please ignore the `microsite` controller. It’s currently a bare decorator for the jsonapi controller service to add the cache context on an overridden `buildWrappedResponse()` (PoC from yesterday), but I rather not have to do something like this.

He said yes and asked to fill in a ticket, so here it is.

In the end I removed the decorator end ended up replacing the whole jsonapi.entity_resource service with the same `buildWrappedResponse()` overridden to add my needed context but not to have to override also the constructor on the decorator.

From Slack: https://drupal.slack.com/archives/C6DJEP1EK/p1556217296004400 (likely to be lost in the backscroll noise but here for reference)

Extend Cacheable/RedirectResponse constructor to accept GeneratedUrl

$
0
0

Problem/Motivation

1 - As far as I know, it's dangerous (can lead to hard to trace bugs) to not add cacheability metadata into a response object.

2 - The current code structure leads people in the direction of forgetting to add the metadata, or not even knowing about this.

I'll illustrate that with an example which is me in 2017:

Say, I'm a simple contrib module developer. I have a route where I just want to do a quick thing and then issue a redirect, directly in my Controller, for some reason.

  • I look around for a response object and find LocalRedirectResponse. And I find TrustedRedirectResponse, which just from the name sounds like I should be using it, because it's... trusted, right? (There are several other RedirectResponse objects and nothing really says which to use, but either of these ones feels most logical, I guess.)
  • It accepts a string.
  • I also see a Url object, which looks a bit daunting to me, but it has a toString(). This says something about bubbling metadata but I have no clue what that means and the code is impenetrable, so I ignore it in the end. (Note it doesn't say anything about the fact that unless I pass TRUE here, I could be causing caching-related bugs this way. The character string "cach" occurs zero times in the Url class.)
  • So, great. I make a URL through Url::generateFromRoute()->toString() and pass it into my response.
  • BOOM! LogicException. Which says something about "Leaked metadata" and "early rendering" which I don't understand.
  • Reading the Url class and related code (UrlGenerator, GeneratedUrl...) just makes me feel lost.
  • Web searches tell me to just do Url::generateFromRoute()->toString(TRUE)->getGeneratedUrl(), as per e.g. https://drupal.stackexchange.com/questions/187086/trustedresponseredirec... / #2630808-16: Response::getResponse() does not collect cacheability metadata from Url object
  • I never find out that this is the wrong advice around totally ignoring cache metadata. There's no other info.

Almost two years later I find out what I should have done , and why. This is (Copypaste from https://www.lullabot.com/articles/early-rendering-a-lesson-in-debugging-...):

$url = $node->toUrl()->toString(TRUE);

// The generated URL string, as before.
$url_string = $url->getGeneratedUrl();
// Add the $url object as a dependency of [ the response ]
$response = new CacheableResponse($url_string, Response::HTTP_OK);
$response->addCacheableDependency($url);

Proposed resolution

We can help people prevent creating obscure bugs / not promoting flawed practices by making the following equivalent possible / hiding the parts of cacheability that they don't need to learn about if they just want to redirect somewhere:

$url = $node->toUrl()->toString(TRUE);

$response = new CacheableResponse($url, Response::HTTP_OK);

(Hmm... I am guessing this means we need to override the CacheableResponse constructor for this example to work, not just CacheableRedirectResponse. I guess... that makes sense? Not 100% sure.)

Alternative proposed resolution

After typing up this issue, I came across the following from Wim Leers in #2491981: Drupal 8 has far too many ways to generate URLs (and links):

Conclusions/notes
-> we can provide our own RedirectResponse class that does accept Url objects

And... I guess that's true; using Url would be just as good as good as a GeneratedUrl. Again not 100% sure though. (Maybe there's a case against
passing in ungenerated Urls which still have a dependency on some (UrlGenerator) service? That's too fuzzy for my experience level.)

Remaining tasks

You:

  • Tell me if it makes sense
  • tell me whether to use Url or GeneratedUrl
  • tell me how we document additions to method parameters in minor versions of Drupal Core; I can't find that.

(Or provide a patch if you feel like it.)

Me: Provide a patch.

...which should also include a @see https://www.drupal.org/docs/8/api/responses/cacheableresponseinterface in CacheableResponseInterface, because that's excellent info.

User interface changes

None.

API changes

The above.

Data model changes

None.

Release notes snippet

TBD

Allow layout builder sections to be nested.

$
0
0

Problem/Motivation

For many page layouts, section layouts often need to nested to achieve the required layout designs. Right now layout builder doesn't make this easy because layout sections cannot be nested. This requires developers and site builders to incorporate some other way to added these nested grids, such as a grid paragraph type, or using the standard block UI for adding sidebar blocks.

For instance, one common page layout is having a left and right sidebar section and middle content section. The left sidebar section might have a menu block, while the right might have related block such as related content/links, forms, ads, or other information complementary to the main content. Within the middle content section, content editors often still need to place content in multi-column grids. Some examples include: placing an image and text in a 2 column grid (often called a media object), a grid of cards or photos, multi-column lists, etc.

Allowing layout builder sections to be nested would greatly increase the flexibility and functionality to easily implement even the most complex of layouts.

Proposed resolution

Extend layout builder sections functionality to allow them to nested.

Remaining tasks

Agree on an approach and implement.

User interface changes

Layout builder UI will be to be adjusted to properly accommodate nested sections.

API changes

Unknown.

Data model changes

Unknown.

State API docs are unclear

$
0
0

In the docs for the State API, the term 'reset' is used, without any reference as to what a reset is:

use State API to store transient information, that is okay to lose after a reset.

I've spent a significant amount of time digging through the back-end implementation of the State API, looking at the database tables, and testing writing values, and as far as I can tell, the state data is never removed.

So the documentation needs to be cleaned up to explain what exactly this means, as 'reset' is not a term I've heard used in reference to Drupal before.

Viewing all 295276 articles
Browse latest View live


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