Alignment break and spacing issue
Step1 : Install Drupal
Step2 : Enable layout builder module
Step3 : Use Layout Builder from Administration > Structure > Content types > Article > Manage display > default > layout options
Step4 : Create Article from Content > Add content > Article and Save
Step5 : Click on Layout tab
TypeError: Cannot access offset of type string on string in drupal_array_set_nested_value() (line 6955 of /includes/common.inc).
The website encountered an unexpected error. Please try again later.
This error appeared after updating the Drupal version 7.101 and pages built by the views started to throw an error if you have filters on it.
This bug comes when calling drupal_array_set_nested_value from _form_builder_handle_input_element in /includes/form.inc file.
function _form_builder_handle_input_element($form_id, &$element, &$form_state) {
...
if (!$input_exists && !$form_state['rebuild'] && !$form_state['programmed']) {
// Add the necessary parent keys to $form_state['input'] and sets the
// element's input value to NULL.
drupal_array_set_nested_value($form_state['input'], $element['#parents'], NULL);
$input_exists = TRUE;
}
...
}function drupal_array_set_nested_value(array &$array, array $parents, $value, $force = FALSE) {
$ref = &$array;
foreach ($parents as $parent) {
// PHP auto-creates container arrays and NULL entries without error if $ref
// is NULL, but throws an error if $ref is set, but not an array.
if ($force && isset($ref) && !is_array($ref)) {
$ref = array();
}
$ref = &$ref[$parent];
}
$ref = $value;
}The function drupal_array_set_nested_value should be called with force = TRUE argument to match the statement
"when $ref is set, but not an array" in drupal_array_set_nested_value function.
Layout Builder introduces a new paradigm shift in page building and block placement for content entities without introducing a block visibility mechanism.
Provide a mechanism for configuring each block/component of a layout region to have conditional visibility using core's visibility plugins similar to existing blocks.
Address feedback
Review
Repeat
Usability review
Finalize patch
- New "Configure Visibility" link on LB component links.
- New configuration forms for managing visibility within Layout Builder.
Visibility is added into the existing configuration schema and functionality is built into the event system so no API changes are needed.
See API changes.
Media derive their thumbnail images and alt text for those images from their media source plugins. For image-based media, that's the "Image" media source plugin. When the plugin is asked to present the alt text for its thumbnail image, it returns the alt text stored in the image field of the media entity. This works great, unless the alt text is an empty string. The Image plugin treats this as a "falsey" value and ends up returns NULL for the alt text instead of the empty string.
An empty string value for the alt text attribute (alt="") has important meaning for accessibility. It instructs assistive tech that the image is decorative and should be ignored by screen readers. Drupal's image formatter template will correctly output the alt="" attribute on the image element in this case. If the alt is NULL, then Drupal's image formatter template won't print the alt attribute at all. This is very problematic as assistive tech may instead announce the image filename when it comes upon the image, because it's assuming the missing alt attribute is a mistake and the image may be important for the user to know about.
This is a simple fix. Modify the getMetadata method of the Image media source plugin so that it if the alt text of the associated media entity is an empty string, return the same empty string.
No. Could have an update function to update all existing media thumbnails to swap NULL thumbnail alt values with an empty string instead, but that's probably not worth it. Some sites will have tens of thousands of media items and I guess this update function could take a while to run.
Upgraded to 10.3 and status-message.html.twig is missing as a theme suggestion, breaking my custom theme. See screenshots.
Copied git bisect result from #24
2172d1009cec0e8f908a51fb2c99a1eb06b8b6da is the first bad commit
commit 2172d1009cec0e8f908a51fb2c99a1eb06b8b6da
Author: Alex Pott <alex.a.pott@googlemail.com>
Date: Thu Feb 22 08:52:28 2024 +0000
Issue #3379885 by catch, Wim Leers: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder
(cherry picked from commit 44c345dd9b8e2e1fb7131868a5d8b27c57e5b8e3)
core/modules/big_pipe/big_pipe.services.yml | 2 +-
core/modules/big_pipe/src/Render/BigPipe.php | 79 +++++-----------------
.../big_pipe/tests/src/Functional/BigPipeTest.php | 8 +--
.../FunctionalJavascript/BigPipeRegressionTest.php | 9 ++-
.../tests/src/Unit/Render/FiberPlaceholderTest.php | 4 +-
.../tests/src/Unit/Render/ManyPlaceholderTest.php | 4 +-
6 files changed, 32 insertions(+), 74 deletions(-)
Issue: #3379885: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder
First bad commit: 2172d1009cec0e8f908a51fb2c99a1eb06b8b6da
Bad commit at the relevant file: core/modules/big_pipe/src/Render/BigPipe.php
"The website encountered an unexpected error. Try again later.
InvalidArgumentException: The allowed types parameter is required and must be an array of strings. in Drupal\media_library\MediaLibraryState->validateRequiredParameters() (line 150 of core/modules/media_library/src/MediaLibraryState.php)."
Sharing SS:
After Deleting all Media types, I am getting this error on the home page & content page as an admin, except for admin pages...
Platform D10.2.7, MySQL - 5.8, PHP- 8.3
1. Delete all media types from admin>structure>media.
2. Go back to the home page or any content page.
Fix the issue in validateRequiredParameters()
By doing a search, when you choose to display all the items (items_per_page=All). This error occurs.
DivisionByZeroError: Division by zero in Drupal\Core\Pager\Pager->setTotalPages() (line 78 of core/lib/Drupal/Core/Pager/Pager.php).
Drupal\Core\Pager\Pager->__construct('24', 0, 0) (Line: 56)
Drupal\Core\Pager\PagerManager->createPager('24', 0, 1) (Line: 232)
Drupal\views_bulk_operations\Service\ViewsBulkOperationsViewData->getTotalResults() (Line: 205)
Drupal\views_bulk_operations\Plugin\views\field\ViewsBulkOperationsBulkForm->updateTempstoreData(Array) (Line: 657)
Drupal\views_bulk_operations\Plugin\views\field\ViewsBulkOperationsBulkForm->viewsForm(Array, Object) (Line: 111)
Drupal\views\Form\ViewsFormMainForm->buildForm(Array, Object, Object, Array) (Line: 172)
Drupal\views\Form\ViewsForm->buildForm(Array, Object, Object, Array)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('views_form_chirequien_page_1', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 224)
Drupal\Core\Form\FormBuilder->getForm(Object, Object, Array) (Line: 2262)
Drupal\views\Plugin\views\display\DisplayPluginBase->elementPreRender(Array)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 859)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 421)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 231)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
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: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->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: 53)
Asm89\Stack\Cors->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Set the 'Items per page' filter
Select 'All'
Apply
Check the limit value to avoid dividing by 0
Validate the patch
Enter "example (test)" value to any entity autocomplete field.
The following exception will be thrown.
The website encountered an unexpected error. Please try again later.
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type bigint: "test" LINE 5: ...('tags')) AND ("taxonomy_term_field_data"."tid" IN ('test')) ^: SELECT "base_table"."revision_id" AS "revision_id", "base_table"."tid" AS "tid" FROM "taxonomy_term_data""base_table" INNER JOIN "taxonomy_term_field_data""taxonomy_term_field_data" ON "taxonomy_term_field_data"."tid" = "base_table"."tid" WHERE ("taxonomy_term_field_data"."vid" IN (:db_condition_placeholder_0)) AND ("taxonomy_term_field_data"."tid" IN (:db_condition_placeholder_1)); Array ( [:db_condition_placeholder_0] => tags [:db_condition_placeholder_1] => test ) in Drupal\Core\Entity\Query\Sql\Query->result() (line 273 of core/lib/Drupal/Core/Entity/Query/Sql/Query.php).
Drupal 10.1.x, PHP 8.2, PostgreSQL 15
Views module adds $variables['view'] to node templates.
This is impossible to provide cacheable metadata for, because we don't have the render context of the view. I've also never seen it used.
We should deprecate it in 11.1.0 for removal in 12.0.0
Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).
appears on pages, where layouts are being listed in a select which uses $this->layoutPluginManager->getLayoutOptions() to get its options.
Example:
$form['field_layouts']['field_layout'] = [
'#type' => 'select',
'#title' => $this->t('Select a layout'),
'#options' => $this->layoutPluginManager->getLayoutOptions(),
'#default_value' => $layout_plugin->getPluginId(),
'#ajax' => [
'callback' => '::settingsAjax',
'wrapper' => 'field-layout-settings-wrapper',
'trigger_as' => ['name' => 'field_layout_change'],
],
];
(FieldLayoutEntityDisplayFormTrait.php)
layout_builder's layout_builder_blank aka BlankLayout neither has a label nor a category defined in its annotation:
/**
* Provides a layout plugin that produces no output.
*
* @see \Drupal\layout_builder\Field\LayoutSectionItemList::removeSection()
* @see \Drupal\layout_builder\SectionListTrait::addBlankSection()
* @see \Drupal\layout_builder\SectionListTrait::hasBlankSection()
*
* @internal
* This layout plugin is intended for internal use by Layout Builder only.
*
* @Layout(
* id = "layout_builder_blank",
* )
*/
class BlankLayout extends LayoutDefault {
it should be sorted out by
/**
* Implements hook_plugin_filter_TYPE_alter().
*/
function layout_builder_plugin_filter_layout_alter(array &$definitions, array $extra, $consumer) {
// Hide the blank layout plugin from listings.
unset($definitions['layout_builder_blank']);
}
(layout_builder.module)
but that hook never gets called!
So the layout_builder_blank layout is being passed through without label or category, but these methods rely on these values to be present. They are being called indirectly by $this->layoutPluginManager->getLayoutOptions()
/**
* {@inheritdoc}
*
* @return \Drupal\Core\Layout\LayoutDefinition[]
*/
public function getSortedDefinitions(array $definitions = NULL, $label_key = 'label') {
// Sort the plugins first by category, then by label.
$definitions = $definitions ?? $this->getDefinitions();
uasort($definitions, function (LayoutDefinition $a, LayoutDefinition $b) {
if ($a->getCategory() != $b->getCategory()) {
return strnatcasecmp($a->getCategory(), $b->getCategory());
}
return strnatcasecmp($a->getLabel(), $b->getLabel());
});
return $definitions;
}
/**
* {@inheritdoc}
*
* @return \Drupal\Core\Layout\LayoutDefinition[][]
*/
public function getGroupedDefinitions(array $definitions = NULL, $label_key = 'label') {
$definitions = $this->getSortedDefinitions($definitions ?? $this->getDefinitions(), $label_key);
$grouped_definitions = [];
foreach ($definitions as $id => $definition) {
$grouped_definitions[(string) $definition->getCategory()][$id] = $definition;
}
return $grouped_definitions;
}
/**
* {@inheritdoc}
*/
public function getLayoutOptions() {
$layout_options = [];
foreach ($this->getGroupedDefinitions() as $category => $layout_definitions) {
foreach ($layout_definitions as $name => $layout_definition) {
$layout_options[$category][$name] = $layout_definition->getLabel();
}
}
return $layout_options;
}
This is why the error appears.
This deprecation warning didn't appear in older versions of PHP, so the bug wasn't visible.
TL;DR:
/**
* Implements hook_plugin_filter_TYPE_alter().
*/
function layout_builder_plugin_filter_layout_alter(array &$definitions, array $extra, $consumer) {
// Hide the blank layout plugin from listings.
unset($definitions['layout_builder_blank']);
}
(layout_builder.module)
is not called, so the layout_builder_blank layout, which neither has a label nor a description is not being sorted out, which leads to this error!
field_layout module./en/admin/structure/types/manage/article/form-display.Alternatively, install Drupal with the Standard profile, then enable the field_layout and layout_builder modules.
It seems as like the LayoutPluginManager (DI-injected by $container->get('plugin.manager.core.layout'),) is entirely missing FilteredPluginManagerTrait, so that its alterations are never being called:
/**
* Implements \Drupal\Core\Plugin\FilteredPluginManagerInterface::getFilteredDefinitions().
*/
public function getFilteredDefinitions($consumer, $contexts = NULL, array $extra = []) {
if (!is_null($contexts)) {
$definitions = $this->getDefinitionsForContexts($contexts);
}
else {
$definitions = $this->getDefinitions();
}
$type = $this->getType();
$hooks = [];
$hooks[] = "plugin_filter_{$type}";
$hooks[] = "plugin_filter_{$type}__{$consumer}";
$this->moduleHandler()->alter($hooks, $definitions, $extra, $consumer);
$this->themeManager()->alter($hooks, $definitions, $extra, $consumer);
return $definitions;
}
meanwhile, they are being called in Layout builder (e.g. admin/structure/types/manage/page/display/default/layout) when adding a section.
So maybe layout_builder is doing something different or special?
If layout_builder is not installed, everything is fine!
Drupal\layout_builder\Plugin\Layout\BlankLayout so that getCategory() and getLabel() return string|\Drupal\Core\StringTranslation\TranslatableMarkup as required, instead of NULL.getFilteredDefinitions() in LayoutPluginManager::getLayoutOptions().Either (1) or (2) by itself is enough to avoid the error. If we implement (1) but not (2), then it leads to a regression: the blank layout is listed, when it currently is not. See Comment #50. If we implement (2) but not (1), then we are hiding the error instead of fixing it.
For (3), mock Drupal::service('theme.manager'), since that is called in FilteredPluginManagerTrait::themeManager(). Then call getLayoutOptions() and confirm that the module and theme alter() methods are called.
The decision is made: #3450764: Make $consumer optional in Drupal\Core\Plugin\FilteredPluginManagerTrait::getFilteredDefinitions() is the follow-up issue.
None, except for not showing the PHP error.
Drupal\Core\Layout\LayoutPluginManager::getLayoutOptions()
respects hook_plugin_filter_alter(), so modules and themes can alter the list of layouts.
N/A
User themes can have something like font-size: 1vw; (just for instance) set on html tag, to have proportional scaling of all UI elements no matter which resolution of the screen.
Almost all sizes of everything related to Navigation module are based on --admin-toolbar-rem CSS variable, which is doing its job great. However we still have few UI elements with the px sizes set, or some where don't have sizes set at all (for instance logotype)
1. Standard profile installation
2. Enable Navigation module
3. Then on any page try to zoom out or zoom in
4. Then add for instance font-size: 1vw; to the html tag and try to zoom out or zoom it again
I found 3 UI elements (could be more, but seems only 3, at least i didn't find anything else) where we have to set or replace sizes in rems:
1. Logotype
2. Dividing line between sections in navigation bar
3. Outlines/borders, hovers and focuses (to be checked for all interactive elements which does have these states with outlines)
1. Convert existing hardcoded px values into rems (using --admin-toolbar-rem css variable)
2. For the elements like logotype - add sizes
Breadcrumb builders are called in a specific order, the first one that returns a valid Breadcrumb object from its build() method is the one that will be returned from the manager. Before a builder is called, we first check its applies() method and only if that returns TRUE do we call build().
The problem lies within the fact that the applies check might introduce variability that needs to be represented by a cache context, but is not unless it returns TRUE. At that point does the build() method add the right cacheable metadata to the breadcrumb result. This is wrong, though, because a negative outcome also needs to have said cacheable metadata.
You can see how this breaks in #3452181-7: VariationCache needs to be more defensive about cache context manipulation to avoid broken redirects, comments 7 through 9.
Pass cacheable metadata to the applies() method so that it can properly set its variability (cache contexts) and dependencies.
Review MR and commit
N/A
BreadcrumbBuilderInterface::applies() now takes a second argument CacheableMetadata $cacheable_metadata
N/A
Updated: Comment #206
Twig debugging output is supposed to show all template suggestions. Currently, the debug output does not show all the template suggestions that the Drupal render system knows about.
Here are a few examples where this feature fails:
/admin/content and look at the Filter form at the top of the page; Twig debug shows: 'views_exposed_form', but Drupal's theme system is given this list of suggestions: ['views_exposed_form__content__page_1', 'views_exposed_form__page_1', 'views_exposed_form__default', 'views_exposed_form__content__page', 'views_exposed_form__page', 'views_exposed_form__content', 'views_exposed_form'] (defined in Drupal\views\Form\ViewsExposedForm::buildForm()).x item-list--search-results.html.twig, x item-list--search-results.html.twig, * item-list.html.twig, but Drupal's theme system is given this list of suggestions: ['item_list__search_results__node_search', 'item_list__search_results'] (defined in Drupal\search\Controller\SearchController::view()).The underlying cause of this issue is when #theme is set as an array of suggestions. The twig_debug output only works* when #theme is a string or when suggestions are added via suggestions_alter hooks.
* where "works" is defined as super buggy output, showing duplicates and out-of-order suggestions. See #2752443: Incorrect order and duplicate theme hook suggestions
When #theme is set as an array of suggestions, Drupal\Core\Theme\ThemeManager::render() will call the theme suggestions alter hooks with the base hook and will conditionally add an entry from the #theme array if that entry is actually implemented in the system. If none of #theme array suggestion entries are implemented, only the base hook is sent to the theme suggestions alter hooks and the code handling the twig debug comments code.
Here's a specific example of what Drupal core does now:
#theme is set to ['item_list__search_results__node_search', 'item_list__search_results'] in Drupal\search\Controller\SearchController::view()Drupal\Core\Theme\ThemeManager::render() will look for implementations of the theme suggestions in the #theme entry.
item-list.html.twig (like in the Stable themes), the theme suggestion alter hooks will be passed this list of suggestions: item_list, [list of suggestions from hook_theme_suggestions_item_list() (if this function existed)]item-list--search-results.html.twig Twig template is implemented (like most core themes), the theme suggestion alter hooks will be passed this list of suggestions: item_list, [list of suggestions from hook_theme_suggestions_item_list()], item_list__search_resultstwig_render_template() generates the Twig debugging comments by looking at the list of theme suggestions returned by the theme suggestion alter hooks (passed in $variables['theme_hook_suggestions']). But it doesn't know about the item_list__search_results__node_search suggestion in Step 1, so the list is wrong.Theoretically, we could fix this by #2923506: Deprecate and discourage use of the "array of theme hooks" feature, but that is a loooong road of deprecations that is completely stalled. And since the "array of theme hooks" feature has been in core since 6.x and has been used frequently in contrib and in core 9.1.x and earlier, we need to fix the bug now.
To minimize the possible side effects to changing how Twig chooses templates, we should not modify any existing lines of code inside OMG. No. This is technically possible, but a "proper list of theme suggestions" requires super ugly code if we're not going to modify existing lines of code. See comment #204 for proof in the form of a patch that implements this option.Drupal\Core\Theme\ThemeManager::render() and only add code to generate a proper list of theme suggestions.
Instead of conditionally appending suggestions from #theme on to the end of the suggestions from hook_theme_suggestions_HOOK(), we should always append those suggestions so that hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter() can see them.
Extending the example above, no matter what item_list Twig templates are implemented, the theme suggestion alter hooks will be passed this list of suggestions: item_list, [list of suggestions from hook_theme_suggestions_item_list()], item_list__search_results, item_list__search_results__node_search
This will make it easy to output an accurate suggestion list in twig debugging comments.
We will need to add extensive tests to make sure we aren't breaking anything.
This solution also fixes #2752443: Incorrect order and duplicate theme hook suggestions.
Twig debug output will display all templates suggestions, no matter the source of those suggestions.
The theme suggestions from #theme will always be added to the end of the hook_theme_suggestions_HOOK() list of suggestions before sending them to hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter().
Previously, theme suggestions from #theme (like views_exposed_form__content__page) were only sometimes added to the $suggestions variable passed to hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter(). Now those suggestions are always passed to alter hooks.
When exporting the layout builder settings from a site, if inline blocks are present the resulting *.yml file will look like this:
128118dd-d092-4a42-958e-2d686c0a1351:
uuid: 128118dd-d092-4a42-958e-2d686c0a1351
region: blb_region_col_1
configuration:
id: 'inline_block:see_more'
label: 'See more'
label_display: '0'
provider: layout_builder
view_mode: full
context_mapping: { }
block_revision_id: 468 <------- REVISION ID
block_serialized: null
weight: 1
additional: { }
After importing this configuration to a different environment, layout builder fails because the block $entity
on Drupal\layout_builder\Plugin\Block::build() is null.
public function build() {
$block = $this->getEntity();
return $this->entityTypeManager->getViewBuilder($block->getEntityTypeId())->view($block, $this->configuration['view_mode']);
}
This is due to the revision_id being nonexistent on the new environment (see Drupal\layout_builder\Plugin\Block::getEntity():)
elseif (!empty($this->configuration['block_revision_id'])) {
$entity = $this->entityTypeManager->getStorage('block_content')->loadRevision($this->configuration['block_revision_id']);
$this->blockContent = $entity;
}
$entity is NULL and $this->blockContent is set to NULL as a result.
- On an environment, create and export default layout builder settings for a given entity. Use at least one inline block.
- On a different environment, import the entity_view_display settings of the entity view mode that is using layout builder.
- Try to edit the layout: an error will occur as the inline block revision ID can't be loaded and is not created on the fly or any sanity check is in place.
I don't know much about Layout Builder inner workings, but i'm guessing that one of the following should happen:
- The revision_id shouldn't be used, and instead the block config should be exported and a brand new revision created on import.
- Inline block export on layout builder shouldn't be supported yet, sanity checks put into place to avoid fatal errors (this will result on blocks missing after an export/import)
- Somehow, inline block instances and their exact revisions should be exported alongside layout builder settings (how? i don't know)
Follow up to #2765297: Return translated term name on views "Content: Has taxonomy term ID (with depth)" which seems to have caused a regression where in certain situations the token replacement now returns no term label.
This might be caused when getTranslationFromContext return NULL, which according to the Interface docblock it can do, but looking at the implementation in \Drupal\Core\Entity\EntityRepository::getTranslationFromContext this will never happen.
Please provide steps to reproduce.
This is an issue that we haven't had to deal with since the Drupal 6 to Drupal 7 upgrade path, but now we do again.
The following scenarios are broken:
system_update_100000() is added to 11.0.x and 10.3.x
[time elapses]
system_update_100100() is added to 11.1.x to support a new feature, it is not backported to 10.4.x
[time elapses]
A critical bug fix which is eligible for backport to 10.4.x, but requires a small update, is committed to 11.1.x
[dragons emerge from the darkness, volcanos erupt]
If this update is added as system_update_100101() and backported to 10.4.x, then when 10.4.x sites are updated to 11.1.x, they won't run system_update_100100() because their schema version will be higher already.
If this update is added as system_update_100001() in 11.1.x, and 10.4.x, it won't run on 11.x sites because their schema version will be 100100 already.
This is less of an issue, but still a problem:
system_post_update_fix_config() is added to 11.1.x, it is backported to 10.4.x, but not 11.0.x because it's security-only.
If a site updates from 10.4.x to 11.0.x, then the post update goes 'missing' from the code base. It will then re-emerge when the site updates again to 11.1.x or 11.2.x
Sequential backports to minor branches without skipping a release are OK though for post updates regardless of how far they go back, since they don't interfere with other post updates.
This is only a serious problem for hook_update_N() due to sequential update ordering. Because post updates are tracked individually and order isn't guaranteed, the only issue with those is a site updating from 10.4 to 11.0 (i.e. 'backwards' in terms of minor release parity).
For hook_update_N(), we can add a small API addition to the update system, which will probably be exclusively used by core updates.
1. An 11.x hook_update_N() would be added as normal, with no extra method calls or metadata. Let's say system_update_11100()
2. When that same update is backported to 10.x, we backport it with it's own update number, say system_update_10400().
In system_update_10400(), we call \Drupal::service('update.update_hook_registry')->skipUpdate(11100)
This logs the module, update being run, and future update, to a key value collection.
When a site updates to 11.1 from 10.4, it will have this information in key value. In update_do_one() we then check against the key value collection, and if an 11.1 update should be skipped, we skip it and log a success message.
The huge advantage of this is that there is no 11.x-specific code dealing with the 10.4.x update numbers, we just need the API in place to check key/value and that's it. 11.x updates can be committed with no API changes. 10.4 update backports need to call one method with a small amount of information.
If a site tries to update to 11.0 from 10.4, then in terms of database updates it will be going 'backwards' - however because we have the key value store, we can detect this, and issue an update requirements error telling them to go to 11.1 instead.
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.
Configure the field formatter and check that we don't have flexibility to render absolute url.
- 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.
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
- New option is added on both the field formatters.
- N/A
- N/A
After upgrading Drupal core to version 10.2.0, an issue has arisen within the image field functionality. Specifically, the image field is now permitting duplicate allowed image types, which goes against the expected behavior.
Create or navigate to an existing content type with an image field. Observe that the image field is permitting the addition of duplicate image types (see attached screenshot for reference).
Follow-up to #3353210-37: [PHPUnit 10] @dataProvider methods must be declared static and public.
Data providers methods to tests should have an appropriate typehint: array or iterable depending on the test approach.
Maybe the script developed in #3353210: [PHPUnit 10] @dataProvider methods must be declared static and public could be reused for the purpose.