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

ckeditor_stylesheets cache busting: use system.css_js_query_string

$
0
0

I added my theme css using the following in the *.info.yml:

ckeditor_stylesheets:
  - css/style.css

While updating the css/style.css I found that my changes wasn't reflecting into the WYSIWYG editor. Watching at the html head of the editor iframe I found that my css file was include as follow:

<link type="text/css" rel="stylesheet" href="/my_project/docroot/themes/unepmap/css/style.css">

That is, the above isn't included with any cache busting as any of the other css includes!?...

Now, not sure what is supposed to do CKEDITOR.timestamp included in #2679903: CKEditor uses separate cache-busting query string from Drupal's but it doesn't seems to cover the the above...


Add exposed filters and sorts to field list report

$
0
0

While it appears as though the Administer -> Reports -> Field list hasn't turned into a view yet (I'm assuming this is non-trivial given that there's no native support for creating a view of fields), we should still find a way to make it more usable, whether we do this through Views or not.

For example, I'd like to be able to do the following:

  • Sort by field type.
  • Filter by field type.
  • Increase the number of items on each page.

I found a contrib module that looks like it handles the filtering: Filter Field List

"Javascript" should be "JavaScript"

$
0
0

JavaScript is sometimes "Javascript", which is not correct.

Use form element of type date instead textfield when selecting a date in an exposed filter

$
0
0

Problem/Motivation

When adding a datetime exposed filter I cannot simply select a date - I have to manually enter a date which is very bad UX.

Proposed resolution

Use a form element with '#type' => 'datetime' so it's easy for users to select the date.

Change Record

