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

Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

August 14, 2019, 11:14 am
$
0
0

Problem/Motivation

Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches, Drupal 9 may need to retrieve modules that start with 8.x-. The update module is not currently aware that modules starting with 8.x can be compatible with Drupal 9.

Proposed resolution

  1. Update requests should no longer request information from URLs that have \Drupal::CORE_COMPATIBILITY(8.x) as the final path segment. This should be replaced with 'current'. For example, a request that previously requested https://updates.drupal.org/release-history/paragraphs/8.x will now request https://updates.drupal.org/release-history/paragraphs/current
  2. The contents of /current has a somewhat different structure than what was returned by requests to /8.x, The update module and its tests will need refactoring to reflect those changes.
    • The following tags are no longer provided, the information should be parsed from the version tag instead: version_major, version_minor, version_patch, version_extra
    • recommended_major (which differed depending on the API requested) may be replaced with recommended_branches, which will be provided by Drupal.org if needed. Currently recommended_major is dropped
    • supported_majors replaced with supported_branches, which includes core compatibility for non-semver version numbers.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧
Search

drupalPostForm lacks headers

September 14, 2019, 11:14 am
$
0
0

Problem/Motivation

https://www.drupal.org/project/seckit/issues/3074080 is porting to the new BrowserTestBase. The old method was protected function drupalPostForm($path, $edit, $submit, array $options = [], array $headers = [], $form_html_id = NULL, $extra_post = NULL) { where the new method is protected function drupalPostForm($path, $edit, $submit, array $options = [], $form_html_id = NULL) {. It misses $headers. Notably protected function drupalGet($path, array $options = [], array $headers = []) { still has $headers.

Proposed resolution

  1. Add an optional $headers to prepareRequest and submitForm
  2. Move the header setter code from drupalGet into prepareRequest.
  3. Pass down $headers from drupalPostForm to drupalGet and submitForm both.

Remaining tasks

Write it.

User interface changes

API changes

Additional optional $headers argument on prepareRequest and submitForm and drupalPostForm. It'll be a bit annoying the order of arguments change vs WebTestBase but I guess that can't be helped now.

Data model changes

Release notes snippet

↧
↧

Best practice for adding CSS to admin core theme?

June 21, 2016, 3:46 pm
$
0
0

Hello,

What would be the best way of adding a small CSS file to the core admin theme? We are simply looking to improve the UX of multi select list boxes we are using for taxonomy selection by making them taller.

↧

Layout builder incorrectly resolves global contexts values when viewing layouts

December 10, 2019, 3:06 am
$
0
0

Layout builder incorrectly assumes it can get global contexts and values with getAvailableContexts. This means context providers that correctly adhere to \Drupal\Core\Plugin\Context\ContextProviderInterface currently do not resolve values with layout builder.

When rendering layouts, \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::getContextsForEntity should call contextRepository->getRuntimeContexts on the result of contextRepository->getAvailableContexts since by design the value are not intended to be added in getAvailableContexts.

It so happens the CurrentLanguageContext and CurrentUserContext incorrectly populate values in getAvailableContexts, which likely lead to this unnoticed issue. The way these context providers are allowing empty arrays to be passed to getRuntimeContexts is cheating. Even the contract for \Drupal\Core\Plugin\Context\ContextProviderInterface::getRuntimeContexts specifies only those provided must be returned. The attach patch basically does the empty-array cheat on contexts, but using the API as specified.

Contexts like NodeRouteContext correctly implement the interface, and could be made to work with LB. Currently this context also doesnt work properly because it doesnt set a default context value on layout builder build pages (See \Drupal\layout_builder\Context\LayoutBuilderContextTrait::getAvailableContexts). Note, solving NodeRouteContext is not within scope of this bug.

See the documentation for \Drupal\Core\Plugin\Context\ContextProviderInterface::getAvailableContexts, and the interface in general, for more information.

↧

