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

Extracting update text with update_get_update_list() should handle all line endings

$
0
0

Problem/Motivation

We are developing on windows and due to the default setting of git's core.autocrlf = true setting all line endings are handled by git.
This comes from GitLab's overall suggestion to setting up like this.
composer will checkout with git's cli if you are using dev-master version constraint.

So if you are using drush to make the database updates on windows with cygwin the table output is printed a little bit slipped.
First I thought it is related to drush, but moshe showed me the right code base where it happens. Thanks for this!

https://github.com/drupal/drupal/blob/9.2.x/core/includes/update.inc#L40...

// The description for an update comes from its Doxygen.
$func = new ReflectionFunction($module . '_update_' . $update);
$patterns = [
  '/^\s*[\/*]*/',
  '/(\n\s*\**)(.*)/',
  '/\/$/',
  '/^\s*/',
];
$replacements = ['', '$2', '', ''];
$description = preg_replace($patterns, $replacements, $func->getDocComment());
$ret[$module]['pending'][$update] = "$update - $description";

I think we could easily fix that by normalizing the line endings before extracting the description text.

// The description for an update comes from its Doxygen.
$func = new ReflectionFunction($module . '_update_' . $update);
$patterns = [
  '/^\s*[\/*]*/',
  '/(\n\s*\**)(.*)/',
  '/\/$/',
  '/^\s*/',
];
$replacements = ['', '$2', '', ''];
$description = preg_replace('/\r\n|\r/', "\n", $func->getDocComment());
$description = preg_replace($patterns, $replacements, $description);
$ret[$module]['pending'][$update] = "$update - $description";

What do you think?

Steps to reproduce

Requirement: The doc comment of the hook_update_N or other update type has to have crlf line endings

  1. drush updb -y

Proposed resolution

Normalize line endings via another preg_replace() in update_get_update_list()
Found that solution on TestDiscovery in Core: https://github.com/drupal/drupal/blob/9.2.x/core/lib/Drupal/Core/Test/Te...

Remaining tasks

  • Review
  • Commit

User interface changes

Improved CLI table output via drush

I can elaborate on this with a merge request if you want.


Mark as many 3rd party JS library as possible as internal

$
0
0

Problem/Motivation

We're trying to reduce the number of libraries core uses, and reduce the API surface we're providing for contrib/projects. A few libraries can be marked as internal as we don't expect contrib to use or extend them.

Steps to reproduce

Proposed resolution

Generalize what we did with backbone in #3258931: Deprecate backbone and tag it internal:

  1. deprecate core/<library>
  2. create a new core/internal.<library> definition
  3. replace all uses core/<library> with core/internal.<library>
  4. update the vendor-update script

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[meta] How do we approach core/drupal.ajax divorcing from jQuery?

$
0
0

Problem/Motivation

Efforts are underway to remove jQuery from core: #3052002: [meta] Replace JQuery with vanilla Javascript in core
The functionality in ajax.es6.js seems particularly tricky to separate from jQuery. It seems unlikely it could be accomplished in the scope of a single issue, so this is going to be a meta.

Removing the dependency on the jquery-form library seems like a priority. It's possible the jQuery removal efforts won't complete before it becomes necessary to update to jQuery 4. There's no guarantee that jquery-form will work with jQuery 4, particularly since the library already officially states "Partially compatible with jQuery 3".

Steps to reproduce

Proposed resolution

  • Figure out the best way to approach un-jQuerying Drupal core ajax. Consider things like deprecating specific functionality, using modern libraries to achieve equivalent results, see what can be converted to simple Vanilla JS now that ES6 does cool stuff that wasn't available when core/drupal.ajax was built.
  • Create issues

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Set up a formal process for ensuring JavaScript dependencies remain up to date

$
0
0

Problem/Motivation

At the moment, the process for keeping JavaScript dependencies up to date is informal and dependent on individual contributors ensuring that updates have been applied on time. Ideally we would have processes in place for getting notified of security vulnerabilities in the dependency tree, and a step to make sure that dependencies get updated prior to every release to make (patch, minor and major). This would make sure that if an individual contributor is not available, the team would still be responsible for ensuring that updates have been applied on time.

For context, the total dependency tree at the moment is over 3000 packages meaning that updates are happening at a high frequency. Preparing to a new release should likely include multiple check points where lates updates get applied.

Proposed resolution

Remaining tasks

Release notes snippet

Deprecate core/scripts/js/babel-es6-build.js for removal from 10.0.x

$
0
0