Remaining tasks

  • Investigate why the default value of the exposed filter is not picked up by the form (see #104). see #115
  • Hide time element for date-only type fields
  • Create a follow-up for the possibility for site builder to decide the widget type from the views management UI (see #48)

User interface changes

Exposed date filters will have input[type=date], and will leverage HTML5 handling if supported by the browser, or fall back to the polyfill if it doesn't.
For datetime w/ type date-only we should still use the datetime form element, but in date-only mode ($element['#date_time_element'] = 'none'.

API changes

None.

Data model changes

None.

Deprecate the Views relationship from moderated content to the "content_moderation_state" entity

$
0
0

Problem/Motivation

The "content_moderation_state" entity is a mechansim for tracking state information about content entities. It is exposed through a computed field on entities called moderation_state.

Previously a views relationship was required from entities to "content_moderation_state" in order to display and filter by state. Ideally users shouldn't need to understand how states are stored and should just be able to reason about the "moderation_state" field on their moderated entities directly. For this reason, lets provide first class filtering and displaying of the state by way of the computed field.

Blockers:

#2862041: Provide useful Views filters for Content Moderation State fields
#2852067: Add support for rendering computed fields to the "field" views field handler

Given the "content_moderation_state" entity is going to become @internal, we shouldn't allow people to add a relationship to it. There shouldn't be a reason to once the above blockers are resolved.

Proposed resolution

Remove the views relationship to this entity type.

Remaining tasks

User interface changes

API changes

Data model changes

Unable to update Drupal 8.6 to Drupal 8.7; Field storage definition for 'type' could not be found in file_update_8700()

$
0
0

Original composer managed D8.6.15 site with [drush updb] and [drush entup] showing no updates required. Using PHP 7.2.17.

Updated core to D8.7.0 using composer with no errors.

However running [drush updb] afterwards results in WSOD and the following error:

 ------------------- ---------------- --------------- ------------------------- 
  Module              Update ID        Type            Description              
 ------------------- ---------------- --------------- ------------------------- 
  file                8700             hook_update_n   Set the 'owner' entity   
                                                       key and update the       
                                                       field.                   
  menu_link_content   make_menu_link   post-update     Update custom menu       
                      _content_revis                   links to be              
                      ionable                          revisionable.            
  system              add_expand_all   post-update     Initialize               
                      _items_key_in_                   'expand_all_items'       
                      system_menu_bl                   values to                
                      ock                              system_menu_block.       
  system              clear_menu_cac   post-update     Clear the menu cache.    
                      he                               @see                     
                                                       https:www.drupal.orgpro  
                                                       jectdrupalissues3044364  
  taxonomy            make_taxonomy_   post-update     Update taxonomy terms    
                      term_revisiona                   to be revisionable.      
                      ble                                                       
  taxonomy            remove_hierarc   post-update     Remove the 'hierarchy'   
                      hy_from_vocabu                   property from            
                      laries                           vocabularies.            
  views               exposed_filter   post-update     Update exposed filter    
                      _blocks_label_                   blocks label display to  
                      display                          be disabled.             
  views               make_placehold   post-update     Rebuild cache to allow   
                      ers_translatab                   placeholder texts to be  
                      le                               translatable.            
 ------------------- ---------------- --------------- ------------------------- 


 Do you wish to run the specified pending updates? (yes/no) [yes]:
 > 

>  [notice] Update started: file_update_8700
>  [error]  Field storage definition for 'type' could not be found. 
>  [error]  Update failed: file_update_8700 
> TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /var/www/html/drupal/web/core/modules/views/src/EntityViewsData.php on line 290 in /var/www/html/drupal/web/core/modules/views/src/EntityViewsData.php on line 387

Full message attached.

Where do I begin?

update from 8.6.15 to 8.7 fails due to menu_link_content

$
0
0

I get this error when i try to run the database update:

Failed: Drupal\Core\Entity\EntityStorageException: The entity update process    [error]
failed while processing the entity type menu_link_content, ID: 3. in
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema-&gt;copyData() (line
216 of
D:\FILES\REPOS\detroitmi-test\docroot\core\lib\Drupal\Core\Entity\Sql\SqlFieldableEntityTypeListenerTrait.php).

Figure out how to solve the curious case of /jsonapi

$
0
0

Over in #3035979: [DISCUSSION] Should a facility be added to JSON:API which limits automatic exposure of all entities, one of the concerns that was raised by a few people was with the /jsonapi endpoint, which is both a nice DX improvement but also basically a map of where all of the possible API attack vectors are for a jerk. Suggestions were to put it behind a permission, make it only available in dev, etc.

However, there was also pushback that since the URLs are entirely guessable anyway, removing this wouldn't actually provide any additional security, and if an attacker were to script something, they wouldn't even bother using this page, just go against the URLs they know exist on every JSON:API-enabled site.

This is an issue to have that argument. :)


Improve accessibility of Views table sortable columns

$
0
0

Problem/Motivation

Currently views table columns are read by screen readers in a way that is not helpful to users. A table column named "Status" would be read as "Status sort descending" which is both hard to understand and doesn't state the actual status of the column, only the action of the link. Some help text is given in a title tag, but title has been widely panned for no longer being an accessibility best practice:

Proposed resolution

I recommend both changing the title tag to one that's read: aria-label, and supplementing the help text with more descriptive content based on these examples:

The aria-label on columns could work like:

(unsorted) 'Status' column. Activate to sort descending.
(active, sorted) 'Status' column, sorted descending. Activate to sort ascending.

The column name is wrapped in single quotes to be set off as not part of a sentence by the screen reader. If the column is sorted, the sort is indicated. Then the link action is indicated using "activate" instead of "click" to be pertinent to all users, whether they're navigating by keyboard, mouse, or another device.

Remaining tasks

I've tested in VoiceOver, but the behavior should be tested in other screen readers. The code isn't the DRYest... but it seemed like this was easier to read then chunking it up and concatenating the pieces together.

User interface changes

No visual changes, but changing what seems to be an unusable title tag into something more accessible.

API changes

None.

Data model changes

None.

Release notes snippet

[PP-1] [upstream] Support version negotiation for any entity type (currently only Node & Media are supported)

[PP-4] [META] Revisions support

$
0
0

Problem/Motivation

We want to support revisions in order to provide a fully featured editorial experience and support content preview.

Proposed resolution(s)

Terminology

We will be following the RFC 5829 from the IETF. That means that:

  1. We will refer to the current/published revision as: "working-copy"
  2. We will refer to the latest revision as: "latest-version"

Revision Negotiation

We will enable revision negotiation by supporting a custom query string parameter with the name of "resource_type". Consumers will transfer the desired revision by setting the value in this query string parameter.

We will introduce a new plugin type that will enable different ways to specify a revision. This way we will be able to do https://example.org/jsonapi/node/article/f6da07d8-eb1a-4422-b19e-d209a408b7d6?resource_version=rel:latest-version to load the latest version, https://example.org/jsonapi/node/article/f6da07d8-eb1a-4422-b19e-d209a408b7d6?resource_version=id:6 to load revision with ID 6, https://example.org/jsonapi/node/article/f6da07d8-eb1a-4422-b19e-d209a408b7d6?resource_version=date:2018-01-09T13:08:22Z to load the revision that was in effect on that particular date.

In addition to the plugin type, we'll implement the id:{revision-ID} and the rel:{(working-copy|latest-version|…)} (although initially we'll only support "latest-version" and "working-copy").

Revision Discovery

As stated in RFC 5829 we will need to add links to the JSON API entities (both collections and individual entities) so consumers can discover the URLs for the revisions. That includes the presence of a Link HTTP header and an entry in the "links" section in the response payload.

Revisions on Collections

Due to the nature of collections we can't ensure correct support for all revision ID negotiation plugins. For instance we know we can't support the ID plugin (because each item requires a different revision_id). However we can easily support Rel with "latest-version" and "working-copy" because they apply to any entities and Entity Query supports them (yay!).

Full CRUD on Revisions

This issue does not address write operations like deleting a revision, updating a particular revision, etc.

Note: Place here the issue to plan Full CRUD on Revisons. Per #2350939: [PP-1] Implement a generic revision UI, this needs a generic revision access API, which doesn't yet exist for reading (also not for writing). The issue for that is #3043321: Implement a generic revision access API.

Modify Layout Builder's use of the off-canvas tray to improve UX of larger block forms

$
0
0

Problem/Motivation

The Layout Builder uses core's off-canvas "tray" when adding/editing blocks to a layout. It opens the tray on the right side of the page, but it's not very wide, and as a result it doesn't accommodate larger block forms very well. This is most evident when adding block that has a textarea field w/ CKEditor:

ckeditor tray

This problem surfaced in #2948064: Layout Builder should support inline creation of Custom Blocks using entity serialization.

An interesting issue to follow that may help resolve this is #2916781: Allow off-canvas dialog to be rendered at the top of the page.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Spec Compliance: JSON API's profile (Fancy Filters, Drupal sorting, Drupal pagination, relationship arity) needs to be explicitly communicated

$
0
0

http://jsonapi.org/format/#crud

Problem/Motivation

While working on #2931785: The path for JSON API to core, I think we overlooked one very important thing wrt spec compliance. The fact that the JSON API module for Drupal incorporates two spec extensions:

  1. Fancy filters: https://gist.github.com/e0ipso/efcc4e96ca2aed58e32948e4f70c2460
  2. Partial success: https://gist.github.com/e0ipso/732712c3e573a6af1d83b25b9f0269c8

… yet we support Accept: application/vnd.api+json and Content-Type: application/vnd.api+json. Which signifies we're implementing the base spec. Additionally, we're not even mentioning in jsonapi.api.php that this module implements more than just the base spec!

http://jsonapi.org/format/#content-negotiation says:

Content Negotiation

Client Responsibilities

Clients MUST send all JSON API data in request documents with the header
Content-Type: application/vnd.api+json without any media type parameters.

Clients that include the JSON API media type in their Accept header MUST
specify the media type there at least once without any media type parameters.

Clients MUST ignore any parameters for the application/vnd.api+json
media type received in the Content-Type header of response documents.

Server Responsibilities

Servers MUST send all JSON API data in response documents with the header
Content-Type: application/vnd.api+json without any media type parameters.

Servers MUST respond with a 415 Unsupported Media Type status code if
a request specifies the header Content-Type: application/vnd.api+json
with any media type parameters.

Servers MUST respond with a 406 Not Acceptable status code if a
request’s Accept header contains the JSON API media type and all instances
of that media type are modified with media type parameters.

Note: The content negotiation requirements exist to allow future versions
of this specification to use media type parameters for extension negotiation
and versioning.

… and sadly, JSON API's extension system was reverted. http://jsonapi.org/extensions/ currently says An extension system is currently under development […]… on May 21, 2015.

In https://github.com/json-api/json-api/issues/614, Roy Fielding (of REST fame) is quoted to have written that media type negotiation like vnd.api+json is meaningless. He clarified his statement at https://github.com/json-api/json-api/issues/614#issuecomment-101741478. That issue spawned https://github.com/json-api/json-api/pull/650, which tried to improve things, but it was considered "too late before the imminent 1.0 release". Then, ironically, it is https://github.com/json-api/json-api/pull/660, which is mentioned nor linked in neither of the two issues above (614 an 650), and it simply removed the concept of/support for extensibility altogether. This was May 21, 2015.

It was worked on a bit in November 2015, in https://github.com/json-api/json-api/issues/915. Again in December 2015, in https://github.com/json-api/json-api/pull/957. And then again in https://github.com/json-api/json-api/pull/1195, in July 2017. And finally, https://github.com/json-api/json-api/issues/1207 in August 2017.

https://github.com/json-api/json-api/issues/1207 is the latest and greatest, confirmed by spec author dgeb at https://github.com/orbitjs/orbit/issues/479#issuecomment-358654119 on Jan 18, 2018. but it still hasn't actually gone anywhere — there's still nothing spec implementers can actually do …

Finally, note that http://jsonapi.org/format/#content-negotiation (quoted in full above) says the server must send an error response if any media type parameters are specified!

Proposed resolution

  1. Update jsonapi.api.php to state that the JSON API module implements the base spec + 2 extensions
  2. Figure out how to communicate in our HTTP responses that it's the base spec + 2 extensions … even though the JSON API spec literally forbids it, and there's a whole string of GitHub issues: 614, 650, 660, 915, 957, 1207.

Remaining tasks

Discuss!

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Correctly determine when to display fields as inline

$
0
0

When Drupal displays a field, the template is field.html.twig, which generates block-level markup including optional labels, attributes, and supports multiple values.

For the node title, uid and created fields Drupal supplies an overridden template (e.g. field--node--title.html.twig) that generates simplified inline markup without label or title_attributes.

If the site owner has hooked the node title to setDisplayConfigurable(), then the inline display is incorrect. The label is missing, markup is inline, and the markup might not match normal CSS selectors for fields (for example if the CSS selector specifically matches on div). For the node created field, also the metadata rel="schema:author" is missing.

Solution

Disable the overridden field templates if the fields are setDisplayConfigurable(). To preserve back-compatibility, only do this if an additional entity type property is set - reusing the mechanism from #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI.

Workaround

/**
 * Implements hook_theme_registry_alter().
 */
function XXX_theme_registry_alter(&$theme_registry) {
  // Disable the 'inline' versions of node base field templates to workaround
  // https://www.drupal.org/node/2993647.
  unset($theme_registry['field__node__title']);
  unset($theme_registry['field__node__uid']);
  unset($theme_registry['field__node__created']);
}

Use library version as query strings for external css (like js does)

$
0
0

Non-aggregated CSS external files do NOT use the library version as a query string like JS library files do. I'm not sure why this is other than it seems like an oversight. Perhaps someone can give good reasoning as to why this was left out of core.

See attached patch for 8.7.1.


Umami's language-switcher as a drop-down menu

$
0
0

Problem/Motivation

Umami comes with a new language switcher.
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header.

Proposed resolution

Add the list of available languages into a dropdown menu.

Remaining tasks

Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"

When Batch ID doesn't exist, Drupal should emit a 404

$
0
0

Problem/Motivation

Currently if you try to go to /batch?id=123 you get redirected to the homepage with a message stating "No active batch".

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryUsability Bug, because the message "No active batch" is not clear, since no batch is ran and it does not exists. Response must help figure out what is going on actually.
Issue priorityNormal, because this is a self-contained bug and does not impact the overall functionality of the software.
Unfrozen changesNot unfrozen because it changes automated tests and needs a bug fix.
Prioritized changesPrioritized, the main goal of this issue is a bug fix, usability and user experience improvement.
DisruptionImpact on improving usability is fair. Also it doesn't disrupt core API because it is internal to batch API only.

Proposed resolution

Since the batch doesn't exist Drupal should just emit a 404 instead

User interface changes

Error message displayed, "Trying to execute an invalid batch ID : N."

API changes

If you try to go to /batch?id=123 Drupal emit a 404.

Recent fix for CurrentUserContext does not assign the "anonymous" role

$
0
0

I am experiencing a problem with the current fix because the user does not get the "anonymous" role.

I have a use case where I have a menu for "anonymous" users and one for "authenticated". This doesn't work with the current fix.

Using #8 from the parent issue fixes this problem but this was not commited to 8.7.x or 8.8.x. Should I just create my own patch and apply everytime I update core or whats the way to go here?

I am currently using 8.7.1

[regression] Impossible to filter for resources with an empty relationship object in JSON:API 2.x

$
0
0

I am not sure if this is a bug but have isolated that the issue appeared with RC4. I read the notes in the jsonapi.api.php about the new access testing that RC4 introduced and that's what is causing the API to return no data.

First - here is the API Request. The filedepot_folder content type is very basic but has a entity reference back to itself in order to represent a nested file folder structure. In this case, we are looking for all folder nodes that don't have the parent_folder field set -- ie: are top level root folders.

  • This worked fine up to RC4 and continues to work if the client app is logged in as Admin "uid 1"
  • Does not work even if the client user has the administrative role
  • Works if I grant Bypasss content access control permission to the client user

http://{site_url}/jsonapi/node/filedepot_folder?sort=-nid&fields[node--filedepot_folder]=title,uid,field_parent_folder,changed,drupal_internal__nid&include=uid,field_parent_folder&fields[user--user]=name,mail&filter[folder][condition][path]=field_parent_folder.id&filter[folder][condition][operator]=IS%20NULL&page[limit]=50

Result:

{
   "data":[

   ],
   "jsonapi":{
      "version":"1.0",
      "meta":{
         "links":{
            "self":{
               "href":"http:\/\/jsonapi.org\/format\/1.0\/"
            }
         }
      }
   },
   "links":{
      "self":{
         "href":"http:\/\/d8react2.ddev.local:8080\/jsonapi\/node\/filedepot_folder?fields%5Bnode--filedepot_folder%5D=title%2Cuid%2Cfield_parent_folder%2Cchanged%2Cdrupal_internal__nid\u0026fields%5Buser--user%5D=name%2Cmail\u0026filter%5Bfolder%5D%5Bcondition%5D%5Boperator%5D=IS%20NULL\u0026filter%5Bfolder%5D%5Bcondition%5D%5Bpath%5D=field_parent_folder.id\u0026include=uid%2Cfield_parent_folder\u0026page%5Blimit%5D=50\u0026sort=-nid"
      }
   }
}

Tested with enabling all content view related permissions, including contact and user-information. Also tested API without the uid and 'user--user' fields - same result.

But if I use a different [operator] and filter condition, then the query works and data is returned.

http://d8.6.5.ddev.local:8080/jsonapi/node/filedepot_folder?sort=-nid&fields[node--filedepot_folder]=title,uid,field_parent_folder,changed,drupal_internal__nid&include=uid,field_parent_folder&fields[user--user]=name,mail&filter[folder][condition][path]=field_parent_folder.id&filter[folder][condition][operator]=%3D&filter[folder][condition][value]=f71b6e54-71c5-4cda-8861-cd9e67f4f604&page[limit]=50

Is this a bug or usage issue?

Thanks!

Failed while updating from 8.6.15 to 8.7.x: Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable

$
0
0

Attemp to update my site from 8.6.15 to 8.7.0 using: composer update drupal/core webflo/drupal-core-require-dev --with-dependencies as always.

All modules are updated to last release and the site with version 8.6.15 was working with no a single error.

After successfully running composer update drupal/core webflo/drupal-core-require-dev --with-dependencies, I tried to update the site from UI,

Available Updates:

system module
8701 - Remove the unused 'system.theme.data' from state.
8702 - Add the 'revision_translation_affected' entity key.
Initialize 'expand_all_items' values to system_menu_block.
Clear the menu cache. @see https:www.drupal.orgprojectdrupalissues3044364
comment module
8700 - Set the 'owner' entity key and update the field.
8701 - Make the 'entity_type' and 'field_name' comment fields required.
Add comment settings.
file module
8700 - Set the 'owner' entity key and update the field.
node module
8700 - Set the 'owner' entity key and update the field.
taxonomy module
8701 - Add an index on the 'taxonomy_term__parent' field table.
Update taxonomy terms to be revisionable.
Remove the 'hierarchy' property from vocabularies.
layout_discovery module
Recalculate dependencies for the entity_form_display entity.
Recalculate dependencies for the entity_view_display entity.
menu_link_content module
Update custom menu links to be revisionable.
views module
Update exposed filter blocks label display to be disabled.
Rebuild cache to allow placeholder texts to be translatable.

while updates are running, and more specifically when the "Post updating layout_discovery", I am receiving the below error:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /update.php/start?id=352&op=do_nojs&op=do
StatusText: OK
ResponseText: TypeError: Argument 1 passed to Drupal\Core\Entity\EntityStorageBase::loadMultiple() must be of the type array or null, string given, called in S:\Sites\dev\web\core\modules\views\src\Plugin\views\filter\EntityReference.php on line 397 in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 256 of S:\Sites\dev\web\core\lib\Drupal\Core\Entity\EntityStorageBase.php).

When I click on the available link: see full error in details, the below messgae displayed:

Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of core\modules\system\src\Controller\DbUpdateController.php).
Drupal\system\Controller\DbUpdateController->results(Object) (Line: 179)
Drupal\system\Controller\DbUpdateController->handle('results', Object)
call_user_func_array(Array, Array) (Line: 115)
Drupal\Core\Update\UpdateKernel->handleRaw(Object) (Line: 76)
Drupal\Core\Update\UpdateKernel->handle(Object) (Line: 28)

The update process was aborted prematurely while running update # in menu_link_content_post_update_make_menu_link_content_revisionable.module.

Any help please ? Thank you

Viewing all 295783 articles
Browse latest View live