Priority needs to be given to updating the MR; posting a patch without updating the MR will not move this issue forward.
✨ Expose UUID tokens for all content entities in Drupal core Active has been committed to 11.x.
I was using a patch in this issue to generate UUID tokens for custom entities, but I am now able to remove the patch and I still have UUID tokens as a result of the change referenced above.
Is there still a need for this issue? It seems like it has now been fixed upstream for most? use cases.
This was marked "RTBC" but no tests have been added. I think this still needs a test to confirm that the non-deletion behavior works as expected.
Updated the IS. This is definitely caused by the CR I linked to earlier, and MR146 fixes the issue, so I'm marking RTBC.
Ok, cool. Should we add the tamper attributes to the existing plugins (without removing the annotations)? I'm pretty sure the only thing this requires is PHP 8.1.
Well, that was a way bigger pain than I expected :/
But I fixed the tests. It seems that whitelist and blacklist have a block because they want us to use "allowList" now, but since these are parameters, we can't actually change that. So I ignored the lines individually.
Pipeline had this error:
*****************************************************************************************************************************
This project contains a top-level directory named 'web' which is the same as the variable _WEB_ROOT. This variable defines the location for installing Drupal core and the clash may cause some jobs to fail or give misleading results.
To resolve this, you can either rename the directory within your project or set a different custom value for the _WEB_ROOT variable. The name can be anything other than an existing directory in your project.
*****************************************************************************************************************************
There was an empty file, web/.gitkeep, so I removed it. I don't actually know what this file was for, though. Is it safe to remove?
https://www.drupal.org/project/jsonapi_extras/issues/3489101 📌 PHP 8.4/phpcs: implicit nullable deprecation Active
Please add an MR instead of a patch. Drupal.org CI infrastructure only runs the module's tests on MRs, not patches.
Drupal itself is GPL-2: https://www.drupal.org/about/licensing#drupal-license →
So if you are worried about GPL-2, you should consider another project.
The issue occurs because this module's composer.json has the following:
"psr-4": {
"Drulma\\": "./src/"
}
As far as I can tell, this only affects the Render callback, which should be namespaced to Drulma instead of Drupal according to the composer.json. But this is not the way Drupal modules are usually written, so I am opening a PR to remove this instruction.
ptmkenny → created an issue.
ptmkenny → created an issue.
Welcome back and I'm glad this solution works for you!
Since the module has GitLab CI tests now, we need an MR, not a patch, because the CI tests are only run for MRs, not patches.
Please add an MR, not a patch. This module runs automated tests via GitLab CI, but only MRs get tested, not patches. So we need an MR to run the tests.
Ok, I looked into this more, and I think this may be a problem with the Data Field module, not Field Encrypt.
foreach ($field_types as $name => $field_type) {
// Special handling for preconfigured definitions.
// @see \Drupal\Core\Field\FieldTypePluginManager::getUiDefinitions()
$type = str_starts_with($name, 'field_ui:') ? $field_type['id'] : $name;
$field_definition = BaseFieldDefinition::create($type);
$definitions = $field_definition->getPropertyDefinitions();
In this code, we are pulling in all the field types, including those with PreconfiguredFieldUiOptionsInterface. These preconfigured definitions do NOT include a name property, so the "special handling" gets the actual field type ID so that it can call BaseFieldDefinition::create(), and then we access getPropertyDefinitions().
It seems that DataFieldType relies on field_name being set, but this is not true for PreconfiguredFieldUiOptionsInterface field types.
Committed and will be in the next beta, thanks everyone!
@megakeegman Thanks for rebasing. Have you encountered this error, and does the MR fix it for your site?
Thank you for rebasing, but the tests are now failing.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
This has been handled, and we are going to move forward with 1.1, not 2.x, so I'm closing this.
@vodde83 If you change the path in a module like JSON:API Extras, you have to take responsibility yourself for modifying the path; this module doesn't have a way to determine what overrides you may have made.
Hopefully @ro-no-lo, as the author of the code, can describe how it is supposed to work.
ptmkenny → created an issue.
The MR needs to be rebased. I won't be working on this further, but I will commit the code if it gets rebased and tested.
New features now need to go into 2.0.x. 1.x will only receive security fixes.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
This is blocked on 📌 12: Use getOriginal() not ->original Active
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
JSON-RPC 3 beta 1 has been released, so let's move to support it.
ptmkenny → created an issue.