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

drupal_lookup_path() - different aliases returned 1 time after cache clear and later

$
0
0

Hello, i believe there is mistake in drupal_lookup_path() function, because if i have 2 aliases for the same node in different languages - in my lang and in LANGUAGE_NONE, then this function will first time after cache clear return an alias for my lang, but after that it will always return an alias of LANGUAGE_NONE.

You can reproduse this, by creating 2 aliases for same node - first in language 'en', second in language LANGUAGE_NONE. You need to clear cache, and then call drupal_lookup_path('alias', 'node/[your_node_id]', 'en'). This function will return to you alias in language 'en'. Refresh the page, and you will see, that the alias changed to LANGUAGE_NONE.

i'm sure this strange behaviour is because different logic used in drupal_lookup_path for first time, and later, when getting alias from cache. As you can see below, the ordering is totally reversed for some strange reason.

path.inc from line 108:

<?php
         
if ($path_language == LANGUAGE_NONE) {
           
// Prevent PDO from complaining about a token the query doesn't use.
           
unset($args[':language']);
           
$result = db_query('SELECT source, alias FROM {url_alias} WHERE source IN (:system) AND language = :language_none ORDER BY pid ASC', $args);
          }
          elseif (
$path_language < LANGUAGE_NONE) {
           
$result = db_query('SELECT source, alias FROM {url_alias} WHERE source IN (:system) AND language IN (:language, :language_none) ORDER BY language ASC, pid ASC', $args);
          }
          else {
           
$result = db_query('SELECT source, alias FROM {url_alias} WHERE source IN (:system) AND language IN (:language, :language_none) ORDER BY language DESC, pid ASC', $args);
          }
?>

but couple lines below the ordering is reversed
path.inc from line 142:

<?php
       
// See the queries above.
       
if ($path_language == LANGUAGE_NONE) {
          unset(
$args[':language']);
         
$alias = db_query("SELECT alias FROM {url_alias} WHERE source = :source AND language = :language_none ORDER BY pid DESC", $args)->fetchField();
        }
        elseif (
$path_language > LANGUAGE_NONE) {
         
$alias = db_query("SELECT alias FROM {url_alias} WHERE source = :source AND language IN (:language, :language_none) ORDER BY language DESC, pid DESC", $args)->fetchField();
        }
        else {
         
$alias = db_query("SELECT alias FROM {url_alias} WHERE source = :source AND language IN (:language, :language_none) ORDER BY language ASC, pid DESC", $args)->fetchField();
        }
?>

Do not query user_roles directly

$
0
0

Currently user_roles is a weird bridge between the list of available roles (which is configuration) and the user (which is an entity). I suggest we move a user's role assignments to the user entity as a default field. This implementation would be similar to the one I proposed for path aliases in #1751210: Convert URL alias form element into a field and field widget.

- Add a multi-instance text field to the user entity, which has a select list of available roles (which will be stored in CMI).
- Set this field to be Format: Hidden by default in all view modes

In the aliases issue I suggested saving the aliases out to denormalized storage for the purposes of performant reading, but I'm not sure that is necessary here.

Return of the silly typo.

$
0
0

getNegotiator() has a RETUN value!!!!

Test issue for Make ContentEntityDatabaseStorage handle changes in the entity schema definition

Convert content_translation routes to a new style controller

Add tim.plunkett as a maintainer for Forms system, Routing system, and Configuration module

$
0
0

Problem/Motivation

Because the initiatives I've worked on in D8 have touched every part of core, my fingerprints are all over pretty much everything. But in addition to what I've already signed up for, there are 3 other parts of core I'm willing to work on post-release:
Form system:
Between FormInterface, FormBuilder, and soon FormState (and the unit tests for each), I have a pretty solid grasp on the form system and would like to continue working on it going forward.
Routing system:
Other than Crell and dawehner, I think I've spent the most time here and am willing to help out.
Configuration module:
There's not that much to the config.module right now, other than the full import/export and the single import/export. I wrote the single import/export, and as a former comaintainer of Features in contrib, have some ideas about what might evolve in that space.

Proposed resolution

Add me for each of those

Remaining tasks

Get sign-off from sun/fago/effulgentsia on the form system
Get sign-off from Crell on the routing system

User interface changes

N/A

API changes

N/A

