recursive_render_depth may also need to be added to media.settings.yml and media.schema.yml.
It looks like the fact that it's not saving probably has to do with the new way of setting values in config forms. See issue: 📌 Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms Fixed .
So, in MediaSettingsForm.php replace:
'#default_value' => $this->config('media.settings')->get('recursive_render_depth') ?? 20,
with:
'#config_target' => 'media.settings:standalone_url',
I just discovered this and don't know how to set a default value in the form if the config value is unset or null, but this should be fine because the patch sets a default in MediaEmbed.php if the config value is null.
This didn't end up being addressed in 🐛 Validate the min, max and default values for Numeric fields Fixed . This remains an issue if min >= 1000 and max is not set in the field settings. I've re-rolled the patch for 10.3.
#14 did not work for me with version 2.0.2. However, I'm also using a Workflow and the workflow_buttons module, so that may have something to do with it.
I was able to make everything work just by adding the IEF-related elements from the main submit button ($form['actions']['submit']) to the Next button definition in FormButton.php. I can't guarantee that this is the right way to fix it, but patch is attached if others want to test.
private function showNextButton(array &$form) {
$step_format_settings = $this->stepSettings->format_settings;
if (count($this->steps) - 1 !== $this->currentStep) {
$form['actions']['next'] = [
'#limit_validation_errors' => [],
'#type' => 'submit',
'#value' => $step_format_settings['next_button_text'],
// Change the #submit to this.
'#submit' => [
['\Drupal\inline_entity_form\ElementSubmit', 'trigger'],
'simple_multistep_register_next_step',
],
'#weight' => 0.1,
// Add the following two lines.
'#ief_submit_trigger' => TRUE,
'#ief_submit_trigger_all' => TRUE,
];
$form['actions']['submit']['#access'] = FALSE;
}
}
Thanks for confirming! Here's a patch.
I think it's due to this line being remove in commit 7ec4b704 (line 399 in src/ConditionalFieldsFormHelper.php), causing the dependentValidation to execute when saving conditions:
if (!isset($form['#conditional_fields'])) {
return;
}
If you add that back in just after the following, the error goes away and the conditional field rules work:
$inline_entity_form_parents = self::findInlineEntityFormParentsForElement($form, $element);
if ($inline_entity_form_parents) {
$form = NestedArray::getValue($form, $inline_entity_form_parents['element_parents']);
}
I don't know if this is the correct solution as the removal may have been intentional in issue 2856720 ✨ Support for Inline Entity Form Fixed . However, I tested the fix with my initial conditions and the conditional fields inside an "Inline entity form - Simple" and it worked. I didn't test with "Inline entity form - Complex".
jvogt → created an issue.
This proposed patch to the core FileWidget fixed the issue for me: https://www.drupal.org/project/drupal/issues/3276280 🐛 File widget with multiple values may duplicate empty items Needs work
To add to this, it seems like using the Back button sort of resets the count. In my form with the file upload on the fifth step, the following happens:
- Click Next 4 times. 5 upload inputs are displayed on the fifth page.
- Click Back once. Click Next once. 2 upload inputs are displayed.
- Click Back twice. Click Next twice. 3 upload inputs are displayed.
Actually it looks like there's probably more to it than just changing the column-fill. With either of the options I suggested, if the items don't distribute evenly across the number of columns, it makes the middle columns the longest, which looks a little weird (and is different from the Grid display option which weights the longer columns to the left). Examples below using the Gin theme.
Column display: 3 columns, column-fill: balance
Grid display: 3 columns
(Original for context) Column display: 3 columns, column-fill: auto
Sounds like this one can be closed? Just trying to clean up the issue queue.
I ran into this too and digging around it looks like it's because the filter has to disable caching (see token_filter_filter_info() in token_filter.module). See text_field_load() in text.module for details on how the safe_value is set. It only sets the safe_value if the filter format allows caching.
You can get the safe_value manually by passing the value through check_markup():
// $entity_wrapper is an entity_metadata_wrapper
$field_value = $entity_wrapper->field_my_field->value();
$safe_value = $field_value['safe_value'] ?? check_markup($field_value['value'], $field_value['format']);
There's also an open issue with a patch to add a setting to toggle the caching: https://www.drupal.org/project/token_filter/issues/2055307 →
Yep, it's those two core modules. I think your suggestion will work for us. Thanks for your insights!
Thanks for the quick patch, Jurgen!
Not sure this applies to everyone getting the error, but I was getting this error after enabling css preprocessing. The error went away when css preprocessing was disabled, but I didn't want to leave it that way. Turns out that I somehow had the bootstrap theme, but it wasn't being managed by composer.
Running composer require drupal/bootstrap solved the issue for me and allows css preprocessing.
The latest is working great for us! Thank you all for your hard work!
I still think the button styling could use some work to look like a button. I wrote this patch, but it depends on the Gin theme css variables so I don't know if it's appropriate to commit it to this project.
diff --git a/css/linkit-media-library.css b/css/linkit-media-library.css
index dbeb22b9e..678dd3cdf 100644
--- a/css/linkit-media-library.css
+++ b/css/linkit-media-library.css
@@ -1,8 +1,17 @@
.ck.ck-link-form.ck-link-form_layout-vertical button.ck-media-library {
- width: 100%;
- border-top: unset;
+ border: 2px solid var(--gin-color-primary);
+ border-radius: var(--ck-border-radius);
+ margin: auto;
padding: var(--ck-spacing-small) var(--ck-spacing-large);
display: block;
+ cursor: pointer;
+}
+
+.ck.ck-link-form.ck-link-form_layout-vertical button.ck-media-library .ck-button__label {
+ font-size: var(--gin-font-size-s);
+ font-weight: var(--gin-font-weight-semibold);
+ color: var(--gin-color-primary);
+ cursor: inherit;
}
.ui-dialog.ui-dialog-off-canvas ~ .ck-body-wrapper .ck-balloon-panel {
I think it ended up partially being a server capacity issue. We increased our storage and it's no longer happening so I'm unable to test it now. My theory is that the temp file was getting too close to the storage limit and causing the backup to fail. The concerning part is that the module didn't know it was failing. It was recording the backups as successful with file sizes that matched what was expected. But looking directly at the backup files via SFTP, they were ~1KB. The failed backups tar.gz files also remained in the temp folder with the larger sizes, but were corrupted and could not be unzipped.
LAMP stack with CentOS7. Multisite install with the backup files saving to /www/drupal-7/sites/{site-folder}/files/private/backup_migrate/scheduled (or /manual for manually executed). Probably not all that helpful since everything is working fine again after increasing the server capacity.
I wouldn't call it exotic for us. We're trying to write a ckeditor5 plugin that outputs a themed "button". The HTML structure is as follows:
<a href="https://example.com" class="btn btn-lg arrow purple">
<span>Button text</span>
<span class="arrow-box"><span class="arrow"></span></span>
</a>
ckeditor5 rewrites that to the following which doesn't work with the theme:
<a href="https://example.com" class="btn btn-lg arrow purple">
<span>Button text</span>
<span class="arrow-box arrow"></span>
</a>
The theme CSS and HTML are provided by our institution and aren't Drupal-specific. We'd like to stick to the main theme as much as possible for the sake of maintenance and future compatibility, rather than reworking it to avoid nested spans. Also, from what I can tell, nesting a <span> in another <span> is considered valid HTML so it seems reasonable for ckeditor to allow it.
I was having the issue when rendering referenced media entities with a view as well. To fix that, I had to make the following changes in /core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php as well. Basically replicating the changes #16 makes to MediaEmbed.php. Sorry it's not a real patch; I couldn't re-roll the D10 patch because I had to apply it manually due to conflicts with another patch.
diff --git a/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php
index cc5a68cb7..f101046f0 100644
--- a/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php
+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php
@@ -2,6 +2,7 @@
namespace Drupal\Core\Field\Plugin\Field\FieldFormatter;
+use Drupal\Core\Config\ConfigFactory;
use Drupal\Core\Entity\EntityDisplayRepositoryInterface;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\Core\Field\FieldDefinitionInterface;
@@ -64,6 +65,13 @@ class EntityReferenceEntityFormatter extends EntityReferenceFormatterBase {
*/
protected static $recursiveRenderDepth = [];
+ /**
+ * The config factory.
+ *
+ * @var \Drupal\Core\Config\ConfigFactory
+ */
+ protected $configFactory;
+
/**
* Constructs an EntityReferenceEntityFormatter instance.
*
@@ -87,12 +95,15 @@ class EntityReferenceEntityFormatter extends EntityReferenceFormatterBase {
* The entity type manager.
* @param \Drupal\Core\Entity\EntityDisplayRepositoryInterface $entity_display_repository
* The entity display repository.
+ * @param \Drupal\Core\Config\ConfigFactory $config_factory
+ * The config factory.
*/
- public function __construct($plugin_id, $plugin_definition, FieldDefinitionInterface $field_definition, array $settings, $label, $view_mode, array $third_party_settings, LoggerChannelFactoryInterface $logger_factory, EntityTypeManagerInterface $entity_type_manager, EntityDisplayRepositoryInterface $entity_display_repository) {
+ public function __construct($plugin_id, $plugin_definition, FieldDefinitionInterface $field_definition, array $settings, $label, $view_mode, array $third_party_settings, LoggerChannelFactoryInterface $logger_factory, EntityTypeManagerInterface $entity_type_manager, EntityDisplayRepositoryInterface $entity_display_repository, ConfigFactory $config_factory) {
parent::__construct($plugin_id, $plugin_definition, $field_definition, $settings, $label, $view_mode, $third_party_settings);
$this->loggerFactory = $logger_factory;
$this->entityTypeManager = $entity_type_manager;
$this->entityDisplayRepository = $entity_display_repository;
+ $this->configFactory = $config_factory;
}
/**
@@ -109,7 +120,8 @@ public static function create(ContainerInterface $container, array $configuratio
$configuration['third_party_settings'],
$container->get('logger.factory'),
$container->get('entity_type.manager'),
- $container->get('entity_display.repository')
+ $container->get('entity_display.repository'),
+ $container->get('config.factory')
);
}
@@ -174,14 +186,24 @@ public function viewElements(FieldItemListInterface $items, $langcode) {
. $entity->id();
if (isset(static::$recursiveRenderDepth[$recursive_render_id])) {
- static::$recursiveRenderDepth[$recursive_render_id]++;
+ static::$recursiveRenderDepth[$recursive_render_id]['depth']++;
}
else {
- static::$recursiveRenderDepth[$recursive_render_id] = 1;
+ static::$recursiveRenderDepth[$recursive_render_id]['depth'] = 1;
+ }
+
+ // Issue #3151977: get the recursive max depth from media settings,
+ // if not set, we are defaulting it to 20.
+ $recursive_render_depth = $this->configFactory->get('media.settings')->get('recursive_render_depth');
+
+ // Issue #3151977: if there is no recursive depth in settings, set it to the
+ // default value of 20.
+ if ($recursive_render_depth == NULL) {
+ $recursive_render_depth = 20;
}
// Protect ourselves from recursive rendering.
- if (static::$recursiveRenderDepth[$recursive_render_id] > static::RECURSIVE_RENDER_LIMIT) {
+ if (static::$recursiveRenderDepth[$recursive_render_id]['depth'] > $recursive_render_depth) {
$this->loggerFactory->get('entity')->error('Recursive rendering detected when rendering entity %entity_type: %entity_id, using the %field_name field on the %parent_entity_type:%parent_bundle %parent_entity_id entity. Aborting rendering.', [
'%entity_type' => $entity->getEntityTypeId(),
'%entity_id' => $entity->id(),
Looking good! I'm seriously so excited to see this moving along.
First take: it works! Linking text to newly uploaded or existing media is now a reality. Woohoo!
Good stuff:
- So far, it looks compatible with the Gin admin theme and with Paragraphs.
- The button only shows up if the selected Linkit profile has a Media matcher.
Notes:
- I think it needs to "look" like a button (in Claro/Gin themes specifically). Understandably not the first priority, but maybe an opportunity for people to contribute who aren't CKeditor5 plugin builders.
- The Media Library button doesn't appear if the "Linkit URL converter" filter is disabled. I don't know if that's intentional.
- The URL isn't converted when linking embedded media (e.g. an image) to another media entity. This looks like it's actually a Linkit-level issue though. Same problem when linking embedded media to nodes.
- I haven't tested extensively with Advanced link editor, so I'll get back to you on that.
I'm not sure the patches in #24/26 address the original issue. I think they are (and I am) looking for a way to control the image resolution from a Media reference field, with Image media as an allowed type, rather than from the Image field within a Media type. I realize this means two places where min/max can be configured, but I'm really trying to avoid creating a separate Media type for images where I want to control the resolution at time of upload.
It's possible that this just isn't how Media entities are intended to be used in Drupal 8/9/10+, but if that's the case, I'm struggling to find any documentation to that effect or a good workaround for my use case. The entity_browser → module provides the "Upload images as media items" widget that allows you to specify an upload location, which overrides the selected Media type's location, so maybe that's a more appropriate place for this kind of feature.
@rajeevgole: no I don't believe it does. It seems to alter only the Media library upload form.
Oh, that makes sense! Thanks for all your work on this!
Confirmed that patch #8 works on 4.0.17 on Drupal 10.1.6 with php 8.2. Thanks for the patch!
The patch in #12 applies to 1.0.3 but isn't working in Drupal 10.1.6 (php 8.2). It also appears to conflict with editor_advanced_link → .
Scenario A: without editor_advanced_link installed:
The Media library button shows up, but clicking it does nothing. No javascript errors are thrown. FWIW, the console does log "_addMediaLibraryButton()" from line 28 of index.js.
The linkit matcher becomes non-functional. All of the javascript events are removed except blur, change, focus and input from ckeditor5-dll.js.
The rest are various additional issues when editor_advanced_link is installed and configured (no change if just installed and not configured).
Scenario B: only one advanced link attribute enabled (and it's not the Open in new window attribute): the same issues as Scenario A except this js error is thrown when clicking the Link button to bring up the link dialog: "Uncaught CKEditorError: collection-add-item-invalid-index" in ckeditor5-dll.js.
Scenario C: only the Open in new window attribute enabled: same issues as Scenario A except the Media library button does not show up.
Scenario D: multiple advanced attributes enabled, including Open in new window: Media library button doesn't show up. Matcher is non-functional like Scenario A. JS error thrown when expanding the "Advanced" accordion: "Uncaught CKEditorError: collection-add-item-already-exists" in ckeditor5-dll.js.
Scenario E: multiple advanced attributes enable, but not Open in new window: same as Scenario A except with a JS error thrown when expanding the "Advanced" accordion: "Uncaught CKEditorError: collection-add-item-invalid-index" in ckeditor5-dll.js.
#4 applied cleanly and solved the issue for me as well with Drupal 9.5.11 and php 8.2.
I'm seeing this since upgrading from php 7.4 to 8.2. The tar.gz files on the server are all 0b, but this module shows them as 5GB (which is what they should be) in the list of saved backups. Executing the public files backup manually resulted in a WSOD after about 5 min with no errors in the log.
This solved the issue for me. Applied to 7.x-3.2. Drupal 7.98. php 8.2.
The patch solved the issue for me.
Thanks, Kasey. Setting max resolution is critical for us as well. It's about making the images fit for purpose. We want to prevent users from bogging down the site storage with 5000px wide images that will only ever be used as a 100px wide thumbnail.
Well, I downgraded back to 7.x-1.6, but after running drush dl entityreference, the output of drush pml | grep entityreference -i is:
Fields Entity Reference (entityreference) Module Enabled 7.x-1.9
Fields Entity Reference Behavior Example (entityreference_behavior_example) Module Not installed 7.x-1.9
This is still an issue for me in 7.x-1.9 when the field is referencing User entities. Tested on both php 7.4 and 8.1. It ignores both "A field attached to this entity" and "A property of the base table of this entity."
I couldn't replicate this, but it's possible we're not using the same field type. With the Date module installed, I see three field type options: Date, Date (ISO format), and Date (Unix timestamp). Are you using one of these or do you have a field type called "Date/Time"?
I tested with the Date field type.
Core: 7.98
Date: 7.x-2.14
Field type: Date
Field settings:
- Number of values: 1 (default)
- Date attributes to collect: Year, Month, Day, Hour, Minute (default)
- Time zone handling: No time zone handling (default)
- Number of values: 1
---
More settings and values:
- Date entry options: 09/01/2023 - 10:18:34pm
- Starting year: -3 (default)
- Ending year: +3 (default)
- Time increments: 15 minutes (default)
- Advanced settings - Position of date part labels: Above (default)
- Advanced settings - Render as regular field: Unchecked (default)
- Default date: now (default)
---
Widget: Pop-up calendar
---
TEST
Input: 09/13/2023 11:30AM
Code:
function MY_MODULE_form_CONTENT_TYPE_node_form_alter(&$form, &$form_state) {
$form['#validate'][] = 'MY_MODULE_form_CONTENT_TYPE_node_form_validate_alter';
}
function MY_MODULE_form_CONTENT_TYPE_node_form_validate_alter(&$form, &$form_state) {
drupal_set_message('Date value: ' . $form_state['values']['field_test_date']['und'][0]['value']);
}
Output: "Date value: 2023-09-13 11:30:00"
Just encountered this. Looks like it's due to a change in how the max() function works in php 8+. Before php 8, it sounds like it treated strings as equal to 0. Now it does...something else, like maybe getting the ord() value of strings? Anyway, it takes strings into account and can return a string value.
In this case, array_keys($settings['items']) is being passed to max() and those array keys are a mix of ints and strings. If I'm understanding correctly, we only want to look at the int array keys. I'm not sure of the most efficient way to do that, but a foreach would work. Something like:
$key = 0;
foreach(array_keys($settings['items']) as $index) {
if (is_int($index) && $index > $key) {
$key++;
}
}
$form_state['key'] = ++$key;
jvogt → created an issue.
#3 applies cleanly to 4.2.3 and deals with the original error, but now there's a new error:
"Error: Typed property Drupal\views_bulk_operations\ViewsBulkOperationsEvent::$entityGetter must not be accessed before initialization in Drupal\views_bulk_operations\ViewsBulkOperationsEvent->getEntityGetter() (line 110 of modules/contrib/views_bulk_operations/src/ViewsBulkOperationsEvent.php)."
Is it possibly something to do with dblog/watchdog entries not being entities ( https://www.drupal.org/project/drupal/issues/2401463 📌 Make dblog entities Postponed )?
Patch #4 applies cleanly to rules 7.x-2.13 with php 8.1 and core 7.95. It resolves the issue of the error message ("Deprecated function: dirname(): Passing null to parameter #1 ($path) of type string is deprecated in drupal_get_path() (line 2974 of /[...]/includes/common.inc).") I haven't tested it beyond that.
FWIW, I can confirm that the patch from 133 applied successfully in my environment:
Drupal core: 9.5.3
Php: 7.4.10
Linkit: 6.0.x-dev (against the latest commit: https://git.drupalcode.org/project/linkit/-/commits/6.0.x)
I believe it did fail against the 6.0.0-beta3 release, so maybe that's what Rar9 is experiencing.
The latest patch to make Linkit compatible with CKEditor 5 is testing well: https://www.drupal.org/project/linkit/issues/3232190 📌 CKEditor 5 readiness Fixed . Can work on this issue be started against that patch?
My experience building CKEditor 5 modules is limited (assuming that's needed for this fix), but I'm happy to help collaborate and test. This functionality is critical to my sites as well.