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

tel: link is improperly formatted

$
0
0

Enter a phone number in proper format +49 (89) 1234567 and you get

<a href="tel:%2B49%2889%291234567">+49 (89) 1234567</a>

No mobile phone or desktop application understand this. Everything that is not a number need to be removed as I know. I'm myself not sure what need to be done with #2004142: Vanity numbers may need conversion to numbers


Module Theme Cannot Set Group

$
0
0

Module's Library cannot override Theme's CSS by added Group / Weight (i.e, append the CSS include at the last)
I would like to make my custom make module always override Theme's CSS such that i can have a full control without adding "important"

Page not found is displayed upon clicking Cancel on the Delete Confirmation page.

$
0
0

Page not found is displayed after clicking on the Cancel button in the following scenario.

Steps To Recreate:
1) Navigate to Structure>Media Types(or any other option under Structure)
2) Click on 'Add Media type'
3) Now Edit the Media type
4) Click on Delete
5) Click on Cancel button
6) Observe

Expected: User should be navigated back to the added media type
Actual: User is displayed with the 'Page not found' error(refer screenshot)

Entity queries querying the latest revision very slow with lots of revisions

$
0
0

After upgrading to 8.4 we noticed a performance decrease on one of our sites. The page that is taking minutes to load is a multilanguage page with several field collections and revisions enabled.

Some debugging lead me to the change in issue 2864995.

This change introduces a latestRevision() method which is used by QuickEdit (this explains why it is only when logged in). On a field collection that has about 4000 revisions, this query takes seconds to run.

If I understand correctly the change introduces a self-join to the base revision table. Because of this, for each revision in the table, a set of revisions + next revisions is added to the result. From this result only the row that has no next revision (is null) is used (in my case 7000000 rows are searched for the one that has no next revisions).

base_table.revision_idbase_table_2.revision_id
......
335916335986
335916336066
335986336066
336066NULL

Maybe we can think of a more efficient way of querying the latest revision?

Reduce memory consumption of the functions using taxonomy loadTree (includes the taxonomy overview and forums)

$
0
0

Problem/Motivation

When a taxonomy vocabulary contains too much terms, it is absolutely impossible to reach some pages like taxonomy overview, even if their content is paginated, because of an huge memory usage. This is caused by the taxonomy_get_tree function for huge taxonomies, but for medium sized taxonomies, this is also caused by the fact that we never clean unused variables.

For information, with a 72000 terms taxonomy (what is not so many for big websites) :

$start = memory_get_usage(TRUE);
$tree = \Drupal::entityManager()->getStorage('taxonomy_term')->loadTree($vid); // 72000 terms
$used_memory = memory_get_usage(TRUE) - $start;
echo $used_memory; // ~ 242 MB

Proposed resolution

Just unset loadTree result when it is not needed anymore. This will not save the life of huge websites but this will definetely help medium ones to stay usables.

Remaining tasks

Post the patch

User interface changes

None

API changes

None

Beta phase evaluation

-->

Reference: https://www.drupal.org/core/beta-changes
Issue categoryBug because it can cause fatal errors on very common features
Issue priorityMajor because that's a bug
Prioritized changesThe main goal of this issue is performance. (By clearing that unused variables we can free up a lot of memory)
DisruptionNot disruptive for core, contributed and custom modules because the variables are cleared while neither the core or a hook uses them.

Inline labels in classy theme do not clear floats

$
0
0

Problem/Motivation

When choosing inline labels in "manage display," the classy theme (and template) attaches a "field--inline-label" class to the div that contains the inline field and label. Then, the inline label contains a class ".field--label-inline .field__label" that floats the label left.

However the enveloping div should include a "clearfix." Because clearfix is missing, any subsequent non-text fields will float up onto one line.

This bug can often be disguised if a field containing an inline label is a text field, since text fields automatically contain a clearfix, or when a field using an inline label is followed by a text field, since that clearfix will clear the float from the prior inline label.

NOTE: Since Bartik uses classy as a base theme, the problem occurs there as well.

Proposed resolution

Add a clearfix class to the div enclosing the field label and field contents in the template, OR

Create a ".field--label-inline" class for the div only, that will clear the label's float in "core\themes\classy\css\components\field.css"

Remaining tasks

User interface changes

API changes

Data model changes

Update dropbuttons in tables because of various table cell alignments

$
0
0

Problem/Motivation

Dropbuttons in tables are not positioned correctly because of various table cell alignments.
For example: /admin/structure/display-modes/view

