I performed the same routine as I used in #210 to check the patch in #179, this time using Drupal 10.3.6 and PHP 8.3.13. The patch works as expected.
I applied the patch on a site that was already running Drupal 10.3.2 (php 8.2.13, Apache 2.4.54) and could not replicate the behaviour that was described in #209, the patch worked as expected on this install.
Specifically I did the following:
- put the patch link in the "patches" section of the root composer.json and ran composer install, the patch (in #179) applied cleanly.
- logged into the site as an administrator and opened a page in dutch, the admin had dutch set as the "Administration pages language" on his profile, the administration menu items in the toolbar showed in dutch, as expected.
- changed the "Administration pages language" in the admin profile to english and opened the same dutch page, the administration menu links now showed in english, as expected.
Based on this behaviour it seems that the patch functions correctly on this install running Drupal 10.3.2, I also checked the logs for anything unusual but all was working perfectly fine. Hope this helps!
Frontmobe → made their first commit to this issue’s fork.
The most recent patch did not apply to cores 10.3.1, I attached a rerolled patch.
I am sorry to re-open this issue, but it seems that it is not fixed yet. I added a screenshot of the module update page, there still is the warning that the module is currently unsupported and should be uninstalled.
On the project page there are no download links visible for any version of the project, could it be that the project as no published version or something? Just guessing here ;-)
Frontmobe → made their first commit to this issue’s fork.
Re-roll patch in #7 to make it work with version 3.0.3 of the module.
@claudiu.cristea can you clarify what you mean with "It needs updating the imagecache_external.settings schema."? The current patch already adds imagecache_external_save_as_image_style: '' to the schema.
That sure is a quick fix, thanks John! For what it's worth, I tested the patch and can confirm that it solves the issue as described, but I'm sure you already knew that ;-)
Frontmobe → created an issue.
Thanks @markconroy, then that is what we are going to do here as well, cheers!
@markconroy, in #5 you mention that you created a work around, is that work around simply uninstalling the module like you mention here 📌 Automated Drupal 10 compatibility fixes Needs work and from there maintain the taxonomy yourself in your project? Or is there something more to it?
P.S. I agree with your statement in #7, the message could very much be improved like you suggest ;-)
I see the same warning in the Drupal backend under /admin/reports/updates. The module also seems to no longer be available on the project page https://www.drupal.org/project/countries_info →
What does this mean? Is the project abandoned?
Frontmobe → created an issue.
@Klaas would you mind crediting everyone that worked on this issue? Looks like this wasn't done automatically. You can do this at the Credit & committing section at the bottom of this page.
The Drupal 10 compatible version of webform was released in October last year, see: https://www.drupal.org/project/webform/releases/6.2.0 → . So it makes sense to now commit the patch code for this module.
The patch applies cleanly and is confirmed to work on D10.2.1 icw webform 6.2.2.
This has been lying around for quite a while now. I can confirm that the patched module works perfectly fine on D10.2.1, as already noted in this duplicate issue: https://www.drupal.org/project/countries_info/issues/3286802 📌 Automated Drupal 10 compatibility fixes Needs work .
Can we please get this committed? People are now forced to use the mglaman/composer-drupal-lenient Composer plugin to install the module, that's not ideal.
That's awesome Nathaniel, thanks for tagging the new release!
This issue still occurs with the current version of the module (version 2.11). It seems to me it would be good to get the patch committed, especially since this issue has been around for 6 years now.
The current patch in #16 applies cleanly to version 2.11 of the module, the code looks good to me.
Is a test needed to get this committed?
Many thanks Nathaniel!
Do yo think tagging a new release would be possible to prevent the error from showing up after updating to version 6.0.5?
I just realised that other issues in this queue don't (yet) use the Gitlab merge request workflow, but use the patch workflow in stead.
I added a patch that does the same as the commit in the issue fork, use whatever works easiest I would say ;-)
I created an issue fork where I added the suggested change. I tested the change locally and can confirm it solves the issue, so I went on and also made the merge request.
All we need now is a review and then hopefully a merge I suppose ;-)
Frontmobe → changed the visibility of the branch 6.0.x to hidden.
Frontmobe → made their first commit to this issue’s fork.
I noticed that the issue as described in the issue summary of this issue also exists in the (parent) https://www.drupal.org/project/cmrf_core → module.
I created issue 3411199 📌 Incorrectly namespaced module dependencies Active with an issue fork that addresses the issue.
Please review that issue @DieterHolvoet, so that we can get both fixes in.
I reviewed the commit and can confirm that this now works as expected, the changes in the issue fork can be merged into he main (2.0.x) branch.
Frontmobe → changed the visibility of the branch 2.0.x to hidden.
Frontmobe → created an issue.
The patch attached changes the function signature as described in the issue summary.
Frontmobe → created an issue.
I can confirm the issue still exists when trying to use webform_mailchimp module on Pantheon (webform_mailchimp 5.10, webform 6.1.6, mailchimp 2.2.2, Drupal 9.5.11, PHP 8.1.26).
Using the code FNAME: '[webform_submission:values:first_name]' locally without php-yaml installed also works, so the instruction of adding the '' around the token seems to work with OR without php-yaml installed.
Should the patch in #2 be committed? Its seems to fix the issue regardless of php-yaml being installed..
This patch adds a textfield to the webform handler that accepts one or more tags (separated by comma's). It adds the tags to the mailchimp_subscribe() function used in the handler code.
Do note that when adding tags to sign-ups this way, Mailchimp will create new tags for the audience in case the tags were not yet created on the audience before.
Frontmobe → created an issue.
Many thanks indeed, highly appreciated!
Re-roll patch in #2 against 8.x-1.0-rc10 version of the module.
Test failed, another approach to perform test.
Test failed, another approach to perform test.
Test failed, trying a new approach to test text in the summary.
Test failed, trying a new approach to test text in the summary.
Refactor, make test click link.
The javascript in comment-entity-form.js now passes all linting tests.
Rewritten the test to no longer use jQuery, since this triggered the testrobot to return an error and we want to get rid of jQuery anyway.
Rewritten javascript, another attempt to get the tests in the green.
Another attempt at fixing the testbot errors.
Attempt at fixing the testbot errors in patch #64.
This is still present in Drupal 11.x, added a re-roll from #54.
💬 Turn node/%/customPath to path/alias/customPath Closed: won't fix Closed and moved to the pathauto issue queue
Hopefully a solution was found to address this by now.
As this clearly is not a core bug, changing this to a support request. Also moving this to the pathauto issue queue because this is where it belongs.
Closing the issue for now, if support on this is still needed feel free to re-open the issue.
This behaviour still exists in the Drupal 10.1 / 11.x branches.
Since the the issue does not break anything but instead deals with doing testing the right way, I am changing the category from "Bug report" to "Task" here.
Looking for another issue where this might be addressed, resulted only in the much broader meta issue 📌 [meta][no patch] Replace uses of REQUEST_TIME and time() with time service Active calling for uses of time() and REQUEST_TIME to be replaced by the time service, like in this issue.
Using the time service here does seem useful because consistent use has clear benefits, as outlined here → .
As stated in comment #5, there are several issues on the spatie/calendar-links Github page that relate to this issue.
There is a new issue on the Github page that is now merged and solves the Github issues in: #73, #119 and #140.
The issue itself states:
This PR intends to fix Daylight Savings Time issues reported in #119 and #73.
This code originated in PR #140 (thanks @kodie) and was rerolled so that it now applies cleanly to version 1.8
I can confirm after testing that the issue with ICS import being off by 1 hour are now gone with this fix merged.
This would render the patch provided in #7 in this issue queue obsolete since the problem is now solved upstream in the spatie/calendar-links library. I will leave this issue set to "needs review" because committing the patch seems no longer needed. Maybe someone else can test and set this issue to "fixed"?
Done, great to see this effort being made! I forwarded this to 2 colleagues, can't get enough feedback on this I suppose.
Correcting small typo (triggering an error) on line 161.
I updated the patch provided in #5 to incorporate the first change suggested in #4 (use image_style_options() to get a list of image style options), I kind of overlooked that completely justified suggestion when rerolling the patch. About the second suggestion made in #4, this feature does lead to code duplication, will think about what is best to do here.
In the mean while, I uploaded the updated patch reflecting the first suggestion made in #4 here.
Rerolling the patch in #3 to the 3.0.x dev branch to make it apply to the current 3.0.1 release.
Adding the patch posted in #3 for use with Drupal 9.4.x here:
I have applied the patch provided and can confirm that the Plupload uploads now work flawlessly with the batch API!
I tested this locally as well as remotely with a high number of large files, combined with short PHP timeouts configured. The new pluploadSubmitBatch() and batchFinished() functions in PhotosUploadForm.php work and the integration with batch API like progress messages work as expected. No errors show up in the php error log when using the module with the patch applied.
I had to manually apply the patch to Photos module 6.0.2, because the patch is created against de dev version of the module. Any chance of maybe tagging a new release once this patch is confirmed to work ok?
Many thanks for this nice extension of the module, using batch API for bulk uploads really increases stability.
I can confirm the patch in #13 solves the issue on a search index view with multiple contextual filters enabled, search_api 1.28 and views_contextual_filters_or 1.4 modules enabled (running Drupal 9.5).
Thanks for the patch!