[META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module

$
0
0

Problem/Motivation

see: #2256497: [meta] Menu Links - New Plan for the Homestretch

The architecture and general implementation is being reviewed in #2227441: New plan, Phase 1:Review the architecture and overall implementation proposal for menu links as plugins. Comments on those aspects of the patch should be posted to that issue.

This issue is to focus on implementation details, tests, and code and comment polish necessary to get the patch committed.

Proposed resolution

This issue to to build to a patch that will replace almost entirely the system in HEAD with a new one with minimal user-facing changes but substantial new features under the hood and performance gains.

  • Define an extensible framework for different types of links, with a plugin type as a common facade
  • The developer-facing APi is a plugin manager that also handles building trees into render arrays and access checks. The tree storage is a separate service that hides the implementation details of efficient hierarchy handing
  • Manage links defined in YAML and links defined by views
  • Full l10n support for localizing the D8 admin interface
  • i18n support via config translation for translating the links provided by Views.
  • A NG content entity whose base table stores the plugin definition
  • The custom menu link entity is defined as being fieldable
  • Link title is the (translatable) entity label
  • Menu link content entity can be added/edited via the node form (substituting for existing functionality)

Remaining tasks

  1. #2301239: MenuLinkNG part1 (no UI or conversions): plugins (static + MenuLinkContent) + MenuLinkManager + MenuTreeStorage
  2. #2301273: MenuLinkNG part2 (no UI or conversions): MenuLinkTree API and unit tests
  3. #2301313: MenuLinkNG part3 (no conversions): MenuLinkContent UI
  4. #2301317: MenuLinkNG part4: Conversion
  5. #2301319: MenuLinkNG part5: Remove dead code; and party!

User interface changes

Minimal. Module-defined menu links will have static title, description, and path that are not editable via the UI.

API changes

A new menu link system.

For reviewers there are 3 very notable changes:

  1. All menu links operate behind the facade of the \Drupal\Core\Menu\MenuLinkInterface. This means that multiple different implementations can operate together in the same tree. In addition, since we consider them as plugins, the details of the optimized tree storage are not exposed. The MenuTreeStorageInterface takes only a plugin definition and returns it again, while the details of the implementation (e.g. the p1-p9 columns) are not accessible or part of the API.
  2. The methods for loading and rendering menu link trees have been completely consolidated and made consistent in just 3 methods on the MenuLinkTreeInterface. A lot of previously crufty code that was forward-ported from 6 and 7 has been removed, aided by the decoupling of breadcrumbs form menu links
  3. The code for performing these steps has been broken up into multiple services, each with a clear interface so that in the cases where the behavior needs to be customized for a site or for a different tree storage (e.g. noSQL) only a limited amount of logic needs to be re-implemented to affect the change.

Patch map

This patch completely removes the menu_link module. It moves some of that module's former logic into \Drupal\Core\Menu, some into a new menu_link_content module, and removes some former logic. Details:

  • hook_translated_menu_link_alter(): removed. Can override plugin class instead.
  • hook_menu_link_CRUD_OP(): removed. Menu links are no longer entities, but for custom links, there's now hook_menu_link_content_CRUD_OP().
  • hook_menu_link_defaults_alter() -> hook_menu_links_discovered_alter().
  • menu_link_schema() -> MenuTreeStorage::schemaDefinition()
    • fields changed:
      • uuid + machine_name -> id
      • plid -> parent
      • link_path -> url OR route_name and route_parameters. url is only populated for external links
      • langcode + link_title -> title + title_arguments + title_context
      • module -> provider (in line with all other plugins)
    • fields removed:
      • customized -> (replaced with MenuLinkInterface::isResetable())
      • external (replaced by check if url is populated or Url::isExternal() after getting the Url object)
      • updated (this was outdated for D5 -> D6 update)
    • fields added:
      • description
      • class
      • metadata
      • form_class
    • private fields (in the schema of MenuTreeStorage, but not accessibly via any API):
      • route_key
      • discovered
      • p1..p9 (these were public in HEAD, but are made private by the patch)
  • menu_link_help(): removed. Do we need a menu_link_content_help()?
  • menu_link_uri() -> MenuLinkInterface::getUrlObject()
  • menu_link_CRUD_OP(): removed as menu links are no longer entities. Interact with MenuLinkManager instead (e.g., $menu_link_manager->getInstance(), $menu_link_manager->updateLink(), etc.).
  • menu_link_maintain(): removed. See above.
  • menu_link_system_breadcrumb_alter() -> menu_ui_system_breadcrumb_alter().
  • Entity\MenuLink ->
    • Storage-related functionality of link hierarchy and rebuild moved to MenuTreeStorage.
    • Storage-related functionality of custom links moved to MenuLinkContent.
  • MenuLinkAccessController ->
    • For routes (e.g., menu_ui.link_edit) that only need to check "administer menu" permission, check just uses _permission.
    • Access control of custom links moved to MenuLinkContentAccessController.
    • Access control of menu_ui.link_reset moved to MenuLinkResetForm::linkIsResetable().
  • MenuLinkDeleteForm -> MenuLinkContentDeleteForm
  • MenuLinkForm -> MenuLinkFormInterface (with MenuLinkDefaultForm and MenuLinkContentForm implementations)
  • MenuLinkInterface: removed as obsolete. The new MenuLinkInterface contains different methods.
  • MenuLinkStorage ->
    • Tree-related storage moved to MenuTreeStorage
    • Entity related storage removed as obsolete, because MenuLinkContent can use regular content entity storage.
  • MenuTree -> split into various new classes in \Drupal\Core\Menu.
  • StaticMenuLinks: removed. Static link discovery embedded into MenuLinkManager.

This patch also moves a bunch of procedural code from menu.inc to appropriate classes and removes code made dead by the new architecture. Details:

  • _menu_item_localize(): removed. MenuLinkInterface::getTitle() and other getter methods return localized strings.
  • _menu_link_translate() ->
    • unserializing moved to MenuTreeStorage::prepareLink()
    • access checking moved to a "menu tree manipulator" (DefaultMenuLinkTreeManipulators)
    • title/URL/etc. expansion moved to MenuLinkInterface getter methods.
  • menu_(get|set)_active_menu_names(): removed. Was obsolete code even before this patch due to refactored breadcrumbs already in HEAD; this patch just surfaced that.
  • menu_link_get_preferred() -> MenuActiveTrail::getActiveLink().
  • menu_reset_static_cache(): removed, because that static cache is removed.
  • _menu_link_save_recursive() -> MenuTreeStorage::saveRecursive().
  • menu_link_rebuild_defaults() -> MenuLinkManager::rebuild() which passes the discovered definitions into MenuTreeStorage::rebuild().
  • menu_load_links() -> MenuTreeStorage::loadByProperties().
  • menu_delete_links() -> MenuLinkManager::deleteLinksInMenu().
  • _menu_(update|set)_expanded_menus(): removed. This optimization was not carried into the new architecture for simplicity. This might need profiling to determine the performance cost, but once we render cache menus, it might change the value of this optimization.

Theme .info.yml file changes are not picked up even after clearing cache or running rebuild.php

$
0
0

Drupal 8 no longer detects changes to either the set of regions of a theme or simply name changes after a cache clear; this information is stored in State and unfortunately only updated when either a theme is disabled or enabled, or a module is installed or uninstalled.

This is a terrible Themer Experience. It's also a regression compared to Drupal 7, where I was able to have the changes be detected by simply clearing all caches.

I propose a simple solution: refreshing this info whenever saving a theme's configuration. Adding the following snippet to ThemeSettingsForm::submitForm() fixes the problem:

    // Also refresh the theme info, to ensure new or modified regions are detected.
    \Drupal::service('theme_handler')->refreshInfo();

Remove #type 'tableselect'

[meta] Convert hook_element_info() to RenderElement and FormElement plugins

Typo in docs for function Testclass::verbose

$
0
0

Hello.

Just stumbled across this on Drupal 7, but see now that this is also present in drupal 8.

I tried to search if someone else posted a patch for this, but could not find it. If that is the case, feel free to close this :)

