$book_title variable in book-navigation.tpl.php contains the page title

March 13, 2009, 8:21 am

≫ Next: Olivero: jQuery UI (deprecated in D9) date picker visually broken

≪ Previous: Provide default view mode per bundle for media embed

I wanted to add a link to the first page of the book in the book navigation. The $book_url variable contains the url of the first page, however, $book_title contains the title of the current page!

From book.module:

function template_preprocess_book_navigation(&$variables) {
  $book_link = $variables['book_link'];

  // Provide extra variables for themers. Not needed by default.
  $variables['book_id'] = $book_link['bid'];
  $variables['book_title'] = check_plain($book_link['link_title']);
  $variables['book_url'] = 'node/'. $book_link['bid'];
  ...

Not sure what the best way to fix this is - I have resorted to querying the node table in a preprocess function.

↧

Olivero: jQuery UI (deprecated in D9) date picker visually broken

June 2, 2020, 9:47 am

≫ Next: Double // in file paths

≪ Previous: $book_title variable in book-navigation.tpl.php contains the page title

The jQuery UI datepicker is visually broken. Note that jQuery UI is only in D8 core. Within Drupal 9, it is deprecated.

However, the D9 version of webform loads it's own version of the jQuery UI datepicker. This is only visible in Safari, as FF, and Chrome have their own UI. This may also be visible in IE and Edge.

Question: Should we support this, since it is not supported by D9 core?

↧

Double // in file paths

June 12, 2020, 11:26 pm

≫ Next: TypeError EntityViewsData::mapFieldDefinition() null given

≪ Previous: Olivero: jQuery UI (deprecated in D9) date picker visually broken

Problem/Motivation

This is a follow up to #2925899: MigrateUpgradeImportBatch does not use source_private_file_path & source_base_path correctly, making it impossible to have public & private files in separate locations.
benjifisher reported

When I run file migrations and there are missing files, the message often lists a path including //, and I think one of those characters comes from this line. Do we need to add a trailing / here?

$configuration['source']['constants']['source_base_path'] = rtrim($base_path, '/') . '/';

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

TypeError EntityViewsData::mapFieldDefinition() null given

June 9, 2020, 1:43 pm

≫ Next: htaccess rules appear to break image styles

≪ Previous: Double // in file paths

I get the following error after upgrading from 8.8 to 8.9.
TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /var/www/html/web/core/modules/views/src/EntityViewsData.php on line 315 in Drupal\views\EntityViewsData->mapFieldDefinition() (line 412 of core/modules/views/src/EntityViewsData.php).

I made a quick patch to handle the error so that I can keep going until I or someone can take a closer look.
Hope this helps someone.

↧

htaccess rules appear to break image styles

February 12, 2018, 12:39 pm

≫ Next: "Illegal choice 0 in Book element" when switching the book outline field from anything to "- None - "

≪ Previous: TypeError EntityViewsData::mapFieldDefinition() null given

This is a very strange issue that I am having difficulty isolating, but also do not appear to be the only one experiencing it.

It seems that the addition of mod_rewrite rules (whether to conf.d or htaccess) breaks image styles.

For example, if I enable the following rule:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?<my domain> [NC]
RewriteRule \.(pdf|apk|log)$ - [NC,F,L]

Then any time the code base requests a Medium version of an image be made, it is simply never created. The folder where it should be contained is empty.

Disabling this rule stops the problem and image styles generate as normal.

My stackexchange thread: https://drupal.stackexchange.com/questions/255474/image-styles-not-gener...
Another stackexchange thread: https://drupal.stackexchange.com/questions/251541/adding-protection-agai...
drupal.org thread: https://www.drupal.org/forum/support/post-installation/2015-06-16/image-...

None of the suggestions contained in any of these links worked for me.

↧

"Illegal choice 0 in Book element" when switching the book outline field from anything to "- None - "

February 10, 2017, 6:34 am

≫ Next: Deprecate more jQuery UI library definitions

≪ Previous: htaccess rules appear to break image styles

↧

Deprecate more jQuery UI library definitions

February 13, 2020, 3:43 am

≫ Next: Autocomplete for exposed forms does not work on mobile

≪ Previous: "Illegal choice 0 in Book element" when switching the book outline field from anything to "- None - "

Problem/Motivation

We deprecated most jQuery UI library definitions, and removed these from Drupal 9.x

Some library definitions were not deprecated though, because they're dependencies of core JavaScript - drupal.dialog, drupal.autocomplete etc. which have not been refactored yet. This includes jquery.ui.button jquery.ui.mouse jquery.ui.resizable jquery.ui.widget, and jquery.ui itself.

However, those core libraries like drupal.autocomplete don't have to depend on jQuery UI libraries specified in core.libraries.yml, they could instead depend directly on the components themselves, essentially merging the library definitions together.

The big advantage of this is it allows us to avoid adding to the skipped deprecation list, see #3098489: Remove deprecated jQuery UI library definitions which is where this idea developed.

This doesn't reduce our dependency on the components themselves, but it prevents new dependencies on them being added in contributed and custom modules during the 9.x cycle.

Proposed resolution

1. Where an actual core library like drupal.autocomplete depends on jQuery UI components, add the components as direct javascript and CSS file dependencies, removing the dependency on the library definition.

2. Deprecate all of the remaining jquery.ui library definitions in core, ensuring that contrib replacements exist (true for most but not all as I type this).

Remaining tasks

1. Should we do a late deprecation for 9.x removal in 8.8 and 8.9? An argument in favour is that jQuery UI is already abandoned, and we already made a big announcement about this, we're just adding more to the same change record. If not, we'd need to decide whether to add an early 10.x deprecation (since we actively want to discourage dependencies on jQuery UI) or wait until 9.1.x

2. Views UI uses jquery.ui.dialog directly, instead of drupal.dialog. This makes it harder to deprecate jquery.ui.dialog. One option is to have Views UI declare its own views.jquery.ui.dialog library that's a clone of the jquery.ui.dialog definition. Another is to rely on the skipped deprecation list for jquery.ui.dialog

User interface changes

None.

API changes

Yes, more jquery.ui library definitions deprecated.

Data model changes

Release notes snippet

The core jquery.ui, jquery.ui.autocomplete, jquery.ui.dialog, jquery.ui.draggable, jquery.ui.menu, jquery.ui.mouse, jquery.ui.position, jquery.ui.resizable, and jquery.ui.widget library definitions have been deprecated. Modules and themes with a dependency on these library definitions should use the contributed module versions.

Modules that override these library definitions, or the definitions of libraries that depend on them (such as drupal.autocomplete, drupal.dialog, and drupal.tabbingmanager) may need to update their overrides to ensure the same changes to the resulting JavaScript and CSS are applied.

↧

Autocomplete for exposed forms does not work on mobile

October 20, 2020, 9:34 am

≫ Next: Render multiple value fields in node template

≪ Previous: Deprecate more jQuery UI library definitions

Hi,

The autocomplete for exposed forms does not work on mobile.

You have to type for example on space, so that the suggestions appear.

↧

Render multiple value fields in node template

July 31, 2016, 10:15 am

≫ Next: Wrong link in messages created at installation

≪ Previous: Autocomplete for exposed forms does not work on mobile

You can access single value field in node template easily:

{{ content.field_test }}
or
{{ node.field_test.value }}

But iteration over multiple value fields is not pretty:

{% for key, item in content.field_tags if key|first != '#' %}
  <div class="item-{{ key + 1 }}">{{ item }}</div>
{% endfor %}

You can, of course, use a field template, but sometimes it doesn't make sense to have a ton of field template when you can simply have one node template.

Example:

I need to add "," between a field's values (a multiple value entity references field rendered in label). So I have a field template with:

{% for item in items %}
  {{ item.content }}{% if not loop.last %},{% endif %}
{% endfor %}

And in my node template I have:

{% if content.field_facilities is not empty %}
   <p>{{ content.field_facilities }}</p>
{% endif %}

But I would prefer to have a similar code directly in my node template like:

{% if content.field_facilities is not empty %}
   <p>
     {# This do not works! #}
     {% for item in content.field_facilities %}
       {{ item.content }}{% if not loop.last %},{% endif %}
     {% endfor %}
   </p>
{% endif %}

What would be the best way to solve that?

Wrong link in messages created at installation

February 22, 2018, 1:27 am

≫ Next: Status Report Page Update

≪ Previous: Render multiple value fields in node template

The warning messages (created at install time) contain incorrect links. The links in screenshot have the following hrefs:

<a href="/core/install.php/admin/config/regional/language">Add at least one more language</a>
<a href="/core/install.php/admin/config/regional/content-language">Enable translation</a>

The links should not contain "/core/install.php"

↧

Status Report Page Update

June 11, 2019, 1:42 pm

≫ Next: [ignore] bnjmnm new patch graveyard

≪ Previous: Wrong link in messages created at installation

Current Issue:

The current design of the status page does not reflect recently updated Claro designs. Most importantly noting the change from tan/yellow to grey backgrounds. There are also issues with inconsistent iconography in the table layouts, browser support of defaults for some icon behavior, and the responsive nature of the table layouts in general.

The current design that we are to build upon has been uploaded as a screen shot for reference.

Proposed Solution:

Status Page needs to reflect the new design considerations of Claro. The page will be broken up into a variety of components that we will pull from other final components designed in Figma here.

This layout will also require the design of new components. The page is currently comprised of the following components (some have already been redesigned and some can pull from redesigned elements):

Page Title
Breadcrumbs
Page Description
Quick-Look Report Card
General System Information
Errors List
Warnings List
Checked List

Remaining tasks

~~Finalize design~~
Style page
Test for Accessibility conformance

↧

[ignore] bnjmnm new patch graveyard

December 10, 2019, 10:07 am

≫ Next: IGNORE: Testing issue

≪ Previous: Status Report Page Update

Just crash testing patches

↧

IGNORE: Testing issue

July 2, 2020, 12:12 am

≫ Next: Layout builder's quickedit integration breaks if you embed another layout builder view mode in the full page

≪ Previous: [ignore] bnjmnm new patch graveyard

↧

Layout builder's quickedit integration breaks if you embed another layout builder view mode in the full page

January 30, 2020, 4:30 pm

≫ Next: Remove accidentally duplicated words in code comments

≪ Previous: IGNORE: Testing issue

Problem/Motivation

- Create a teaser view mode and configure it with layout builder
- In full view mode, configure to show an ER field using 'rendered entity' and 'teaser' where teaser uses LB
- Enable quickedit
- Error on quickedit/metadata

InvalidArgumentException: Invalid UUID "fdc5f1c3-6681-48d4-a962-b8427206d18e" in Drupal\layout_builder\Section->getComponent() (line 177 of core/modules/layout_builder/src/Section.php).

Proposed resolution

Catch the exception and carry on?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧

Remove accidentally duplicated words in code comments

October 6, 2020, 10:32 am

≫ Next: Reorder Layout Builder sections

≪ Previous: Layout builder's quickedit integration breaks if you embed another layout builder view mode in the full page

Problem/Motivation

Fix duplicated words in core, i.e. 'settings settings'. Keep in mind that in English there are situations where a duplicate word is correct. Here are examples from https://www.grammarphobia.com/blog/2013/08/this-and-that.html

“I can see that that is going to be a problem.”
“I received this this morning.”

Original report
Repeated 'settings' word in multiple files

Steps to reproduce

Proposed resolution

Grep for all potential instances of incorrectly duplicated words and remove the instances that are clearly wrong:

This should find any duplicated words in docblocks:

egrep -r '\<([a-zA-Z]+)\> \<\1\>' ./ | grep -v 'node_modules' | grep -v 'vendor' | grep '* '

This should find any duplicated words in inline comments:
egrep -r '\<([a-zA-Z]+)\> \<\1\>' ./ | grep -v 'node_modules' | grep -v 'vendor' | grep '// '

Occasionally, a duplicated word is actually correct. (E.g. "that that" is grammatically correct in some cases in English, and there are also other instances like annotation/parameter declarations where it might be correct.) So don't just blindly remove the duplicated word -- check each one.

Remaining tasks

Patch
Review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

↧

Reorder Layout Builder sections

September 11, 2019, 7:07 am

≫ Next: Replace Loose comparison by Strict comparison in contact module

≪ Previous: Remove accidentally duplicated words in code comments

Problem/Motivation

Some complex page layouts leverage multiple section containers for long-form content, where reordering sections would be helpful.

Proposed resolution

Allow re-ordering of sections through the UI in mobile-friendly, accessible manner.

Remaining tasks

Determine the best UI for re-ordering sections
Write patch with functionality
Write tests

User interface changes

TBD

API changes

None anticipated.

Data model changes

None anticipated.

Release notes snippet

TBD

↧

Replace Loose comparison by Strict comparison in contact module

October 22, 2020, 4:11 am

≫ Next: [ignore] Patch Testing Only

≪ Previous: Reorder Layout Builder sections

Problem/Motivation

PHP is weakly typed and this can lead to bugs like https://bugs.php.net/bug.php?id=54547.
In addition, it causes our code to be less explicit than it could be; core is littered with 0/1 where it should be FALSE/TRUE, and strings where they should be integers.

Proposed resolution

Adopt a policy of always using the strongly typed comparison operators, and use them.
It might even expose a bizarre edge-case bug or two.

Create a child issue for each module. Take care of each conditions, only real strict comparison should be converted.
Ex:

// No needs changes because we potentially compare two differents types.
$nid = 1;
if ( $node->id() == $nid) {

}

// Needs changes, we are sure to have string in both.
if ( $node->id() === $node->original->id()) {

}

↧

[ignore] Patch Testing Only

August 27, 2020, 9:40 pm

≫ Next: Allow themes to specify default region

≪ Previous: Replace Loose comparison by Strict comparison in contact module

IGNORE - PATCH TESTING ONLY - IGNORE

↧

Allow themes to specify default region

December 14, 2015, 1:32 pm

≫ Next: [backport] "This block is broken or missing..." should only be shown to users that have access to do something about it

≪ Previous: [ignore] Patch Testing Only

Currently, system_default_region() simply returns the first region in the list of regions. This isn't great, because the first displayed region is usually something like 'header', which in general is not a good default.

It would be better if themes could define the default region somehow, and fall back to the old behavior if necessary. We could also apply some simple heuristics, e.g. looking for a content region, if a default isn't explicitly specified.

↧

[backport] "This block is broken or missing..." should only be shown to users that have access to do something about it

October 23, 2017, 7:50 am

≫ Next: Menu link migration tries to migrate shortcut links, and it ends in a MigrateException

≪ Previous: Allow themes to specify default region

Problem/Motivation

When a block gets broken, this message is shown to all users, even anonymous:

This block is broken or missing. You may be missing content or you might need to enable the original module.

Steps to reproduce

Proposed resolution

This message should only be shown to users who have access to edit the block. However, because the block is broken we no longer know the details of the block, so it will be tricky to determine who gets to see the message. At the very least we can hide this from anonymous users.