wrd-oaitsd → created an issue.
wrd-oaitsd → created an issue.
Tested this yesterday afternoon, in fact, and it does seem to solve the problem! Code looks very straightforward to me.
I removed the custom stylesheet from my theme, and applied the patch from #7, and the result looks good to me!
Adding that code via ckeditor5-stylesheets does indeed seem to solve the problem -- thanks!
wrd-oaitsd → created an issue.
For the moment, my workaround is to use an alias to install Drush:
composer require drush/drush:"13.1.1 as 12.5.3"
This seems to be working, although it breaks site creation in Acquia Cloud Site Factory.
Yeah, I've run into this as well. It's primarily a problem because the new core Recipes feature only works with Drush 13. Recipes can be applied using core/scripts/drupal, but I can't seem to get that working for a remote site.
wrd-oaitsd → created an issue.
Yes indeed, I seem to have a working slider again. Thanks much!
Patch #103 works beautifully for me. I'm reluctant to add it to a production site until it's officially merged into core, but I look forward to the change.
wrd-oaitsd → created an issue.
This JS error appears in the console when I have the Caption Text option enabled...but it doesn't look especially helpful, since this just appears to be an error handler within drupal.js.
wrd-oaitsd → created an issue.
That patch had a rather significant error...here's a new one.
Trying to reroll #11 for the latest dev release.
Looks like this patch isn't applying to the latest dev release.
Just tried adding this module to an existing site, and it's not showing the option for me, either. The SVG image module is not enabled on this site.
wrd-oaitsd → created an issue.
This problem appears to be exactly as described in Using CKEditor 5 inside Bootstrap Modal causes interaction issues → . However, while we're using version 3.30, the problem does not appear to be fixed. At least, not for us!
wrd-oaitsd → created an issue.
wrd-oaitsd → created an issue.
I'm not sure if this is helpful, but disabling this "top" style seems to fix the problem...at least, it looks that way. I'm not sure if it causes other problems.
.ck.ck-sticky-panel .ck-sticky-panel__content.ck-sticky-panel__content_sticky {
z-index: 2;
/* top: calc(var(--gin-toolbar-y-offset) + var(--gin-sticky-offset)) !important; */
}OK, I was able to reproduce the problem with a standard install. I've added the steps to the issue description.
wrd-oaitsd → created an issue.
Well, that didn't help at all.
This is an attempt to remove the non-applying patch from the module's composer.json file.
Yeah, this is happening to me as well. The library folders are present in docroot/libraries, and they were added automatically by composer thanks to the merge plugin, but the status report says the module can't find either of them.
wrd-oaitsd → created an issue.
#2 solved the problem for me. Thanks!
wrd-oaitsd → created an issue.
Upon further investigation, it appears that something in our sites is altering the select elements in fields with more than one value into numeric input elements. This isn't happening on a site that is built with the standard profile; the weight field on my test site remains a select after adding additional values.
This is also happening in Claro, but the input field is large enough to use in Claro, so it's not an obvious problem.
So there's gotta be a form_alter or something like that happening somewhere that's causing the input element to change, and that's clearly not Gin's fault.
I'll see if I can narrow it down. It's happening on multiple sites, so I assumed Gin was the common denominator, but perhaps there's some other factor they share in common.
I ran into the same issue today. #9 appears to resolve the issue.
I've noticed that literally nobody has mentioned the title attribute that Linkit generates… 😇 Seems like people really don't quite use that?
Our accessibility people discourage the use of the title attribute, to encourage our content people to use descriptive link text rather than relying on the attribute. I'm not sure if this is a common reason, but that's why we don't use it on our government sites.
wrd-oaitsd → created an issue.
To expand on #27, the way we want our links to behave by default in the editor depends quite a bit on the media type we're linking to. For the most part, we link to the entity with PDFs, and display them in an embedded viewer using the PDF module and PDF.js library. For other document types (for which we use a different media type), we want the link to download the file. I imagine we'd want to be able to configure the default behavior for a link based on entity type and bundle of the target.
I believe this will do the trick. Added a bit of conditional handling to media_oembed_control_preprocess_field based on whether or not the iframe_domain is set in media.settings.
wrd-oaitsd → created an issue.
wrd-oaitsd → created an issue.
wrd-oaitsd → created an issue.
wrd-oaitsd → created an issue.
I'm getting the same result when using the Nominatim service.
I included the link to the other issue in the "Related issues", but to include it here as well, it can be found at: https://www.drupal.org/project/geocoder/issues/3059514 →
Testing out Google's geocoding example code on jsfiddle:
https://jsfiddle.net/gh/get/library/pure/googlemaps/js-samples/tree/mast...
...produces the same result if I input the address like so:
Input: 408 Washington Avenue Suite 100 West Plains, MO 65775 United States
{
"results": [
{
"address_components": [
{
"long_name": "100",
"short_name": "100",
"types": [
"subpremise"
]
},
{
"long_name": "408",
"short_name": "408",
"types": [
"street_number"
]
},
{
"long_name": "Washington Avenue",
"short_name": "Washington Ave",
"types": [
"route"
]
},
{
"long_name": "Downtown Houston",
"short_name": "Downtown Houston",
"types": [
"neighborhood",
"political"
]
},
{
"long_name": "Houston",
"short_name": "Houston",
"types": [
"locality",
"political"
]
},
{
"long_name": "Harris County",
"short_name": "Harris County",
"types": [
"administrative_area_level_2",
"political"
]
},
{
"long_name": "Texas",
"short_name": "TX",
"types": [
"administrative_area_level_1",
"political"
]
},
{
"long_name": "United States",
"short_name": "US",
"types": [
"country",
"political"
]
},
{
"long_name": "77002",
"short_name": "77002",
"types": [
"postal_code"
]
}
],
"formatted_address": "408 Washington Ave #100, Houston, TX 77002, USA",
"geometry": {
"location": {
"lat": 29.7654582,
"lng": -95.3614463
},
"location_type": "RANGE_INTERPOLATED",
"viewport": {
"south": 29.7640738197085,
"west": -95.3627994802915,
"north": 29.7667717802915,
"east": -95.3601015197085
}
},
"place_id": "Ei80MDggV2FzaGluZ3RvbiBBdmUgIzEwMCwgSG91c3RvbiwgVFggNzcwMDIsIFVTQSI6GjgKMRIvChQKEgnJRi06Lr9AhhGV09IgdaweuhCYAyoUChIJM09JeVPHQIYRFNRygKFHGo0SAzEwMA",
"types": [
"subpremise"
]
}
]
}If I add a comma after the address and before the city name, the result is correct:
Input: 408 Washington Avenue Suite 100, West Plains, MO 65775 United States
{
"results": [
{
"address_components": [
{
"long_name": "100",
"short_name": "100",
"types": [
"subpremise"
]
},
{
"long_name": "408",
"short_name": "408",
"types": [
"street_number"
]
},
{
"long_name": "Washington Avenue",
"short_name": "Washington Ave",
"types": [
"route"
]
},
{
"long_name": "Downtown Houston",
"short_name": "Downtown Houston",
"types": [
"neighborhood",
"political"
]
},
{
"long_name": "Houston",
"short_name": "Houston",
"types": [
"locality",
"political"
]
},
{
"long_name": "Harris County",
"short_name": "Harris County",
"types": [
"administrative_area_level_2",
"political"
]
},
{
"long_name": "Texas",
"short_name": "TX",
"types": [
"administrative_area_level_1",
"political"
]
},
{
"long_name": "United States",
"short_name": "US",
"types": [
"country",
"political"
]
},
{
"long_name": "77002",
"short_name": "77002",
"types": [
"postal_code"
]
}
],
"formatted_address": "408 Washington Ave #100, Houston, TX 77002, USA",
"geometry": {
"location": {
"lat": 29.7654582,
"lng": -95.3614463
},
"location_type": "RANGE_INTERPOLATED",
"viewport": {
"south": 29.7640738197085,
"west": -95.3627994802915,
"north": 29.7667717802915,
"east": -95.3601015197085
}
},
"place_id": "Ei80MDggV2FzaGluZ3RvbiBBdmUgIzEwMCwgSG91c3RvbiwgVFggNzcwMDIsIFVTQSI6GjgKMRIvChQKEgnJRi06Lr9AhhGV09IgdaweuhCYAyoUChIJM09JeVPHQIYRFNRygKFHGo0SAzEwMA",
"types": [
"subpremise"
]
}
]
}I'll see if I can test with a different geocoder and see if the result is different.