problem

Proposed resolution

We would probably something more like this:

problem

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Allow ckeditor_stylesheets to refer to a Drupal root URL

$
0
0

After adding support for external stylesheets the next step is to add support for Drupal root paths, in the same way that Library definitions can have a Drupal root url for CSS/JS assets.

Stylesheets that aren't external and use a '/' as the first character can be safely assumed to be Drupal root relative (this what LibraryDiscoveryParser does).

So the supported set of stylesheets paths would look like this:

ckeditor_stylesheets
  - //www.external.com/stylesheet.css
  - /libraries/your-library/stylesheet.css
  - css/stylesheet.css

The use case for this is to include CSS assets from outside the theme directory (i.e. the libraries directory).


Call to a member function getConfigDependencyKey() on null in core/modules/user/src/Plugin/views/filter/Roles.php

$
0
0

To replicate,

* create users view
* add roles filter (exposed) with "Select all" selected in Options field.
* Export view to module/profile and reinstall website.

The following error would occur
Error: Call to a member function getConfigDependencyKey() on null in Drupal\user\Plugin\views\filter\Roles->calculateDependencies() (line 93 of /docroot/core/modules/user/src/Plugin/views/filter/Roles.php).

While debugging the role_id with the value all is used in Drupal\user\Plugin\views\filter\Roles::calculateDependencies() in the following code

    foreach ((array) $this->value as $role_id) {
      $role = $this->roleStorage->load($role_id);
      $dependencies[$role->getConfigDependencyKey()][] = $role->getConfigDependencyName();
    }

Cannot save views changes

$
0
0

Since the last 2 core updates I have not been able to make any changes to a view. When clicking the "apply" button after making a change in the "edit" page dialog pop-up, nothing happens and no error is registered in the error log.

ignoring Arabic diacritics

$
0
0

when removing diacritics in function search_simplify(), it not considering remove Arabic diacritics.

How to test:
1- add this text to any article:
"السُّلَّامُ عَلَيْكُمْ وَرَحْمَةُ اللهِ وَبَرَكَاتُهُ"

2- search for "السلام"

learning form this article, I develop an ugly patch to fix it. It may be better to move it to PhpTransliteration.php but I am not sure.

Datetime::getInfo() caches user's timezone causing unpredictable timestamps.

$
0
0

I couldn’t find any similar issues on Drupal.org so I opened this one, if anyone knows of a similar issue please feel free to link and close this as duplicate.

Problem/Motivation

This was found while diagnosing an issue on the Scheduler module. However it also affects the “Authored On” field.
https://www.drupal.org/project/scheduler/issues/3085947

The node edit form's "Authored On" field uses the timezone of whatever user was on that form during the last cache clear. This can end up with a Chicago User saving a node that has an “Authored On” value in UTC.

This only seems to affect new nodes, editing existing nodes are not affected.

Steps to Reproduce
Requirements: Have two users, one with a UTC timezone and one with a Chicago Timezone

Step One: Create content as an UTC User

  1. Log in as the UTC user
  2. Clear the Drupal cache
  3. Create a new Basic Page
  4. Note the Authoring information (e.g 4:00:00 PM)
  5. Save and publish the node.

Step Two: Create content as a Chicago User

  1. Log in as the Chicago user
  2. Do not clear the cache
  3. Create a new Basic Page
  4. Note the Authoring information
  5. Observe that the Authoring information shows approximately the same time at UTC (e.g 4:02 PM)
  6. This should show a time relative to Chicago (e.g 11:00 AM)

For authoring information this is relatively benign however it does impact Scheduling.

Proposed resolution

It looks like this is being caused by code in the Datetime::getInfo() method.

core/lib/Drupal/Core/Datetime/Element/Datetime.php

public function getInfo() {

      // .. node: some code removed for brevity …

     return [
      '#input' => TRUE,
      '#element_validate' => [
        [$class, 'validateDatetime'],
      ],
      '#process' => [
        [$class, 'processDatetime'],
        [$class, 'processAjaxForm'],
        [$class, 'processGroup'],
      ],
      '#pre_render' => [
        [$class, 'preRenderGroup'],
      ],
      '#theme' => 'datetime_form',
      '#theme_wrappers' => ['datetime_wrapper'],
      '#date_date_format' => $date_format,
      '#date_date_element' => 'date',
      '#date_date_callbacks' => [],
      '#date_time_format' => $time_format,
      '#date_time_element' => 'time',
      '#date_time_callbacks' => [],
      '#date_year_range' => '1900:2050',
      '#date_increment' => 1,
      // Timezone is set here and gets cached. 
      '#date_timezone' => drupal_get_user_timezone(),
    ];
} 