Problem/Motivation

Based on discussion during Drupal Dev Days between @lauriii, @nod_, and @justafish, the build tooling is no longer needed in Drupal 10 due to wide enough support for ES6 features in browsers. However, the tooling is used widely by contrib ecosystem even though it was never designed for that use case, and was explicitly marked as internal.

Proposed resolution

Deprecate core/scripts/js/babel-es6-build.js for removal from 10.0.x

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The JavaScript ES6 build process is removed given that all browsers supported by Drupal Core are now ES6 compatible. This means that once the build tooling is removed from Drupal 10, core developers are no longer required to run the commands when they make changes to core JavaScript. This also means that babel/core and all related dependencies will no longer be included as core development dependencies.

[PP-1] Remove Internet Explorer 11 polyfills

$
0
0

Postponed on #3263823: Deprecate drupal libraries which are related to Internet Explorer 11 polyfills which are supposed to be removed in D10, these should be deprecated in 9.4.x before they are removed from 10.0.x

Problem/Motivation

Drupal 10 will drop support for Internet Explorer 11: #3155358: [policy, no patch] Drop IE11 support from Drupal 10.0.x. Drupal ship with number of polyfills to accommodate JScripts lack of modern features supported by other JavaScript engines.

Proposed resolution

Based on comments in the core/misc/polyfills files, it seems like all of the polyfills in that folder could be deleted. On top of that, we have couple of polyfills in package.json. From the package.json, we could remove following packages:

  • core/css.escape
  • core/drupal.array.find
  • core/drupal.nodelist.foreach
  • core/es6-promise
  • core/picturefill
  • core/drupal.element.closest
  • core/drupal.element.matches
  • core/drupal.string.includes
  • postcss-calc
  • #3272425: Remove Details Aria Polyfill - this is broken out because it needs extensive screen reader testing

Remaining tasks

Complete the issue where these libraries are deprecated in 9.4.x
👉 #3263823: Deprecate drupal libraries which are related to Internet Explorer 11 polyfills which are supposed to be removed in D10

Simply remove these in 10.0.x. We confirmed there is no error if a polyfill is removed even if a module/theme continues to list them as a dependency. The deprecations are available in 9.4 for those who require supporting IE11 etc and have to manually add support that D10 no longer includes.

User interface changes

API changes

Data model changes

Release notes snippet

Add svg image support for ckeditor 5

$
0
0

Currently, Drupal 9.3.13 ckeditor 5 does not support SVG Images to upload.

InvalidArgumentException: Source path has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() line 186 of core/lib/Drupal/Core/Path/AliasManager.php

$
0
0

I have updated the Drupal core version 8.5.5 to 8.6.13.
I am trying to access config > System > Basic site settings (admin/config/system/site-information) it is getting the below error.

The website encountered an unexpected error. Please try again later.InvalidArgumentException: Source path has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 186 of core/lib/Drupal/Core/Path/AliasManager.php).

