Hi there,
The patch has been reviewed by me with Upgrade Status module, looks good.
CONTRIBUTED PROJECTS
--------------------------------------------------------------------------------
Commerce Hyperpay
Scanned on Sat, 11/16/2024 - 13:34.
No known issues found.
I installed the module on Drupal 11 and faced with another issue ( I guess it's not related to compatibility) https://www.drupal.org/project/commerce_hyperpay/issues/3487940 🐛 Fatal error when Add payment gateway Active
e.bogatyrev → created an issue.
Hi @berdir,
Thanks for findings, they make sense.
Please take a look and review updated patch or MR
driverok → credited e.bogatyrev → .
driverok → credited e.bogatyrev → .
e.bogatyrev → changed the visibility of the branch 3454809-Port-module-to-8.x to hidden.
e.bogatyrev → created an issue.
Hi everyone,
I reviewed the patch. It fixes issue partially (not fixed issue for login form).
I updated the patch and added interdiff.
Please review
driverok → credited e.bogatyrev → .
driverok → credited e.bogatyrev → .
Hi everyone,
Please review the patch.
I suggest to use callback arguments as a string with line ending separation in the Cron Job configuration form since we don't actually know the final amount of them. It depends on the particular implementation of each callback. Then this string will be parsed, split to arguments and passed to callback.
e.bogatyrev → made their first commit to this issue’s fork.
After verification no issues found.
[notice] Processing /var/www/html/web/modules/contrib/user_agent_class.
================================================================================
User Agent Class, --
Scanned on Sat, 02/17/2024 - 15:59
No known issues found.
Please review MR https://git.drupalcode.org/project/user_agent_class/-/merge_requests/2/d...
Thanks
e.bogatyrev → created an issue.
Hi everyone,
Please review updates https://git.drupalcode.org/project/auditfiles/-/merge_requests/21/diffs
@dpi all changes are not related to the issue itself have been removed.
Thanks
Re-attached the patch to fix test issues
Hi everyone,
I cannot apply the initial patch due the errors. I have to create a new one.
Before creation see the following issues.
[notice] Processing /var/www/html/web/modules/contrib/moderation_scheduler.
================================================================================
Moderation Scheduler, 8.x-1.x-dev
Scanned on Sat, 02/17/2024 - 13:26
FILE: web/modules/contrib/moderation_scheduler/moderation_scheduler.module
STATUS LINE MESSAGE
--------------------------------------------------------------------------------
Fix now 59 Call to deprecated constant REQUEST_TIME: Deprecated in
drupal:8.3.0 and is removed from drupal:11.0.0. Use
Drupal::time()->getRequestTime();
--------------------------------------------------------------------------------
Fix now 70 Call to deprecated constant REQUEST_TIME: Deprecated in
drupal:8.3.0 and is removed from drupal:11.0.0. Use
Drupal::time()->getRequestTime();
--------------------------------------------------------------------------------
Fix now 73 Call to deprecated constant REQUEST_TIME: Deprecated in
drupal:8.3.0 and is removed from drupal:11.0.0. Use
Drupal::time()->getRequestTime();
--------------------------------------------------------------------------------
FILE:
web/modules/contrib/moderation_scheduler/src/Form/ModerationScheduleForm.php
STATUS LINE MESSAGE
--------------------------------------------------------------------------------
Fix now 98 Call to deprecated constant REQUEST_TIME: Deprecated in
drupal:8.3.0 and is removed from drupal:11.0.0. Use
Drupal::time()->getRequestTime();
--------------------------------------------------------------------------------
Fix now 102 Call to deprecated constant REQUEST_TIME: Deprecated in
drupal:8.3.0 and is removed from drupal:11.0.0. Use
Drupal::time()->getRequestTime();
--------------------------------------------------------------------------------
Fix now 225 Call to deprecated constant REQUEST_TIME: Deprecated in
drupal:8.3.0 and is removed from drupal:11.0.0. Use
Drupal::time()->getRequestTime();
--------------------------------------------------------------------------------After applying own patch
[notice] Processing /var/www/html/web/modules/contrib/moderation_scheduler.
================================================================================
Moderation Scheduler, 8.x-1.x-dev
Scanned on Sat, 02/17/2024 - 13:35
No known issues found.Please review
e.bogatyrev → made their first commit to this issue’s fork.
driverok → credited e.bogatyrev → .
driverok → credited e.bogatyrev → .
MR/patch has been updated, please verify.
Ok, let's do it. I will remove the configuration form and add this check.
Hi @gisle,
Yes, I agree with you, any filters except "Full HTML" are not suitable (I've checked "Images examples" you mentioned).
Only one concern here - the "Full HTML" could be disabled by some reason (replaced by more enhanced new filter format).
What filter will we use in this case?
Hi @gisle,
Thank you for your quick response.
For sure, the help pages can be added by developer only and he could add any nasty code to them. May be it could be a lightweight insurance since developer must update the advanced_help.settings config as well to get appropriate display result. In case when MR will have a dozen of help pages administrator (or anyone who has merge permissions) could miss something from HTML attributes but will more accurate and attentive if noticed changes in format settings. Just thoughts, may be it's not a use case.
Anyway, I think we need to leave a chance to change this setting and avoid hardcode.
Hi everyone,
The root cause is #markup will be always passed trough Xss::filter where 'style' attribute will be stripped.
I added a configuration form with ability to choose filter format. To apply this I had to change the output render array type to #processed_text. It allows us (e.g. chosen full_html) to display more attributes including "style".
Please take a look at MR or patch.
e.bogatyrev → made their first commit to this issue’s fork.
Hi there,
The patch has been attached.
e.bogatyrev → created an issue.
Hi everyone,
Previous patch doesn't work (produces an error "Error: Object of class Drupal\Core\Link could not be converted to string")
Opened a new MR and uploaded the same changes in a separate patch file.
Verified with nesting items. Please review
e.bogatyrev → made their first commit to this issue’s fork.
driverok → credited e.bogatyrev → .
Hi there,
Please take a look and review MR https://git.drupalcode.org/project/auditfiles/-/merge_requests/21
How to repoduce the issue
- Create any paragraph type
- Add an icon to the field "Paragraph type icon"
- Go to the report "/admin/reports/auditfiles/usednotreferenced"
e.bogatyrev → made their first commit to this issue’s fork.
Hi there,
The issue is also presented on branch 4.1.x. The fix should be applied to it as well.
Please review
e.bogatyrev → made their first commit to this issue’s fork.
driverok → credited e.bogatyrev → .
driverok → credited e.bogatyrev → .
Hi everyone,
I checked out the branch 3288151-automated-drupal-10, verified compatibility and discovered the following after scanning issues by the upgrade_status module
drush upgrade_status:analyze jsonapi_views
================================================================================
JSON:API Views, --
Scanned on Fri, 02/10/2023 - 01:52
FILE: web/modules/contrib/jsonapi_views/jsonapi_views.info.yml
STATUS LINE MESSAGE
--------------------------------------------------------------------------------
Check manually 0 Value of core_version_requirement: ^8.8 || ^9 || ^10 is not
compatible with the next major version of Drupal core. See
https://drupal.org/node/3070687.
--------------------------------------------------------------------------------
FILE:
web/modules/contrib/jsonapi_views/tests/modules/jsonapi_views_test/jsonapi_views
_test.info.yml
STATUS LINE MESSAGE
--------------------------------------------------------------------------------
Check manually 0 Value of core_version_requirement: ^8.8 || ^9 || ^10 is not
compatible with the next major version of Drupal core. See
https://drupal.org/node/3070687.
--------------------------------------------------------------------------------
FILE: web/modules/contrib/jsonapi_views/composer.json
STATUS LINE MESSAGE
--------------------------------------------------------------------------------
Check manually 0 The drupal/core requirement is not compatible with the next
major version of Drupal. Either remove it or update it to be
compatible. See
https://drupal.org/node/2514612#s-drupal-9-compatibility.
--------------------------------------------------------------------------------
Apart from this I verified the tests. The issue is related to missed parameter (field_identifier: nid) in test view views.view.jsonapi_views_test_node_view.yml
After applying the patch
Compatibility check
================================================================================
JSON:API Views, --
Scanned on Fri, 02/10/2023 - 01:54
No known issues found.Tests run
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.
Testing Drupal\Tests\jsonapi_views\Functional\JsonapiViewsResourceTest
...... 6 / 6 (100%)
Time: 01:40.078, Memory: 10.00 MB
OK (6 tests, 180 assertions)Please review the patch.