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

Move all external libraries from core modules into core.libraries.yml

$
0
0

Problem

  • Some external libraries are contained in specific core modules, which prevents contrib from using them without having to depend on the respective core module.

Details

  1. Previously, core.libraries.yml did not exist, so e.g., System module registering CKEditor module's library made little to no sense.

  2. By introducing the capability for the Drupal core base system itself to register libraries, the new world order is this:

    1. All external libraries supplied by Drupal core are placed into /core/assets/vendor.
    2. All of those libraries are registered by core.libraries.yml.
    3. Placing an external library into a core module is discouraged and requires a very sound, solid, and sophisticated reasoning.
  3. Here is why:

    1. A contributed or custom module that would like to use the existing bundled library but does not like the usage/implementation of the core module, would (1) either have to needlessly depend on the core module to get the library registered or (2) re-register the library from scratch on its own (which breaks dependencies of other modules, since the library owner/provider would no longer be "core").
    2. Re-registering a core library in a contrib/custom module would be close to impossible to manage with regard to the declared library version. Drupal core might ship with an updated version, but that will not be reflected in the contrib module's declaration unless it is updated accordingly.

    In short, this is required for e.g. Wysiwyg module to use the CKEditor library bundled with core, without having to depend on the ckeditor.module in core. Same for other libraries/modules/use-cases.

Task

  1. Move the picturefill.js library from Picture module into core.
  2. Move the jquery.joyride library from Tour module into core.

Remove deprecated user_authenticate() function

Add an administrative description for a comment field

$
0
0

Updated: Comment #N

Problem/Motivation

Site builders may wish to give a comment-field an administrative description to clarify it's intent to other site-builders/admin - analagous to the admin description for node types.

Proposed resolution

Add a field setting to store/record this value on the field
Display it at admin/structure/comments

Remaining tasks

Patch
Review

User interface changes

Screenshots:

API changes

None

Follow-up from #731724: Convert comment settings into a field to make them work with CMI and non-node entities.

Make \Drupal\views\Plugin\views\HandlerBase unit-testable

$
0
0

I want to unit test my own Views handlers, but Views' base classes depend on the global scope too much. I do not have time to write a unit test for \Drupal\views\Plugin\views\HandlerBase myself, but I am hoping that a green test result and my feedback about my contrib tests passing will be enough to get this issue fixed.

Duplicated lines in style.css of Seven theme

$
0
0

Input fields box-sizing setting is declared at line 797.

This is duplicated in the "Improve form element usability on narrow devices." section at line 855.

Than those fields are listed again at line 874.

Add an SVG version of Druplicon

Bartik: template.php cleanups

$
0
0

from sun's issue here: #849862: Bartik code problems

