🇺🇸United States @Kasey_MK

Incorporating the fix from Need bigger range of weights on tabledrag rows 📌 Need bigger range of weights on tabledrag rows RTBC since that no longer applies after the change in #9.

This checks for the 'node' array key before trying to invoke it. Non-node menu links are not currently included in ReorderMenuForm,

menu_ui_get_menus is deprecated; this patch uses \Drupal\system\Entity\Menu::loadMultiple() instead, fixing /admin/config/pagemenureorder

I'm getting an error that You are not allowed to specify an external URL together with internal:/. in Drupal\Core\Url::fromInternalUri() which is annoying because that's exactly what I want to do: our feeds may link to content on the same domain using the view_node internal link to content, or on one of our other domains using a link field which may contain an external absolute link.

The #15 fix on Improve behavior of RSS view with fields if you enabled "Use absolute link" 📌 Improve behaviour of RSS view with fields if you enabled "Use absolute link" Active lets me mix'n'match as I need to by allowing valid absolute links to pass right through the getAbsoluteUrl function.

There's obviously a lot more going on in this MR but I'm hoping that at the end of the day, I can be allowed to specify external URLs together with internal. Thanks!

I think this may be a duplicate issue: Views RSS row plugin incorrectly assumes links are relative 🐛 Views RSS row plugin incorrectly assumes links are relative Needs work

I can't seem to reproduce this problem now, on Drupal 10.2.6, PHP 8.2.18. I remember it being a real deal-breaker at the time - leaving a checkbox unchecked on a search resulted in a "false" filter instead of including "any."

Thanks @globexplorer! The patch in #14 didn't quite work for me (I'm sometimes using absolute URLs to external sites from a link field instead of linking to the stub pages on the current domain, where 'Use absolute link' would apply), but you pointed me in the direction of a change that does seem to do the trick for how I'm using it.

Instead of using UrlHelper to decide whether or not to send the $url_string to the getAbsoluteUrl function, I used it within that function itself - if the $url_string is already valid (absolute) then it can be sent right back and needs no further processing:

