@kksandr

I have published a fix in this MR. Could you please test the patch and confirm if it resolves your issue?

kksandr → changed the visibility of the branch 3541318-allowed-widgets-option to hidden.

Thanks for the report. To investigate this on 4.0.0-rc2 we need the exact configuration so we can reproduce.

Please attach or paste:

• core.entity_form_display.* for the bundle where the field should appear
• field.field.* for the affected field(s)
• Drupal core version
• Any errors in Recent log messages or the browser console

You can get the config with:

drush cget core.entity_form_display.<entity>.<bundle>.default
drush cget field.field.<entity>.<bundle>.<field_name>

Clearing caches after changing the option also helps confirm whether it is a display issue or configuration.

@heavystonehead you can now configure which widgets show the caption field in your image field settings. Look for the "Caption field allowed widgets" option and select the widgets where you want captions enabled.

kksandr → changed the visibility of the branch 3541318-improve-widget to hidden.

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

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

kksandr → changed the visibility of the branch 3255807-request-option-to to hidden.

1. Apologies — due to a rushed release, the update was not properly tested and unintentionally reset the field settings. This issue is now fixed and won't overwrite existing settings anymore.

2. Thanks for pointing that out. I'll pass this to the maintainers for possible inclusion on the release page or a change record.

kksandr → changed the visibility of the branch 3472997-fixes-3 to hidden.

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

kksandr → changed the visibility of the branch 3472997-fixes-2 to hidden.

Thank you for the feedback.

Regarding the issue:

Warning: Undefined array key "caption_allowed_formats" in image_field_caption_field_widget_single_element_image_image_form_alter() (line 42 of modules\contrib\image_field_caption\image_field_caption.module).

we've released version 4.0.0-beta3 which should resolve it. We're aiming to keep the configuration safe to use, avoiding excessive isset/empty/?? checks across the codebase. This release includes a post-update hook that applies default settings for fields. Please remember to export your configuration after updating to avoid losing changes on the next import.

As for the validation error:

Error message
The submitted value plain_text in the Text format element is not allowed.

Unfortunately, we don't have a proper fix for this yet. plain_text is a valid format, and forcing its change just because it's a fallback would be a bad approach. All we can suggest is enabling its usage by editing the configuration. This will allow it to be used and will avoid the validation error:

drush config:set filter.settings always_show_fallback_choice TRUE

kksandr → changed the visibility of the branch 3472997-fixes to hidden.

Thanks for the follow-up. Yes, I meant 4.0.x. Despite the "beta" label, it's the stable and recommended version for testing and production. The 4.0.x branch is a full rewrite with proper test coverage, and I'm confident in its stability.

All further development will continue in 4.0.x. Older versions (like 3.x) will be deprecated soon due to architectural limitations.

If the issue still occurs in 4.0@beta feel free to follow up.

That's a good idea, let's do it that way.

kksandr → changed the visibility of the branch 3472997-rewrite-module-to to hidden.

This has been fixed in version 4.0.0-beta1. The caption and caption_format are now field properties, so they are available as tokens.

Thanks for the report. This issue refers to an outdated version of the module (8.x-1.x-dev), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest version (4.0.0-beta1). If it does, feel free to update this issue or open a new one with details.

Thanks for the report. This issue refers to an outdated version of the module (8.x-1.2), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest version (4.0.0-beta1). If it does, feel free to update this issue or open a new one with details.

Thanks for the report. This issue refers to an outdated version of the module (8.x-1.x-dev), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest version (4.0.0-beta1). If it does, feel free to update this issue or open a new one with details.

This has been fixed in version 4.0.0-beta1. The caption and caption_format are now field properties, so you can work with them just like alt or title.

Thanks for the report. This issue refers to an outdated version of the module (8.x-1.x-dev), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest version (4.0.0-beta1). If it does, feel free to update this issue or open a new one with details.

Thanks for the report. This issue refers to an outdated version of the module (8.x-1.2), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest version (4.0.0-beta1). If it does, feel free to update this issue or open a new one with details.

This has been fixed in version 4.0.0-beta1. Please try the latest release and feel free to reopen or create a new issue if needed.

Thanks for the report. This issue refers to an outdated version of the module (2.0.x), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest stable version (4.0.x). If it does, feel free to update this issue or open a new one with details.

Thanks for the report. This issue refers to an outdated version of the module (2.0.x), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest stable version (4.0.x). If it does, feel free to update this issue or open a new one with details.

Thanks for the report. This issue refers to an outdated version of the module (2.0.x), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest stable version (4.0.x). If it does, feel free to update this issue or open a new one with details.

Thanks for the report. This issue refers to an outdated version of the module (2.0.x), which is no longer supported. The 4.0.x release includes significant changes, and this problem may already be resolved.

Please check if the issue still occurs with the latest stable version (4.0.x). If it does, feel free to update this issue or open a new one with details.

Was fixed here: 🐛 Issue with first time saving the image caption of an image field. ( Paragraph ) Active .

Alright, I’ve closed the MR that only included the test to avoid any confusion. I’ve also changed the target branch to 11.x.

I’ve added two branches:

1. 3537774-validation-test - contains only a test to demonstrate the issue.
2. 3537774-validation-fix - includes both the test and the fix.

kksandr → created an issue.

Funny enough, the order of operations between && and = was also the problem behind #3403999: Exposed filter values ignored when using batch.

@godotislate These are two completely different cases.

kksandr → changed the visibility of the branch 10.3.x to hidden.

kksandr → changed the visibility of the branch 11.x to hidden.