[IGNORE] Composer-friendly patches for filename sanitation while #2492171 awaits #3032390

November 12, 2019, 6:43 pm
$
0
0

Problem/Motivation

#2492171: [PP-1] Provide options to sanitize filenames (transliterate, lowercase, replace whitespace, etc) is blocked on #3032390: Add an event to sanitize filenames during upload which is itself languishing.

People are re-rolling older versions of #2492171 and confusing things in the parent issue.

Proposed resolution

Post "composer-friendly" re-rolls here, so as not to further confuse the parent issue.

Remaining tasks

-

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

↧
↧

Allow media items to be edited in a modal when using the field widget

July 11, 2018, 10:17 am
$
0
0

Problem/Motivation

In #2962525: Create a field widget for the Media library module, the media edit/view link was disabled in the field widget and widget view in order to prevent unintended data loss. Long term, we would still like the ability to quickly edit media items from the field widget, without navigating to a new page.

Proposed resolution

Allow media items to be edited in a modal while using the field widget. The Entity Browser module allows for similar functionality.

Remaining tasks

Write a patch, discuss scope.

User interface changes

Undecided.

API changes

None.

Data model changes

None.

↧

Ajax replace inside a modal causes the current field to lose focus.

December 10, 2019, 2:08 pm
$
0
0

Problem/Motivation

When a field inside a modal form is replaced, focus is moved to the top of the form.

Proposed resolution

Don't move focus if the currently focused element is inside the modal.

↧

Update handbook page link on cron settings form

December 10, 2019, 2:39 pm
$
0
0

Problem/Motivation

On admin/config/system/cron there is a link to a cron tutorial on drupal.org. It points to a D7 handbook page.

Proposed resolution

Update the link to point to an equivalent D8 handbook page.

↧
Search

Improve the DX for migrating content entities: view modes, fields, formatters, widgets etc should be migrated per entity type + bundle

November 28, 2019, 4:07 am
$
0
0

Problem/Motivation

Similar to #3096951: d7_node migration should have dependency on d7_node_title_label migration and #3097327: [PP-1] d7_node_title_label migration plugin should be derived per node type AND should only be created for node types that have an override.

Right now there is only one:

  • "View Modes" (d7_view_modes) migration
  • "Field configuration" (d7_field) migration
  • "Field instance configuration" (d7_field_instance) migration
  • "Field formatter configuration" (d7_field_formatter_settings) migration
  • "Field instance widget configuration" (d7_field_instance_widget_settings) migration

… rather than one of those per entity type + bundle.

This is harder to understand, and harder to debug.

Furthermore, just like #3097314: d7_comment migration should have dependency on d7_comment_entity_display, same for d7_custom_block + block_content_entity_display, the concrete entity migration not having a dependency on the above configuration makes it harder to compare the data on the destination D8 site with the source D7 site, because equivalent formatters and widgets will be used.

Proposed resolution

  • Add a deriver to each of the aforementioned migration plugins.
  • Add optional migration dependencies. to the corresponding content entity migrations.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

↧
↧

Constrain the width of aligned images, media, blockquotes etc to a max of 75%

August 30, 2019, 5:27 am
$
0
0

Problem/Motivation

Given that alignable elements are:

  • Media Embeds aligned-left or aligned-right
  • Media Embeds with captions aligned-left or aligned-right
  • Images aligned-left or aligned-right
  • Images with captions aligned-left or aligned-right
  • Blockquote text aligned-left or aligned-right

Alignable elements can be aligned-right or align-left (as well as aligned-center or not aligned). When align-right or aligned-left, there is an implicit assumption that there will be space opposite of the alignment.

  • If aligned-right, it makes sense to allow space to the left of the alignable element.
  • If aligned-left, it makes sense to allow space to the right of the alignable element.

This is arguable essential within the text editor to allow:

  • a visual representation of the alignment
  • space to edit the text wrapping around the aligned embed
  • to prevent bizarre squished text

