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

[meta] Round-up of form buttons, buttons, link buttons, and links

$
0
0

Background

  1. #1845728: Refactor and introduce generic button CSS styles for forms and links revamped and generalized the CSS for all possible buttons:

    .button,
    button

    Note: Seven does not implement styles for .button.

  2. #1238484: [docs update] Ability to mark the form buttons to be of a specific type (so that they can be styled differently) advanced on it and introduced support for specific button "types":

    <?php
    $form
    ['actions']['submit']['#button_type'] = 'primary';
    $form['actions']['delete']['#button_type'] = 'danger';
    ?>


    .button--primary { color: blue; }
    .button--danger  { color: red; }

    Relevant case study: http://www.lukew.com/ff/entry.asp?571

    #button_style is not limited to 'primary' and 'danger'. The value is simply taken over as .button--$value CSS class name. See http://getbootstrap.com/css/#buttons for common button types.

    Note: Bartik does not implement styles for .button--danger.

  3. Based on the last two building blocks, #1719640: Use 'button' element instead of empty links introduced dynamic/on-page buttons for JS interactions which masquerade as links, in order to avoid <a href="#"></a> as well as href="javascript:void(0)":

    <button type="button" class="link">Show summary</button>

    /**
    * Show buttons as links.
    */
    button.link {
      background: transparent;
      border: 0;
      cursor: pointer;
      margin: 0;
      padding: 0;
    }

    Note: Styling is broken in Bartik (faulty font override).

  4. #216064: Entity form "Delete" button triggers server-side + HTML5 form validation; change "Delete" button to a link is about to convert all "Delete" buttons into links, so as to avoid HTML5 front-end form validation and needless back-end form processing code:

    <?php
    $actions
    ['delete'] = array(
     
    '#type'=> 'link',
     
    '#title'=> $this->t('Delete'),
     
    '#attributes'=> array(
       
    'class'=> array('button', 'button--danger'),
      ),
    );
    ?>


    <a class="button button--danger" href=".../delete">Delete</a>

    Note: That patch will not adjust/fix the link button styles in Bartik/Seven.

Goal

  1. Every button has a .button class or is a <button> or [type=submit] or [type=button].

  2. By default, every link in a form actions container has a .button class, so as to appear as a button. A theme is easily able to override this.

  3. Every link/button that (1) will trigger a confirmation for a destructive action or (2) immediately causes a destructive action uses .button--danger. A theme is easily able to override this button type styling (in both places).


Convert theme_admin_block() to Twig

$
0
0

Issue #2151089 by joelpittet, c4rl, IshaDakota, pplantinga, gnuget, longwave, jeanfei, sbudker1: Convert theme_admin_block() to Twig

Task

Convert theme_admin_block() to a Twig template.

Remaining tasks

  • Patch
  • Patch review
  • Manual testing
  • Profiling

Steps to test

Navigate to /admin/config

Move the parameters out of the .services.yml file

$
0
0

Updated: Comment 0

Problem/Motivation

If you first time teach people about routing/local tasks and finally .services.yml files you will get the result that it is harder for people to
understand why they need to specify services: yml file in these files, even the filename already specify it.

Proposed resolution

Allow to specify services on the root level.
Before:

services:
  access_check.permission:
    class: Drupal\user\Access\PermissionAccessCheck
    tags:
      - { name: access_check }
  access_check.user.register:
    class: Drupal\user\Access\RegisterAccessCheck
    tags:
      - { name: access_check }

after
access_check.permission:
  class: Drupal\user\Access\PermissionAccessCheck
  tags:
    - { name: access_check }
access_check.user.register:
  class: Drupal\user\Access\RegisterAccessCheck
  tags:
    - { name: access_check }

Remaining tasks

User interface changes

API changes

Rename 'fieldable' key in entity definitions

$
0
0

The entity definition / entity info key 'fieldable' does not fit any more - all content entities have fields now. So we should rename this + fix the name of FieldableEntityStorageControllerInterface // the base class to match that.

PHPUnit test the entity base classes

$
0
0

Use PHPUnit to test the Entity, ConfigEntityBase, and ContentEntityBase classes. In order to do that, add wrappers to access services and procedural code.

Naive test in table prefixing code causes test exceptions

$
0
0

Problem/Motivation

The Simpletest-specific table prefix handling code in _drupal_bootstrap_database() includes the following test:

<?php
elseif (is_array($value['prefix'])) {
 
$current_prefix = $value['prefix']['default'];
}
?>

