🇦🇺Australia @jannakha

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.