Thank you!
Ok, now I also see this. With gin 3.0.0-rc13 it still works so it has to be a recent change.
Hey @jeroent. Do you have some more information about the versions you have installed? I setup a fresh installation of Drupal 10.3.6 with paragraphs_ee dev and gin 3.0.0-rc14 and the buttons are centered and styled correctly.
Could you please be more specific about the versions you are using. I've tested this in a fresh installation with Drupal 10.3.6, Gin RC3 and the latest development version of Paragraphs EE and it worked as expected.
MR10044 contains the correct changes.
I rebased the branch with 11.x and the test errors are gone. It is not clear to me how the change could lead to these test failures.
There is no reason to be annoyed. You both tried to solve the problem.
I created a new branch based on your changes.
Thanks a lot! The call to ->getThirdPartySettings()
was totally wrong, indeed. I fixed this based on your suggestion.
stborchert β changed the visibility of the branch 3482067-drupal.views.parsequerystring-returns-incorrect to hidden.
stborchert β created an issue.
stborchert β changed the visibility of the branch 2.x to hidden.
stborchert β changed the visibility of the branch 3224400-2.x-missing-resizeobserver-api to active.
stborchert β changed the visibility of the branch 2.x to active.
Could you please add some steps how to reproduce this error.
Thanks for your help!
stBorchert β made their first commit to this issueβs fork.
I've committed the attached logo to the repository. See https://www.drupal.org/project/paragraphs_ee/issues/3466037 π Add logo for Project Browser Fixed
This is the way ...
Massive thanks to bitingDuke β for the logo!
stBorchert β created an issue.
Closing as version 2.x is outdated and not supported anymore.
Please reopen if you've got more information how to reproduce this.
Thanks a lot. I missed that.
stBorchert β made their first commit to this issueβs fork.
Hey, ParagraphsEE maintainer here. Thanks for pushing this forward.
Unfortunately, I'm not really happy with any of the suggestions. We will try to come up with an alternative.
Created a new release for Drupal 10.3+
Thanks for reminding me about this.
I've updated the MR with some necessary changes and rebased it onto the 11.x branch.
stBorchert β made their first commit to this issueβs fork.
stBorchert β made their first commit to this issueβs fork.
Hm, I don't see how this is related to the changes in the MR ... https://git.drupalcode.org/issue/drupal-3449991/-/jobs/1705056#L5182
I've added a new branch and pushed my changes to it.
@smustgrave Could you please create a new MR for it? I don't seem to be able to do this (https://git.drupalcode.org/issue/drupal-3449991/-/merge_requests/new results in a 404).
Hm, maybe it's because I've branched from 11.x and not 11.0.x?
I've added a test to Drupal\KernelTests\Core\Database\InsertTest and Drupal\KernelTests\Core\Database\UpsertTest and a small change to Upsert::preExecute()
.
Without the change, the test method in UpsertTest will fail.
stBorchert β created an issue.
> just broke some sites again, since an enabled module is no longer available, as it's removed from the requirement list
Uhm, I hate to say this, but you should always export your configuration if you change anything on your site (including updating modules). If you did, the list of enabled modules is saved to {config-export-directory}/core.extension.yml and no module is uninstalled accidentally because it isn't required by other config anymore.
At least the release notes should have made some notes about the changes and possible outcomes.
Great!
> For term merge submodule issues let's open new issues.
Uhm, the merge request already includes the new submodule: Taxonomy Manager Merge. All code related to the integration of Term Merge went into this module.
I've reverted the commits integrating Term Merge and added a submodule to provide the functionality.
Created a merge request based on the previous patches and that works for us.
stBorchert β changed the visibility of the branch 8.x-5.x to hidden.
stBorchert β changed the visibility of the branch 6.0.x to hidden.
This error still exists in 6.0.x. The patches doesn't apply though.
As JΓΌrgen already said, simply enabling the module in an update hook won't work. Using automatic deployments you cannot simply run drush updb
multiple times, they will break on errors.
If some parts of your code rely on external modules, it's advisable to move this code into a submodule. In this case, all code related to MergeTermForm
should live in a submodule of Taxonomy Manager.
Otherwise you'll break the majority of the sites having Taxonomy Manager.
We had tried to solve the problem somehow, but unfortunately it doesn't work that way.
So the arrows must all remain visible :(
Thanks for finding this!
Are you sure, this is caused by ParagraphsEE? The error locates the source in the Paragraphs widget but I doubt, ParagraphsEE causes this.
Please test without ParagraphsEE ...
Woah ... while adding some tests I noticed something way really off. So I had to rewrite some parts of the AccessHandler π
Great.
I'll try to add some more tests to catch some edge cases and will merge the changes.
Hey @volodymyr.umanets. I've made some changes and pushed it into MR 2. Could you please review the changes and test if that works for you?
Ok, I see. UserAccessControlHandler is not replaced entirely, but my service is decorating Drupal\Core\Entity\EntityAccessControlHandler. It only wraps some of its methods and adds some functionality.
Unfortunately, in case an AccessControlHandler extending the core EntityAccessControlHandler overrides a function that exists in Drupal\Core\Entity\EntityAccessControlHandler it wouldn't be called after decorating.
Hm, I need to think about a while and search for a way to call the extending classes method.
Hey.
Drupals UserAccessControlHandler overrides tow methods of EntityAccessControlHandler: checkAccess()
and checkFieldAccess()
. Both methods are not overridden by the entity access control handler defined by pACH so pACH doesn't change anything defined in UserAccessControlHandler.
Do you have other modules installed controlling access to entities? In your screenshot I see "domain_alias" for example ... Could you please post some more details about your setup?
Thanks for sharing. That will help others hopefully, too.
Quick question: is there any reason why you don't use version 10.x of ParagraphsEE?
Hey. We use the latest patch and it breaks creating content when using content moderation for content types.
Steps to reproduce
:
- setup a default workflow for content moderation ("Draft", "Published")
- set the initial state to "Draft"
- select a content type (e.g. "Page") to use the workflow
- go to node/add/page (or whatever your selected content type has been named)
- do no update the workflow state (leave as "Draft")
- save the node
This will result in
EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' cannot be null ...
This happens because the patch explicitly sets the value of field "status" to NULL
:
$items->setValue(NULL);
This is wrong for fields that must not be null (based on their schema), e.g. for "status" null-values are not allowed.
@TejaVardhanReddy Patches are always created to the development branch, not existing releases. 8.x-1.0 is already released and cannot be changed anymore.
Additionally, when providing a patch, please add an
interdiff β
, so reviewers can see what has changed since the last patch.
Hey.
I tried to reproduce this behavior using the latest development version but it works without any problems here.
Could you please use the latest dev version and try again?
Why wait ... I've merged the changes into 10.0.x π
Done :)
@ras-ben cool :)
I've rewritten some parts of the MR some hours ago so the buttons are attached to the drag handle (like you do in your patch) and added using JS (and not as render elements).
This is how it looks like right now:
I'm still working on the Gin integration and will commit it hopefully today to the MR.
I've opened a merge request based on the work of DuaelFr β in https://www.drupal.org/project/paragraphs_features/issues/3345478 β¨ New feature: drag and drop arrows Needs review .
I've changed some styling so the arrows are highlighted (at least a little) on focus/hover: https://www.drupal.org/files/issues/2024-02-20/paragraphs_ee-drag_drop.mp4 β
@DuaelFr Assuming you agree, I would simply add the feature to ParagraphsEE. @see https://www.drupal.org/project/paragraphs_ee/issues/3246408 β¨ Arrow buttons instead of drag n drop? Active
Closing this due to lack of activity and no further reports.
Thanks for the MR. Wouldn't hurt if validation is generally disabled for the button :)
stBorchert β made their first commit to this issueβs fork.
Sorry about the noise ... didn't find the already fixed issue π
stBorchert β created an issue.
Hi Viktor.
Thanks for offering your help. I warmly welcome you as a new maintainer for Multi-path autocomplete :)
Sorry, I f*d up MR5. Created a new branch: https://git.drupalcode.org/project/require_on_publish/-/merge_requests/15
Credits go to @AndreRB and @SteffenR
stBorchert β made their first commit to this issueβs fork.
This has been fixed after creating the release for 3.0.1 so the fix isn't included in this release.
It is fixed in the latest development version: https://git.drupalcode.org/project/paragraphs_sets/-/blob/3.0.x/paragrap...
Thanks for the patch. We stumbled across this issue after updating to Drupal 10.2 and all paragraph forms were broken.
Without the patch you'll get the following javascript error:
Cannot read properties of undefined (reading 'colSpan')
stBorchert β made their first commit to this issueβs fork.
Hey @volodymyr.umanets. While adding tests to the latest version I noticed some error when decorating UserAccessControlHandler. Maybe these are the reason for your issue ... could you please try version 2.0.3 (or 10.0.0 if you are already on Drupal 10.2).
Thank you.
see β¨ New feature: drag and drop arrows Needs review
Sorry, but that won't work. I will not ship Paragraphs EE with a complete copy of Claro's styles.
Paragraphs Features is not built to work with themes not depending on Claro and so will Paragraphs EE. Maybe optionally loading the required libraries from Claro would do but I believe this will break other stuff.
How did you manage to get the "Add-in-between" buttons working without using Claro (at least as the base theme for your theme)?
Paragraphs Features requires
this patch
π
Add-in only works if active theme is claro or gin
RTBC
to make the buttons work in subthemes of Claro or Gin. Other themes won't work.
stBorchert β created an issue.
Since the module is compatible to 9.3+ also and the hook is removed in Drupal 10 it should be left as is unless Paragraphs Sets is compatible to Drupal 10 only.
Thanks for the fix. It would be very interesting to know, where paragraphs_set_load()
is called from ...
Thanks a lot.
Please update to version 3.0.1 or the latest development version. This error has been fixed a while ago (commit 4a79bb).
stBorchert β made their first commit to this issueβs fork.
Thanks for the patch. Seriously, who uninstalls this module? π
stBorchert β made their first commit to this issueβs fork.
It's very strange. I didn't see this error before but now it is there :)
Thanks for the update.
While I couldn't reproduce this behavior it totally makes sense to loop over the wrappers here. Thanks for you patch.
I rebased branch 2854585-improve-icon-selection with 8.x-1.x and improved the calls to file_create_url()
resp. the file_url_generator service.
Update to the information provided by @aschiwi:
I've debugged through the access hooks called when viewing the node and every involved hook (*_entity_access()
, *_node_access()
returns AccessResult::neutral()
.
domain_access_node_grants()
returns an array referencing the assigned domain record and true for all grants:
<?php
$grants['domain_id'][0] = 3187922; // This is the domain_id of the domain assigned to the node.
$grants['domain_site'][0] = 0;
$grants['all'][0] = 1;
?>
So there is no module restricting access to this node. According to the code domain_access doesn't care about restricting access to published nodes (see domain_access.module#352):
<?php
// In order to access update or delete, the user must be able to view.
// Domain-specific permissions are relevant only if the node is not published.
if ($op === 'view') {
if ($node->isPublished()) {
// Explicit restatement of the condition, for clarity.
$allowed = FALSE;
}
elseif ($account->hasPermission('view unpublished domain content') && $manager->checkEntityAccess($node, $account)) {
$allowed = TRUE;
}
}
?>
I think we need to add an own implementation of hook_node_access()
restricting the view permission to published nodes (using domain_entity_get_user_available_domains() from domain_entity).