The getInfo() method only gets called on cache clear, therefore the element that gets loaded gets the timezone of whichever user loads the page after the cache is cleared.

It looks like this was introduced as part of: https://www.drupal.org/project/drupal/issues/2799987

Simplify Dropbutton markup in line with our CSS standards

$
0
0

Problem/Motivation

The current markup for Dropbutton looks like this:

<div class="dropbutton-wrapper dropbutton-processed dropbutton-multiple">
<div class="dropbutton-widget">
<ul class="dropbutton">
<li class="edit dropbutton-action"><a href="/admin/structure/views/view/content">Edit</a></li>
<li class="dropbutton-toggle"><button type="button"><span class="dropbutton-arrow"><span class="visually-hidden">List additional actions</span></span></button></li>
<li class="clone dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/clone">Clone</a></li>
<li class="disable dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/disable?token=hQ2egsGF5LtsScdw2oQFeoWNKrUi1HHP9W1WZhjehOk" class="use-ajax ajax-processed">Disable</a></li>
<li class="delete dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/delete">Delete</a></li>
</ul>
</div>
</div>

There's a lot we could do we simplify and improve the markup so it's inline with our CSS coding standards

Proposed resolution

<div class="dropbutton dropbutton--modifier"> <!-- whole component is dropbutton. -->
  <a class="button dropbutton__action">Action One</a>
  <button type="button" class="button dropbutton__trigger">
    <span class="visually-hidden">List additional actions</span>
  </button>
  <ul class="dropbutton__menu" role="menu">
    <li><a class="dropbutton__action">Action Two</a></li>
    <li><a class="dropbutton__action">Action Three</a></li>
  </ul>
</div>

Remaining tasks

Decide on a battle plan of improvements
Write a patch
Test a lot

User interface changes

None

API changes

Mark up changes

Accessible dropdown for Umami's language-switcher and mobile main-menu

$
0
0

Problem/Motivation

Umami's new language switcher has various issues:
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header, or when viewing the website in RTL language.

Umami's mobile main-menu has accessibility issues (#2940023)

Proposed resolution

Creating an accessible dropdown component can solve the current issues with both Umami's language switcher and Umami's mobile main-menu.

Remaining tasks

Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"


Umami main menu missing in IE11 with current latest patch.

Remove Classy templates that have identical versions in Stable

$
0
0

Problem/Motivation

As stated in the parent issue #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

This process included documenting template usage in this spreadsheet:Core Theme's use of Classy. This documenting made it apparent that there are 24 templates in Classy that are identical to the same-named templates in Stable. This makes it possible to simply remove these files so they are no longer a Classy dependency for any core theme. (as opposed to copying individual versions of every Classy-inherted template to every core theme, a step that will be necessary for most templates.

Running diff -srq classy/ stable/ | grep identical shows that these templates are identical:

Files classy/templates/content-edit/file-upload-help.html.twig and stable/templates/content-edit/file-upload-help.html.twig are identical
Files classy/templates/content-edit/file-widget-multiple.html.twig and stable/templates/content-edit/file-widget-multiple.html.twig are identical
Files classy/templates/field/image-style.html.twig and stable/templates/field/image-style.html.twig are identical
Files classy/templates/form/checkboxes.html.twig and stable/templates/form/checkboxes.html.twig are identical
Files classy/templates/form/confirm-form.html.twig and stable/templates/form/confirm-form.html.twig are identical
Files classy/templates/form/container.html.twig and stable/templates/form/container.html.twig are identical
Files classy/templates/form/dropbutton-wrapper.html.twig and stable/templates/form/dropbutton-wrapper.html.twig are identical
Files classy/templates/form/form-element-label.html.twig and stable/templates/form/form-element-label.html.twig are identical
Files classy/templates/form/form.html.twig and stable/templates/form/form.html.twig are identical
Files classy/templates/form/input.html.twig and stable/templates/form/input.html.twig are identical
Files classy/templates/navigation/links.html.twig and stable/templates/navigation/links.html.twig are identical
Files classy/templates/navigation/menu-local-action.html.twig and stable/templates/navigation/menu-local-action.html.twig are identical
Files classy/templates/navigation/pager.html.twig and stable/templates/navigation/pager.html.twig are identical
Files classy/templates/navigation/vertical-tabs.html.twig and stable/templates/navigation/vertical-tabs.html.twig are identical
Files classy/templates/views/views-view-grid.html.twig and stable/templates/views/views-view-grid.html.twig are identical
Files classy/templates/views/views-view-list.html.twig and stable/templates/views/views-view-list.html.twig are identical
Files classy/templates/views/views-view-mapping-test.html.twig and stable/templates/views/views-view-mapping-test.html.twig are identical
Files classy/templates/views/views-view-opml.html.twig and stable/templates/views/views-view-opml.html.twig are identical
Files classy/templates/views/views-view-row-opml.html.twig and stable/templates/views/views-view-row-opml.html.twig are identical
Files classy/templates/views/views-view-rss.html.twig and stable/templates/views/views-view-rss.html.twig are identical
Files classy/templates/views/views-view-unformatted.html.twig and stable/templates/views/views-view-unformatted.html.twig are identical