Obviously, there's an invalid assumption there--that just because $value is an array it therefore has a value at index "default". If it's wrong, it causes test exceptions.

Note: The problem no longer exists in Drupal 8.

Proposed resolution

Make the logic smarter.

Remaining tasks

Review.

User interface changes

n/a

API changes

n/a

Move code for finding/saving default menu links from menu.inc to menu_link module

$
0
0

Updated: Comment #N

Problem/Motivation

menu.inc still contains menu_link-specific code.

Proposed resolution

Move it to menu_link.module

Remaining tasks

Decide if more of the menu tree functions should move as well.

User interface changes

N/A

API changes

menu_load_links() and menu_delete_links() were renamed to menu_link_load_links_by_menu() and menu_link_delete_links_by_menu()

Original report by @pwolanin

Follow-up from #2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit.

The code in menu.inc already has a check as to whether the menu_link module is enabled. It would be logically better to simply move all the code for finding/saving/resetting default menu links to this module and out of menu.inc.

Make text consistent: "Add new content" -> "Add content"

$
0
0

There's an inconsistency on the front page of newly installed Drupal 8 sites. A link appears twice with different texts: "Add new content" and "Add content" (see graphic). A search through core shows that this inconsistency appears in several other places as well.

I propose making it consistent throughout core. My preference is for "Add content" because it's shorter and the word "new" is unnecessary.

A patch follows.


Add target_uuid to json and xml output of entity reference fields

$
0
0

Currently, HAL outputs UUIDs and URIs for reference fields. However, the "simple" formats (e.g., json and xml), only output a direct representation of an entity. Since for performance, ER fields internally use just a 'target_id' (the local serial id), that's all that's included in the serialized output of those fields.

However, a common use case for serialization is to migrate/deploy an entity from one site to another (e.g., stage -> prod). Outputting UUIDs for ER fields would help that.

Remove calls to deprecated global $user wherever possible (outside bootstrap and authentication)

$
0
0

Remove calls to deprecated global $user in module as part of the meta #2047951: [META] Remove calls to deprecated global $user and $GLOBALS['user']

From #2163203-5: Remove calls to deprecated global $user wherever possible (outside bootstrap and authentication).

Let's expand the scope of this issue to convert all the trivial references outside bootstrap and session handling, and then work on those tougher issues separately.

Before RTBCing a patch for this issue, confirm that no more references to the global remain outside #2061953: Remove calls to deprecated global $user in core/lib/Drupal/Core/Authentication/AuthenticationManager.php , #2062771: #2062771: Remove calls to deprecated global $user in core/includes/session.inc, #2062069: Remove calls to deprecated global $user in core/includes/bootstrap.inc . Edit: Fixing TestBase and its child base classes might also merit a separate issue, but uses in normal test classes themselves should be (edit) either in this patch or in that patch, depending on which makes more sense. But not separately.

Allow contrib modules to provide plugins on behalf of optional modules

$
0
0

Updated: Comment #4

Problem/Motivation

In Drupal 7, it was common for modules like Views to provide plugins on behalf of other modules. Like node views handlers:

if (!function_exists('node_views_api')) {
  function node_views_api() { return views_views_api(); }
}

We need the annotated plugin version of that.

Proposed resolution

Force DefaultPluginManager to check for a module being enabled.

Remaining tasks

None

User interface changes

N/A

API changes

Plugins whose 'provider' is a disabled module will not be available

To do this the following method signatures are changing:

  • DefaultPluginManager::__construct() now has the module handler injected
  • DefaultPluginManager::alterInfo() no longer requires the module handler

N/A

Replace the current_user service with a current_user factory service

$
0
0

Updated: Comment #N

Problem/Motivation

  1. Any service that has 'current_user' as a dependency will call the authentication manager (see definition of current_user service in core.services.yml). So this can get called when dependencies are resolved for services before the AuthenticationSubscriber gets a chance to do its thing.

    So, for example, what currently happens is RouteListener > DynamicRouter > RouteManager > csrfRouteSubscriber > csrfGenerator > Current user. So when the event dispatcher lazy loads the services it needs for KernelEvents::REQUEST, RouteListener is first, so this happens. Then later... the AuthenticationSubscriber runs.

  2. When one needs to change the current_user inside a request, well, they need to first have a ContainerAware object. second even after they set the new current_user to the container, all other objects that had the current_user injected, will have the outdated object (expect the services that have a setCurrentUser call registered in services.yml) This can cause serious security issues.
    And of course we cant keep everything synchronized because not everything is a service.
  3. calling \Drupal::currentUser() in session.inc leads to circular exceptions: see #2062771: #2062771: Remove calls to deprecated global $user in core/includes/session.inc and #2062069: Remove calls to deprecated global $user in core/includes/bootstrap.inc which makes getting rid of $GLOBALS['user'] a very hard thing to do

