🇦🇺Australia @jannakha

thanks for you contribution!
Tested MR16 - looks good.

Screenshot before patch:

Screenshot after patch:

So my test case is:
I'm moving access checks from hook_ENTITY_TYPE_access into RouteSubscriber.

I've got a custom RouteSubscriber which adds Requirement with '_custom_access' based on user/entity on routes:
$collection->get('entity.node.delete_form')
$collection->get('entity.node.edit_form')

the routes are not accessible when conditions are met - as expected
but on views Edit/Delete operations are visible (although they lead to access denied/error page)

after applying patch #135 (to Drupal 10.4.5) - views operations are displayed as expected (no edit/delete ops when they should not be) just like when access was handled in hook_ENTITY_TYPE_access.
hurray!

what else is required to release this issue?

PS now the issue is "Delete" op appears on "Edit" form when it's forbidden by RouteSubscriber/custom access execution.
If I won't find an existing issue, I'll create a new issue for that. here's existing issue for Media https://www.drupal.org/project/drupal/issues/2998824 🐛 MediaAccessControlHandler update/delete access caching is not correct Needs work

PPS back to hook_ENTITY_TYPE_access for now (unless there are better suggestions?)

Thanks for your contribution!

the failed MR status points to a failed unit test - please fix the test.

@ooa33 - do you mind putting your code as a merge request?

Isn't for accessibility colour/visuals should not be the only difference in the meaning of the links?

GitHub has tags for different releases:
https://github.com/vercel/next.js/releases

Isn't for accessibility colour should not be the only difference in the meaning of the links?

GitHub has tags for different releases:
https://github.com/vercel/next.js/releases

there's a module for it:
https://www.drupal.org/project/recipe_tracker →

+1. Tested and ready to be released.

@lendude exactly! #10 is just treatment of a symptom, not an actual solution to the potentially bigger issue.

If EntityField::buildGroupByForm() is not called, then EntityField::submitGroupByForm() should not be called.
EntityField::submitGroupByForm() expects certain fields to be there (hence the null exception).

I haven't found a reason why EntityField::buildGroupByForm() is not called but EntityField::submitGroupByForm() is called on aggregations like min/max/sum/etc, but when it's default (eg group) both EntityField::buildGroupByForm() and EntityField::submitGroupByForm() are called.

jannakha → changed the visibility of the branch 3513598-typeerror-array_filter to hidden.

jannakha → changed the visibility of the branch 3513598-typeerror-arrayfilter-argument to hidden.

Further investigation of the issue:
- when Use aggregation is on, fields on the view have "Aggregation settings"
- if Aggregation type set to "Group results together" other form options (Group column and Group columns (additional)) are rendered
- if Aggregation type set to Max/Min/etc other form options are not rendered, but they are being processed by submitGroupByForm() in web/core/modules/views/src/Plugin/views/field/EntityField.php
- if Aggregation type set to other than "group" - EntityField::submitGroupByForm() still processes although EntityField::buildGroupByForm() was never called (only HandleBase::buildGroupByForm() is called)

see attached screenshots

jannakha → changed the visibility of the branch 2909372-enable-drupal.commenting.variablecomment.missingvar-coding to hidden.

jannakha → changed the visibility of the branch 2909372-enable-drupal.commenting.variablecomment.missingvar-coding to active.

Patch works as expected and fixes the issue.
+1 for RTBC

I found the order of menu items goes crazy if I update order of menu items in menu management interface: admin/structure/menu/manage/main (if it's your main menu)

If I update the actual structure of taxonomies - then menu renders correctly.

Check your weight values in config: config/sync/default/core.menu.static_menu_link_overrides.yml

I wonder if there should be feature to reset menu items weights based on taxonomy weights.

I tried to reproduce it on 10.4 with taxonomy_menu version v3.7.0 and it works without any errors.
Please update status to Closed (outdated)

works now on php 8.3
thanks for the patch

@veronicaseveryn thanks for patch!
+1 for patch #2

changing priority to critical

Can you please provide more details?
I've tested core.base_field_override.node.mdb_page.promote.yml on 10.4 - I didn't find any issues with export/import.

Here's example of config:

uuid: e1ff4807-ef12-49c0-ac95-2c1100875e5c
langcode: en
status: true
dependencies:
  config:
    - node.type.mdb_page
id: node.mdb_page.promote
field_name: promote
entity_type: node
bundle: mdb_page
label: 'Promoted to front page ok'
description: 'generic description of a field'
required: false
translatable: true
default_value:
  -
    value: 1
default_value_callback: ''
settings:
  on_label: 'On'
  off_label: 'Off'
field_type: boolean

I've tested MR - it looks like it's working with media as required.

I think it still needs more testing - especially for security/permissions.

@torfj - what were your test cases for term permissions?

all good - ready to go Drupal 11!

thanks for your contributions!

gargsuchi → credited jannakha → .

Both MR70 and #20 patches work and fix the issue.

MR70 will require developers to update any custom twig templates.

is it possible to create a merge request out of the patch for review?

1.4.10 is exporting these fields recursively

I found why this issue is happening! (unfortunately, CKEditor is editable by users and they can copy paste things as they please)!

Steps to reproduce:

1. On a content node (article) insert into a text field's CKEditor source (a link to non-existent node):

<a href="/node/21991" target="_blank" data-entity-type="node" data-entity-uuid="30d77877-0000-0000-0000-14589bc25583" data-entity-substitution="canonical"><em><strong>HERE</strong></em></a>

2. Save node
3. Go to Export tab of this node
4. It will crash with same exception
TypeError: Drupal\single_content_sync\ContentExporter::isReferenceCached():

Proposed solutions:
- ignore invalid links, if $linked_entity is NULL don't try to add to $embed_entities
- report an error - link doesn't exist (so users will fix it and then do export)

Users are silly - they'll put all sorts of stuff into text fields, so

I can confirm this issue exists.
I've got the same issue on 1.4.10 (upgraded from 1.4.8 - which worked fine)
doesn't happen on all content types, I'm investigating which field causing the issue

+1 as well. Tested on Drupal 10.4.1 and it works.

+1 RTBC
thanks for your contribution!

Please release :-)

