#4 works for me.
Thanks!
Maybe the patch #25 in https://www.drupal.org/project/fullcalendar_view/issues/3280982 🐛 FullviewCalendar With Repeating Smart Date Events Causing Significant Load Times Closed: won't fix is a solution.
Maybe the patch #25 in https://www.drupal.org/project/fullcalendar_view/issues/3280982 🐛 FullviewCalendar With Repeating Smart Date Events Causing Significant Load Times Closed: won't fix is a solution.
As far as I see, #25 helped me too.
The page view#s speed is acceptable now.
Thanks!
With patch #21 and the advice from #26 to replace the line after the patch the errors are gone for me.
I have a fullcalendar view with nodes where media files are referenced.
Thanks so far!
Thanks for comment #50.
That worked for me too (as mentioned, together with patch from
linkit_media_library.opener.editor must be an instance of Drupal\media_library\MediaLibraryOpenerInterface)
@imclean: why did you reopen this issue that had been solved by #5?
Isn´t that solution working anymore in 10.0.1?
I solved the issue for me.
I simply commented out the corresponding lines in the UPSSdk.php file:
- File: /src/UPSSdk.php
- Lines 209 - 211:
// 'PickupType' => [
// 'Code' => '01',
// ],
great Tom!
Thanks
I agree with @leymannx.
Luckily I found this issue...
I don´t want to use layout builder by the way.
Thanks for the module!
#69 applied cleanly in Drupal 10.2.5 and latest dev-Version of colorbox.
And it works well.
Thanks!
Hi,
I´m still having problems with negotiated rates.
After applying latest patch 7 to the (also latest) dev-Version.
Actually, rates get reduced from e.g. 47.07 (= standard rate) to 46.60 (= negotiated).
But negotiated should go to something like 18.81
I´m sure I do use the correct credentials (especially account number).
Do I have to use any other patches besides this 7.patch to get this solved?
Thanks!
One day later, after I put some new into the cart and switch addresses, it works.
I will do some more tests to be sure that there is no existing bug.
Thanks, patch #3 works for me!
Thanks @introfini
With your patch the error is gone.
Had these errors after updating to PHP 8.2:
Deprecated function: Creation of dynamic property PictureMapping::$id is deprecated in PictureMapping->__set() (line 377 of /sites/all/modules/picture/includes/PictureMapping.php).
Deprecated function: Creation of dynamic property PictureMapping::$table is deprecated in PictureMapping->__set() (line 377 of /sites/all/modules/picture/includes/PictureMapping.php).
Deprecated function: Creation of dynamic property PictureMapping::$type is deprecated in PictureMapping->__set() (line 377 of /sites/all/modules/picture/includes/PictureMapping.php).
Deprecated function: Creation of dynamic property PictureMapping::$export_type is deprecated in PictureMapping->__set() (line 377 of /sites/all/modules/picture/includes/PictureMapping.php).
Pasted your lines there (too) and the errors were gone.
Thanks
Supplement to my comment #136:
I just realized that for new nodes CKeditor shows up without the checkmark as mentioned above.
But for existing nodes I have to do that.
#132 applies cleanly on drupal 10.2.2.
CKeditor didn´t show up until I turned on "Always show the summary field" in content type´s form display for the body field.
Is that intended?
#2 works for me in 10.2.2
Patch #19 worked fine for media_library_edit 3.0.2, but no more for media_library_edit 3.0.3
file_usage does not seem to get touched when a filefield gets deleted.
So we can not even find those files anymore that had been referenced (= used) by the deleted field. At least not in bulk.
All files still keep value "1" in column "status" .
At least this value should have changed after deletion of the field.
Am I wrong?
I can confirm that the patch from #12 works as expected.
Thanks!
As the original poster of this issue I can state that, for my usecase, the answer of #8 (thanks @to bkosborne !) fits best/exactly to what I had been looking for:
You do not reuse single image styles anymore as you did in D7.
In D9/10 and the crop API you can instead
- with manual crop: (re)use single crop entities
- or with focal point: set the with and height
for each image style
Of course as soon as you need cropping for different aspect ratios you may need one extra crop entity for each aspect ratio (in case you use manual crops).
Thanks @marrrc - that worked for me!
Thanks ovilla - the patch #4 worked smoothly for me.
I can confirm that #6 works as expected.
Thanks!
Patch #3 applied cleanly in D 9.5.10 and in D 10.1.5
That´s exactly what I was looking for. Webmasters are now able to edit and therefore also to crop images...
Thanks a lot @xaqrox!
#34 doesn´t apply any more after update from drupal 10.1.4 to 10.1.5
Thanks!
#5 worked for me on rc1
Thanks!
edit: found it just after my post:
I could change the position in the settings of my bootstrap barrio subtheme.
Under "Components" and then "Messages".
Switched this issue to "works as designed".
Thanks!
Same here too.
Hopefully an easy answer for this issue ;-)
Thanks!
Thanks - that worked too ;-)
The answer is almost certainly yes ;-)
I had the same issue. At least it worked when I dragged the purchased entity back into the visible area.
I had then to hide it via CSS. If someone knows another method - welcome!
According to #49 I put this issue back to "fixed".
As of today you will still need to use the dev version of commerce stock, until they make a new stable release.
Needed this today because we had to translate all variation titles (but no title field anywhere, no matter what we tried). Glad I found this issue.
Patch #27 didn´t apply to latest 2.x-dev, so I did that manually.
Works for me actually.
It would be good to have this in the future too.
Thanks!
Thanks - that worked for me!
two questions that likely/probably fit into this issue:
- In checkout the customer can select the carrier. If that´s intentional: that should be hidden in my case --> I have only UPS so far
- Maybe at least a "default" carrier could be set automatically
Anyway - thanks for the module!
Seems like I have it here too.
I will go on searching but wanted to leave this message here....
If someone can help: very much appreciated.
Patch from #6 helped me too!
Drupal 9.5.3
Thanks
Yes, it is.
I solved it by using
"Tamper: Strip Tags" with
- Data: [taxonomy-field]
- Token name: any_name
In the email I print [any_name].
So now my model is still super simple:
- Event: Insert content entity (Type Comment:myComment-Type)
- Tamper: Strip Tags
- Send an Email
Thanks again!
Not yet - I'm sorry ;-)
But I'd like to go on:
How do I "Initialize empty name list"?
Thanks!