I disagree that it should be on a different page.
The Drupal community selected DDEV as the recommended local development environment in June 2024.
https://www.drupal.org/docs/getting-started/installing-drupal/install-dr... →
Can someone verify that the issue is reproduceable and fixed by the changes?
Re-adding the previously removed issue, now that the issues it depended on are closed.
I had the admin role and the module's permissions were given to it. This was on Drupal 10.5
solideogloria → created an issue. See original summary → .
The module page should be updated to remove the warning pointing to this issue.
If we're going to be consistent with parameters and return types, then there definitely shouldn't be a space around them. It looks better without.
Note that this is also the issue that is causing PHPCS to fail in the CI pipeline, so merging this will fix that stage.
Bump. It would be great to get this merged and included in a release.
Can we have a new release that contains these fixes, please?
Confirmed that applying the changes removes the deprecation warning seen when using PHP 8.4.
Can we get this merged, please? I confirmed that it fixes the issues.
Updating title and priority. Compatibility with PHP 8.4 is not a minor issue.
If the text is updated, then should the casts themselves be deprecated if an old type? Currently, it has this:
elseif (is_string($value) && preg_match('/^\((int|integer|bool|boolean|float|double|real)\)\s*(.+)$/', $value, $match)) {
$type_cast = $match[1];
$type_value = $match[2];
switch ($type_cast) {
case 'int':
case 'integer':
$data[$key] = (int) $type_value;
break;
case 'bool':
case 'boolean':
$data[$key] = (bool) $type_value;
break;
case 'float':
case 'double':
case 'real':
$data[$key] = (float) $type_value;
break;
}
We could log a warning or something if an old type is used.
I don't see any changes that fixed this. Why is it Needs Review?
Also, there are no 2.x branches on GitLab.
This is a section I'm not sure about:
$form['additional']['cast'] = [
'#type' => 'checkbox',
'#title' => $this->t('Cast posted element value and custom data'),
'#description' => $this->t('If checked, posted element values will be cast to integers, floats, and booleans as needed. Custom data can be cast by placing the desired type in parentheses before the value or token. (i.e. "(int) [webform_submission:value:total]" or "(int) 100")') .
'<br/>' .
'<br/>' .
$this->t('For custom data, the casts allowed are:') .
'<ul>' .
'<li>' . $this->t('@cast - cast to @type', ['@cast' => '(int), (integer)', '@type' => 'integer']) . '</li>' .
'<li>' . $this->t('@cast - cast to @type', ['@cast' => '(float), (double), (real)', '@type' => 'float']) . '</li>' .
'<li>' . $this->t('@cast - cast to @type', ['@cast' => '(bool), (boolean)', '@type' => 'boolean']) . '</li>' .
'</ul>',
'#return_value' => TRUE,
'#default_value' => $this->configuration['cast'],
];
Should the allowed casts be updated in this element? I left this as-is.
solideogloria → changed the visibility of the branch 3558621-php-8.5-compatibility-2 to hidden.
I don't actually use D11 yet; I just happened to notice that lack of compatibility in the version listing.
Perhaps you could message @pavelculacov → , since he was helping with 📌 Drupal 11 version Needs review ?
solideogloria → created an issue. See original summary → .
solideogloria → created an issue. See original summary → .
Here is how to patch it automatically with Composer as a workaround.
Download the patch and add the following to your composer.patches.json file:
"codemirror/codemirror": {
"#3531472: Drupal 10.5 / 11.2 incompatibility": "./patches/ckeditor_codemirror-codemirror-LIBRARY-3531472-copyobj-hasownproperty-fix.diff"
},
Or use the URL:
"codemirror/codemirror": {
"#3531472: Drupal 10.5 / 11.2 incompatibility": "https://www.drupal.org/files/issues/2025-11-13/ckeditor_codemirror-codemirror-LIBRARY-3531472-copyobj-hasownproperty-fix.diff"
},
I apologize for the long and bulky file name. I wanted it to be clear that the file is patching the library and not the Drupal module, while still making it clear which module and issue it is for.
Note that the codemirror.js file that is patched does not exist in the GitHub repo. It is probably a build artifact or is specific to an older version. Regardless, I manually created the patch file line by line to apply to the file, and the patch file works.
Re #16,
Had tried the suggested fix in the docroot/libraries/ckeditor5-source-editing-codemirror/src/sourceeditingcodemirror.js file.
The library wouldn't use the code in the src folder, it uses the minified code file in the build folder.
solideogloria → changed the visibility of the branch 3531472-drupal-10.5- to hidden.
The route for that form says the functionality is not implemented
ultimate_cron.logger_settings:
path: '/admin/config/system/cron/settings/logger'
defaults:
_form: '\Drupal\ultimate_cron\Form\LoggerSettingsForm'
_title: 'Logger settings'
requirements:
# Form disabled as functionality is currently not implemented.
_access: 'FALSE'
The code in the patch doesn't look like what the module's code has now. Does the issue still occur in the current version?
solideogloria → made their first commit to this issue’s fork.
I think 50 or 100 would be more reasonable. 1000 seems too high. I would probably choose 50, as that's the number of rows displayed in /admin/people or other similar screens.
This module is essentially doing nothing when on these versions of Drupal. I don't know how to contribute toward fixing this.
The PHP standards are voted on by the voting members of the group. See https://www.php-fig.org/faqs/
I've been using 3.x successfully in production for more than 2 years.
Do you get the same error as in the issue summary when you view the report? If not, maybe open a separate issue.
DER was removed, but the content depends on it. You have to remove all link data then rescan if you don't want it to break. That's the entire reason for this issue, and it's the workaround mentioned in comment #2.
A fresh module install shouldn't have any issues. If you remove it then re-add the module, it should work.
Can you create an initial release for 5.0.x, even if an alpha release?
Shouldn't we just go right for version 2.x of the library? I guess we could do that in a follow up.
I agree, that should probably be a follow-up. The README for this module doesn't have instructions for how to use that version, either, as this module's README mentions the dist folder. And if it no longer exists in the library, the code won't be able to reference the files that were previously there.
There are at least a couple issues on GitHub where users are asking for documentation for 2.x and how to migrate from v1 to v2. That information doesn't seem to have been added yet, so it will probably be best to wait to use 2.x for now.
@bkosborne It will work. Just look at the MR. It updated the URL to be https://github.com/fengyuanchen/cropperjs/archive/refs/tags/v1.6.2.zip
If you download that file and look inside the dist folder, it has all the files that the code references. So what about it would not work?
Contributed and custom modules using composer-merge-plugin: The managing dependencies for a custom project documentation previously recommended using the composer-merge-plugin to manage external dependencies added by a custom project. If you have a site that followed this advice, you will need to examine your root composer.json file to ensure that your dependencies will continue to be included. There are two options available. First, you could use a path repository, as now recommended in the documentation. Alternately, you could make sure that the composer-merge-plugin remains in your root composer.json file, and is configured appropriately to include your custom modules' composer.json files. Switching to a path repository will provide a performance improvement for Composer operations.
You should add the library stuff to the image_widget_crop module's composer.json file, right? That's what the linked Drupal change record → seems to indicate.
That issue was already resolved. See composer.libraries.json. As long as this file shows the correct libraries, the composer merge plugin will work.
I do agree that MR 7117 is not the way to go. It's not flexible at all, as it won't work for anything added/changed by contrib.
in_array($element['#type'], ['radios', 'checkboxes']);
This is a hardcoded list of types. Not flexible.
@smustgrave What do you think about moving the isComposite method to a Trait or abstract class? The check should probably be extensible, so that contrib modules can add composite elements to the list. See
comment #40
🐛
Broken aria-describedby in radios and checkboxes.
Needs work
@meanderix Though it doesn't solve the problem, this might be relevant for you: https://drupal.stackexchange.com/questions/220173/suppress-watchdog-a-sp...