That seems to fix it, thanks!
Yeah, you're right. Let's just not do this then. Don't you agree it's a bit unnecessary to try and hide the password on a non-public, admin settings form?
Should be possible if you grant the role the permission to view revisions. That permission only applies to nodes the user already has permission to see.
Thanks for your input! You're right, probably not the best idea. It was worth considering though :).
We'll have to drop support for PHP 7.3 if we're adding property types, but I think that's acceptable. Left some comments in the MR.
dieterholvoet → created an issue.
CKEditor 45.0.0 has been released with support for full screen mode: https://github.com/ckeditor/ckeditor5/releases/tag/v45.0.0
I opened
📌
Update CKEditor 5 to 45.0.0
Active
to update CKEditor in core.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
The changes in this merge request break backwards compatibility. If someone configured an ignore list with paths with language prefixes, those rules won't work anymore. I think it would be better to check both with and without language prefixes, to make sure we don't break any existing setups. Or we could change the ignore list in an update hook to remove any language prefixes from existing rules.
I tested adding aliases to the ignore list, that works as it should.
That's weird, I have a website using Domain Access, but I can't reproduce this issue. When I attempt to open the node as a non-authenticated user on domain B, it just redirects to the login form on domain B.
mparker17 and louis-cuny seem to be the only active maintainers in the past 2 years. Only mparker17 has their contact tab enabled, so only sending him a message for now. This is the message:
Hi,
Could you post a comment on my offer to co-maintain Structure Sync ( https://www.drupal.org/project/structure_sync/issues/3517380 💬 Offering to maintain Structure Sync Active )? I would like to become a co-maintainer of the module to help resolve any pending and future issues.
Thanks in advance,
Dieter Holvoet
dieterholvoet → created an issue.
Same question as solideogloria, any reason Drupal\Core\Queue\QueueFactory doesn't implement the new interface?
dieterholvoet → created an issue.
Yeah, ideally we would generate entity type classes implementing only the necessary interfaces, like the Trash module generates entity storage classes, but as long as that's not completely necessary I'd like to avoid adding that complexity to the ECK module.
I just thought about something. Most getters/setters in Drupal\eck\Entity\EckEntity have a hasField() check for this exact situation, while the isPublished() / setPublished() / setUnpublished() methods don't. I'll fix this issue that way. Thanks for your input berdir.
Fixed, tests are passing.
Seems like adding those uidowner keys created some new expectations, we have a failing test:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'uid' cannot be null
Don't think this really needs additional tests.
If you implement EntityPublishedInterface then isPublished() and setPublished() are expected to work.
ECK allows for entity types to optionally enable the published field, but all ECK entities share the same base class. Drupal\Core\Entity\EntityPublishedTrait::publishedBaseFieldDefinitions() checks both the presence of the interface and the presence of a published key, so we should probably do the same here. That, together with
🐛
Entity keys should only be added to an entity type if they are enabled
Active
, would fix this issue. I'll work on getting that fix in ECK first.
dieterholvoet → created an issue. See original summary → .
dieterholvoet → created an issue.
The module doesn't let you manually create settings entities, it creates 1 entity automatically. You might still be able to manually create entities with user 1 since that user bypasses all access checks, but there isn't much we can do about that.
I think I found a fix, could you test the changes from the MR?
dieterholvoet → created an issue.
dieterholvoet → created an issue.
Every setting (bundle) has always 1 and only 1 associated entity. That's something we're not going to change. If you need multiple instances of the same bundle, I recommend you use the Site Settings and Labels module → or you create a setting with a multiple entity reference field referencing another bundle, using the Inline Entity Form widget → .
@fgarciap I have been testing and if I understand your issue report correctly, it looks like this doesn't work when the user is author either. If a user doesn't have the 'access content' permission, having the 'view own unpublished content' permission isn't going to make a difference. If a user has the 'access content' permission, it has access to all content, including unpublished content. Your snippet in the issue description doesn't fix the issue, did you test it?
This would also fix the following issues:
dieterholvoet → created an issue.
Almost forgot, but we'll have to bump the minimum core version to 10.1.0 since that's when some of the permissions were added.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Drupal 7 is EOL as of 5 January 2025 and so is the Drupal 7 version of this module. Marking as Closed (won't fix). Feel free to re-open if this issue is still present in any supported version of the module.
Thanks!
We should probably also look into deprecating the outdated permissions. Since there isn't an official way to deprecate permissions yet (see 📌 Provide a mechanism to deprecate permissions Needs work ), we could update the label/description.
dieterholvoet → changed the visibility of the branch 3428241-automated-drupal-11 to hidden.
Looks like the core_version_requirement wasn't updated, will create a new commit for that.
dieterholvoet → made their first commit to this issue’s fork.
Also, the default branch is outdated and I don't seem to have permission to change it: 📌 Change default branch to 8.x-1.x in Gitlab Active .
dieterholvoet → created an issue.
dieterholvoet → made their first commit to this issue’s fork.
Thanks! Unrelated question: I noticed the D7 releases have been marked as unsupported. Would it be okay for you if I close any D7 issues as won't fix?
dieterholvoet → created an issue.
It doesn't seem like a good idea to duplicate all schema of the email handler this handler extends. That way, any time something changes in the parent handler, this handler will need to be manually updated as well.
Did you test version 1.0.0-beta2 or higher? Because since that version the config schema is set in config/schema/webform_email_confirmation_link.plugin.handler.schema.yml and altered in the webform_email_confirmation_link_config_schema_info_alter() hook. If something is not working as expected, those files should be fixed.
@benstallings could you confirm if the latest versions of both modules fixed the issue you're having?
@larowlan could we move this forward? All important issues are ready for review or reviewed. I'd be happy to become co-maintainer and prepare a new release.
I created a new MR on 11.x and rebased the existing changes.
dieterholvoet → changed the visibility of the branch drupal-3075230-3075230-provide-menu-link to hidden.
dieterholvoet → changed the visibility of the branch 11.x to hidden.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
The proposed fix here overlaps with the one in 🐛 Warning: Undefined array key "min" in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput() (line 437 of core/modules/views/src/Plugin/views/filter/NumericFilter.php) Needs work .