Now, I am not a native english speaker, but it seems to be some suboptimal grammar in these sentences. In addition to a flat out typo (vebose -> verbose).

Attaching a couple of minor patches for Drupal 8 and Drupal 7. As I said, English is not my first language, so please feel free to chime in on the wording i chose.

Have a nice weekend everyone!

Convert hook_element_info() to annotated classes

$
0
0

Problem/Motivation

#1617948: [policy for now] New standard for documenting form/render elements and properties explains the problem space.

Proposed resolution

This will introduce a new ElementInfo annotation, and use that to replace hook_element_info().

We will NOT provide a plugin-level alter, since ElementInfo will only contain the plugin ID in the annotation.
The actual element info will be in a method on the class.

The existing alter hook will remain, running on the collected info.

Remaining tasks

Decide on more advanced ways to document the properties used by the elements (or punt that to another issue?)

User interface changes

N/A

API changes

No API change yet, but Drupal\*\ElementInfo\* will act as a replacement for hook_element_info().

"class" attribute in drupal_render should be an array

$
0
0

API page: https://api.drupal.org/api/drupal/core!includes!common.inc/function/drup...

The drupal_render documentation has instances of setting class to a string like:

<?php
'#attributes'=> array('class'=> 'foo'),
?>

which should really be:

<?php
'#attributes'=> array('class'=> array( 'foo')),
?>