Text without much horizontal space for editing:
bizarrely squished text

Text with the words exploded into letters:
bizarrely squished text 2

This from feedback from @effulgentsia here #2801307-54: [META] Support WYSIWYG embedding of media entities:

[...] add CSS along the lines of max-width: 75% on media that's aligned left or right. It's fine for the media to be smaller. It's just that if you're explicitly choosing to align it left or right, then you're choosing to put something else beside it, which means leaving some amount of room for that something else.

Proposed resolution

  • Must-have: Add a max-width for embedded media in CKEditor when aligned-left or aligned-right (only).

Additional suggested improvements:

  • Add a max-width for alignable elements when aligned-left or aligned-right in Classy theme and themes that extend Classy.
  • Add some margin between alignable elements and the elements opposite in the CKEditor.
  • Add some margin between alignable elements and the elements opposite in the Classy theme and themes that extend Classy.

Remaining tasks

  1. Review
  2. Test coverage
  3. Commit.

User interface changes

TBD

API changes

None.

Data model changes

None.

Release notes snippet

Draft Change record:
https://www.drupal.org/node/3085749

↧

Remove @import parsing from Drupal.AjaxCommands.prototype.add_css

December 10, 2019, 3:12 pm
$
0
0

Problem/Motivation

Originally introduced in #1071818: Lazy-loading CSS fails in IE to support IE 6 - 9 which did not support @import statements within dynamically added style elements. IE 10 fixed stylesheet limitations, and only IE 11 is now officially supported by core #2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x.

Additionally, Drupal no longer uses @import statements when rendering CSS assets #2897408: Remove IE9 support from CssCollectionRenderer and provide it in contrib instead, so this code should never be executed.

Proposed resolution

Remove @import parsing from Drupal.AjaxCommands.prototype.add_css()

↧

Dynamic Views Arguments via Tokens

July 24, 2012, 4:40 pm
$
0
0

For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.

Entity Reference allows using a View of a specific display type to set the available options. This is good.

It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.

Those arguments must be completely static. This is not good.

Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.

That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.

Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:

1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.

2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.

In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.

(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)

Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.

So:
1) Is this feature something that would be accepted?

2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)

↧

Adding JS/CSS assets in AJAX responses requires 'unsafe-inline' Content Security Policy

December 10, 2019, 3:50 pm
$
0
0

Problem/Motivation