+++ themes/bartik/template.php 6 Jul 2010 03:48:59 -0000
@@ -0,0 +1,146 @@
+function bartik_process_page(&$variables) {
...
+function bartik_process_maintenance_page(&$variables) {

Both process functions partially contain identical lines, i.e., duplicate code. Those lines should be moved into a dedicated private helper function, e.g., _bartik_process_page(&$variables).

+++ themes/bartik/template.php 6 Jul 2010 03:48:59 -0000
@@ -0,0 +1,146 @@
+  // Always print the site name and slogan, but if they are toggled off, we'll
+  // just hide them visually.
+  $variables['hide_site_name']   = theme_get_setting('toggle_name') ? FALSE : TRUE;
+  $variables['hide_site_slogan'] = theme_get_setting('toggle_slogan') ? FALSE : TRUE;

These variables (and others) should be negated, i.e., into "show_xyz" or "toggle_xyz".
I've personally implemented and used similar "hide_xyz" template variables in custom themes some time ago, only to find out that a constant double negation of "hide foo" => FALSE ===> yes, TRUE is a super major source of confusion.
If you look closely at these lines, then you hopefully realize this problem already. Removing the double negation would lead to simplicity in

$variables['toggle_name'] = (bool) theme_get_setting('toggle_name');

Additionally, it slightly hurts my brain to see new flag names being introduced here, which require everyone to map "toggle_name" to "hide_site_name" and vice-versa. Effectively, not only a different name, but also negated meaning.
Final note for D8: We should auto-provision theme settings into a dedicated $variables['settings'] key for all templates by default, so as to simplify and remove all of this code from Bartik.

+++ themes/bartik/template.php 6 Jul 2010 03:48:59 -0000
@@ -0,0 +1,146 @@
+  // System menu blocks should get the same class as menu module blocks.
+  if (in_array($variables['block']->delta, array_keys(menu_list_system_menus()))) {

Faster:

if (($menus = menu_list_system_menus()) && isset($menus[$block->delta])) {

Edit icon for node in view's preview doesn't work

$
0
0

Updated: Comment #N

Problem/Motivation

when editing a view with 'edit' on (the pencil icon in right corner of toolbar), getting edit icons for nodes in views preview. However they does nothing when you click them

Proposed resolution

Option 1: Remove them from preview, as it is a preview of a view
Option 2: Make the link work as it does in all other places.

Remaining tasks

User interface changes

Yes, we may not see the icon, if we go with option 1.

API changes

N/A


Find a new OO home for drupal_get_hash_salt()

$
0
0

Updated: Comment #N

Problem/Motivation

We still have (and would like to convert) usages of drupal_get_hash_salt() in our OO code. This is not ideal, as tests have to do the if(!function_exists('ffdfdf')) hack etc.. We cannot just use the setting directly as we need to keep the logic that throws an exception if it is empty.

Proposed resolution

Find a new home for this. We could just check for this when we get the hash_salt setting. I think it makes more sense to just have this living somewhere though.

Remaining tasks

Find a place, patch. Convert remaining usages.

User interface changes

None

API changes

Hopefully no more drupal_get_hash_salt(), just the new thing.

Style select elements

Inject EntityManager dependency into UuidResolver

$
0
0

Updated: Comment #N

Problem/Motivation

The Drupal\serialization\EntityResolver\UuidResolver class uses the entity_load_by_uuid() method directly. This is not what we ideally want to do, nor is it good for testing.

Proposed resolution

Objects for the serializer are services anyway, so let's utilise that! Inject the EntityManager into the UuidResolver class, and add a loadEntityByUuid() method to the entity manager.

Remaining tasks

Patch, tests (now it will be better to test), review.

User interface changes

None

API changes

None

N/A

Two patches attached:

1. Adding a new loadByUuid to EntityStorageControllerInterface/EntityStorageControllerBase class
2. (after speaking breifly to berdir) Adding a loadEntityByUuid method to the Entity manager, this can then wrap the other logic needed for this. Otherwise, people would have to implement this same thing every time - not cool.

Primary button's border is not visible on focus

$
0
0

Seven's primary button focus styling sets a border colour that is really similar to the background gradient. It looks like there is no border at all.

The offending CSS is on line 83 of buttons.theme.css:

.button--primary:focus {
  border-color: #0087db;
}

[meta] Replace calls to check_plain() with Drupal\Component\Utility\String::checkPlain()

$
0
0

Instructions

This is part of #2093143: [meta] Remove calls to @deprecated and "backwards compatibility" procedural functions from core

Writing patches

We want to replace calls to check_plain(), and any references in the documentation, to Drupal\Component\Utility\String::checkPlain()

To do this, we don't want to have to write the whole "Drupal\Component\Utility\String::checkPlain()" every time so we want to use namespace aliases so that we can simply write String::checkPlain() - see the PHP documentation http://www.php.net/manual/en/language.namespaces.importing.php

We need to be sure that each file that needs to use String::checkPlain() has the statement use Drupal\Component\Utility\String; at the top of it.

Automatic patching

Instead of doing taking the manual approach I decided to create a tool https://gist.github.com/grom358/9106837 . It could be improved, possibly using the Grammar Parser project? It works by going through the tokens from token_get_all looking for calls to the function and if so inserting a use declaration and changing the function call.

~/dev/drupal $ ~/function_replacer.php 'Drupal\Component\Utility\String''StringUtil''check_plain''checkPlain'

Converting existing patches

IMPORTANT: Most of the work for this issue has already been done in #2089465: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/A-L and #2089471: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/M-Z (except system/simpletest) but because the patches touched basically all of core they needed to keep being re-written. For that reason we are splitting those issues into per-module issues but the code changes in the patches from the large issues should be re-cycled as much as possible.

Issues

Needs work:

- #2089351: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/includes

Postponed on "Disruptive Day":

- #2089471: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/M-Z (except system/simpletest)
- #2196817: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in comment module
- #2196835: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in entity_reference module
- #2196839: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in field/field_ui module
- #2196841: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in file module
- #2196893: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in filter module

Done!

- #2187829: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/views
- #2093167: Deprecate check_plain(), call \Drupal\Component\Utility\String::checkPlain() directly instead
- #2089461: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/lib
- #2089465: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/A-LAssigned to: thedavidmeister
- #2196797: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in action module
- #2196801: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in aggregator module
- #2196805: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in ban module
- #2196807: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in block module
- #2196811: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in book module
- #2196815: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in color module
- #2196895: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in forum module
- #2196897: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in image module
- #2196901: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in language module
- #2196907: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in link module
- #2196909: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in node module
- #2196951: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in picture module
- #2196995: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in rest module
- #2196821: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in contact module
- #2196825: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in content_translation module
- #2196831: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in edit module

Regression: Form submit redirects from 404 pages are no longer possible

$
0
0

The commit to issue #2147153: Replace the last instance of $_GET/$_POST; Create a special exception listener / exception controller which allows to use POST requests introduced a regression. Steps to reproduce:

a) Create a form whose submit method is a redirect:

    $form_state['redirect_route'] = array(
      'route_name' => 'some.module.route',
    );

b) Put the form in a block.

c) Display the block on a 404 page, such as example.com/foo.

d) Attempt to submit the form. It will not work -- you'll end up back on the starting URL example.com/foo instead of your intended destination.

