COBadger → made their first commit to this issue’s fork.
Moving to 'needs review'.
COBadger → created an issue.
It's not clear to me where this was addressed in 10.2.x, so I'm attaching a patch that I re-rolled from the 11.x patch for use against 10.2.3 in case it's useful to anyone.
Marking this as 'Needs review', though perhaps this issue could be closed if it's addressed in the linked issue.
Please ignore MR 72. That MR is intended to go against https://www.drupal.org/project/password_policy/issues/3236423 ✨ Do not require unique characters in "Password character type" constraint Needs review .
Not sure why it's not automatically being added to this page, but I created a new MR against 4.0.x:
https://git.drupalcode.org/project/password_policy/-/merge_requests/72
Re-rolled patch for 10.2.x and added test coverage.
I'm changing the version for this issue from 8.x-3.x-dev to 4.0.0 because 3.x is not compatible with Drupal 10 and 4.0.0 is the recommended release.
I altered the approach to solving this problem from adding a conditional in PasswordPolicyValidator to enabling PasswordPolicyValidator to use constraints that are independent of password_policy submodules, making it easier to maintain and test against those constraints.
MR #70 contains:
- An update to PasswordPolicyValidator to enable the use of constraints
- PasswordNotZeroConstraint
- PasswordNotZeroConstraintTest
- An update to _password_policy_user_profile_form_validate() that enables password validation when the password is the character zero
@Kristen-Pol, to answer your question about why patch #7 has more logic than MR #10, the update to _password_policy_user_profile_form_validate() -- which originally was in MR10 and was subsequently removed -- is necessary in order for the module to perform password validation when the password has been set as "0".
Assigning this to myself to work on the issue.
COBadger → made their first commit to this issue’s fork.
COBadger → made their first commit to this issue’s fork.
COBadger → made their first commit to this issue’s fork.
The patch in comment 10 🐛 Mismatched entity and/or field definitions Needs work solved this problem for me, but it seems as though this needs test coverage so I'm marking this as "needs work".
Re-rolled the patch from comment 26 → for Drupal 10 compatibility, addressing " app.root and site.path services have been converted to container parameters → ".
Please review merge request #4.
COBadger → created an issue.
Updated the merge request to correct YoastSeoManager's definition of the Yoast SEO Field Manager, and to inject additional services per Drupal coding standards → .
COBadger → made their first commit to this issue’s fork.
The patch in comment 3 🐛 Deprecated function: Creation of dynamic property PHP8.2 RTBC resolved this issue in my testing.
Marking this as RTBC as the change to the info.yml file indicates Drupal 10 compatibility. Added the parameter and return type hinting logic from @admirlju (I didn't even know that those were part of Drupal coding standards! good catch @admirlju). Created merge request.
COBadger → made their first commit to this issue’s fork.
Thanks for the catch @Paulrad! Updated my merge request to indicate compatibility with Drupal core ^9.3 or ^10.
Please review the merge request.
COBadger → created an issue.
COBadger → made their first commit to this issue’s fork.
Please review the merge request.
COBadger → created an issue.
Re-rolled patch for 10.1.x.
Revised 10.1 patch forthcoming.
Updated my patch; revised patch attached.
Patch attached.
While I agree that removing the setInterval call here:
lpDialogInterval = setInterval(repositionDialog.bind(null, lpDialogInterval), 500);
will correct the stuttering behavior, it doesn't address the need to reposition the dialog when its height changes (see https://www.drupal.org/project/layout_paragraphs/issues/3252978 → and https://stackoverflow.com/questions/5456298/refresh-jquery-ui-dialog-pos...).
We had some logic that used to test for whether the dialog height had changed but that logic was removed in commit b95cccc3.
In a moment I'll add a patch that only repositions when the height of the dialog has changed (while maintaining the logic that handles multiple dialogs).
After much testing and a strong tip from @joelsteidl I have a revised patch for testing.
Was getting errors with my previous patch. Apologies for the many posts. Revised patch attached.
Revised revised patch with new an improved filename.
Revised patch attached.
In my case this issue was resolved by removing my vendor directory and `composer install`-ing again.
Here's a patch that:
- Defines the zoomapi.client service conditionally, dependent upon the existence of apitools.client_base, and
- Installs the apitools module via implementation of hook_update_N().
In my case I needed to require and enable apitools, then update zoomapi. I got the same error as @catch did otherwise, and I could not enable apitools with drush.
@mikeohara great work on this patch. Wish I had time to further develop it, but in any case for my limited use case (filtering nodes) this patch solves the problem. I won't mark it as RTBC because we need test coverage, but here's a hearty +1 for what you have done so far.
In my testing of this patch, clicking on the "x" for one of the filters caused the page to reload and the other filter values were lost in the reload.
In my use case the view is added to the page in the page template via lazy views.
@joelsteidl thanks for the reference to the other issue.
I tested the patch in that issue 🐛 Remove link removes all filters Needs review and found that clicking on an "x" to close one filter reloaded the page. In my use case this caused the remaining filter values to be lost, perhaps because the view is loaded in the page template via lazy views.
I wonder if the patch in this issue would resolve what @pixelwhip was seeing.
Marking this as RBTC - patch #6 🐛 Update from 1.0.0 to 2.x (1013cfc) runs forever and watchdog shows error Fixed solved this issue for me.
PR above is ready for review.
COBadger → created an issue.
Patch attached.
COBadger → created an issue.
Patch attached.
Patch forthcoming.
nicxvan → credited COBadger → .
nicxvan → credited COBadger → .
nicxvan → credited COBadger → .
I tested the patch in comment #6 📌 Automated Drupal 10 compatibility fixes Fixed against 2.x-dev and it resolved the issues that upgrade_status reports, however the ckeditor plugin throws ajax errors:
ResponseText: Error: Non-static method Drupal\image_popup\Controller\ImagePopup::render() cannot be called statically in Drupal\image_popup\Form\EditorImagePopupDialog->submitForm() (line 261 of /app/web/modules/contrib/image_popup/src/Form/EditorImagePopupDialog.php).
nicxvan → credited COBadger → .
As the tests have passed I'm marking this RBTC.
Changing status back to "Needs work".
In my test of the merge request I took the following steps:
- Created a new paragraph in the original language of a node
- Navigated to a translation of the node
- Opened the layout editor
- Observed that the new paragraph from Step 1 above did not render in the layout editor as expected
With the logic from my comment on the merge request when I performed the above steps I did see the new paragraph in the layout editor, and it saved as expected.
@jleehr thanks so much for the suggested changes to MR122. 🐛 Experimental widget displays the original language on translation Needs work I included them in a patch file → and tested locally.
My experience was that the error that @grumpy74 described 🐛 Experimental widget displays the original language on translation Needs work did not appear, so that's great.
However, in my testing the new paragraph that I added on the site's main language did not show up when I edited the page in an alternate language.
I'd be curious to hear whether others experience the same thing using patch 36 → .
Updated patch. Typo had snuck in to docblock in previous patch.
Needs review.
Patch attached.
COBadger → created an issue.
Updated patch attached.
Re-rolled patch attached.
Re-rolled patch forthcoming.
Patch attached.
COBadger → created an issue.