There are 3 additional templates that should be added to this list as they should be identical.
classy/templates/field/image-formatter.html.twig: the only difference a line in Classy's DocBlock that should have been removed in #2350837: Convert most usages of EntityInterface::getSystemPath() to use routes.
classy/templates/form/select.html.twig: the only difference are annotation changes that should have been applied to Stable in #2546248: Use consistent style to mention HTML tags in code comments, but were only applied to Classy.
classy/templates/form/field-multiple-value-form.html.twig: the version in stable had a line of whitespace following the DocBlock that was not present in Classy's

Proposed resolution

Address the differences in the 3 almost-identical templates listed in Problem/Motivation
Remove the templates from Classy
Add a test that confirms these templates were truly identical.

Remaining tasks

Implement, review.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a


Allow adding classes to JavaScript messages default wrapper

$
0
0

Problem/Motivation

The Drupal.Message.defaultWrapper() removes class="hidden" from the fallback div by using wrapper.removeAttribute('class'); which prevents adding classes needed for styling on the wrapper element.

Proposed resolution

Replace wrapper.removeAttribute('class') with wrapper.classList.remove('hidden').

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Programmatically associate error messages with inputs

$
0
0

Problem/Motivation

I would like the field errors to have the same structure as the description of the field - unique id and his id added to his corrsponding input `aria-describedby` attribut (look screenshot).

Proposed resolution

Add this attribute as it is added to the Webform description label.

Remove PhantomJS based testing

$
0
0

Problem/Motivation

PhantomJS tests are deprecated in Drupal 8. We should remove them and all their dependencies in Drupal 9.

Proposed resolution

Remove all our code and the dependencies from composer. The following classes are removed:

  • Drupal\FunctionalJavascriptTests\JavascriptTestBase
  • Drupal\FunctionalJavascriptTests\LegacyJavascriptTestBase

References to these classes are updated appropriately.

This has the effect of removing the following dependencies:

  • jcalderonzumba/gastonjs
  • jcalderonzumba/mink-phantomjs-driver

Support for the following environment setting:

  • MINK_DRIVER_ARGS_PHANTOMJS

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

The following dev dependencies:

  • jcalderonzumba/gastonjs
  • jcalderonzumba/mink-phantomjs-driver

are removed

GDToolkit::load() wrongly calls GDToolkit::isValid()

$
0
0

GDToolkit::getResource() checks GDToolkit::$resource is a resource; if it's not, it calls GDToolkit::load(), which first calls GDToolkit::isValid(), which checks that either GDToolkit::$preloadInfo or GDToolkit::$resource has been set.

GDToolkit::load() should not call GDToolkit::isValid(). GDToolkit::load() is a protected method called to initialize GDToolkit::$resource; checking if GDToolkit::$resource has been set and return FALSE if it was not doesn't make sense. The method should check if GDToolkit::$preloadInfo has been set, which means that GDToolkit::parseFile() has returned TRUE (i.e., the file whose filename is set with GDToolkit::setSource() contains an image).

GDToolkit::isValid() doesn't return FALSE simply because the Image constructor calls GDToolkit::parseFile() after calling GDToolkit::setSource(); still checking the value of GDToolkit::$resource twice doesn't make sense.

Explore how we can inform contrib/other developers not to use Database/Connection::escapeLike() in Database/Connection::query() and Database/Connection::queryRange() queries

$
0
0

Problem/Motivation

How to best inform contrib/other developers how not to use db_like() in their queries

Proposed resolution

open

Remaining tasks

open

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

maybe

Original report by [username]

@alexpott

Viewing all 298122 articles
Browse latest View live


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