Setting the class attribute to a string will work for some render arrays, but not for any that have pre_render functions that expect class to be an array. Any similar instances of this error in other Drupal 8 docs should also be corrected.

Convert PasswordHashingTest unit tests to phpunit

$
0
0

These are:

System/PasswordHashingTest.php

Tests that require a fully bootstrapped environment and/or the database are:

  • System/SettingsRewriteTest.php
  • System/SystemInitTest.php

Test that have been converted already:

  • System/ExceptionControllerTest.php

See #1938068: [Meta] Convert UnitTestBase to PHPUnit.

field_update_field() fails if a field schema removes an index

$
0
0

I have a field type in which the schema can be edited by the user in the UI. They can add or remove columns to the field schema, which means there also may be indexes that existed in my hook_field_schema() at one point when the field is created, but later does not exist. The problem I'm experiencing is that when field_update_field() is called which should drop the old field table and re-create with the current schema, it loads the 'old' indexes from the field_read_field() stored in the database. This causes a database exception because field_sql_storage attempts to create an index on a table column that does not exist.

It seems that field_create/update_field() supports passing in additional indexes that are not defined in hook_field_schema(), which frankly seems like a very bad idea.

This will need to be verified if this also is present on Drupal 8.


Views do not depend on modules providing their displays

$
0
0

Problem/Motivation

Views collects dependencies for a view in all sorts of ways, eg. handlers used under displays. Unfortunately the module providing the display itself is not added as a dependency, although it may very well be an optional module. Eg. user module provides two views that have block displays. The block display cannot be validated as configuration unless the block module is enabled. The display then is merely "optional" or in other words plain broken.

Found this in #2183983: Be stricter about schema issues once a config has schema.

Proposed resolution

1. Make the view inherit the provider of displays as dependencies of the view config entity.
2. Add missing provider info on block, rest and entity_reference displays in shipped config. There are two other displays in tests, but those are not referenced in shipped config.

The resolution itself will not fix the dependency problem as configuration is still imported even if internal dependencies are not met. The configuration system requires that configuration is in containing modules that are themselves dependent on all modules that their configuration depends on. That means the crucial node, user and comment module views affected in this patch will *also* need to move to a place where block module is enabled (naturally to standard profile). That will be in #2309715: Node, comment and user modules have views that also depend on block, move to standard profile.

Remaining tasks

Reviews. Commit.

User interface changes

None.

API changes

None.

Add an easy way to create HTML on the fly without having to create a theme function / template

$
0
0

Problem/Motivation

#1825952: Turn on twig autoescape by default introduced autoescape and with it a mechanism to mark strings as safe. This works great as long as render arrays are used or only t() functions, but it begins to be a problem once user input is involved that needs to be concatenated or modified in some way:

Consider the following code:

<?php
$build
['#markup'] = SafeMarkup::set('<span class="x">'. $my_maybe_secure_value . '</span>');
?>

The problem here is that $my_maybe_secure_value might not be known if its secure at the moment. A way to mitigate that is to use:

<?php
$build
['#markup'] = SafeMarkup::set('<span class="x">'. SafeMarkup::check($my_maybe_secure_value) . '</span>');
?>

but that NEEDS to be done or a XSS will happen. We also discourage direct usage of SafeMarkup::set() as it is marked as internal only function, so we need something better.

This can get complicated very fast:

<?php
          $summary_escaped
