ah ok that's unfortunate. The module lets me add more than one instance of each setting so I thought this may have just been a usecase that wasn't considered.
The suggested MR adds support for retrieving individual instances of settings with the instance ID. It should be backwards compatible with the tokens that were there before.
Adjusted issue summary and subject.
pavlosdan → created an issue.
The patch provided seems to only be doing coding standard fixes and not addressing anything relevant to the reported issue.
pavlosdan → created an issue.
pavlosdan → created an issue.
Thanks johnv!
pavlosdan → created an issue.
chadhester → credited pavlosdan → .
surabhi-gokte → credited pavlosdan → .
chadhester → credited pavlosdan → .
Happy to help with this when the time comes :)
In my opinion Full HTML as that could be a potential security issue and we should add and configure an editor for the restricted HTML format. I'm a bit late to the party but I would have preferred to remove Full HTML and kept Basic HTML.
pavlosdan → created an issue.
May I suggest https://github.com/acquia/drupal-spec-tool as a way to define the content model?
The google sheet can be copied and then we can remove the Acquia CMS Community starter kit fields, content types etc and fill it in with the Drupal CMS ones. Once all content types, fields (with names and types), menus, etc are added we will end up with a living document that gives us an immediate bird's eye view of the Drupal CMS content model that anyone can then take and implement.
The current content strategy currently calls out only content types. We should also define the taxonomies (e.g Tags) that will ship with Drupal CMS as well as any menus (e.g Main Navigation, Footer, Social links) and media types (Image, Document, Video (remote?)) and call them out specifically as these entities could have their own fields that we need to create as well. I assume we will avoid using the image and file fields and we will instead use media entities which should also be called out.
Additional things to consider for the content model and be added to the spec tool:
- Image styles (since we have fields for feature images it would make sense to define some out of the box image styles as well)
- Views for listing content such as events and blogs (probably provided by their respective recipes)
- User roles (who will be able to edit what)
Do we want to add relationships between the content types? For example, the article, blog, project, case study content types could have an "author" field that references the "person profile" content type.
Is the location field on the event content type an address field, or a reference field to a location content type (in which case we also need to define that).
Some fields such as "body" and "description" seem like they would be rich text fields. These should be defined with the appropriate text formats as well. Which leads me to the Full HTML text format. This could be considered a security risk and ideally we should disable it or completely remove it.
pavlosdan → created an issue.
Thank you for your patience. Merged and created new release.
heatherwoz → credited pavlosdan → .
liberatr → credited pavlosdan → .
Ah yes, didn't think about that. The test just shows that it's more performant if the original entity is set in $entity->original before calling hasTranslationChanges().
I ll adjust to test the validator changes too.
Rebased MR against 11.x, added test, and fixed some minor coding standard issues gitlab caught.
pavlosdan → made their first commit to this issue’s fork.
Added merge request targeting 11.x and addressed the comments in #147.
pavlosdan → made their first commit to this issue’s fork.
A few years ago I was working on a small paragraphs_enhancements module for the needs of my project back then. The option we went with at the time was a new config entity (to facilitate the exportability as Taxonomy terms wouldn't work for that use case and we don't want site building tasks like that to be taking places in an environment they shouldn't).
Site builders could create their paragraph groups and assign paragraphs to them, which would then be displayed in optgroups in the select add mode. We did this by extending the (back then) experimental paragraphs widget. We could add this functionality to the current paragraphs widget for the select and modal add modes.
If there's still desire for this I could get the code from https://git.drupalcode.org/project/paragraphs_enhancements and adjust it for the latest paragraphs module and open a merge request for review and discussion. Ideally this would solve the grouping issue for paragraphs and allow us to retire the https://www.drupal.org/project/paragraphs_enhancements → module.
Merged. Thanks all!
Admittedly setting a limit at the storage level was not something I thought about since I thought we'd be setting granular limits using the handler. Good catch!
Is it fair to assume that you weren't using the patch from ✨ This module should disallow adding more than the allowed amount of paragraph items in the add widget Fixed prior to rc2?
So the issue seems to be happening when the field is limited by core's field storage setting "Allowed number of values". If this is set to unlimited the pages are working as intended. If this is limited at the storage level, Drupal removes the add more button completely from the form and paragraphs_limits breaks.
Would be nice to have a test for this.
pameeela → credited pavlosdan → .
Thanks @vishal.kadam. I've ran phpcs on the project and it is also green in the related gitlab job: https://git.drupalcode.org/project/paragraphs_limits/-/jobs/2468511.
pavlosdan → created an issue.
Looks like this was resolved with 🐛 Undefined index: handler_settings in Drupal\paragraphs_limits\Plugin\EntityReferenceSelection\ParagraphsLimitsSelection->buildConfigurationForm() Fixed . I can't replicate this.
Merged. Thanks all.
Asked in the #gitlab channel on Drupal slack and there was indeed a problem with the pipeline. See:
🐛
Test-only job cannot be run due to wrong dependency
Fixed
It is now resolved. Rebased the fork and the tests seem to be triggering now: https://git.drupalcode.org/issue/drupal-3401726/-/pipelines/249631
During the initial setup after setting:
xquartz -> Settings -> Security -> Allow connections from network clients was checked.
I had not restarted XQuartz and the debug.sh script was failing. Once I restarted XQuartz and manually trying to run
ddev exec \
--dir /var/www/html/web/modules/contrib/experience_builder/ui \
"node_modules/.bin/cypress open --browser electron --project ."Cypress finally started.
Running from the script again, the script kept failing with:
xhost +
xhost: unable to open display ":0"
Adjusted debug script to open XQuartz first and give it a small delay to give it a chance to initialize before running xforce +
that helped and cypress is now running successfully.
Without the delay even if i run XQuartz before xforce + i would still get the unable to open display error.
The bottom of my debug.sh script now looks like:
# Run Cypress.
open -a XQuartz
sleep 2 # Give XQuartz some time to start.
xhost +
ddev exec \
--dir "/var/www/html/$MODULE_PATH/ui" \
"node_modules/.bin/cypress open --browser electron --project ."
And it runs successfully.
Kristen Pol → credited pavlosdan → .
Another usecase for this would be to ask for a language when installing a recipe that enables content translation.
I tested the MR in #3401726 as well and it seems to resolve the issue.
Added test. Setting back to needs review.
pavlosdan → made their first commit to this issue’s fork.
I can't replicate this with the stable widget on Drupal 10.2.6 and the latest dev version of the module.
I've added a paragraph field where the paragraphs would be collapsed by default. Added a node with some paragraphs and then went back and added some limits. Trying to resave the same node triggers the correct message to display. Could you please check that this is still an issue?
Looks like the same code works for the legacy widget as well and we just needed the extra hook for that one. Setting this back to needs review.
Would these messages be displayed inline as the user is adding/removing paragraphs? Or are you looking to customize the existing constraint messages that show up on submit per paragraph type?
I've tested this with Drupal 10.2.6 but I can't replicate the issue. The constraint messages are correctly displaying.
Please feel free to re-open if this is still happening for you with some steps to replicate.
Looks like this hook exists for Drupal 9 as well so we should be good in that regard: https://api.drupal.org/api/drupal/core%21modules%21field%21field.api.php... (at least it exists for 9.5).
I've removed support for D8 given its EOL and paragraphs dropping it as well.
I've tested the patch with all the edit modes that the "Paragraphs (stable)" widget has and it looks like it works as advertised. Thanks a lot for driving this forward!
Setting this back to needs work to see if we can get this working for the legacy widget as well.
Updated constraints to drop support for Drupal 8 since paragraphs no longer supports it, and support Drupal 11. Note that paragraphs hasn't added support for D11 yet.
pavlosdan → made their first commit to this issue’s fork.
Pushed out alpha6 to include the fix from 🐛 Undefined index: handler_settings in Drupal\paragraphs_limits\Plugin\EntityReferenceSelection\ParagraphsLimitsSelection->buildConfigurationForm() Fixed . Marking this as a duplicate of that one.
Went ahead and removed %min_max and split the constraint message into upper limit and lower limit messages.
griffynh → credited pavlosdan → .
I'm thinking it may be better to split the constraint message into upper limit message and lower limit message so we don't risk losing context if the %min_max string gets translated. The %min_max token can then be removed.
Thoughts? Making this into a bug rather than a feature request as the strings should be translatable.
Thank you for the reviews and suggestions @acbramley!
Change record added https://www.drupal.org/node/3424780 → and issue summary updated.
I endorse Matt for this role as well. He's proven his skills in the Drupal update field time and again with contributions that help such as phpstan, drupal-check, and retrofit. No doubt, Matt will be an excellent and integral addition to the team!
Created a new branch from 11.x and cherrypicked the commits onto it.
Setting this back to needs review. The issues in #39, #47 seem to have been addressed except no1 in #39 which I don't think is out of scope since we need content moderation to be testing for taxonomy_term entity as well which may have a different entity key for label than other entities which may use "title".
pavlosdan → made their first commit to this issue’s fork.
pavlosdan → created an issue.
Thanks for testing this @Sandeep_k. Pushed a commit to fix the issue!
pavlosdan → created an issue.
Thanks larowlan!
Installing a site from existing config using Drupal 10.2 and Workbench Email 3.0.2 throws the following errors:
[error] Unexpected error during import with operation create for workbench_email.workbench_email_template.to_published: Route "entity.workbench_email_template.canonical" does not exist.
[error] Unexpected error during import with operation create for workbench_email.workbench_email_template.to_archived: Route "entity.workbench_email_template.canonical" does not exist.
[error] Unexpected error during import with operation create for workbench_email.workbench_email_template.to_published: Route "entity.workbench_email_template.canonical" does not exist.
Re-opening as the issue is not solved even with the workaround in place.
Steps to reproduce:
- Install a site using the Standard profile
- Enable Content Moderation and Content Translation modules (content moderation will give us the moderated content admin dashboard which has this issue "/admin/content/moderated")
- Assign the "Editorial" workflow that gets created when enabling the content moderation module to the Article content type.
- Add a second language to the site, e.g French.
- Enable translation on the Article content type.
- Add an Article node and mark it as published.
- Add a translation for the article node that was just added but mark it as draft.
- Visit "/admin/content/moderated" and observe that the Content Type column for our translated node will have no information in it.
- Added compatibility for Drupal 10.
- Minor language adjustments and coding standard fixes.
- On the translation edit form used access = FALSE instead of class hidden to prevent entrepreneurial users from removing the class from the HTML and making changes.
pavlosdan → made their first commit to this issue’s fork.
Had a chat with Martin the other day about this. Here's a patch to hopefully unblock people until we get a fix incorporated into Site Studio.
Please review and let us know if this works.
I was able to replicate this for content types as well by adding a layout canvas field to it. Not sure why adding a media reference field makes it work as the key issue seems to be that Site Studio is looking for the form submit button within the
`#${drupalSettings.cohesion.drupalFormId} input[type="submit"]`
I've recommended to the Site Studio team that the selector be changed to the following
const defaultSubmitEl = document.querySelectorAll(
`input[type="submit"][form="${drupalSettings.cohesion.drupalFormId}"]`
)[0];
so the submit button can be found wherever it is placed as Gin places the buttons outside of the form which is still valid https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#attr-form)
Marking this as "postponed" until we see whether Site Studio will be able to incorporate the change. Meanwhile if people find any good workarounds, merge requests are welcomed.
The patch is indeed incorporated into Site Studio now and is no longer needed. Closing this.
I can't replicate this with Gin 3.0.0-rc3, Site Studio 7.1.0, and Site Studio Gin 1.0.0 and a basic content type with only a body field on it.
Is this still an issue?
https://git.drupalcode.org/project/paragraphs_limits/-/blob/8.x-1.0-alph...
The code from the patch is present in alpha5. Is the issue not resolved @PCate?
Thanks all, merged.
pavlosdan → made their first commit to this issue’s fork.
Patch applied and merged.
pavlosdan → made their first commit to this issue’s fork.
pavlosdan → made their first commit to this issue’s fork.
Updated merge request to address #13
Thanks for taking it for a spin and the feedback @chrisrhymes! Setting it back to needs work to address findings in #13.
Built on @hershy.k's work to hopefully get this through the finish line or nearer to it.
Made adjustments to support multiple buttons since multiple paragraph embed buttons can be added.
pavlosdan → made their first commit to this issue’s fork.
pavlosdan → created an issue.
pavlosdan → created an issue.