The issue has been fixed in 2.x: #3265219: Fix coding style issues and achieve phpstan lvl6 → , 📌 Drupal 11 compatibility Needs work

Will be fixed here: 🐛 Issue with first time saving the image caption of an image field. ( Paragraph ) Active .

Will be fixed here: 🐛 Issue with first time saving the image caption of an image field. ( Paragraph ) Active .

Will be fixed here: 🐛 Issue with first time saving the image caption of an image field. ( Paragraph ) Active .

Will be fixed here: 🐛 Issue with first time saving the image caption of an image field. ( Paragraph ) Active .

I confirm that the handling of the absence of $value['image_field_caption']['value'] is correctly implemented here, and it resolves the issue of the value disappearing during repeated programmatic entity saves (not through forms).

I am also redirecting this MR to the 2.0.x branch, as a completely new implementation of the module is planned for the 3.0.x branch.

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

Yes, I will add such processing for images that are corrected by this module.

But always checking all images, loading them to get the real resolution will be too resource-intensive task and is far beyond the scope of what this module works with.

So if you want to have such processing for all images, I think you should look for a solution elsewhere.

Fixed in #3461212-6: FlagFollowerUITest failing since new access policy was committed to core →

I thought that an access denied would be sufficient to redirect to (or show subrequest of) the next path in the dynamic link

You understand everything correctly. All links in the specified order are checked for access and if there is an accessible one, it will be shown. If all links return access denied then the result will be an access denied. Are you sure that the next link in the list is accessible for the user you are testing?

If you are sure that the configuration is correct, then perhaps there is an error in the module, in which case it is necessary that you provide an example of the view configuration and dynamic link to investigate your case.

The edit has been corrected. Also, the test coverage has been updated to detect such cases.

I find this fix useless because I can't reproduce this issue on 7.0.0-beta1 or 6.0.6 following the steps in the issue. The patch looks like it disables this and makes this code dead, so yes it does solve the problem, but not very well. It's very strange that there is no test case here and the fix is ​​already merged and released.

Same problem, pager is broken after this fix. Rolling back to 7.0.0-beta1 also solves the problem.

@hmdnawaz I use phpredis, so it's class: Redis, which is the global class provided by that PHP extension.

This event was added to editors in version 8.0-alpha3~680 11 years ago, so it is compatible with Drupal 8 which the module claims to support.

kksandr → changed the visibility of the branch 2.1.x to hidden.

kksandr → created an issue. See original summary → .

This issue is still happening, I have added steps to reproduce it.

kksandr → created an issue.

@ddrozdik was there a response from @WorldFallz?

kksandr → created an issue.

I updated the steps to reproduce the issue according to the updated test and opened a merge request with the fix.

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

kksandr → created an issue.

I made the error message more descriptive using "Error::logException()". This will be useful because some exceptions do not have a message (as in the case of "FormAjaxException") and their cause is implied in the name of the exception class.

Yes, exactly them. Now I completely override the style library of this module like this:

:root {
  --hphp-color-comment: #696969;
  --hphp-color-red: #d91e18;
  --hphp-color-orange: #aa5d00;
  --hphp-color-yellow: #aa5d00;
  --hphp-color-green: #008000;
  --hphp-color-blue: #007faa;
  --hphp-color-purple: #7928a1;
  --hphp-color-bg: #fefefe;
  --hphp-color-fg: #545454;
  --hphp-border: 4px solid #d4d4d8;
  --hphp-indent: 0.5em 0.5em 0.5em 20px;
}

.dark-mode {
  --hphp-color-comment: #d4d0ab;
  --hphp-color-red: #ffa07a;
  --hphp-color-orange: #f5ab35;
  --hphp-color-yellow: #ffd700;
  --hphp-color-green: #abe338;
  --hphp-color-blue: #00e0e0;
  --hphp-color-purple: #dcc6e0;
  --hphp-color-bg: #2b2b2b;
  --hphp-color-fg: #f8f8f2;
  --hphp-border: 4px solid #43454a;
}

/* Comment */
.hljs-comment,
.hljs-quote {
  color: var(--hphp-color-comment);
}

/* Red */
.hljs-variable,
.hljs-template-variable,
.hljs-tag,
.hljs-name,
.hljs-selector-id,
.hljs-selector-class,
.hljs-regexp,
.hljs-deletion {
  color: var(--hphp-color-red);
}

/* Orange */
.hljs-number,
.hljs-built_in,
.hljs-builtin-name,
.hljs-literal,
.hljs-type,
.hljs-params,
.hljs-meta,
.hljs-link {
  color: var(--hphp-color-orange);
}

/* Yellow */
.hljs-attribute {
  color: var(--hphp-color-yellow);
}

/* Green */
.hljs-string,
.hljs-symbol,
.hljs-bullet,
.hljs-addition {
  color: var(--hphp-color-green);
}

/* Blue */
.hljs-title,
.hljs-section {
  color: var(--hphp-color-blue);
}

/* Purple */
.hljs-keyword,
.hljs-selector-tag {
  color: var(--hphp-color-purple);
}

.hljs {
  overflow-x: auto;
  display: block;
  padding: var(--hphp-indent);
  color: var(--hphp-color-fg);
  white-space: pre;
  background: var(--hphp-color-bg);
  border-inline-start: var(--hphp-border);
}

.hljs-emphasis {
  font-style: italic;
}

.hljs-strong {
  font-weight: bold;
}

But it would be great if a dark theme could be created by simply overriding variables by extending the existing library in the theme.

I came across this request several times, maybe someone else needs it, so I suggest introducing an option for this.