= '';
         
$separator = '';
          foreach (
$summary as $summary_item) {
           
$summary_escaped .= $separator . SafeMarkup::escape($summary_item);
           
$separator = '<br />';
          }
         
$field_row['settings_summary'] = array(
           
'#markup'=> SafeMarkup::set('<div class="field-plugin-summary">'. $summary_escaped . '</div>'),
          );
?>

and escaping gets to be something that is difficult, discouraged and an uneasy task.

We could use for this particular example (if SafeMarkup::escape supported arrays - it does not):

<?php
          $summary_escaped
= SafeMarkup::escape($summary);
         
$field_row['settings_summary'] = array(
           
'#markup'=> SafeMarkup::set('<div class="field-plugin-summary">'. implode("<br />", $summary_escaped) . '</div>'),
          );
?>

which is way shorter, but still uses SafeMarkup::set directly, which module authors should never think about.

This would not a problem if the whole section used a template as we then would be getting the autoescape for free and the BIG and BEST solution is to move all those little markup things into a larger encapsulating template.

However we need something in between for until more code can be converted.

Proposed resolution

This issue proposes to introduce a new #type called twig_inline that allows safe creation of markup without calling SafeMarkup::set() directly. This also decreases the chance of single tags getting marked as safe as render arrays are usually just passed up un-rendered to the top page level.
(at least once the SafeMarkup::set() within drupal_render uses the $recursive flag)

Before:

$build['#markup'] = SafeMarkup::set('<span class="x">' . SafeMarkup::escape($possible_unsafe_var) . '</span>');

After:

<?php
$build
['string'] = array(
 
'#type'=> 'inline_template',
 
'#template'=> '<span class="x">{{ var }}</span>',
 
'#context'=> array(
   
'var'=> $possible_unsafe_var,
  ),
);
?>

This also has the advantage that we store less #markup within render arrays, which we also should discourage. While before the render array was only changeable with either re-creating the value or using str_replace, now the template can theoretically still be changed in larger encompassing templates or preprocess functions, which is a slight theming win, too. For forms a simple form_alter() can also be enough.

The more complicated example looks then like:

<?php
          $field_row
['settings_summary'] = array(
           
'#type'=> 'inline_template',
           
'#template'=> '<div class="field-plugin-summary">{{ summary|safe_join("<br />") }}</div>',
           
'#context'=> array('summary'=> $summary),
          );
?>

safe_join is needed here which does automatic escaping before implode - comparable to the SafeMarkup::check() originally done. We had been debating to directly have |join always escape and be a safe filter, but that discussion is still ongoing.

As already discussed in the Motivation section the best would be to move as much of those to larger encompassing structures and templates, but this is probably the best we can do in the short term.

Remaining tasks

* Reviews and discussions.

User interface changes

* None.

API changes

* Addition of #type => 'twig_inline'.

Original report by Fabianx

I wondered if we should allow simple twig inline templates:

Before:

$build['#markup'] = SafeMarkup::set('<span class="x">' . SafeMarkup::escape($possible_unsafe_var) . '</span>');

After:

<?php
$build
['string'] = array(
 
'#type'=> 'inline_template',
 
'#template'=> '<div>{{ var }}</div>',
 
'#context'=> array(
   
'var'=> $possible_unsafe_var,
  ),
);
?>

That gives us autoescape for free and is compiled and cached to disk like normal templates, so pretty performant and not more difficult to use than t().

Refactor file.inc to make it simpler and prevent PDO exceptions

$
0
0

Problem/Motivation

There is a unique constraint on the uri column in {file_managed}. When inserting a new row it is only checked that the URI is unique on the filesystem, but not in the database. If the file has been deleted from the filesystem, but the entity still exists, this results in a PDO exception.

Proposed resolution

The code is already too complicated and buggy - previous patches posted in this issue were making it more complicated: refactor the code related to creating unique URIs.

Managed file operations, e.g. file_copy() / file_move() should not have the option to "take over" an existing file entity. It should be hardcoded to make sure the new URI is unique in database and filesystem. A file entity's URI can change, but the contents of a file entity's file must never change.

Replace constants:
FILE_EXISTS_RENAME, FILE_EXISTS_REPLACE, FILE_EXISTS_ERROR
should be:
FILE_CHECK_EXISTS_FALSE, FILE_CHECK_EXISTS_FS, FILE_CHECK_EXISTS_DB_FS