Drupal\system\Form\SiteInformationForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 518)
Drupal\Core\Form\FormBuilder->retrieveForm('system_site_information_settings', Object) (Line: 275)
Drupal\Core\Form\FormBuilder->buildForm('system_site_information_settings', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 119)
Drupal\cdn\StackMiddleware\DuplicateContentPreventionMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

  1. Clean Drupal installation
  2. Go to admin/structure/block, edit any (for example: Search) block that appears on the frontpage
  3. Go to pages tab and set /user/* and click "Show for the listed pages"
  4. Go to your.site/index.php.php
  5. There is an exception: InvalidArgumentException: Source path .php has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 229 of core/lib/Drupal/Core/Path/AliasManager.php).

JSON:API module does not support POSTing dynamic entity references with only `type`, `id`/entity reference field does not validate type when setting with entity property

$
0
0

Problem/Motivation

There are a few existing issues (added as related) dealing with core/json:api module's assumption that entity references are, basically, always "core" entity references which can only target a single entity type. The denormalization performed in the top-level JSON:API normalizer does what amounts to early denormalization of this data and deprives field normalizers (or Extras field enhancers) sufficient information about the reference to accomodate for other entity type targets. E.g., Dynamic Entity Reference needs to set entity_type in addition to target_id.

Interestingly, we are dangerously close to actually supporting this, in so far as the target entity type is identifiable by its public json:api name, which is how these entities actually pass initial validation and are loaded up to get their target IDs.

You can post DER data by specifying the target_type in meta, however this is unnecessary as it effectively duplicates the type member of the relationship identifier object and requires the client to know about this drupalism (and potentially expose your internals.) See #2888553: Handle denormalizing meta payload in relationships where this pattern was introduced.

Note that there is #3027430: [PP-2] Dynamic Entity Reference normalization support and others which address the normalization/querying side, but AFAICT simple reporting of DER field data "works", and there may be some quirks with querying (particularly as it releates to included data and filtering by relationships) but there are no open issues for the create/update denormalization side of the coin.

Steps to reproduce

Try to post just a relationship with type and id to a DER field.

Proposed resolution

Load up what I'm referring to as the "early denormalized" value array for entity references with the entity type; this should be a no-op for the core ER field but will provide DER with what it needs (and any other field doing something similar.)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

DX: Log warning in development when TemporaryQueryGuard disallows a filter

$
0
0

Problem/Motivation

I've now run into this issue on more than one occasion and the underlying cause is mysterious/rare enough that I think we should improve the DX.

Steps to reproduce

Try to perform a json:api collection query on an entity that does not implement any of published, status, or owner entity keys.

OR

The entity being queried does implement one of those entity keys, but the module providing the entity type does not implement hook_jsonapi_entity_filter_access() or hook_jsonapi_ENTITY_TYPE_filter_access() to provide the "known subset" access levels.

In that case, the query guard runs ::alwaysFalse() which adds a "weird looking" condition that is always false. You get an empty set with no explanation in the response payload.

Proposed resolution

We should do some logic in an assert() (similar to the json validation against the json:api spec) that notifies the developer that they got an empty response due to the query guard denying the filtering. This might be intended, but many times it's not and this is a real Drupal WTF in the meantime.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

JsonApiDocumentTopLevelNormalizerTest::generateProphecies called with extra arguments

$
0
0

Problem/Motivation

JsonApiDocumentTopLevelNormalizerTest::generateProphecies($entity_type_id, $bundle) is called with an extra argument quite a few times. Those need to be removed.

Example:

[$request, $resource_type] = $this->generateProphecies('node', 'article', 'uid'); 

should be 

[$request, $resource_type] = $this->generateProphecies('node', 'article');

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Remove dead code from JsonApiDocumentTopLevelNormalizerTest

$
0
0

Problem/Motivation

Follow up #2922121: When fetching related resources, getResourceType() in CurrentContext gets the wrong resource type. to remove

$this->markTestIncomplete('This fails and should be fixed by https://www.drupal.org/project/drupal/issues/2922121');

from \Drupal\Tests\jsonapi\Kernel\Normalizer\JsonApiDocumentTopLevelNormalizerTest::testNormalizeRelated.

Steps to reproduce

Proposed resolution

Remaining tasks

Patch
Fix test
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Drupal.behaviors.formSingleSubmit method name should be case-insensitive

$
0
0

Problem/Motivation

Webform adds a $form['#method'] ('get') in lowercase, and this then is not matched by Drupal.behaviors.formSingleSubmit 'form:not([method~="GET"])' javascript. Thus cannot be submitted twice.
The lowercase method name could also be set via form alterations etc.

Proposed resolution

The single submit form selector should be case insensitive.

Remaining tasks

Needs JS tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Views' User Name exposed group filter validation

$
0
0

Problem/Motivation

When adding an exposed and grouped user_name filter, the value doesn't validate correctly. It issue stems from the entity reference autocomplete field handling values using the target_id key, and loaded entities.

This is exactly the same issue as reported in #2576927: Grouped exposed taxonomy filter fails validation for autocomplete widget. Please check it out for more details.

Other changes applied in the merge request are just allowed new tests to pass. There were 2 issues:
1) Default value of the filter was trying to be processed twice but failed with the exception. More information is in duplicated issue: #3250352: Username views filter should not process default value twice . Fixed in this commit: https://git.drupalcode.org/project/drupal/-/merge_requests/1445/diffs?co...
2) There was a PHP notice in \Drupal\user\Plugin\views\filter\Name::validateExposed method, that was fixed in this commit: https://git.drupalcode.org/project/drupal/-/merge_requests/1445/diffs?co...

Steps to reproduce

  1. Install Drupal with "Standard" profile
  2. Open content view (/admin/structure/views/view/content)
  3. Add an exposed grouped filter by "Authored by" (User). Make sure the group item is using autocomplete widget
  4. Add at least one item to the group configuration (e.g. "admin")
  5. Submit

Proposed resolution

Apply the same fix and test coverage as in #2576927: Grouped exposed taxonomy filter fails validation for autocomplete widget. Also, make additional fixes to let tests pass.

Remaining tasks

Review, commit.

There are no User interface, API or Data model changes.

Remove Modernizr


Move QuickEditImageController from image to quickedit

$
0
0

Problem/Motivation

#3227033: [PP-3] Remove quickedit from core is trying to remove quickedit from core. Before we can do that, we need all of its parts moved under the quickedit module, instead of having integrations sprinkled throughout the rest of core. \Drupal\image\Controller\QuickEditImageController needs to move from image to quickedit and be refactored.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[Backport] Add extra test coverage for operators of views date filters

$
0
0

Problem/Motivation

The original report in this issue was about incorrect validation on adding grouped filter by date field with "Is empty(NULL)" or "Is not empty(NULL) operator:

steps to reproduce the problem:
1. edit view, add a filter which field type is date
2. select "Expose this filter to visitors, to allow them to change it"
3. select "Grouped filters"
4. in the group options, select "Is empty(NULL)" or "Is not empty(NULL) as operator
5. input a label for this options
6. Click "Apply (all displays)" button, will cause this issue: "The value is required if title for this item is defined. "
issues
The problems:
"Is empty(NULL)" or "Is not empty(NULL) operator do not need input value, and could not input value, but the group options validator will check it, so could not setup the label for date filter group options.

However, it's not possible to reproduce at this moment. See #8 and #16.

Given the test coverage for mentioned operators is missing, there is a proposal to add extra test coverage for exposed date filters operators, which are using different values. It'll prove that available operators pass the validation and work as expected.

Proposed resolution

Add additional asserts to check that date filter operators, that uses different value properties.

Here is a list of possible variations:

OperatorsExpected values
<, <=, =, !=, >=, ><code>value
between, not between<code>min, max
empty, not empty-

It should be enough to cover at least 1 operator from each row.

Table displaying on mobile

$
0
0

When we have long element in table they are cut off on tablet/mobile resolution.

Roadmap to CKEditor 5 stable in Drupal 9

$
0
0

This lays out what remains to be done after #3231364: Add CKEditor 5 module to Drupal core lands in Drupal core.

This plan was originally taken from the IS at #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10, and after that from #3201824: Roadmap to core.

Roadmap to Stable

  1. Ensure that sites can update from using CKE4 to CKE5 safely when using no contributed CKEditor modules
    1. #3247634: [PP-1] [upstream] [drupalImage] Unlinking linked inline images while GHS is enabled: wrapping <a> is impossible to remove
    2. #3268306: [upstream] [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar>
    3. #3271418: [PP-1] [upstream] [drupalMedia] Linked media wrapped with <div> doesn't upcast correctly
    4. #3274651: Impossible to enable <ol type> or <ul type> with GHS
    5. #3276217: [drupalMedia] GHS attributes are not retained in linked media
    6. #3273983: Do not assume that plugin supporting <tag attr> also supports <tag> in SourceEditingRedundantTags and upgrade path
  2. ✅ Ensure contrib modules can do everything: translations, automatic upgrade path from CKE4 …
    1. Currently none
  3. ✅ Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup: #3222801: [META] Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup
    1. Currently none
  4. Ensure CKE5 functionality matches that of Drupal core's CKE4:
    1. #3222756: [upstream] Allow using images from external source
    2. #3222797: Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style
    3. #3274937: Get CKEditor 5 to work in (modal) dialogs
  5. ✅ Documentation gates:
    1. Currently none
  6. ✅ Theming CKEditor 5
    1. Currently none
  7. ✅ Accessibility
    1. Currently none
  8. Test coverage, reliability and maintainability matching or exceeding CKEditor 4's:
    1. #3247683: Disable CKEditor 5's automatic link decorators (in Drupal filters should be used instead) + explicitly test manual link decorators
    2. #3268983: [regression] FilterHtml throws Unsupported operand types error when * used in tag attribute
  9. ✅ Low-hanging fruit major UX improvements over CKEditor 4:
    1. Currently none
  10. Superior configuration UX:
    1. #3245967: Messages upon switching to CKEditor 5 are overwhelming
  11. ✅ Performance
    1. Currently none.

Roadmap after Stable

  1. Upstream Drupal improvements that would simplify or improve CKEditor 5:
    1. #3226673: API addition: \Drupal\editor\Plugin\EditorPluginInterface::getDefaultSettings() should accept old Editor + Format to generate smart defaults
    2. #3230829: editor_form_filter_format_form_alter() does not remove "editor_plugin" from form state when needed
    3. #3231322: Fix a @todo: move a form alteration to the CKEditor 5 plugin's subform definition
    4. #3231341: Deprecate EditorLinkDialog and EditorImageDialog in Drupal 9, remove in Drupal 10
    5. #3231342: Introduce ConfigEntityForm to standardize use of validation constraints for config entities
    6. #3231347: Add Editor::setFilterformat()
    7. #3231354: [META] Discuss: merge the Editor config entity into the FilterFormat config entity
    8. #3246260: [PP-1] Simplify CKEditor5ImageController once #2940383 lands
    9. #3263668: [PP-1] Re-enable inline form errors in assessActiveTextEditorAfterBuild function→ blocked on Vertical Tabs bug: #2911932: Correct vertical tab does not focus on form validation
    10. #3269101: [PP-1] Ensure enabled CKEditor 5 plugins remain available by calculating corresponding dependencies→ blocked on Text Editor module bug: #2950795: CKEditor 4+5 plugin module dependency not added to text format configuration
  2. Obsoleteness of upgrade path in Drupal 11:
    1. #3239012: [late 2023] Deprecate the upgrade path from CKEditor 4
  3. Performance:
    1. #3224261: [PP-2] Front-end performance: concatenate CKEditor 5 JS assets for every unique configuration
  4. Media improvements
    1. #3196593: Ease the transition to Media: save image uploads in CKEditor 5 as media entities when media is enabled? (or module specific solution if core issue won't land)
    2. #3073901: Determine an upgrade path from CKEditor image button to media library (or module specific solution if core issue won't land)
  5. Low-hanging fruit major UX improvements over CKEditor 4:
    1. #3227354: Add support for ckeditor5-autoformat
    2. #3274635: [PP-2] Use CKEditor 5's native <ol type> and <ul type> UX
  6. Superior configuration UX:
    1. #3225033: Whenever "Enable image uploads" is enabled for a text editor, the editor_file_reference filter should be enabled
    2. #3227948: Hide incompatible filters
  7. Maintainability:
    1. #3248432: [drupalImage] Split DrupalImageEditing into multiple plugins
    2. #3273746: Move media-embed-error class styling from core themes to CKEditor 5
    3. #3275237: Don't convert, instead use response.entity_type in DrupalImageUploadEditing

Completed

This section mimics the structure of the above sections.

💯 Roadmap to Alpha

  1. ✅ Create the ckeditor5 module
  2. ✅ Create an @Editor PHP plugin with the ID ckeditor5.
  3. ✅ Create a Drupal.editors JS plugin with the ID ckeditor5.
  4. ✅ Getting CKE5 (CKEditor 5) to load at all on the /node/add/article form.
  5. #3201820: Manually test that CKE 5 can be used in off-canvas
  6. ✅ Enable a Drupal + CKE5 ecosystem
    1. #3196178: Provide test module to verify contrib can extend CKEditor5
    2. #3200008: Validation and editor settings
  7. ✅ A CKE5 configuration UI
    1. #3198297: Toolbar UI for selecting and sorting buttons
  8. ✅ Ensure Quick Edit integration works
    1. #3201648: Add test coverage for Quick Edit integration
    2. #3205090: Field html not restored when cancelling Quick Edit
  9. ✅ Evaluate CK4 plugins and match features
    1. #3194650: Support media elements and browse media library
    2. #3194111: Support inline image upload
    3. #3201646: Add support for image caption (<img data-caption>)
  10. #3201821: Add JavaScript test coverage for CKE 5
  11. #3206686: IE11 warning for CKE5 in Drupal 9

💯 Roadmap to Beta

  1. #3215506: Plugins should be enableable based on toolbar configuration
  2. ✅ Ensure filter_html's HTML restrictions are respected inside CKE5 — tackled in #3201637: Figure out how to prevent data loss during upgrade/migration path
  3. #3206687: Toolbar UI accessibility review
  4. #3201641: Improve the HTML filter configuration UX
  5. Enable translation features for CKEditor 5
    1. #3202664: CKEditor 5's UI language should match Drupal's interface translation

Roadmap to Stable

  1. Ensure that sites can update from using CKE4 to CKE5 safely when using no contributed CKEditor modules
    1. Ensure that Arbitrary HTML is not lost: #3216021: Automatically use CKE5's General HTML Support feature on text formats without any TYPE_HTML_RESTRICTOR filter + add `sourceEditing` button
    2. #3201637: Figure out how to prevent data loss during upgrade/migration path
    3. #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration
    4. #3245079: Automatic upgrade path always enables all <h*> tags when only >=1 was enabled before
    5. #3245320: Automatic upgrade path always disables image uploads — in the UI
    6. #3228464: API for contrib projects to load CKEditor translations
    7. #3227822: [GHS] Ensure GHS works with our custom plugins, to allow adding additional attributes
    8. #3268174: Bug in CKE 4 → 5 upgrade path "format" does not always map to "heading", it could map to "codeBlock" too, or both, or neither
    9. #3269868: [drupalImage] Some Image attributes are lost in edge cases where image upcasts into inline image
    10. #3273527: Upgrade path never configures the ckeditor5_heading plugin to allow <h1>
    11. #3273312: Upgrading from CKEditor 4 for a text format that has FilterInterface::TYPE_MARKUP_LANGUAGE filters enabled
    12. #3268318: [drupalMedia] <a> with GHS allowed attributes downcast wraps data-caption with <a>
    13. #3230230: Enable table captions; override CKE5's default downcast to generate <table><caption></table> instead of <figure><table><figcaption></figure>
    14. #3268311: [upstream] [drupalMedia] GHS-enabled markup in data-caption crashes CKEditor 5
    15. #3272516: Deprecate FilterInterface::getHTMLRestrictions()' forbidden_tags functionality
    16. #3273510: CKEditor 5 crash when multiple alignment buttons are activated due to duplicate configuration thanks to #3259593: Alignment being available as separate buttons AND in dropdown is confusing
  2. Ensure contrib modules can do everything: translations, automatic upgrade path from CKE4 …
    1. #3226335: Follow-up for #3216015: allow contrib & custom Drupal modules providing CKEditor 4 plugins to specify their CKEditor 5 equivalents + settings to be migrated
    2. #3228778: Drupal-specific CKEditor 5 plugins should be able to use Drupal's JS translation API: Drupal.t()
    3. #3245723: Follow-up for #3201637: omitting PrimitiveTypeConstraint violations for filter settings is implemented too broadly
    4. #3245807: DX: allow contrib modules to subclass \Drupal\Tests\ckeditor5\Kernel\ValidatorsTest
    5. #3274278: Migrate "codetag" contrib CKEditor 4 plugin to built-in equivalent in core's CKEditor 5
    6. #3273325: CKE5 and contrib: better "next action" description on upgrade path messages
  3. Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup: #3222801: [META] Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup
    1. Infra: #3215466: Attribute values not accounted for in CKEditor5PluginManager::getProvidedElements
    2. Infra: #3207660: Allow using a subset of the tags supported by the enabled CKEditor 5 plugins
    3. #3222851: <cite>
    4. #3222847: <img width height>
    5. #3222838: Configure basicStyles.Italic to output <em> instead of <i>
    6. #3222842: <a hreflang> + <blockquote cite>
    7. #3222847: <img width height>
    8. #3220293: Make all supported heading types visible in the UI
    9. #3222840: <ol start>
    10. #3222852: <dl> <dt> <dd> by introducing "Manually editable HTML tags" configuration on Source Editing
    11. #3224256: <h* id> (or more generically: <$block id>)
    12. #3222808: Follow-up for #3201646: markup in image captions is lost
    13. #3228346: Follow-up for #3222852: revert ineditable attributes (<blockquote cite> and <a hreflang>) now that Source Editing plugin can handle arbitrary elements & attributes
    14. #3246168: Images are not linkable through UI; already linked images are unlinked (data loss!)
    15. #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!)
    16. #3259493: [GHS] Unable to limit attribute values: ::allowedElementsStringToHtmlSupportConfig() does not generate configuration that CKEditor 5 expects
    17. #3246365: [drupalMedia] Show the Image Media's default alt text that is being overridden
    18. #3260853: [GHS] Partial wildcard attributes (<foo data-*>, <foo *-bar-*>, <foo *-bar>) and attribute values (<h2 id="jump-*">) not yet supported
    19. #3260869: Resolve mismatch between <$block> interpretation by CKEditor 5 and Drupal
    20. #3268860: Elements wrapping <drupal-media> are not retained
    21. #3268307: $block wildcard resolves into a superset of the actual $block tags
  4. Ensure CKE5 functionality matches that of Drupal core's CKE4:
    1. #3201646: Add support for image caption (<img data-caption>)
    2. #3211050: Add "Alignment" plugin
    3. #3211125: Add "Block Indentation" plugin, but only allow list indentation
    4. #3211282: Add plugins which are provided as a part of essential plugin: Undo/Redo
    5. #3211610: Add "Horizontal line" plugin.
    6. #3227871: Add ckeditor5-paste-from-office to allow pasting from Microsoft Office & Google Docs
    7. #3227875: Add ckeditor5-remove-format to allow removing formatting from pasted content
    8. #3227890: Add ckeditor5-special-characters to allow inserting special characters for users that do not know the native picker
    9. #3247246: Attribute value encoding not compatible with Xss::filter()
    10. #3248448: Dialog loading text is unstyled
    11. #3260554: [drupalMedia] Support alignment on <drupal-media>
    12. #3246380: [drupalMedia] Media previews do not update after alt text was modified
    13. #3224652: [drupalImage] Add ckeditor5-image's imageresize plugin to allow image resizing
    14. #3246385: [drupalMedia] Support captions on <drupal-media>
    15. #3264775: [drupalMedia] Toolbar should be visible when element inside <drupalMedia> is focused
    16. #3264727: [drupalMedia|drupalImage] Allow removing data-align in the UI, and making an image inline
    17. #3245950: [upstream] <script> tag support in GHS
    18. #3256566: [upstream] <style> tag support in GHS
    19. #3263384: Add ckeditor5-code-block package and CodeBlock plugin
    20. #3245720: [drupalMedia] Support choosing a view mode for <drupal-media>
    21. #3276974: [drupalMedia] Media View Modes don't work if alignment not enabled
    22. #3269657: [drupalMedia] The CKEditor 4 → 5 upgrade path for the media_embed filter should not forcefully allow the `data-view-mode` attribute on `<drupal-media>`
  5. ✅ Documentation gates:
    1. #3205654: ckeditor5_hook_help()
    2. #3201186: Create ckeditor5.api.php (the core equivalent of README.md) + CKEditor5PluginDefinition::toArray()
    3. #3243850: hook_ckeditor5_plugin_info_alter()'s example sets ['drupal']['config'], but that's not one of the documented definition properties
    4. #3248430: Improve Drupal.ckeditor5 documentation
    5. #3248425: Ensure that all classes and functions in Drupal-specific CKEditor 5 plugins are documented
  6. Theming CKEditor 5
    1. #3202666: Follow-up for #3198297 Improve admin CSS DX
    2. #3194084: Support functionality equivalent to ckeditor_stylesheets
  7. Accessibility
    1. #1872206: Improve CKEditor toolbar configuration accessibility
    2. #3218252: Toolbar configuration fieldset aria cleanup
    3. #3218260: Safari focus outline on buttons leaves artifacts after blur
    4. #3207451: Toolbar UI Button size accessibility
    5. #3238257: Fragment link pointing to <textarea> should be redirected to CKEditor 5 instance when CKEditor 5 replaced that textarea
    6. #3245735: Follow-up for #3222852: validation errors are not associated with the correct form element
    7. #3258030: Text fields using CKEditor 5 do not get visual error indicator
    8. #3258668: Extraneous closing parentheses and curly brace in visually-hidden button description text
    9. #3231321: Improve keyboard accessibility in a particular edge case
    10. #3261942: Compatibility issues with inline form errors
    11. #3218297: Voiceover + Safari reads aria-describedby twice when focusing toolbar button
    12. #3248440: [drupalMedia] Media embed attributes are rendered in container div in editing view
    13. #3239423: Toolbar UI accessibility review: round 2
    14. #3270112: Excessive aria-live announcing from ckeditor5-admin-help-message live region
    15. #3270110: Toolbar config items missing "press arrow to do {x}" instructions for screenreaders
    16. #3270108: Editor does not load when using Edge + WHCM
    17. #3222757: [drupalImage] Make image alt text required or strongly encouraged
  8. Test coverage, reliability and maintainability matching or exceeding CKEditor 4's:
    1. #3206522: Add FunctionalJavascript test coverage for media library
    2. #3201641: Improve the HTML filter configuration UX
    3. #3228920: Improve internal consistency: consistent variable names and return type syntax
    4. #3231327: Plugin definition DX: validate ckeditor5.drupal.elements items
    5. #3231362: Refactor ImageUpload's ::validateImageUploadSettings() into the proper validate and submit methods
    6. #3228505: Plugin definition DX: automatically check for plugin definitions whether their ::getDefaultSettings() matches the config schema
    7. #3243867: ckeditor5_module_implements_alter() looks like it has incorrect logic
    8. #3245400: Add an @throws PHPDoc everywhere exceptions are thrown
    9. #3246280: Defense in depth: add anti-CSRF token to this module's routes
    10. #3246521: Make plugin.manager.ckeditor4to5upgrade.plugin a private service
    11. #3246524: Make more (all?) classes @internal
    12. #3247711: Simplify and accelerate builds: update our use of the CKEditor 5 DLL manifest
    13. #3248188: Plugin definition DX: validate drupal.conditions
    14. #3248423: Decide how CKEditor 5-provided types should be referenced
    15. #3259174: Add missing CKE5 SmartDefaultSettings test coverage (wildcard tag with unsupported attribute)
    16. #3228334: Refactor HTMLRestrictionsUtilities to a HtmlRestrictions value object
    17. #3206523: Add FunctionalJavascript test coverage for image upload
    18. #3267721: Add DrupalCI step for ensuring that CKEditor 5 build files are build correctly
    19. #3231337: [drupalMedia] Remove manual dataDowncast from DrupalMediaEditing
    20. #3231328: SmartDefaultSettings should select the CKE5 plugin that minimizes creation of HTML restriction supersets
    21. #3228580: Follow-up for #3222852: additional test coverage for real-time validation race conditions
    22. #3265626: Changes to "Manually editable HTML tags" lost if form is submitted without triggering AJAX
    23. #3231334: Global attributes (<* lang> and <* dir="ltr rtl">): validation + support (fix data loss)
    24. #3229078: Unit tests for all @CKEditor5Plugin plugin classes
  9. Low-hanging fruit major UX improvements over CKEditor 4:
    1. #3261599: Use CKEditor 5's native <ol start> support (and also support <ol reversed>)
  10. Superior configuration UX:
    1. #3201641: Improve the HTML filter configuration UX
    2. #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration
    3. #3226694: Follow-up for #3216015: refactor SmartDefaultSettings to return messages rather than sending them
    4. #3248177: Language toolbar item cannot be removed from the toolbar
    5. #3259443: Plugin settings do not appear when a configurable plugin is added AFTER removing all buttons
    6. #3261585: Remove IE11 warning for CKEditor 5 in Drupal 10, since Drupal 10 does not support IE anyway
    7. #3260857: Expand SourceEditingRedundantTagsConstraintValidator to also check attributes and attribute values
    8. #3261943: Confusing behavior after pressing "Apply changes to allowed tags" with invalid value
    9. #3228691: Restrict allowed additional attributes to prevent self XSS
  11. Performance
    1. #3248469: Research if the CKE off-canvas CSS reset could be optimized
    2. #3264512: Enable aggregation for CKEditor 5 assets
    3. #3260032: CKEditor 5 adds ie11.user.warnings library to every page, triggering a FOUC even for anonymous users
  12. ✅ Moving things into core that can only happen once it is in core:
    1. #3231324: Use core icons where possible after moving to core
    2. #3231325: Use pre-existing filter format config from YAML instead of duplicating it in PHP

Grouped exposed taxonomy filter fails validation for autocomplete widget

$
0
0

Problem/Motivation

When creating exposed grouped filters in a view, if a group is named and using autocomplete widget to add group items (can be taxonomy terms or users), the form throws the error on save:

The value is required if label for this item is defined.

Here is the screenshot of the error:
image 1

The problem behind this is that array of arrays is not recognized here:

$min_values = $operators[$group['operator']]['values'];
$actual_values = count(array_filter($group['value'], 'static::arrayFilterZero'));

In case autocomplete, it has the following data format:

[
  0 => [
    ' target_id' => 1
  ] ,
]

but the code above expects it to be:

[
  1 => 1
]

so it doesn't pass the filtering in static::arrayFilterZero

Affected plugins:

  1. \Drupal\user\Plugin\views\filter\Name (#2920039: Views' User Name exposed group filter validation)
  2. \Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid (this issue)

Steps to reproduce

  1. Install Drupal with "Standard" profile
  2. Open content view (/admin/structure/views/view/content)
  3. Add an exposed grouped filter by "Tags" (Taxonomy). Make sure the group item is using autocomplete widget
  4. Add at least one item to the group configuration
  5. Submit

Proposed resolution

Convert values into array with ids, which is expected by base filter plugin.

Remaining tasks

1) Wait for #1810148: Grouped exposed taxonomy term filters do not work;
2) Review/commit;

Viewing all 296525 articles
Browse latest View live


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