🇦🇺Australia @jannakha

this is a very serious bug

please add more details and screenshots

bot updates are fine, but after 1.0.9 there are merge conflicts
please resolve conflict and I'll retest

ah, that's why we should stick to RTBS process
I just tested latest release on a clean D11 installation.
drupal_entity is twig tweak's function, so if this module is not installed there's an exception:

Twig\Error\SyntaxError: Unknown "drupal_entity" function. in Twig\ExpressionParser->getFunction() (line 20 of /Users/jm/work/d11.local/web/modules/contrib/entity_usage_explorer/templates/entity-usage-overview-page.html.twig).

so basically, instead of using drupal_entity - define a new twig function getEntity (similar to getEntityLabel)

thanks for releasing this feature!

good to go D11

good to go D11!

good to go

abhishek@kumar #2 looks good

please provide a merge request for testing

jannakha → created an issue.

MR 4 ready for review

MR 5 ready for review

jannakha → created an issue.

jannakha → created an issue.

jannakha → created an issue.

MR18 ready for review

jannakha → created an issue.

jannakha → created an issue.

jannakha → created an issue.

MR9 fixes the issue

jannakha → created an issue.

jannakha → created an issue.

jannakha → created an issue.

jannakha → created an issue.

jannakha → created an issue.

jannakha → created an issue.

Added column with bundle for more info:

MR ready for review

jannakha → created an issue.

The issue can be that drush deploy assumes up to date configuration (it's for deployment only) as it doesn't run config:export after updatedb, if there are any schema changes the old updatedb will update the schema, but config:import will import old schema in - that might create issues, like missing config, etc

Follow steps in Deployment of a new feature with configuration management - note actions on LOCAL ENVIRONMENT → before running drush deploy on server.

thanks for MR!
installed & tested

code tested, fix works

good description/readme

thanks for contributing to D11 support!

patch provided as MR

jannakha → created an issue.

after patch there are no more error

no errors after applying patch

no error after applying patch

jannakha → created an issue.

this is not an issue:
- run updb after update
- export config

CI is failing, for D11 it should be all green
+1 for #11 comment

MVP: if a product has a SINGLE product variation - apply the patch (because there's no GUI to update title of product variation if there's only one)

if product has multiple product variations here are some options:
- do nothing (user has to update all titles)
- a batch process can be added if there are many product variations

gargsuchi → credited jannakha → .

Conformed. The code originally commited should not have been there.

maybe this module should be brought into the core?
https://www.drupal.org/project/hide_revision_field →

is there a new release for 10.4.6+?
10.4.6 is still broken and there's no patch here for 10.4.x

MR11 is not solving the underlying bug - it's a new feature and should be moved to another issue

MR8 is not working as expected - see screenshots
config:

before patch:

after patch:

jannakha → changed the visibility of the branch 3488386-hide-all to hidden.

jannakha → created an issue.

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.