@@ -207,9 +208,13 @@ public function getField($index, $field_id) {
    *   A string with an absolute URL.
    */
   protected function getAbsoluteUrl($url_string) {
+    // If the given URL is already valid, allow it.
+    if (UrlHelper::isValid($url_string, TRUE)) {
+      return $url_string;
+    }
     // If the given URL already starts with a leading slash, it's been processed
     // and we need to simply make it an absolute path by prepending the host.
-    if (str_starts_with($url_string, '/')) {
+    elseif (str_starts_with($url_string, '/')) {

Attached are two patches: one that applies against 10.2, which I'm currently using, and one against 11.x.

The patch in #71 (as well as the diff from MR 6352) both result in a WSOD error for me (Drupal 10.2.6 PHP 8.2.18):

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'tid' in where clause is ambiguous: SELECT "node_field_data_taxonomy_term_field_data"."title" AS "node_field_data_taxonomy_term_field_data_title", "node_field_data_taxonomy_term_field_data"."created" AS "node_field_data_taxonomy_term_field_data_created", "node_field_data_taxonomy_term_field_data"."uid" AS "node_field_data_taxonomy_term_field_data_uid", "taxonomy_term_field_data"."weight" AS "taxonomy_term_field_data_weight", COUNT(field_discussion_taxonomy_term_field_data.nid) AS "field_discussion_taxonomy_term_field_data_nid", SUM(field_discussion_taxonomy_term_field_data__comment_entity_statistics.comment_count) AS "field_discussion_taxonomy_term_field_data__comment_entity_st", MIN(taxonomy_term_field_data.tid) AS "tid", MIN(field_discussion_taxonomy_term_field_data.nid) AS "field_discussion_taxonomy_term_field_data_nid_1", MIN(node_field_data_taxonomy_term_field_data.nid) AS "node_field_data_taxonomy_term_field_data_nid" FROM "taxonomy_term_field_data" "taxonomy_term_field_data" LEFT JOIN "node__field_discussion" "node__field_discussion" ON taxonomy_term_field_data.tid = node__field_discussion.field_discussion_target_id AND node__field_discussion.deleted = :views_join_condition_0 LEFT JOIN "node_field_data" "field_discussion_taxonomy_term_field_data" ON node__field_discussion.entity_id = field_discussion_taxonomy_term_field_data.nid LEFT JOIN "node_field_data" "node_field_data_taxonomy_term_field_data" ON (SELECT "node_field_dataINNER"."nid" AS "nidINNER" FROM "node_field_data" "node_field_dataINNER" LEFT JOIN "taxonomy_index" "taxonomy_indexINNER" ON "node_field_dataINNER".nid = "taxonomy_indexINNER".nid LEFT JOIN "taxonomy_term_field_data" "taxonomy_term_field_data_node_field_dataINNER" ON "taxonomy_indexINNER".tid = "taxonomy_term_field_data_node_field_dataINNER".tid WHERE ("taxonomy_term_field_data_node_field_dataINNER".tid = "".tid) ORDER BY "node_field_dataINNER"."created" DESC LIMIT 1 OFFSET 0) = node_field_data_taxonomy_term_field_data.nid INNER JOIN (SELECT "tn"."nid" AS "nid" FROM "taxonomy_index" "tn" WHERE "tn"."tid" = :db_condition_placeholder_6 UNION SELECT "tn"."nid" AS "nid" FROM "taxonomy_index" "tn" INNER JOIN "taxonomy_term__parent" "th" ON "tn"."tid" = "th"."entity_id" INNER JOIN "taxonomy_term__parent" "th1" ON "th"."parent_target_id" = "th1"."entity_id" WHERE "th1"."entity_id" = :db_condition_placeholder_7) "taxonomy_index_depth" ON field_discussion_taxonomy_term_field_data.nid = taxonomy_index_depth.nid LEFT JOIN "taxonomy_term__field_path_prefix" "taxonomy_term__field_path_prefix" ON taxonomy_term_field_data.tid = taxonomy_term__field_path_prefix.entity_id AND taxonomy_term__field_path_prefix.deleted = :views_join_condition_1 AND (taxonomy_term__field_path_prefix.langcode = taxonomy_term_field_data.langcode OR taxonomy_term__field_path_prefix.bundle = :views_join_condition_3) LEFT JOIN "comment_entity_statistics" "field_discussion_taxonomy_term_field_data__comment_entity_statistics" ON field_discussion_taxonomy_term_field_data.nid = field_discussion_taxonomy_term_field_data__comment_entity_statistics.entity_id AND field_discussion_taxonomy_term_field_data__comment_entity_statistics.entity_type = :views_join_condition_4 WHERE ((field_discussion_taxonomy_term_field_data.status = 1 OR (field_discussion_taxonomy_term_field_data.uid = 20 AND 20 <> 0 AND 1 = 1) OR 1 = 1 OR 1 = 1)) AND ("field_discussion_taxonomy_term_field_data"."type" IN (:db_condition_placeholder_5)) GROUP BY "node_field_data_taxonomy_term_field_data_title", "node_field_data_taxonomy_term_field_data_created", "node_field_data_taxonomy_term_field_data_uid", "taxonomy_term_field_data_weight" ORDER BY "taxonomy_term_field_data_weight" ASC; Array ( [:db_condition_placeholder_5] => post [:views_join_condition_0] => 0 [:db_condition_placeholder_6] => 1083 [:db_condition_placeholder_7] => 1083 [:views_join_condition_1] => 0 [:views_join_condition_3] => brand [:views_join_condition_4] => node ) in Drupal\mysql\Driver\Database\mysql\ExceptionHandler->handleExecutionException() (line 45 of core/modules/mysql/src/Driver/Database/mysql/ExceptionHandler.php).

The patch in #66 works for me (doesn't result in a WSOD anyway) but gives this warning:
Deprecated function: Creation of dynamic property Drupal\views\Plugin\views\relationship\GroupwiseMax::$table_aliases is deprecated in Drupal\views\Plugin\views\relationship\GroupwiseMax->leftQuery() (line 253 of core/modules/views/src/Plugin/views/relationship/GroupwiseMax.php).

This patch is just the one in #66 with this bit added:

/**
* The table aliases used by the subquery.
*/
// phpcs:ignore Drupal.NamingConventions.ValidVariableName.LowerCamelName
protected array $table_aliases;

$tableAliases (as in the patch from #72) also works and meets the camelCase requirement, but for simplicity's sake I wanted to stay as close as possible to the patch that seems to work for us.

Sorry made the patch from Drupal default branch this time and this one applies against Drupal 10.2.6.

The change that made my webform submissions work again was adding (count($this->recursionKeys) !== 1) to line 569 in core/lib/Drupal/Core/Entity/EntityViewBuilder.php but starting from the default Drupal branch added some other changes to the patch. Interdiff against the patch in #155 attached.

Adding a check that count($this->recursionKeys) !== 1 allows webform submissions to render without logging an error, but I don't pretend to understand this issue well enough to know what else that might do. Attaching the patch I made and the interdiff from the patch in #155 for review.

Confirming @kmonty's report in #163 using patch in #155.

Re-roll for 2.1.0

Kasey_MK → created an issue.

Hi Xingwu,

As far as I can tell, the patch in #3 still applies to 8.x-1.16; it replaces the word "Orphaned" with the word "Embedded." If you prefer no word at all, you can make a copy of that patch and simply remove the word "Embedded" - since you'd only be changing something within the line and not adding or removing any lines from the patch, nothing else would change.

Best,
Kasey

Bug fix for $this->logger no longer being included, and some whitespace fixes.

Thanks for this solution, which did work to remove the error message we were getting with Flysystem as used by search_api_attachments in our case. I haven't needed twistor/flysystem-stream-wrapper before now, so I'm thinking there must be another solution? I don't know how to account for all the different modules that might interact with Flysystem (but that aren't necessarily designed to do so specifically), but in my admitted ignorance it seems like finding a fix here would be preferred.

In any case, thanks for pointing to twistor/flysystem-stream-wrapper and the patch that adds a public $context property to the stream wrapper, as that does seem to solve the immediate problem.

Yes @DamienMcKenna I believe so.

Thank you, @Rob230 - your note on Rendering of paragraphs broken - recursive rendering attempt aborted 🐛 Rendering of paragraphs broken - recursive rendering attempt aborted Closed: duplicate which highlighted the error Recursive rendering attempt aborted for . In progress: Array ( [] => ) led me back here where - thank you, @godotislate - I learned that MR 4050 works better for us than MR 4994.

I was only seeing that error on some Paragraphs, not all, but having MR 4994 applied and assuming my problem wasn't related to this branch had me banging my head against my code for a good while.

In case it's helpful, I'll note that the erroring paragraph type for us was meant to render a taxonomy term in a display mode showing some different paragraph types on the term. So there was supposed to be a node rendering a paragraph rendering a taxonomy term rendering some other paragraphs which is a lot but shouldn't have been recursive AFAIK. MR 4050 allows this chain of rendering to work.

Thanks @ohmahm, that'll be great! In the meantime, here's a re-roll for 2.1.6

What ended up making those errors go away for me was not using the fullcalendar_view to render a multi-value field's first value only. Instead, I used a custom field formatter and a custom node view mode to render only the first value of the field in question, and including that in my view instead of the multi-value field. In my case I'm using search_api and search_api_solr, so I added the rendered HTML as a storage-only field in my search index, but perhaps that would work with a rendered entity in the view too.

What ended up making those Undefined array key : views_view_fullcalendar 🐛 Undefined array key : views_view_fullcalendar Closed: outdated errors go away for me was not using the search_api_solr-based fullcalendar_view to render a multi-value field's first value only. Instead, I used a custom field formatter and a custom node view mode to render only the first value of the field in question, adding that to my search index as storage-only rendered HTML, and including that in my view instead of the multi-value field.

Gah nevermind that code snippet in #31; it did make the warnings go away but it also messed up the view row data.

Gah nevermind that code snippet in #12; it did make the warnings go away but it also messed up the view row data.

I couldn't get #30 to apply to 5.1.13 so here's a version that does. (I skipped all the whitespace fixes in fullcalendar_view.js because that seems like a separate issue to me; there's no other reason to touch that file in response to this issue that I can see.)

BTW, after installing this patch and moving my fullcalendar_view views to work on search_api and search_api_solr, I started seeing the errors mentioned in Undefined array key : views_view_fullcalendar 🐛 Undefined array key : views_view_fullcalendar Closed: outdated . I don't know if it's related, but this change in src/FullcalendarViewPreprocess.php (not included in patch #31 here) seems to allow my Solr-based fullcalendar views to work without warning messages:

-$des[$idkey] = $field->advancedRender($row);
+if (array_key_exists($idkey, $des)) {
+ $des[$idkey] = $field->advancedRender($row);
+}

FWIW I encountered this on fullcalendar_view 5.1.13, Drupal 10.1.16, PHP 8.1.21.

I'm using a patch to integrate fullcalendar_view with search_api (1.30.0) based on work in Integration with Search API ✨ Integration with Search API Needs review . I don't know if that's relevant, but I didn't see this error message until after I started using search_api and search_api_solr as the base for fullcalendar_view, so I mention it.

My calendar grids look fine and show all the events that I expect to see, including recurring events - I just had a flood of these warning messages at the tops of some of my calendar pages.

This change in src/FullcalendarViewPreprocess.php seems to allow everything that's already working to continue working, and gets rid of the warning messages:

-$des[$idkey] = $field->advancedRender($row);
+if (array_key_exists($idkey, $des)) {
+  $des[$idkey] = $field->advancedRender($row);
+}

Here's a super-simple patch that I think just removes the link button from the UI without touching anything else:

t("Entity Embed toolbar"),items:["entityEmbedEdit","entityEmbedLink","editEmbeddedEntity"] becomes t("Entity Embed toolbar"),items:["entityEmbedEdit","editEmbeddedEntity"]

(editEmbeddedEntity doesn't do anything for me but show a gear with an incorrect message about how I don't have permission to edit the entity, so I'm removing that too on my own site, but it's out-of-scope in this conversation.)

As discussed above, I'd love to see some options built in - to turn the linking on or off entirely, or as suggested, per entity - but this will let me move ahead with my use case.

Thanks to all who work on this! I can see that adding links was a huge effort, and just because I need it to not be there doesn't mean I don't appreciate all the time everyone put on it!

Just updated to 1.5 on Drupal 10.1.6 and I came here hoping to find an option to turn off linking on embedded entities.

We use entity_embed exclusively for Paragraphs, which all handle links their own way. I need a way to prevent users from trying to add links around all that. Even if there was a check-and-fix for a tags within a tags before rendering, I don't want a confusing UI offering options that won't work and obscuring the options that will.

Re-roll for 2.1.4

I'd love to see this; it's especially disorienting when using date fields with timezones - not only is the timezone field missing on the "manage instances" modal, but the times given are translated to my timezone without any indication that that's happened.

Thanks!

FWIW I encountered these errors after installing smart_date 4.0 on my Drupal 10.1.15 site using PHP 8.1.18 and adding a smart date range field to my event content type.

I went to edit an event and got these errors.

The problem was resolved by revisiting the field's edit screen (/admin/structure/types/manage/event/fields/node.event.field_event_smart_date) and (re)saving the field settings.

I can reproduce the problem by adding another smart date range field and failing to use the "Save settings" button before trying to edit a node with the field.

Thanks azinck this has been a frustrating little problem, and how nice that your simple fix just works and makes the problem go away!

@mlncn being able to configure the maximum resolution is absolutely critical to the problem we were experiencing, where people were uploading images that were way too big for Drupal to process (3840 pixels in either dimension seems to be the breakpoint). The uploads would appear to finish, but none of the image styles could be processed from it.

Patch #24 solved that problem for us, allowing people to upload images of any size via any field which would then be properly resized and processed.

I want to see the alias within the link dialogue - for us, anyway, it's the most unique but also human-friendly way to know exactly which page I've selected.

Outside the link dialogue, I'd want to see the title as the linked text, if I hadn't already selected different text to be linked, but that may be a whole different issue.

#42 applied and seems to be working for me on Drupal 10.1.4 with MySQL 10.4.

#43 threw this error: PHP Fatal error: Trait "Drupal\datetime\Plugin\Field\ConfigurableTimezoneTrait" not found in /app/web/core/modules/datetime/src/Plugin/Field/FieldFormatter/DateTimeFormatterBase.php on line 22

Thanks to all keeping this alive!

Could the composer failures be caused by these lines? I'm on Drupal 9.5.10 and when I run `composer require 'drupal/flysystem_s3:^2.0@RC'` my `flysystem_s3.info.yml` doesn't look like the one I get when I git clone the module.

# version: 8.0-dev

# Information added by Drupal.org packaging script on 2022-03-25
version: '2.0.0-rc5'
project: 'flysystem_s3'
datestamp: 1648207248

Re-roll for 2.1.3

First off - thanks for all this!

@laura.gates as noted above, you'll need to patch the embed module 📌 Add CKEditor 5 compatibility and keep supporting CKEditor 4 RTBC as well to get rid of the "only CKEditor is supported" error.

I'm having some trouble with embedded Paragraph entities which contain links - the links interrupt the form's tab order, so once I tab to the CKE field, I can't tab out of it to the next form element. On my screen I can briefly see the first link within a Paragraph flash as if it's selected, but the location of my cursor doesn't change - and every subsequent use of the tab button just flashes that same link. I can Shift+Tab back out of the CKE field, but I can't tab forward past it.

If I add tabindex="-1" to links within the embedded Paragraph, all seems to work as expected, but I'm wondering if there's a better way than this:

// Remove in-Paragraph links from the tab order to prevent breaking the edit form as a whole.
setTimeout(noTabParagraphLinks, 1000);
function noTabParagraphLinks() {
  $('figure.drupal-entity a').each(function() {
    $(this).attr('aria-hidden', 'true').attr('tabindex', -1);
  });
}

NEVERMIND. Found the (unrelated problem) in my code.

Kasey_MK → created an issue.

Re-roll (just the lang version) for 1.4.0

Re-roll patch from #3 for 3.0

I really appreciate all the work going on here, and look forward to seeing where this lands after taking people's feedback into consideration.

In the meantime, we made a patch for ourselves so our users can keep the accessibility improvement they were so excited about last week, and I'm sharing it here in case others feel similarly.

I left out the z-index update which did break things for us as well as for others (we had just overridden that in our CSS with a value of 9990). We didn't encounter any other issues that we couldn't also resolve with some CSS overrides.

The following CSS overrides in our themes make the toolbar a little less huge overall. We decided to set the visual-only icons to width:0 in order to make room for what we perceive as a vastly improved UI. We left the chevrons the size they are, recognizing the value of them being finger-sized, but tightened up some of the padding around the words, trusting that the words themselves are big enough to target.

.toolbar-icon-system-admin-content,
.toolbar-icon-system-admin-structure,
.toolbar-icon-system-themes-page,
.toolbar-icon-system-admin-config,
.toolbar-icon-system-modules-list,
.toolbar-icon-entity-user-collection,
.toolbar-icon-system-admin-reports {
  padding-left: 0.75em !important;
  padding-right: 0.5em !important;
}
.toolbar-icon-system-admin-content:before,
.toolbar-icon-system-admin-structure:before,
.toolbar-icon-system-themes-page:before,
.toolbar-icon-system-admin-config:before,
.toolbar-icon-system-modules-list:before,
.toolbar-icon-entity-user-collection:before,
.toolbar-icon-system-admin-reports:before,
.toolbar-icon-help-main:before {
  width: 0 !important;
}

Thanks again for continuing to work on this!

I and my users really liked the change adding the chevrons and improving the menu's accessibility, and I'm disappointed to see them gone in 3.4.

They did add a lot of real estate for us admin users with lots of menu items, so I did add some style overrides to get rid of the cutesy icons which didn't add much in terms of usability.

Thanks for working on this. I look forward to their reintroduction!

This is a problem with CKEditor too. Toolbar overlays CKEditor menu when CKEditor is maximised → had previously fixed this with z-index 9990.

Re-roll of #14 for version 2.1.2

Kasey_MK → created an issue.

smustgrave → credited Kasey_MK → .

This may be a duplicate of https://www.drupal.org/project/facets/issues/3047910 ✨ Add AND\OR condition for dependent facets processor Needs work , which seems to have more activity