I came across this issue when working on #2949991: Add workspace UI in top dialog.
When scrolling on mobile the toolbar stays pinned to the top of the page, so moves up as the page scrolls. However the toolbar try stays fixed to the right and does not scroll, this introduces a weird space at the top of the page.
I have been able to replicate this on Bartik and Seven, but not on Bootstrap.
Here's the issue in Firefox's mobile emulation:
The workflow transitions are not working properly when using preview mode , prior to saving content.
When clicking to preview and returning to edit mode, the content moderation current state (initial state ) is changed.
The workflow transition when saving would then not be the same ( the "from" being different).
If that new transition is not allowed , it would not even allow saving the modifications
if some rules are set for each independant transition, the whole thing is messed up.
After visiting @alexpott's session "Drupal 9 is coming: Getting your code ready
" (https://events.drupal.org/seattle2019/sessions/drupal-9-coming-getting-y...) in Seattle, I wanted to make the contrib select2 module more BC stable by preventing constructor overwrites.
I found out that I am not able to prevent constructor overwriting for the Select2EntityReferenceWidget (https://git.drupalcode.org/project/select2/blob/8.x-1.x/src/Plugin/Field...) because none of it's base classes is implementing the ContainerFactoryPluginInterface.
The base class chain of this class is Select2EntityReferenceWidget -> Select2Widget -> OptionsSelectWidget -> OptionsWidgetBase -> WidgetBase. That means if one of this base classes changes it's constructor, I will have a breakage in Select2EntityReferenceWidget.
Add ContainerFactoryPluginInterface to Drupal\Core\Field\WidgetBase and Drupal\Core\Field\FormatterBase and implement the ::create() method in them. The big advantage is that all child classes will be more BC stable.
Discuss
Implement
Test
Commit
n.a.
Add ContainerFactoryPluginInterface to Drupal\Core\Field\WidgetBase
n.a.
n.a.
Menu drag and drop can exceed either suhoson max_* or PHP's own max_input_vars, resulting in changes from the form silently disappearing.
Since there is no PHP error, there's no way for the user to know that their form submission has been lost except for checking the form again.
Tabledrag has hidden select lists for weight, it's possible this is hitting limits if a lot of them are shown on the page.
The select lists only show for users without JavaScript, or if 'show weight's is clicked, should we change them to textfields instead?
So I am a long time user of D6 and recently started to create a new website using D8. I'm completely frustrated by the menu system as what should be a fairly straightforward process, is not. Either I am missing something or there is a critical bug out there. All I am trying to do is create a submenu item in the Primary Menu.
I have the default "home" menu item listed there and I have 2 other menu items called "My Items" and "My Coordinations" which are created via Views to the view page.
I would like to simply add a menu item called "Add Item" which is linked to /node/add/item.
I have created this menu item manually through the "add link" button on http://sitename.com/admin/structure/menu/manage/main.
It appears fine and works. But once I move the menu item by dragging it to become the submenu item of "My Items" and click the save button. The page refreshes with the menu item back on the main level with all menus and now (disabled). WHY!?!?!?
Also, another issue is now that it's disabled, if I try to click the enable checkbox and hit save from the main (primary) menu edit page. It will NOT enable after save. It will just go back to being disabled (i.e. NO CHANGE). I have found that I need to actually click the edit button for that menu item and then on the menu item's edit page, I can click the checkbox next to "Enabled" with sub text "A flag for whether the link should be enabled in menus or hidden.". Then after I click the save button on that page, it will go back to the main menu edit page and show it now enabled. Why do I need to drill into it to enable it, why does the enable checkbox on the main edit page of the Main (Primary) menu not work!?!?
Then again, if I now drag it under the "My Items" menu again to make it a submenu item (i.e. it shows as indented under My Items), and click save, it will again move it out from under My Items and disable it again.
What the heck is going on?!!?
This is approved as a public security hardening in #25.
Access to modify a users role is handled inconsistently. The user access control handler incorrectly allows users with administer users to modify roles. The account form correctly requires administer permissions to edit roles of a user since it is implementing its own form elements.
The permission administer permissions is meant to be used to assign roles to users, CRUD roles, and to edit permissions grants for each role. Not administer users.
In Drupal 7, when you go to a users page, you can not edit the roles of the user. Nor can you use the bulk "[Assign/Remove] a role from the selected users" operation on admin/people. Unless you have administer permissions.
In Drupal 8, if you do not have administer permissions, you also cannot edit the roles when you are on the /user/%/edit page.
However if you have administer users, you can go to /admin/people and use the 'add the XXXX role to the selected users' actions.
This is a problem, because the user with administer users can assign himself the built-in 'Administrator' role. Which gives him all permissions, including the ability to edit permissions.
This effectively makes administer permissions useless.
administer permissions to edit the user roles in the user edit form.::access() method is only a run-time check, checking if the action can be done by the current user, on a specific object/entity. But we need more generic check to see if a user is able to read/access an action before the action starts to be executed. The method could be used, mainly, on views with bulk operation form, where the list of actions should be limited to the actions that the current user is allowed to access./admin/people view.None.
Users without administer permissions permission will not see anymore:
/admin/people\Drupal\system\ActionAccessControlHandlerActionAccessControlHandler::checkAccess() will grant the access to the action, first, if the current user has administer actions permission. If not, will ask the plugin to make a decision.::userAccess() in the plugin ActionInterface interface.ActionBase::userAccess() will return TRUE. In this way we ensure the Backward CompatibilityChangeUserRoleBase::userAccess() by checking the user permission.\Drupal\views\Plugin\views\field\BulkForm, limit the bulk operation action options based on action entity ::access().None.
Access to the roles field on the User entity is not handled consistently. This gap has been made possible due to the sort of non-standard approach that the AccountForm takes by providing form elements for fields directly in the form builder instead of using the field system to handle form display with normal widgets. Since it's providing the form elements, it's also setting the #access property, but not in a manner that is consistent with the actual field access. As a result, there is a disconnect between what can be done via the UI and via the REST API for the same user.
The AccountForm only allows access to the roles field for a user with administer permissions.
$form['account']['roles'] = array(
'#type' => 'checkboxes',
'#title' => $this->t('Roles'),
'#default_value' => (!$register ? $account->getRoles() : array()),
'#options' => $roles,
'#access' => $roles && $user->hasPermission('administer permissions'),
);
However, the UserAccessControlHandler allows anyone with administer users access to the roles field.
// Administrative users are allowed to edit and view all fields.
if (!in_array($field_definition->getName(), $explicit_check_fields) && $account->hasPermission('administer users')) {
return AccessResult::allowed()->cachePerPermissions();
}
I am migrating a d6 or d7 to d8, I have a date field with granularity "Year, Month, Day" but these are migrated by default to datetime_type datetime type and not to date type. The complete date of the installation was transferred in the format YYYY-mm-mmTHH:ii:ss into the database. This leads to a non existence of the date! The date is not shown in the rendered representation and in the edit form you get an empty date field
Add something similar how d7 to d8 is doing it.
Shortening the date field in the database to YYYY-mm-dd fixes this issue.
Hi,
In Vimeo you can add specific domain who can embed videos from Vimeo. This settings is found in paid account only.
When you do that thumbnails are not created when adding video in Drupal. If I remove that setting creation of thumbnails works without problems. Tried on 8.6 and 8.7, same result.
To reproduce (Paid Vimeo account needed or signup for try only):
1. Vanilla installation
2. Add field of type Reference / Media to content type Article and choose Remote Video.
3. Go to Content / Media / Add Media
4. Choose Remote Video
5. Paste Vimeo url
Result Defualt media icon, no thumbnail created.
From Vimeo docs: https://developer.vimeo.com/api/oembed/videos
"NOTE: In the case of a video with domain-level privacy, the oEmbed request returns a simplified response containing the embed code only and no private metadata. To get the complete response, send the Referer header along with the request, and set its value to the video's whitelisted domain."
We want to create a roadmap for Drupal 8.8 release.
Starting by putting together a list of our ambitious goals and then prioritize it into:
Must have & Nice to have.
Whatever we cannot complete by the week of October 14, 2019, the scheduled Drupal 8.8.0 Feature Freeze (alpha1 release), we can move to Drupal 8.9 or Drupal 9.
This list will evolve and will be updated through comments and additional conversations.
Some of the items can be achieved by getting help from volunteers in other teams, like Documentation and Translation.
(not sorted by importance)
Improving installation experience
Ambitious goal
Reduce installation time:
(Profiling installation process)
Add an option to install Umami with/without multilingual (#1356276: Allow profiles to define a base/parent profile and load them in the correct order)
SimplyTest improvements:
#3048708: Installation of Umami takes almost 20 minutes(!) and kicks back 504 errors
#3047290: One button Umami drupal installation
Remove warning messages
#3034784: Displaying translation string counts and string errors is too much detail in the installer
Language Switcher improvement
Low hanging fruit
#3042417: Umami's language-switcher as a drop-down menu
Tour
Ambitious goal
Adding Tour content to many more pages (mostly a documentation effort).
Teaching people Drupal with hands-on experience, explaining backend/frontend choices we made to build Umami.
Low hanging fruit
Improve Tour experience, by loading it automatically after installation.
#3038406: How do we make sure people new to Drupal know about the Umami Tour?
404 page
Ambitious goal
Add a View search results of whatever was typed in the URL.
Low hanging fruit
Theme the page with a friendly message, also relevant to 403 pages.
Multilingual
Ambitious goal
Allow installing Umami in any language by switching from CSV import to localize.drupal.org translation import.
Low hanging fruit
To add RTL functionality in Umami, add Hebrew / Arabic as a 3rd language (mostly content translation effort).
Media Library
Ambitious goal
Add (an external) video and audio to some of the pages / recipes / articles.
Low hanging fruit
#2954378: Use Media images in Umami demo Replace all exising image fields with media fields.
Theme Structure / Layout Builder
Ambitious goal
Update Umami's theme to a component-based design.
Low hanging fruit
Implement Layout Builder on every page, recipe & article.
Json:API
Ambitious goal
FE addition that suggests recipes according to groceries you have at home.
Low hanging fruit
Try Umami
Ambitious goal
#3047290: One button Umami drupal installation One button on Drupal.org that installs for you Umami demo on simplytest platform
Miscellaneous
Low hanging fruit
#3044366: Fix styling of Umami for layout builder
#2985551: Style and show content moderation form in Umami
#2940023: Improve accessibility of Umami's responsive main menu
#3051465: Revert "Taxonomies are only displayed in English"
#3041039: Search for content in current language/#3045362: Search for node content in current language
We should keep an eye on https://www.drupal.org/core/roadmap to see which modules could potentially become stable in the next Drupal release.
In the process of Drupal 8.7 development, Layout Builder and JSON:API modules became stable at the very end of the process.
We can prepare patches in advance for Media Library and other upcoming new functionality that might be ready in time for when Drupal 8.8 is going to be released.
According to https://www.drupal.org/core/roadmap there will be no new (big) functionality introduced in Drupal 9.0
Multiple types of demo sites
Ambitious goal
Finding free and open content repository, that we can either copy to into our own CSV files or use their APIs directly.
Create a content model for each type of website and import the content into it.
Create one global theme that can work for all these types of websites.
New core theme (Umami)
Ambitious goal
#3054838: Remove umami theme from profile and add it to core/themes
Fresh Images
Ambitious goal
Fresh new photos for Drupal 9
I am installing modules
For some reason I am getting an out of memory error when I have a limit of 750M.
I would like to go back and see in a report what configurations might be missing from my site.
This will help me troubleshoot.
steps to reproduce
error
Drupal\Component\Plugin\Exception\ContextException: Assigned contexts were not satisfied: entity in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 150 of core/lib/Drupal/Core/Plugin/Context/ContextHandler.php)
But the actual problem is in \Drupal\layout_builder\SectionComponent::getPlugin()
$plugin = $this->pluginManager()->createInstance($this->getPluginId(), $this->getConfiguration());
the id of the plugin will be extra_field_block:node:page:content_moderation_control and this will return and instance of \Drupal\Core\Block\Plugin\Block\Broken
Ensure that when there are new extra fields we clear the block cache.
None
None
None
When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections appear empty.
We should add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).
Write a patch, possibly discuss what setting (unserializing) sections looks like via an API like REST.
None.
A new normalizer will be added for the layout_section DataType.
None.
Fairly often there is a need for some sort of contextual data when rendering an element, which parts of, ultimately needs to make its way down the theme system pipeline.
This is especially true when certain render elements or theme hooks, that are not normally aware of the context in which they'll be rendered, needs additional information to provide rendering variations (i.e. per type or identifier).
While it is possible to add any variable you want in preprocess functions, it is often too late in the process and the original data that usually contains the needed information has long since been lost.
This is, in part, due to arbitrary properties (not registered in the theme hook) from being automatically transferred from a renderable element's properties.
Example from the search module in core, where a 'context' variable was manually added to allow for this flexibility (#2495419: Move the 'search-results' class from the render array and into a Classy template):
$build['search_results'] = [
'#theme' => ['item_list__search_results__' . $plugin->getPluginId(), 'item_list__search_results'],
//...
'#context' => ['plugin' => $plugin->getPluginId()],
];
Another example of use is for Views suggestions (which this issue is blocking): #2923634: [PP-1] Use hook_theme_suggestions in views.
Add a context variable as an empty array for all theme hooks, if one doesn't already exist.
Add a #context property as an empty array to all elements, if one doesn't already exist.
None
#context property added to all elementscontext property added to all theme hooks (for preprocessing purposes only)#context property to the context variablecontext variable immediately prior to rendering (for security concerns).None
The Entity link field uses the wrong translation of the entity. It always uses the original language which is not always desired.
This applies to both deletion and editing.
You can use the Entity operations field instead but that is not always desired to do so.
The exported view:
uuid: b6c259e3-3fbc-46b9-9979-8df90333fff2
langcode: en
status: true
dependencies:
config:
- node.type.article
module:
- node
- user
id: articles
label: Articles
module: views
description: ''
tag: ''
base_table: node_field_data
base_field: nid
core: 8.x
display:
default:
display_plugin: default
id: default
display_title: Master
position: 0
display_options:
access:
type: perm
options:
perm: 'access content'
cache:
type: tag
options: { }
query:
type: views_query
options:
disable_sql_rewrite: false
distinct: false
replica: false
query_comment: ''
query_tags: { }
exposed_form:
type: basic
options:
submit_button: Apply
reset_button: false
reset_button_label: Reset
exposed_sorts_label: 'Sort by'
expose_sort_order: true
sort_asc_label: Asc
sort_desc_label: Desc
pager:
type: mini
options:
items_per_page: 10
offset: 0
id: 0
total_pages: null
expose:
items_per_page: false
items_per_page_label: 'Items per page'
items_per_page_options: '5, 10, 25, 50'
items_per_page_options_all: false
items_per_page_options_all_label: '- All -'
offset: false
offset_label: Offset
tags:
previous: ‹‹
next: ››
style:
type: table
row:
type: fields
fields:
title:
id: title
table: node_field_data
field: title
entity_type: node
entity_field: title
alter:
alter_text: false
make_link: false
absolute: false
trim: false
word_boundary: false
ellipsis: false
strip_tags: false
html: false
hide_empty: false
empty_zero: false
settings:
link_to_entity: true
plugin_id: field
relationship: none
group_type: group
admin_label: ''
label: Title
exclude: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: true
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_alter_empty: true
click_sort_column: value
type: string
group_column: value
group_columns: { }
group_rows: true
delta_limit: 0
delta_offset: 0
delta_reversed: false
delta_first_last: false
multi_type: separator
separator: ', '
field_api_classes: false
edit_node:
id: edit_node
table: node
field: edit_node
relationship: none
group_type: group
admin_label: ''
label: 'Link to edit Content'
exclude: false
alter:
alter_text: false
text: ''
make_link: false
path: ''
absolute: false
external: false
replace_spaces: false
path_case: none
trim_whitespace: false
alt: ''
rel: ''
link_class: ''
prefix: ''
suffix: ''
target: ''
nl2br: false
max_length: 0
word_boundary: true
ellipsis: true
more_link: false
more_link_text: ''
more_link_path: ''
strip_tags: false
trim: false
preserve_tags: ''
html: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: true
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_empty: false
empty_zero: false
hide_alter_empty: true
text: edit
entity_type: node
plugin_id: entity_link_edit
delete_node:
id: delete_node
table: node
field: delete_node
relationship: none
group_type: group
admin_label: ''
label: 'Link to delete Content'
exclude: false
alter:
alter_text: false
text: ''
make_link: false
path: ''
absolute: false
external: false
replace_spaces: false
path_case: none
trim_whitespace: false
alt: ''
rel: ''
link_class: ''
prefix: ''
suffix: ''
target: ''
nl2br: false
max_length: 0
word_boundary: true
ellipsis: true
more_link: false
more_link_text: ''
more_link_path: ''
strip_tags: false
trim: false
preserve_tags: ''
html: false
element_type: ''
element_class: ''
element_label_type: ''
element_label_class: ''
element_label_colon: true
element_wrapper_type: ''
element_wrapper_class: ''
element_default_classes: true
empty: ''
hide_empty: false
empty_zero: false
hide_alter_empty: true
text: delete
entity_type: node
plugin_id: entity_link_delete
filters:
status:
value: '1'
table: node_field_data
field: status
plugin_id: boolean
entity_type: node
entity_field: status
id: status
expose:
operator: ''
group: 1
type:
id: type
table: node_field_data
field: type
value:
article: article
entity_type: node
entity_field: type
plugin_id: bundle
sorts:
created:
id: created
table: node_field_data
field: created
order: DESC
entity_type: node
entity_field: created
plugin_id: date
relationship: none
group_type: group
admin_label: ''
exposed: false
expose:
label: ''
granularity: second
title: Articles
header: { }
footer: { }
empty: { }
relationships: { }
arguments: { }
display_extenders: { }
cache_metadata:
max-age: 0
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url.query_args
- 'user.node_grants:view'
- user.permissions
tags: { }
page_1:
display_plugin: page
id: page_1
display_title: Page
position: 1
display_options:
display_extenders: { }
path: articles
cache_metadata:
max-age: 0
contexts:
- 'languages:language_content'
- 'languages:language_interface'
- url.query_args
- 'user.node_grants:view'
- user.permissions
tags: { }
When clicking on Edit on the Swedish Article exempel node I should be taken to the Edit form for that translation (Swedish)
When clicking on Delete on the Swedish Article exempel node I should be taken to the Delete form for that translation (Swedish)
I am taken to the edit form for the english (original translation).
I am taken to delete form to delete both translations.
Use the EntityTranslationRenderTrait trait to properly render entity row links in the right language.
Add Kernel test for the fields to ensure they work as expected.
Use Rendering language in the view configuration for untranslated entities
Fix translations for \Drupal\comment\Plugin\views\field\EntityLink if needed
Some complex sites have a lot of entity references in one field, for example using paragraphs.
As part of accessing field values \Drupal\Core\TypedData\Plugin\DataType\ItemList::setValue is called which initializes
all the underlying entity references.
Fabian realized last night during performance tuning on a site that ItemList was a lot slower than it should be.
Reuse the created items, so the complex operation in \Drupal\Core\TypedData\TypedDataManager::getPropertyInstance doesn't have to be called multiple times.
User roles missing in /user/login?_format=json REST response.
Super admin login response is mentioned below.
{
"current_user": {
"uid": "1",
"roles": [
"authenticated",
"administrator"
],
"name": "admin"
},
"csrf_token": "SMr4VPJU-2pr3vTOxTNdt-L2pqr6vUzNDePQfVDixGM",
"logout_token": "3HJ-Wzdf_5aX6GTDOjHrBq4OEcVijPk2Ggnpvfi3lGk"
}
If a user try to login via REST resource /user/login?_format=json
{
"current_user": {
"uid": "32",
"name": "sumeshsr110"
},
"csrf_token": "T6eQNBEl9ec9XelondCKV8AXaEd8IQ1mKcE0-289aho",
"logout_token": "cl0z652AK4wpVcdbA4YU05neftpfZiZqgCKCD8hjdNg"
}
I have checked the REST resource. ( core/modules/user/src/Controller/UserAuthenticationController.php ). It has one checking, see the below code.
if ($user->get('roles')->access('view', $user)) {
$response_data['current_user']['roles'] = $user->getRoles();
}
How can I get the user roles for all type of users via successful REST login ?
Markdown is a highly used markup language. It provides a common syntax in order to define formatting for text. CommonMark brings a strict specification for Markdown, documenting how to use it.
Using Markdown for our in-repo documentation will make README, UPDATE, et al, a lot nicer to read.
Rename README.txt to README.md to display on the main page of project on https://git.drupalcode.org/project/drupal
Currently, when rendering the book tree, an in_active_trail value is included in the book tree for each item; however, no is_active value is included. As a result, it's not possible to know if a particular item is active. This is useful for applying active states in book navigation.
When rending items in the book tree, check if the item belongs to the current page. Make this information available in the template layer.
Submit patch
None.
None.
None.
None.
In #2852463: Create a trait to implement \Drupal\Component\Plugin\ConfigurableInterface we added a trait to implement ConfigurableInterface. The methods in the trait rely on a $configuration member that is defined in PluginBase, but not in the trait itself. In php5 a warning is thrown if a class and trait try to provide the same member, but this is allowed in php7 provided the signatures match.
Once php 5 support is truely dead, the protected $configuration; member should be added to ConfigurableTrait
Wait for php5 support to be completely dropped from supported versions (when 8.8 is released and 8.6 is EOL)
Do it!
none.
none.
none.