Proposed resolution

Remove current_user service, add a (get/set)Account method in the authentication service and make \Drupal::currentUser() call that.

Remaining tasks

patch is rtbc, commit it

User interface changes

None

API changes

current_user service is removed. Inject the authentication instead and call getAccount()

Display which vocabulary the taxonomy belongs when editing a term

$
0
0

Problem/Motivation

In large sites with thousands of terms across different vocabularies it is not possible to know which vocabulary the terms belong to when editing it.
I have a situation where the term 'apple' appears in two different vocabularies ending up with one URL for /apple and another for /apple-0.
Then I visit the two term pages and click edit. At this point, there is no information regarding which vocabulary that term belongs to.

Proposed resolution

Display a text field above Name (see example screenshot). i.e. Vocabulary Fruits

Remaining tasks

  • Get the vocabulary name when editing the term
  • Display the information on the form

User interface changes

(new or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text)

Strenghten password hashing mechanism

$
0
0

After discussing this on the security list and in IRC, I am opening this issue report for discussion.

The password hashing function does use salted and iterated hashing
which is far better than not hashing.

However, it does not abide by industry standard stretching practices.

<?php
// We rely on the hash() function being available in PHP 5.2+.
$hash = hash($algo, $salt . $password, TRUE);
do {
  
$hash = hash($algo, $hash . $password, TRUE);
} while (--
$count);
?>

There are a few problems with a function such as this:

First, if there is ever a collision for $hash.$password, that
collision will propegate through to the result. This means that
increasing iteration counts can actually decrease the output space of
the function. This can theoretically lead to password collisions
(where multiple password inputs combinations lead to the same output
hash string).

Second, straight concatenation in the message of the hash function can
be susceptible to certain padding attacks. While the iterations make
the vector more difficult to execute, it's still theoretically
possible.

Suggestion:

Implement the industry standard PBKDF2 derivation function.
http://www.ietf.org/rfc/rfc2898.txt

A PHP implementation looks like this:

https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/Key/D...

<?php
public function derive($algorithm, $password, $salt, $iterations, $length) {
      
$size   = strlen(hash($algorithm, '', true));
      
$len    = ceil($length / $size);
      
$result = '';
       for (
$i = 1; $i <= $len; $i++) {
          
$tmp = hash_hmac($algorithm, $salt . pack('N', $i),
$password, true);
          
$res = $tmp;
           for (
$j = 1; $j < $iterations; $j++) {
              
$tmp  = hash_hmac($algorithm, $tmp, $password, true);
              
$res ^= $tmp;
           }
          
$result .= $res;
       }
       return
substr($result, 0, $length);
   }
?>

(Note, I tweaked it to be pure PHP rather than dependent upon the
CryptLib library).

This implementation is tested against the test
vectors for PBKDF2:
https://github.com/ircmaxell/PHP-CryptLib/blob/master/test/Unit/Key/Deri...

Convert menu tree building to a service.

$
0
0

Updated: Comment #N

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes


Clean up icons in misc

$
0
0

- Move forum-icons.png into forum module
- Consolidate use of watchdog-warning.png and message-16-warning.png and remove one
- Remove all the "powered by drupal" logos if we truly don't care about SEO for drupal.org anymore

move field_view_field() / field_view_value() to methods

$
0
0

The field_view_field() / field_view_value() functions would make much more sense as view() methods on FieldItemList and FieldItemBase respectively (and added to the respective interfaces)

The phpdocs should make clear that, like the former functions, those methods are intended for one-off display of isolated field values in specific cases, but should not be used instead of entity_view().

Most arguments can now go away :
- $entity can be accessed by $this->getEntity()
- $field_name is $this->name,
- $item is $this
- $langcode is $this->getLangcode() (no need to specify the requested language as a param, the caller needs to set the entity to the expected language first, then calls view() on one of the fields / field items)

--> FieldItemListInterface::view($display), FieldItemInterface::view($display)

This could be a "relatively advanced" Novice task :-)

Convert system theme tables to table #type

$
0
0

Task

Convert the following theme functions to use the new table #type:

