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

Use strong validator for ETag and leverage symfony for HTTP revalidation

$
0
0

Problem/Motivation

Follow-up from #2257709: Remove the interdependence between the internal page cache and management of the Cache-Control header for external caches.

Currently the UNIX timestamp is used for the ETag header when serving pages cacheable by proxies and/or the browser. This does not strictly conform to the specification (RFC 2616, Section 13.3) because the ETag is expected to be a strong validator. The UNIX timestamp does not qualify as a strong validator. In order to comply with the RFC, it is either necessary to explicitly mark the ETag as a being weak or alternatively compute a hash of the content and use that.

Upon cache-revalidation the method used check whether a 304 Not modified can be issued also does not really conform to the spec according to @Wim Leers (#2257709-5: Remove the interdependence between the internal page cache and management of the Cache-Control header for external caches):

It is not required for both If-Modified-Since and If-None-Match to be specified to trigger a 304 response. If both an ETag and a Last-Modified response header are specified, then UAs SHOULD use both for HTTP revalidation, but it's not a requirement.

In fact the Symfony Response object already supports cache-revalidation out of the box via the isNotModified() method. However, using this method unmodified would effectively revert #327269: drupal_page_cache_header() should compare timestamp. This needs further investigation (sifting through the Symfony issue tracker, testing with browsers / proxies).

Proposed resolution

Remaining tasks

User interface changes

API changes


dialog.es6.js uses css attributes to apply visually-hidden

$
0
0

Problem/Motivation

Drupal.behaviors.dialog.prepareDialogButtons contains the following code:

// Hidden form buttons need special attention. For browser consistency,
        // the button needs to be "visible" in order to have the enter key fire
        // the form submit event. So instead of a simple "hide" or
        // "display: none", we set its dimensions to zero.
        // See http://mattsnider.com/how-forms-submit-when-pressing-enter/
        const $originalButton = $(this).css({
          display: 'block',
          width: 0,
          height: 0,
          padding: 0,
          border: 0,
          overflow: 'hidden',
        });

This is the inline css variant of the visually-hidden class.

Proposed resolution

Use the visually-hidden class to visually hide the buttons, so the css can be overridden by themes.

Remaining tasks

  1. Write a patch
  2. Review
  3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Facing the issue for "The website encountered an unexpected error. Please try again later."

$
0
0

please, can anybody help me to solve this issue, yesterday the site was working and now it's giving me the issue?

Custom REST Resource Results in "Permission is required"

$
0
0

I followed this tutorial -> https://www.drupal.org/docs/8/api/restful-web-services-api/custom-rest-r... to set up a customer REST endpoint.

Here is my module

<?php

namespace Drupal\demo_rest_api\Plugin\rest\resource;

use Drupal\rest\Plugin\ResourceBase;
use Drupal\rest\ResourceResponse;

/**
 * Provides a Demo Resource
 *
 * @RestResource(
 *   id = "demo_resource",
 *   label = @Translation("Demo Resource"),
 *   uri_paths = {
 *     "canonical" = "/demo_rest_api/demo_resource"
 *   }
 * )
 */
class DemoResource extends ResourceBase {

  /**
   * Responds to entity GET requests.
   * @return \Drupal\rest\ResourceResponse
   */
  public function get() {
    $response = ['message' => 'Hello, this is a rest service'];
    return new ResourceResponse($response);
  }
}

Here is my rest config:

langcode: en
status: true
dependencies:
  module:
    - basic_auth
    - node
id: demo_resource
plugin_id: demo_resource
granularity: resource
configuration:
  methods:
    - GET
  formats:
    - json
  authentication:
    - basic_auth

My module is installed and its rest config was loaded into the database.

On the native Permissions screen, a new permission called "Access GET on Demo Resource resource" appeared in the "RESTful Web Services" section.

That permission is now enabled for authenticated users.

Nevertheless, making a GET request to the defined endpoint results in 403 Forbidden response status and the following response body:

{
    "message": "The 'restful get demo_resource' permission is required."
}

I am sending basic auth credentials and the CSRF token. FWIW, I have also enabled REST services for the built in Page entity, and requests I make to those endpoints, which use the same auth headers, are working.

Is there perhaps some other permission that needs to be flipped? I've been reading a few other bug reports and issue related to this, but no common theme or fix. I appreciate any help you can offer.

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 https://www.drupal.org/project/drupal/issues/2753681 ?

Screenshot explains the issue.

Change country name for North Macedonia

$
0
0

The official, internationally recognized name of the country "Macedonia (the former Yugoslav Republic of)" changes to "North Macedonia" because North Macedonia and Greece ratified this historic name change. I have the honor to provide a core patch on this occasion!

Ajax error on using media library filter button

$
0
0

Hi there,

I was trying to update Drupal core from 8.6.15 to 8.7.1. Everything seems to be fine except media library filter functionality. There's no issue in uploading image or selecting image from media library.

The issue is only when I click `Apply Filters` button. The error reported in log is

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid media library parameters specified. in Drupal\media_library\MediaLibraryState::fromRequest() (line 105 of /drupal/web/core/modules/media_library/src/MediaLibraryState.php).

The error reported in browser is

AjaxError: An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. 
Path: /views/ajax?q=node/159776/edit&name=vet&sort_by=created&ajax_form=1&_wrapper_format=drupal_ajax&media_library_opener_id=field%3Afield_media_banner&media_library_allowed_types%5Bimage%5D=image&media_library_selected_type=image&media_library_remaining=1&hash=bwT8Srs3eyqW8bjTp2XqIZiahnQJ5VkWxrOIVXezsas&name=vet&sort_by=created StatusText: 500 Service unavailable (with message) 
ResponseText: The website encountered an unexpected error. Please try again later.PDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at &#039;reading authorization packet&#039;, system error: 0 in Drupal\Component\DependencyInjection\PhpArrayContainer-&gt;createService() (line 79 of /Users/t00214/Sites/devdesktop/surreymain/drupal/web/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php). Drupal\Component\DependencyInjection\PhpArrayContainer-&gt;createService(Array, &#039;database&#039;) (Line: 173) Drupal\Component\DependencyInjection\Container-&gt;get(&#039;database&#039;, 1) (Line: 260) Drupal\Component\DependencyInjection\PhpArrayContainer-&gt;resolveServicesAndParameters(Array) (Line: 62) Drupal\Component\DependencyInjection\PhpArrayContainer-&gt;createService(Array, &#039;cache.container&#039;) (Line: 173) Drupal\Component\DependencyInjection\Container-&gt;get(&#039;cache.container&#039;) (Line: 543) Drupal\Core\DrupalKernel-&gt;getCachedContainerDefinition() (Line: 904) Drupal\Core\DrupalKernel-&gt;initializeContainer() (Line: 476) Drupal\Core\DrupalKernel-&gt;boot() (Line: 692) Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 24)

Any help would be appreciated.

Set default window size in \Drupal\FunctionalJavascriptTests\WebDriverTestBase

$
0
0

Problem/Motivation

DrupalCI chromedriver image has a screen size of 800x600. When running WebDriverTestBase locally it's unlikely you'll have the same screen size.

Proposed resolution

Set a default screen size for more predictable testing.

Remaining tasks

Agree size

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a


Add hook_entity_translation_access()

$
0
0

Problem/Motivation

Currently is not possible to alter translation access
There is a a GetTranslation method that determines whether you are allowed to translate entities. Currently it is not possible to alter this, the only checks that are done are based on existing permissions in core. When using the group module it may be desirable to add permissions regarding translation on group level, but there maybe many other cases where it is important to alter the permissions.

Proposed resolution

To alter the access result, it would be nice to add a hook_entity_translation_access() like hook hook_entity_access() and hook_entity_create_access().

Remaining tasks

User interface changes

API changes

Data model changes

Content translation create access check with context for the target translation

$
0
0

Problem/Motivation

This is a follow-up of #2155787: Introduce more flexible access control for content translation operations where @kfritsche mentioned in #2155787-22: Introduce more flexible access control for content translation operations that it would be useful to be able perform access checks for the translation create operation based on the target translation language.

Proposed resolution

Add a $context parameter to the access check methods and pass the language code of the target translation when checking the access for the translation create operation :

  • \Drupal\Core\Access\AccessibleInterface::access()
  • \Drupal\Core\Entity\EntityAccessControlHandlerInterface::access()

Remaining tasks

User interface changes

API changes

Data model changes

Introduce more flexible access control for content translation operations

$
0
0

Problem/Motivation

Currently the Content Translation module performs its access checks through a confusing combination of swappable/overridable OO code, procedural callbacks and entity-info-driven callbacks. This makes it hard for entity-defining modules to customize access checks to fit their business logic in clean way.

Proposed resolution

Unify and streamline access checks by relying on a proper entity access controller implementation for translation operations.

Remaining tasks

  • Agree on an implementation plan
  • Write a patch
  • Reviews

User interface changes

None

API changes

Three new entity access operations used by content_translation:

  1. translation_create
  2. translation_update
  3. translation_delete

Content translation should allow for a language-aware access checks

$
0
0

Problem/Motivation

Drupal content translation system does not allow for language-aware access checks. Seems like this has been intentionally done here #1807776-148: Support both simple and editorial workflows for translating entities

Proposed resolution

Introduce new Interface for content translation access check, which is aware of source/target/entity language.

Remaining tasks

  1. Review the approach
  2. Add proper tests coverage
  3. Change record

User interface changes

None

API changes

  • New interface Drupal\content_translation\ContentTranslationAccessHandlerInterface
  • New interface implementation Drupal\content_translation\ContentTranslationAccessHandler
  • Deprecation of Drupal\content_translation\ContentTranslationHandlerInterface::getTranslationAccess()

Data model changes

None

Release notes snippet

Not yet

[meta] Entity translation access control

$
0
0

Problem/Motivation

There a couple of issues trying to add entity translation access control:

#2155787: Introduce more flexible access control for content translation operations => update/delete access via getTranslationAccess().
#2985657: Content translation create access check with context for the target translation => create access in a totally different way.
#2918354: Add hook_entity_translation_access() => adds a hook_entity_translation_access in getTranslationAccess().
#3018576: Content translation should allow for a language-aware access checks => deprecates getTranslationAccess().

The last issue deprecates getTranslationAccess() which means the others issues can't make it into core.

Proposed resolution

  • Agree on an implementation plan.
  • Create child issues or update the existing issues.

Remaining tasks

  • Create a plan of approach.
  • Create child issues or update the existing issues.

RFC 7807: "Problem Details for HTTP APIs" — serve REST error responses as application/problem+json

$
0
0

Problem/Motivation

Existing error messages in Drupal REST responses are one dimensional—a string contextualized by an HTTP status code. This is limiting in several ways:

  • It is very difficult to provide adequate depth of insight into an error via a one-line message.
  • Categorization of "sub-types" below the level of status code and above the specific error message is difficult, inhibiting ease of troubleshooting research
  • The response is too basic to facilitate more advanced integration around fault tolerance and error handling UX.

Proposed resolution

RFC 7807: Problem Details provides a description for structured XML or JSON responses that facilitate greater detail in the error messages.

A few thoughts on some of the available properties:

  • type can link to documentation pages on Drupal.org about the error category, driving developers to a landing page to help facilitate research.
  • title can be made high-level and unique by type, to facilitate googling without the kinds of identifiers, URIs, and file paths that are unique to an environment.

  • instance might be used in the future for more targeted knowledge base building. With some coordination, dedicated URLs or sections within the type URL could be linked to for more specific delving.

Example

{
  "type": "<url>",
  "title": "Access denied to content",
  "status": 403,
  "details": "Currently authenticated user lacks permission to view content on this site.""instance": "<url>#access-denied-to-content",
}

Furthermore, problem-specific extensions allow additional properties to be added. There are many future enhancements that might be considered from there.

Remaining tasks

  1. Decide from a product standpoint if this is a good direction for the Drupal REST implementation
  2. Create a facility to support message output in the application/problem+json or application/problem+xml format.
  3. Perform an initial survey of REST error messages to determine categories.
  4. For each error category, find or prepare a documentation page to server as the type URL.
  5. Convert errors thrown in the course of REST responses to be handled by the new error response mechanism.

Out-of-initial-scope

  • Handling multiple problems per error response
  • Coordinating documentation for error "instance" property
  • Adding flags to tailor the error response based on maintenance mode or other site states

User interface changes

REST error responses will change in structure and Content Type. Code which parses and uses the existing structure will break, though backwards compatibility might be preserved by using existing properties as "extensions" per the RFC.

API changes

New representation for errors will likely result in API additions. Changes in error handling might result in API changes to add additional parameters to some exceptions.

Data model changes

None.

Original report

Problem/Motivation

As was discussed in #1865594: Better REST error messages in case of exceptions, we want to respond with clearer error messages. There seem to be two different approaches which are gaining traction, api-problem from the IETF and vnd.error from the HAL community.

Proposed resolution

Decide which to use by default and implement it in a way that makes it easy to change.

Add a format and start/end validation constraints to DateRangeItem to provide helpful REST/JSON:API error message

$
0
0

Problem/Motivation

Currently \Drupal\datetime_range\Plugin\Field\FieldWidget\DateRangeWidgetBase::validateStartEnd() is validating date ranges - this means that the validation is in the form layer and not the data layer.

Proposed resolution

Create a constraint to handle this validation.

Remaining tasks

Add unit test for constraint.

User interface changes

None

API changes

An additional constraint for something that is currently only enforced by a form.

Data model changes

None


Override alt text per reference for image media items

$
0
0

Problem/Motivation

When reusing the same image in different places, the alt text of the image might be different for each use. Since images could contain a lot of elements, you might want to describe different parts of the image depending on the context of how the image is used. It is currently not possible to override the canonical alt text of a media image on a per use basis.

Proposed resolution

Add an alt text field to the media entity reference to store the alt text for a media item if needed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Introduce ENTITY_TYPE_list:BUNDLE cache tag and add it to single bundle listing

$
0
0

Problem/Motivation

There is ENTITY_TYPE_list cache tag and it is being invalidated very often. For example, if we have 20 different content types and created views page to display the list of content for each type, then whenever editor adds/edits/deletes one of the content - all 20 views pages will be invalidated BUT only related should be invalidated, others still have no changes. So, it means that on current sites if somebody changes something then Drupal will clear cache for almost the entire website.

Proposed resolution

Add bundle specific list cache tags - ENTITY_TYPE_list:BUNDLE
For example:

  • If the node listing is empty then add node_list tag.
  • If the node listing is only showing single bundle(page) then add node_list:page tag.
  • If the node listing is showing more than one bundle then add node_list tag.

Also:

  • Rename getListCacheTags to getListCacheTagsToInvalidate.
  • Add getListCacheTags in the follow up where we determine bundle specific cache tag based on query object.

so that listing pages can add bundle specific list cache tags or generic list cache tags

Remaining tasks

  1. Write tests as per #93.5
  2. Create follow-ups.
  3. Create change record.
  4. Open issues for views, search_api and other modules that will require an update.

Original report by [effulgentsia]

Follow up from #1712456: How to leverage cache tags in Views.

Two problems:

  1. That issue changed EntityViewBuilder::resetCache() from just clearing the TYPE:ID tag to also clearing the TYPE_view_BUNDLE tag. However, what is the meaning of this tag? What does it mean to "view" a bundle? #1712456-50: How to leverage cache tags in Views says "Say you save settings for one node type, it would invalidate caches for every node on the system?!", so ok, if the intent of this tag is to clear caches upon a change to the settings of a bundle, then why is it being cleared upon the saving of a single entity, which is when EntityViewBuilder::resetCache() is called? OTOH, the same comment also says We need a way like this to invalidate 'lists' containing this entity type. This and 'view' could be similar though I guess.. Hm, if the 'view' here refers to lists (where Views module is the most common list generator) rather than to the 'view' in the sense of EntityViewBuilder, then let's rename this tag to 'list' instead. If we then also want a per-bundle 'view' tag for clearing when bundle settings change in a way that would affect their display, then that's what we should use 'view_BUNDLE' for, but then clear it only where bundle settings are managed (e.g., EntityDisplay) rather than in EntityViewBuilder::resetCache().
  2. If we do rename this to TYPE_list_BUNDLE, then how should we handle Views that are cross-bundle? For example, currently in HEAD, if I enable tag-based caching on the front page View, then visit the front page at a time when only Article nodes are promoted to the front page, then I add a Page node and promote it, it doesn't show up on my front page until I manually clear caches. Perhaps we need a non-bundle-specific TYPE_list tag as well, and add that to all cross-bundle Views, but not to Views and EFQ listings that we know are bundle-specific?

Drupal core update 8.7.1 throws an error in Drupal\\serialization\\Normalizer\\EntityNormalizer

$
0
0

After updating Drupal core from 8.6.15 to 8.7.1/8.7.0. Am getting the below error in my error log:

PHP 7.3 version.

Recoverable fatal error: Argument 2 passed to Drupal\\serialization\\Normalizer\\EntityNormalizer::__construct() must implement interface Drupal\\Core\\Entity\\EntityTypeRepositoryInterface, instance of Drupal\\hal\\LinkManager\\LinkManager given, called in ../core/lib/Drupal/Component/DependencyInjection/Container.php on line 277 and defined in ../core/modules/serialization/src/Normalizer/EntityNormalizer.php on line 34 #0 ../core/includes/bootstrap.inc(587): _drupal_error_handler_real(4096, 'Argument 2 pass...', '/.....', 34, Array)\n#1 ../core/modules/serialization/src/Normalizer/EntityNormalizer.php(34): _drupal_error_handler(4096, 'Argument 2 pass...', '/.....', 34, Array)\n#2 ../core/lib/Drupal/Component/DependencyInjection/Container.php(277): Drupal\\serialization\\Normalizer\\EntityNormalizer->__construct(Object(Drupal\\Core\\Entity\\EntityManager), Object(Drupal\\hal\\LinkManager\\LinkManager), Object(Drupal\\Core\\Extension\\ModuleHandler))\n#3 ../core/lib/Drupal/Component/DependencyInjection/Container.php(502): Drupal\\Component\\DependencyInjection\\Container->createService(Array, 'private__iiMwUr...')\n#4 ../core/lib/Drupal/Component/DependencyInjection/Container.php(515): Drupal\\Component\\DependencyInjection\\Container->resolveServicesAndParameters(Array)\n#5 ../core/lib/Drupal/Component/DependencyInjection/Container.php(237): Drupal\\Component\\DependencyInjection\\Container->resolveServicesAndParameters(Object(stdClass))\n#6 ../core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\\Component\\DependencyInjection\\Container->createService(Array, 'serializer')\n#7 ../core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\\Component\\DependencyInjection\\Container->get('serializer', 1)\n#8 ../core/lib/Drupal/Component/DependencyInjection/Container.php(237): Drupal\\Component\\DependencyInjection\\Container->resolveServicesAndParameters(Object(stdClass))\n#9 ../core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\\Component\\DependencyInjection\\Container->createService(Array, 'rest.resource_r...')\n#10 ../core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(105): Drupal\\Component\\DependencyInjection\\Container->get('rest.resource_r...')\n#11 ../vendor/symfony/http-kernel/HttpKernel.php(191): Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher->dispatch('kernel.response', Object(Symfony\\Component\\HttpKernel\\Event\\FilterResponseEvent))\n#12 ../vendor/symfony/http-kernel/HttpKernel.php(130): Symfony\\Component\\HttpKernel\\HttpKernel->filterResponse(Object(Drupal\\Core\\Routing\\TrustedRedirectResponse), Object(Symfony\\Component\\HttpFoundation\\Request), 1)\n#13 ../vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\\Component\\HttpKernel\\HttpKernel->handleRaw(Object(Symfony\\Component\\HttpFoundation\\Request), 1)\n#14 ../core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\\Component\\HttpKernel\\HttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#15 ../core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\\Core\\StackMiddleware\\Session->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#16 ../core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#17 ../core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\\page_cache\\StackMiddleware\\PageCache->fetch(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#18 ../core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\\page_cache\\StackMiddleware\\PageCache->lookup(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#19 ../core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\\page_cache\\StackMiddleware\\PageCache->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#20 ../core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#21 ../vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#22 ../core/lib/Drupal/Core/DrupalKernel.php(693): Stack\\StackedHttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#23 ../index.php(19): Drupal\\Core\\DrupalKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request))\n#24 {main}

Sorry that am coping the full error for clarification.

The way I have updated the core is :

1) Deleted the core and vendor directories.
2) Deleted the composer.lock file
3) Edited the composer.json to hard code the drupal core version as 8.7.1
4) Run composer update - $ composer update drupal/core --with-dependencies
5) Step #4 through an error "symfony/http-foundation version ~3.4.27 required" so I have added the below step
6) composer require symfony/http-foundation:v3.4.27 --update-with-dependencies
7) Again run composer update - $ composer update drupal/core --with-dependencies
8) drush updb
9) drush entup
10) Tested the site

