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

Explore replacing obsolete Joyride asset with latest version from zurb Foundation

$
0
0

Problem/Motivation

The Joyride JavaScript library created by zurb (https://github.com/zurb/joyride) has been incorporated into the "zurb Foundation" project (https://github.com/zurb/foundation), and as a result is no longer maintained as a separate entity. This means that the current jquery-joyride asset library used by Drupal uses an old version (~18 months as of January 2015) that is no longer maintained.

Proposed resolution

Determine the impact of incorporating Joyride from the zurb Foundation library into Drupal. This would probably involve using only a few files from the zurb Foundation project, as the project in its entirety is quite large and outside the scope of the Tour module. If it seems beneficial, incorporate the Joyride plugin and other necessary parts of zurb Foundation into Drupal's asset libraries to upgrade the current jquery-joyride asset.

Remaining tasks

  • Clean up CSS styling
  • Clean up JavaScript code

User interface changes

  • Adds "Previous" button to Tour tips

API changes

TBD


Links styled as buttons not placed inside Dialog's button pane — prevents "cancel" link/button from showing up

$
0
0

In Drupal.behaviors.dialog.prepareDialogButtons(), Form actions that are submit buttons are visually hidden from the modal content and cloned into a separate button pane. The selector to find these buttons is .form-actions input[type=submit], which misses form elements of type link that have been styled to visually appear as (secondary) submit buttons. As a result, modals do not display these link-buttons inline with the rest of the form actions, which is bad UX.

For an example of an extremely commons link-as-button use case, see: \Drupal\Core\Form\ConfirmFormHelper::buildCancelLink().

The provided patch adds support for link-buttons to Drupal.behaviors.dialog.prepareDialogButtons(). I've also attached screenshots which show what modals look like before/after the patch.

Drupal dialogs overflow in small resolutions when vertical toolbar is open

$
0
0

In specific dimensions when editing/adding content modal dialogs seem to break (and it's not possible to close them).
This happens when vertical toolbar is open, width is less than 48em and content is still next to the toolbar, not behind it.

Show/hide group names button in CKEditor toolbar config UI is not keyboard operable

$
0
0

Problem/Motivation

The CKEditor toolbar configuration UI (e.g. at admin/config/content/formats/manage/full_html) has a "Show group names" link. Pressing it expands the active toolbar UI to show group names, and allow button groups to be added.

This show/hide link is not operable using the keyboard. It can't be focused as it is a link without a name, id, or href attribute (i.e. it's not the start or end of a hyperlink). While it has an ARIA role of button, and a click behaviour, it does not have a tabindex (not focusable) and does not have a keyboard handler (due to not having a href attribute).

Consequently users cannot add a new button group (or change button group names) using the keyboard.

Button group order CAN be changed using the keyboard.

Similar buttons elsewhere (e.g. "Show row weights" wherever draggable tables are used) are keyboard-operable. They use a button element, with a "link" class for styling.

Proposed resolution

Change the <a role="button"> element to a <button class="link">. This is the same as the Show/hide row weights button from draggable tables.

Remaining tasks

  • Write a patch.
  • Test with screen readers to ensure this doesn't break/change the experience. - DONE - this problem affects screenreader users too.

User interface changes

  • Markup change from link to button element, to achieve expected behaviour for keyboard users. This is in line with the markup used for similar show/hide buttons elsewhere in the admin UI.
  • No visual change to design.

API changes

None.

Data model changes

None.

Remove unneeded role="button" attribute from <button> elements

$
0
0

I created this issue as follow-up of #2467827: [META] W3C validation for Drupal Core.

Drupal core added a lot of WAI-ARIA roles to Drupal core (which is a good thing), but in the process lots of unneeded duplicates are added as well.
A WAI-ARIA role is needed when the markup itself isn't clear. But markup like <nav role="navigation"> and <button role="button"> is superfluous since the HTML elements themselves already explain their role. Having these (duplicate) attributes makes W3C validation fail and we don't want that.

Limiting options for exposed Language filters causes errors and doesn't work for special languages

$
0
0

Problem/Motivation

With a View, if you limit the options of an exposed Language filter, two things happen:

  1. Several errors will be generated:
    1. Notice: Undefined property: Drupal\Core\StringTranslation\TranslatableMarkup::$option in Drupal\views\Plugin\views\filter\InOperator->reduceValueOptions() (line 277 of core/modules/views/src/Plugin/views/filter/InOperator.php)
    2. Warning: array_keys() expects parameter 1 to be array, null given in Drupal\views\Plugin\views\filter\InOperator->reduceValueOptions() (line 277 of core/modules/views/src/Plugin/views/filter/InOperator.php)
    3. Warning: array_shift() expects parameter 1 to be array, null given in Drupal\views\Plugin\views\filter\InOperator->reduceValueOptions() (line 278 of core/modules/views/src/Plugin/views/filter/InOperator.php)
  2. Special languages (site language default, site language interface, and site language content) aren't listed, even if they're selected as allowed

The cause is due to InOperator->reduceValueOptions() assuming objects it is given have an "option" property. In the case of the Language selector, some of the options arrive as TranslatableMarkup objects (site language default, site language interface, and site language content), which do not have an option property.

The comments in that method don't actually describe what kind of objects are expected to be given to that method:

    // Because options may be an array of strings, or an array of mixed arrays
    // and strings (optgroups) or an array of objects, we have to
    // step through and handle each one individually.

But since the code is verbatim from Drupal 7 Views, it doesn't have any "awareness" of the TranslatableMarkup class, which is functionally a string but of course an regular PHP object.

Proposed resolution

Over in the LanguageFilter class we can update the getValueOptions method to cast the language values to string. When they arrive to the InOperator class there won't be any TranslatableMarkup objects and the logic will work as expected.

Block View dated content never updates (to remove old events)

$
0
0

Block view of content with a date field with filter Date > now never updates block for anon users. Thought it was an issue with site so went back to basics > fresh D813 site > added date field to article content > created 3 dated nodes todays date (mo
20:45, 21:00, 21:15
Performance > no cache, View > advanced > cache none.
I show the time field as time ago to show it never updates
The result can be seen at
http://demo3.leafclub.org
I have used this time of Block many times in D7 with no issue and now my first 2 D8 sites seem to have the same problem
Any guidance appreciated ar maybe a known bug?

Add filter group for a View fails

$
0
0

I had this problem with v8.0.6 as well. Installed 8.1.0 for a test and I'm still having problems adding a new filter group to a View.
Steps to reproduce the bug:
1- Log as admin;
2- Go to Structure->Views;
3- Choose any view to edit;
4- In the filter cryteria area, click 'add/ or rearrange' button;
5- Click the link to create a new filter group;
6- For less than a second the new group appears, but the dialogue closes abruptly;

This causes a JS error in my console:
Uncaught Error: cannot call methods on dialog prior to initialization; attempted to call method 'option'

It seems that the resetSize function (core/misc/dialog/dialog.position.js) somehow conflicts with the create new filter group functionality.
I opened the JS file and commented the following line:
101 $(document).on('drupalViewportOffsetChange', eventData, autoResize);
After this the error stopped and the filter group was added normally. But I have no clue about the side-effects that this comment could cause. Besides I'm wondering whether there is a "less aggressive" sollution.


Render multiple value fields in node template

$
0
0

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?

See also:

Expand the node grants system to a generic entity grants system

$
0
0

Before:

db_select('node')->addTag('node_access')->execute();
$access = node_access('view', $node, $account);

After:

db_select('node')->addTag('entity_access')->addMetaData('entity', 'node')->execute();
$access = entity_access('node', $node, 'view', $account); //Parameter order subject to bikeshed

function entity_access($entity_type, $entity, $op, stdClass $account) {
  $info = entity_get_info($entity_type);
  list($id, $vid, $bundle) = entity_extract_ids($entity_type, $entity);

  // A bundle-specific callback takes precedence over the generic one for the
  // entity type.
  if (isset($info['bundles'][$bundle]['access callback'])) {
    $access_callback = $info['bundles'][$bundle]['access callback'];
  }
  elseif (isset($info['access callback'])) {
    $access_callback = $info['access callback'];
  }
  else {
    $access_callback = NULL;
  }

  if (isset($access_callback) && funciton_exists($access_callback)) {
    return $access_callback($entity, $op, $account);
  }

  // If there is no access callback, default to allowing access.
  return TRUE;
}

We should take advantage of an 'access callback' in the entity info for each entity.

Related issues

#1810320: Remove EntityTranslationControllerInterface::getAccess() once have entity access is postponed on this issue.

Clean up locale CSS inline with our CSS standards

$
0
0

Problem/Motivation

See: #1995272: [Meta] Refactor module CSS files inline with our CSS standards

Proposed resolution

The page in question can be seen on admin/reports/translations after language modules are enabled.
Review the CSS against our standards, see:
http://drupal.org/node/1887918#best-practices
https://www.drupal.org/node/2408617
#1190252: [573] Use csslint as a weapon to beat the crappy CSS out of Drupal core

Remaining tasks

Review current CSS
Write a patch to fix the suggestions
Run CSSlint against the new CSS

User interface changes

None

API changes

None

Add support for #required on #type => details

Improve statistics performance by adding a swappable backend

$
0
0

Problem/Motivation

MySQL doesn't perform well enough for this kind of thing

Proposed resolution

Like drupal's core caching, locking and other systems the plan is to allow contrib to swap out MySQL for other systems such as mongodb or couchdb which will before a little better, heck, you could even have a contrib module to write node view counts to twitter.

Remaining tasks

All the things

User interface changes

None

API changes

The plan is to make it a service that can be overridden.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask
Issue priorityNormal
Unfrozen changesUnfrozen because it helps with migration for node counters.
Prioritized changesThe main goal of this issue is performance. Previously Statistics has had a bad name because of the number of database reads and writes. This patch allows statistics to move to Mongo, Redis, Couch or another fast data store. This patch also provides a clean way to access the storage which can be used by migration.
DisruptionNone

PHP Fatal error: Unsupported operand types in views FieldPluginBase.php on line 1168

$
0
0

Problem/Motivation

We have a view of nodes in a customer project that gives PHP fatal errors if we view it in Finnish, it works fine in English.

When using XDEBUG to haver a looking at the line in question, I notice that the only variables available in $options are label, id and exclude (which is ""). I added a !empty check (dumb patch attached) and now I don't get a white screen. YMMV.

2016/02/15 15:17:35 [error] 1090#1090: *11450 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Unsupported operand types in /vagrant/drupal/web/core/modules/views/src/Plugin/views/field/FieldPluginBase.php on line 1168
PHP message: PHP Stack trace:
PHP message: PHP   1. {main}() /vagrant/drupal/web/index.php:0
PHP message: PHP   2. Drupal\Core\DrupalKernel->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/index.php:19
PHP message: PHP   3. Stack\StackedHttpKernel->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/Core/DrupalKernel.php:637
PHP message: PHP   4. Drupal\Core\StackMiddleware\NegotiationMiddleware->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php:23
PHP message: PHP   5. Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php:55
PHP message: PHP   6. Drupal\page_cache\StackMiddleware\PageCache->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:51
PHP message: PHP   7. Drupal\page_cache\StackMiddleware\PageCache->pass($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:82
PHP message: PHP   8. Drupal\Core\StackMiddleware\KernelPreHandle->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:103
PHP message: PHP   9. Drupal\Core\StackMiddleware\Session->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/C

Allow double underscores to pass through drupal_clean_css_identifier as per new CSS standards

$
0
0

Problem/Motivation

Drupal’s new CSS coding standards recommend a naming convention for classes which requires the use of double-underscores as separators in certain cases. However, Drupal currently processes some classes internally using drupal_clean_css_identifier(), which replaces all underscores with dashes.

Proposed resolution

Allow double underscores to pass through drupal_clean_css_identifier untouched, if the allow_css_double_underscores variable is enabled. Because many modules rely on the current behavior of this function in order to generate standard dash-separated class names from php strings such as field_name (and this does not need to change), we should for the time being retain the existing behaviour for single underscores. #1109854: Overly aggressive transliteration in drupal_clean_css_identifier removes underscores from classes exists to discuss altering the treatment of single underscores.

Remaining tasks

None.

User interface changes

None.

API changes

None.

#1995272: [Meta] Refactor module CSS files inline with our CSS standards
#1109854: Overly aggressive transliteration in drupal_clean_css_identifier removes underscores from classes


Convert web tests to browser tests for forum module

statistics.php should validate nid is within range

$
0
0

Problem/Motivation

Original report by blasthaus to security.drupal.org - security team decided this is not a vulnerability and can be fixed publicly.

This module has a Denial of Service (DOS) vulnerability.

You can see this vulnerability by:
1. Enabling the module or have the module disabled but not yet uninstalled and have set both "Count content views" and "Use Ajax to increment the counter" module settings.
2. As someone with no permission, send a post request to the path /modules/statistics/statistics.php with a POST param of 'nid' set to a numeric value out of range i.e. > int(11).

This causes a PDOException and could be used as an attack vector if repeatedly called to try and take down a site.

Furthermore, per the minimal Drupal bootstrap in this file, no error would ever be sent to watchdog.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Raw value tokens not replaced if used in css class

$
0
0

If I want to create a class for a field or row or etc. using replacement patterns raw values it won't work. It will just replace if I don't use the raw value.

views-raw-type-missing.png

Example:
- if I enter state-[field_state] it works fine (returning state-In work which anyway isn't css compliant)
- if I enter state-[field_state-value] it just returns state--field_state-value when it should return state-1(or whatever the raw value is)

Shouldn't it work with raw values also? If I use them in "Rewrite results" the raw values are displayed correctly.

A little backtracking on this bug brought me to function tokenize_value($value, $row_index = NULL) in views_handler_field.inc.php. I think this is the function that should replace the token with it's proper value but it doesn't do that. But from there on I'm lost :).

Build Spinner (ajax, replaces “throbber”)

Implement the dropdown menu component styling into the autocomplete widget

$
0
0

Problem/Motivation

The Seven style guide defines a reasonable component for a dropdown menu that can be reused in multiple places:

Proposed resolution

Implement the dropdown menu as a separate reusable component and then add the classes to the autocomplete widget

Remaining tasks

User interface changes

A nicer, more consistent looking dropdown popup for autocomplete

API changes

A new reusable CSS component

Viewing all 293317 articles
Browse latest View live


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