Module Theme function name Where in Code What is it really?
systemtheme_status_reportfunctiontable
systemtheme_system_date_format_localize_formfunctionform table
system theme_system_modules_uninstall functionform table
system theme_system_modules_details functionform table

Related issues

Default UUID key in ConfigEntityType

$
0
0

We talked about this today and agreed to just implement the UUID on the ConfigEntityBase class, and enforce this key.

Create API to discover content or config entities soft dependencies and use this to present a confirm form on module uninstall

$
0
0

Updated: Comment #10

Problem/Motivation

While #1776830: [META] Installation and uninstallation of configuration provided by a module that belongs to another module's API concerns the issue of default configuration, this issue is about configuration dependencies when a module is uninstalled. (#2082117: Install default config only when the owner and provider modules are both enabled covers installation.)

During lengthy IRC and discussion at Prague with catch, beejeebus, alexpott, mtift, and others, we came to a general consensus that we should create an API that would allow Module A to declare that it has config entities that depend on Module B. When Module B is being uninstalled this API will be used to inform the user that uninstallation will result in their removal.

Discussion points raised in Prague:

For dual-ownership config entities, what should happen on uninstall? Three options:

  • Allow user to back out or delete all your things
  • Disallow uninstall with soft dependencies
  • Just do nothing and let the site break

If we allow deleting all the things we need:

  • A confirmation screen listing everything that will be deleted
  • We should have a UI to batch deletions for (e.g.) field deletions
  • We should have an API to declare soft dependencies; it should not be in field_system_info()
  • Bundles are not formalized, so field API can't implement this dependency management. Can the entity type provider, e.g. node? There can be any number of bundle providers dependent on one entity type provider.
  • Also would need to create a robust batching API.

We also need to consider if deleting the forum node type also implies those field instances are being deleted? And do we need to tell the user? (we should provide a summary, e.g. this will delete the node type and N nodes)

Proposed resolution

Store dependencies in the configuration entity files in a new dependencies key. For example, field.instance.node.article.body

dependencies:
  entity:
    - 'field.field.node.body:cbc2ff50-059c-4a96-b22c-44a3419c2104'

And the views.view.frontpage
dependencies:
  module:
    - node

Introduce a ConfigDependencyManager that is able to read configuration files and construct a graph to determine dependencies between configuration entities or determine which entities are dependent on a specific extension (module or theme).

What dependencies do config entities have

Config entity type Dependencies
block The module that provides the plugin. The theme? Blocks depending on themes should be a followup since theme can not be uninstalled.
breakpoint if the source is theme or module it depends on that. Currently handled by the module - should be removed in favour of dependency management as a follow up.
breakpoint_group the breakpoint entities, if the source is theme or module that too. Currently handled by the module - should be removed in favour of dependency management as a follow up.
contact_category n/a
custom_block_type the theme it appears on? Custom blocks depending on themes should be a followup since theme can not be uninstalled.
editorThe filter format it is attached to. The module that supplies the editor plugin. Follow up to convert Editor entity to EntityWithPluginBagInterface and therefore the dependency will exist automatically due to ConfigEntityBase::preSave()
entity_form_display the form mode entity, the config entity if one provides the bundle
form_mode module that provides the target entity type
entity_view_display the view mode entity, the config entity if one provides the bundle
view_mode module that provides the target entity type
field_config module that provides the field type
field_instance_config field_config entity, the entity that provides the bundle (eg. node type), the widget and formatter providers
filter_format the modules that supply the filter plugins in use
image_style the modules that supply the image effect plugins in use
language_entity n/a
node_type This has a settings key that modules had into but uninstall is handled.
picture_mapping The breakpoint group
rdf_mapping the bundle entity
search_page the module that provides the plugin
shortcut_set n/a
action the modules that supply the action plugins in use
date_formatn/a
menun/a
taxonomy_vocabularyn/a
tour The module the tour is assigned to.
user_role n/a
view modules that provide the plugins if not optional, field_instances_config entities?

Remaining tasks

  • Design soft dependency API
  • Write patch

User interface changes

None. Although a UI would potentially be built that uses this API, this issue is only about the API.

API changes

A new API to allow one module to indicate it has soft dependencies through config entities it "owns" (i.e. where it provides the config entity type) on another modules.

#1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed
#1765936: Invoke ConfigStorageController::delete on module uninstall and add tests
#1776830: [META] Installation and uninstallation of configuration provided by a module that belongs to another module's API
#2079121: When a module providing a base table is uninstalled, delete all views built on it

Viewing all 293056 articles
Browse latest View live


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