This used to work before the commit to #2147153: Replace the last instance of $_GET/$_POST; Create a special exception listener / exception controller which allows to use POST requests, which caused a failure in the patch for #1366020: Overhaul SearchQuery; make search redirects use GET query params for keywords.

I've marked it Major because 1366020 is Major and is blocked on this being fixed. dawehner is working on a solution, and jhodgdon will create a clean test for this problem.

Replace the ajax-progress-throbber div with a class

$
0
0

Problem/Motivation

Currently ajax.js places the following after the element that has triggered a loading action:
<div class="ajax-progress ajax-progress-throbber"><div class="throbber">&nbsp;</div></div>

This is terribly hard to modify or replace with your own loading animation, it's a UI pattern that is very dated and causes many layout issues as it changes the flow of the document.

Proposed resolution

Replace the element inserted with a class that is added to the element that triggers the loading action. The current behaviour can be replicated perfectly using a CSS pseudo element. Using a class instead increases the flexibility of the action in CSS without having to wade through any Drupal specific code. A button could change text or animate. I would also like to add a class to to the body of the page during loading, this would make full screen loading animations easier, a very common UI pattern.


CRUD module generator / scaffold

$
0
0

Many custom modules are all about CRUD - manipulating lists of obiects. Ads, products in a shop, payments and so on.
It would be great to have "module-builder", script taking database schema (creation sql, yml description, connection to DB, whatever) as it's imput, and creating Drupal module with Views integration, basic operations, template files for freshly generated data and all that repetitive stuff. Relation-aware should be the goal, of course.

That way we could create data structure our module will need, quickly get the boring repetitive parts done, and create only really interesting stuff.

Tab-select renders grippie white one white

$
0
0

When tab-selecting the elements in a table, the table drag widget renders the grippie as white on white.

This happens with the Stark, Seven and Bartik themes.

See attached screenshot.

Use the string field type for the node title field

$
0
0

Updated: Comment #N

Problem/Motivation

When the node title was switched to use a widget, the field was switched to use the text field type. That however contains processing options, a format and the computed processed property that we have to instantiate. All that is overhead that we don't need and will actively get in the way when want to generate the schema automatically because it will attempt to generate a value and format column for the node title.

Proposed resolution

Make the text widget and formatters available for the string field type.

Remaining tasks

User interface changes

API changes

Multiple calls to ConfigFactory::get() inside t() is unnecessary

$
0
0

After doing a standard install, enabling locale and making 1 request to the frontpage the next request to the frontpage will make 240 calls to ConfigFactory::get(). With the attached patch this drops to 112 - meaning that there are 229 calls to LocaleTranslation::getStringTranslation(). There is also a massive reduction in calls for logged in users.

[policy, no patch] Use layout- prefixes instead of l- in CSS Coding Standards

$
0
0

In #1912610: Rename layout classes to follow the layout style naming convention we started applying layout classes following SMACSS conventions. As we did, we noticed the l-prefixed classes don't match our values for readability in CSS selectors. There were some comments suggesting layout- as a SMACSS-compliant alternative and it seemed to gather some support. Since the goal of that issue was another one (apply the layout standards to CSS) we found better to open a new one to gather more feedback.

Viewing all 292987 articles
Browse latest View live