phpunit is green. Good to go.
Manually tested on D11.
+1 for RTBC

Logo looks good.

Test on Drupal 11.
phpstan passes.

jannakha → created an issue.

Looks great and tested on Drupal 11.

Looks good. phpstan is greem and works as expected.
Should create separate issue for CI and phpunit.

Thank you! Committed! 🍻

Looks good as works as expected. Thank you.

+1. Would be good to have security coverage.

Looks great and works as expected.

First settings test added.

jannakha → made their first commit to this issue’s fork.

jannakha → made their first commit to this issue’s fork.

jannakha → made their first commit to this issue’s fork.

works as required.
Thank you for your contributions and support!
Hurray for D11

Tested on Drupal 11. File scanning is working with executable and not allowing to upload the file when execution is disabled.

@smustgrave I think there is some confusion.
D11 compatibility is not fully implemented. File scanner is not working.
Please do phpcs separately once 2.1.0 release is done.

jannakha → made their first commit to this issue’s fork.

+1

jannakha → created an issue.

hook_file_validate() will be replaced with event handler in this task

issue #3423615 was not implemented for this module

tested and works as required

thanks for your contributions!

tested and works as required

works as required
thanks for your contribution

works as required
thanks for your contribution

works as required.
thanks for your contribution

works as required.
thanks for your contribution.

works as required.
thanks for your contribution.

works as required.
thanks for your contribution.

+1 for release please!

looks good
release alpha?

Go Drupal 11!

@octaviosch
patch is on MR - https://git.drupalcode.org/project/simplify/-/merge_requests/8.diff

please review docs on git workflow:
- https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
- https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

After you install patch, please update status of this issue

Changes look good.
Tested.
Ready for release.

Thanks for your contribution!

- error goes away after "Term Merge" module is enabled
- cleaned up taxonomy manager merge library

jannakha → made their first commit to this issue’s fork.

Please don't put multiple issues into a same ticket - it makes it hard to test and review:
- new permissions structure
- add pagination on 'admin/structure/taxonomy_manager/voc' page

When status of ticket goes into "needs review" please provide screenshots and pages to be reviewed

see comments on MR

basically:
config has Editor has create permissions:

Running debug shows different values for different ways of testing permissions:

$taxonomy_vocabulary->access('create') is buggy
see https://www.drupal.org/project/drupal/issues/2886800 🐛 EntityAccessControlHandler::createAccess() and EntityAccessControlHandler::access() return false positive cache hits because it ignores context Needs work

- added extra library to JS from CDN
- requires https://www.drupal.org/project/taxonomy_manager/issues/3046752 🐛 AJAX error when editing term content Postponed: needs info patch #31 (MR49) to work correctly (which includes https://www.drupal.org/project/taxonomy_manager/issues/3474919 🐛 Form element taxonomy_manager_tree broken Active )

jannakha → made their first commit to this issue’s fork.

https://www.drupal.org/project/taxonomy_manager/issues/3046752 🐛 AJAX error when editing term content Postponed: needs info is required for any ajax requests to work

created a patch from MR (it's merged with #3474919)
make sure library/jquery.fancytree contains all JS - see #3467549 ✨ Change require custom libraries to suggestions as a better method with more options Needs work

jannakha → made their first commit to this issue’s fork.

tested MR2 - issue is fixed.

thanks for your work!

tested.
thanks for your work!

check your config has been updated by re-running block_class_update_20017()
this update transformed config from string to json and if your config is old block_class will keep crashing

+1 for patch #13 works on 10.3.10

thanks for the patch!

can someone review?
it'll be nice to get a release with this feature

created patch out of MR4 @ c3e20aa2

just for future, let's not scope creep issues: add to wish list is totally independent from add to cart AJAX and could've been its own MR

@anas_maw - can you expand on your comments on your patch? what should be done with it?
@luksak can you please add documentation about "Add to wish list" to readme.md?

tested

good to go!

tested
good to go

MR8 is ready for review

jannakha → created an issue.