The Content Security Policy module needs to add 'unsafe-inline' exceptions for scripts and styles in order to support AJAX responses (#3100068: Script/style included in AJAX responses blocked without 'unsafe-inline').
This is because CSP blocks script and style elements dynamically added to the page by appending HTML, even if their sources comply with the page's policy.
Since AJAX is widely used, this opens a significant gap in the Cross-Site Scripting protections that Content Security Policy offers.

Proposed resolution

- Add a new Drupal\Core\Ajax\CommandInterface() implementation that serializes an array of assets the calling page needs to add.
- Update \Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor::buildAttachmentsCommands() to use the new command instead of rendering the assets to HTML and using an append/prepend command.
- Update Drupal.AjaxCommands with a new method to execute the corresponding command and add assets in a CSP-safe manner (see https://github.com/jquery/jquery/issues/3969).
- Deprecate \Drupal\Core\Ajax\AddCssCommand, which expects a rendered HTML string.

Remaining tasks

User interface changes

None

API changes

Release notes snippet

↧
↧

Have Remote Image&File&Audio in core media module?

September 11, 2018, 1:47 am
$
0
0

Currently we have "Remote Video" media support available for the remote content to be displayed..

What are the possibilites of having Remote Image, File & Audio media support ?? (just a thought, this helps to drop all heavy files outside the main request/response server of site..)

↧

Missing hash in attributes key in Seven (another one)

December 6, 2019, 7:37 pm
$
0
0

Very similar to this issue #3094397: Attributes key missing hash or pound sign in seven, it appears another hash is missing in the same file (seven.theme), a few lines down. When attempting to add a remote video to a field, User error: "0" is an invalid render array key in Drupal\Core\Render\Element::children() was showing up the dblog several times.

Adding the hash here $form['#attributes']['class'][] = 'media-library-add-form--oembed'; stopped the error from appearing.

Steps to reproduce:
On a Drupal 8.8 site, create an entity reference field (media) that allows remote video. Add the field to a content type. Create a node of that content type and attempt to add a remote video to the field you made. Look at the dblog to see the error.

What behavior were you expecting?
I was expecting there to be no errors in the dblog.

What happened instead?
Several php errors appear in the dblog every time an attempt is made to add a remote video to this field.

I have a patch that adds the missing hash.

Edited to add: this is the first time I've created a patch and am clearly getting the comment numbers wrong. If this is an issue, please let me know and I can fix.

↧
Search

drupal_get_query_array() does not urldecode query names

September 18, 2017, 10:07 am
$
0
0

If a query parameter name is urlencoded (as it should), drupal_get_query_array() does not urldecode it.

This bug was long time partly compensated by drupal_http_build_query() not urlencoding query parameter square brackets, which was fixed in #2289867: [D7] W3C HTML5 Validation error with PHP array-based query-strings built with url() containing [ ] characters.

Said fix now leads to a regressions when modules rely on drupal_get_query_array(drupal_http_build_query($x)) === $x. Most notably views, see #2909709: Links to entity URIs with special characters in query parameter names are broken, especially since Drupal core 7.55 and the code snippet there. Prio major as this breaks existing sites, especially when they work with faceted search urls which contain query parameter names like "f[0]".

↧

Implementations of getAvailableContexts should return available contexts without values

December 10, 2019, 6:12 pm
$
0
0

Implementations of \Drupal\Core\Plugin\Context\ContextProviderInterface::getAvailableContexts should only return available context. Implementations shouldn't return context values, which lead to #3099968: Layout builder incorrectly resolves global contexts values when viewing layouts.

In addition, magic $unqualified_context_ids = empty array is an undocumented hack implemented by some contexts, and should be removed.

Patch is likely to fail until this #3099968: Layout builder incorrectly resolves global contexts values when viewing layouts is fixed.

Applies to:

  • CurrentUserContext
  • CurrentLanguageContext
  • others tbd
↧
↧

Updated NodeRouteContext to work with layout builder

December 10, 2019, 6:15 pm
$
0
0

Context should be updated so it is capable of responding on layout-builder builder routes.

A similar exception should be devised to how it currently responds on node-add routes.

↧

FieldConfigBase does not store constraints

August 31, 2017, 6:05 am
$
0
0

Problem/Motivation

\Drupal\Core\Field\FieldConfigInterface::addConstraint()'s docs say:

   * Note that constraints added via this method are not stored in configuration
   * and as such need to be added at runtime using
   * hook_entity_bundle_field_info_alter().

This means it's required to have a module to add a constraint (because you need a module to implement that hook). It's also rather misleading.

Similar problems have been fixed in #2247085: Constraints cannot be added to configurable fields and #2541228: FieldConfigBase::setPropertyConstraints() and addPropertyConstraints() are broken.

Proposed resolution

It should be possible to add constraints via FieldConfig config entities and have those constraints be stored.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

FieldConfig config entities now store constraints.

↧

What is the Page Title Block?

December 7, 2019, 11:23 am
$
0
0

First I need to clarify that the Page Title Block is being used properly. What is the difference between the Page Title Block and standard Title Field in a node content type?

After testing Page Manager, Display Suite and Switching themes. The Page Tile Block value does not show up anywhere.

I've placed the Page Title Bock within different field groups to display but nothing shows up.

I've tested several settings for the block and still nothing. The only thing that would show on a display is the Page Title label.

I am using a Drupal 8.8/Thunder setup.

↧
Viewing all 295674 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>