Can someone help me to resolve this problem?

Placing blocks that contain forms makes the Layout Builder settings un-save-able

$
0
0

Not sure what to do about this one.

Problem/Motivation

Any block that contains a form breaks the layout_builder layout configuration interface.

Steps to Reproduce

There are lots of ways to reproduce this I think, the steps below are how I came across it.

  1. Install views_block_filter_block - this allows block view displays to have exposed filters.
  2. Configure a view block with an exposed filter
  3. Add the view block to an entity layout
  4. Click 'Save Layout'

The page will refresh and still read "You have unsaved changes".

Why is this happening?

The block preview renders the exposed filters form with the view. This nests one form element inside another. Chrome (and presumably other browsers) then fixes this html so that the layout builder form starts where it should, but ends at the views exposed filters. This excludes the form_id, form_build_id and form_token hidden elements from the form submission so drupal never executes the submit handlers.

Possible Solution

Quick
Set the weight on the 'layout_builder' element really high so that the hidden inputs are all rendered before the layout. This would ensure that they always get submitted with the 'Save Layout' form. This seems like a hacky work around to me though, we would still be rendering invalid html.

Better
Separate the rendered layout from the form. All of the settings are stored in the tempstore rather than read from the form submission, so there is no reason to have the layout preview inside the

tags at all. This could be achieved with a custom controller.

[meta] Miscellaneous UI issues for the Layout Builder module

$
0
0

This is a meta-issue for tracking Miscellaneous UI issues for the Layout Builder module. Please open tasks for new issues using this one as the parent.

Viewing all 300222 articles
Browse latest View live


Latest Images

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