From further testing today, I've found that it's possible to get the same problem without using copy/paste, also without paragraphs clipboard installed.
So, cause is not paragraphs clipboard. It may be due to an invalid configuration, or some issue with Layout Paragraphs module, but I'm closing this ticket - works as designed.
I've tested support for Layout Paragraphs using the Layout Paragraphs widget together with the Layout Paragraphs Clipboard submodule.
Basic copy/paste works, so I'm marking this issue as RTBC. Separate issue #3488737 still needs to be resolved.
RTBC see #5.
Hi @hhvardan. I've tested 3485091-improve-behaviour-for:
* Confirmed the copy to clipboard link is disabled for a new unsaved paragraph using the default widget.
* Confirmed the copy to clipboard icon/button is not shown new unsaved paragraph using the Layout Paragraphs widget.
So, the issue here is fixed.
Additional: I realised while testing, there's a related issue: if you change an existing paragraph without saving, then of course copy to clipboard will copy the original version, not the edited version. I think we have to accept that as a limitation, at least for the initial release. Later, if we can make it to copy the edited version of a paragraph, and maybe even a new one, that would be great.
andy inman → created an issue. See original summary → .
andy inman → created an issue.
Just a note that we have expect to be releasing a module which will do this, or at least meet the same objective, I think. It's already "finished" and working for a specific client. It just needs a bit more work to generalise and polish, before publishing.
It takes a different (and more flexible) approach to what's discussed here, but if I'm understanding correctly what the need is in this ticket, then I think it will meet it.
andy inman → created an issue.
Retested with the latest (1.0.0-beta5), all ok now.
* It's no longer possible to paste a previously copied paragraph into a translation.
* Plegar means collapase, not paste - my mistake - that button is meant to be there.
* The yellow triangle warning shown for a collapsed paragraph means "You have unsaved changes on this Paragraph item" - seems wrong, as no changes were made, but it's not related to this module - still shown if the module is uninstalled.
andy inman → created an issue.
Ok, I've now found in the README:
Automated Testing Kit has a configuration page located at /admin/config/development/automated_testing_kit/edit (stub for now).
So that explains the error. Suggestion: remove the Drupal menu item completely - better than having it trigger an error page IMHO.
andy inman → created an issue.
@ yorchperaza
> seems like not is compatible with layout_paragraphs
Correct - I spoke/wrote too soon. But they're in the process of adding that as a submodule.
Now it exists: https://www.drupal.org/project/paragraphs_clipboard →
I'm hitting what seems to be the same issue, but when using the Responsive Grid rather than table format. Tried patch #65, no change. Should I log this is a separate issue?
A big negative for Lando: security weakness, because it makes your entire home directory accessible (read/write) to anything running in the Lando container.
https://github.com/lando/lando/issues/2635#issuecomment-860211387
This behaviour seems to have maybe changed in some recent version, for Linux: on my Ubuntu 22.04 machine, I see an empty /user directory, when testing:
<code>
lando ssh
ls -al /user
</code>
But under MacOS, the documented behaviour is present.
Patch #6 worked for me - the warning "Missing proxy class 'Drupal\book_tree_menu\ProxyClass\oscBookManager' for lazy service 'book.manager'" was previously appearing after every drush cr, it's gone after applying the patch.
Reporting another successful result with current dev-4.x and Drupal 10.1.2.
One detail: about configuration of entityID, we previously had:
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => NULL,
It seems the NULL/undefined option is no longer supported - to achieve the same result, I needed to change that to:
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => "https://{$_SERVER['HTTP_HOST']}:443/simplesaml/module.php/saml/sp/metadata.php/default-sp",
Looks like there's a failing test, likely needs updating to match new logic
Confirmed - access tests were checking edit-own and delete-own permission based on revision uid rather than entity uid. I've changed that. I've also added a couple of tests cases to check update and delete when user has the edit/delete-own permission but is not the owner.
Before marking as RTBC, I think it's worth at least considering the possibility that somebody out there may have an access control strategy that would be broken by these changes. That seems very unlikely to me, but I suppose it's not impossible. In the worst case, people could get edit/delete access to micro-content that they're not supposed to be able to change. There's no simple solution - I'm just suggesting a pause for thought - maybe wait for a bit more input from others.
Looks like there's a failing test, likely needs updating to match new logic
Confirmed - access tests were checking edit-own and delete-own permission based on revision uid rather than entity uid. I've changed that. I've also added a couple of tests cases to check update and delete when user has the edit/delete-own permission but is not the owner.
Before marking as RTBC, I think it's worth at least considering the possibility that somebody out there may have an access control strategy that would be broken by these changes. That seems very unlikely to me, but I suppose it's not impossible. In the worst case, people could get edit/delete access to micro-content that they're not supposed to be able to change. There's no simple solution - I'm just suggesting a pause for thought - maybe wait for a bit more import from others.
I have learned: don't right-click the Open MR button hoping to check the URL - that will trigger the button action.
Andy Inman → created an issue.
We're also seeing this error with Authorization - Group 8.x-1.0 when trying to add a group.
Possibly related modules installed:
- Drupal Roles Authorization 8.x-1.0-beta6
- LDAP Authorization Provider 8.x-4.3
- Group (group) 8.x-1.5
I need to investigate further, and will post more info when I have it.