We do not need FILE_EXISTS_ERROR - code that needs this functionality can check itself.

The database should be checked for an existing URI before the filesystem as communicating with the filesystem can be very expensive, e.g. it could be in the cloud.

There is no situation where it is necessary to check database for an existing URI but not the filesystem.

Combine file_destination() and file_create_filepath() into file_uri_prepare() - a single function that ensures a URI is suitable for a new file.

Calls to file_valid_uri() just get in the way as it is perfectly valid to pass a filepath instead of a URI.

file_move() shouldn't return an entity as it is just modifying the entity that is passed to it.

file_copy() / file_move() / file_save_data() should set the filename of the resultant entity to the basename of the desired destination (provided it isn't a directory), not the basename of the resultant URI.

Remaining tasks

Review patch.

User interface changes

none

API changes

file_copy(File $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) =>
file_copy(File $file, $destination = NULL)

file_unmanaged_copy($source, $destination = NULL, $replace = FILE_EXISTS_RENAME) =>
file_unmanaged_copy($source, $destination = NULL, $check_exists = FILE_CHECK_EXISTS_FS)

file_destination($destination, $replace) and file_create_filename($basename, $directory) =>
file_uri_prepare($uri, $check_exists = FILE_CHECK_EXISTS_FS)

file_move(File $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) =>
file_move(File $file, $destination = NULL)

file_unmanaged_move($source, $destination = NULL, $replace = FILE_EXISTS_RENAME) =>
file_unmanaged_move($source, $destination = NULL, $check_exists = FILE_CHECK_EXISTS_FS)

drupal_file_exists($uri, $check_db = FALSE)

file_save_upload($source, $validators = array(), $destination = FALSE, $replace = FILE_EXISTS_RENAME) =>
file_save_upload($source, $validators = array(), $destination = NULL)

file_save_data($data, $destination = NULL, $replace = FILE_EXISTS_RENAME) =>
file_save_data($data, $destination = NULL)

file_unmanaged_save_data($data, $destination = NULL, $replace = FILE_EXISTS_RENAME) =>
file_unmanaged_save_data($data, $destination = NULL, $check_exists = FILE_CHECK_EXISTS_FS)

system_retrieve_file($url, $destination = NULL, $managed = FALSE, $replace = FILE_EXISTS_RENAME) =>
system_retrieve_file($url, $destination = NULL, $check_exists = FILE_CHECK_EXISTS_FS)

Original report by pwolanin

Found this in Drupal 7, but the fix should be the same for both 7 and 8 (and maybe 6?).

Discussed the problem with aaronwinborn and effulgensia and the it seems pretty clear we have a bug in terms of file_destination() because for a managed file it only checks if the file exists on disk.

This can lead to an SQL error if the URI exists in the {file_managed} table. For example, if I have 2 webnodes with local /tmp directories, a file being saved to temporary:// may not exist on disk, but may exist in the database. This can also happen if entries are not correctly purged when a file is deleted off disk.

There is a second bug which is a renaming race condition. If 2 users are trying to upload a file at about the same time, the simple incrementing logic may give both users the same file name.

Proposed fixes:

#1: when saving a managed file, check the URI in the database as well as on disk.

#2: when generating a suffix in the case of a duplicate file to be renamed, use a random 4-6 character string, rather than just incrementing.

Move route access checking code from \Drupal\Core\Access to \Drupal\Core\Routing\Access

Use proper machine names for permissions

$
0
0

Problem/Motivation

Drupal currently uses permission with machine names like access all views, and this is inconsistent with machine names found elsewhere in Drupal (where the convention is snake_case_with_underscores. To add to the confusion, some permissions have a mixture of spaces and underscores (such as permissions for particular node types, etc.).

Finally, if permissions are someday defined in YAML (as is proposed in #2295469: Add support for static permission definitions with *.permissions.yml), then permissions keys will need to be quoted, and will not match most other YAML keys as seen in Drupal configuration.

Proposed resolution

Enforce proper machine names like access_all_views instead of the machine names with spaces for all permissions.

Remaining tasks

TODO.

User interface changes

None.

API changes

Permissions should only use machine names. This should probably be documented somewhere.

Viewing all 291172 articles
Browse latest View live


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