I can confirm the above in #13 works fine!
I have a page for a client where both simple textareas and ckeditor textareas are used for different fields in different paragraphs and if I clicked first on a simple textarea field and then on ckeditor textarea field, the focus would not work and Token Browser would not insert toke values.
If I closed the token browser window and clicked again the ckeditor textarea, then it would work, but the first time after a page load, it does not.
I switched the checks in the MR (first check for tokenFocusedCkeditor5 and then for tokenFocusedField) and now it works without a problem.
The only patch version that work for me in 10.2.6 was the one in #34. However, it fixes only the tag filtering, those are respected now but the problem is results are no longer returned.
Ok, done.
The problem was competing form actions. There was $form['add_actions'] as type 'action' and then $form['actions'] as type 'action.
The $name variable was always empty (attached screenshot) when clicking the Save button, hence the error in this issue.
The solution was to make $form['add_actions'] a container within the existing $form['actions'].
Patch added.
Right, closed as in resolved further, meaning MR and RTBC.
Sorry, I wrote that in a hurry.
Never mind, I found the patch for that in
https://www.drupal.org/project/field_group/issues/3395375
🐛
Duplicated required marks in field tabs with GIn admin theme
RTBC
.
This issue can be closed now.
I can also confirm that the patch fixes the issue for 3.6 with Drupal 10.2.6.
Screenshot added.
The patch applied successfully and it also fixed the issue.
But what is going on with the double start on vertical/horizontal tabs? I would add a screenshot but I don't have that option anymore for some reason.
I've just used the latest version of the module (3.6.0 from 3rd of Aug) and now I get for some horizontal tabs a double star (**) for tabs that are required and one start (*) for those that are NOT required.
Also, the main problem still stands: when I fill in the fields in the first tab and click Save at the bottom, nothing happens. It should open the next horizontal tab and highlight the next field that is required to complete, right?
When I apply my patch from https://www.drupal.org/project/set_front_page/issues/3464729#comment-157... 🐛 $pathValidator is deprecated in Drupal\set_front_page\Form\SetFrontPageEntitySettings->__construct() Needs review it gets applied successfully.
I tried applying the patch from https://git.drupalcode.org/project/set_front_page/-/merge_requests/3.patch but it fails to get applied (screenshot attached) - this was applied through the composer.json method.
I also tried applying it manually but that failed as well.
I've just tested on D10.2.6, php 8.3, on 3.x-dev@dev and it doesn't get applied.
I attached 2 screenshots: first when applying the patch through composer.json and the second manually.
Patch uploaded
andreic → created an issue.
Ok, it worked after I made sure that fontawesome_iconpicker_widget module is uninstalled (submodule of fontawesome) and then I created a new textfield and I was able to select the formatter.
Great, thank you!
https://www.drupal.org/project/fontawesome_iconpicker/issues/3463581
🐛
Widget not available
Closed: works as designed
Last evening the rc1 wasn't available and composer require drupal/fontawesome_iconpicker:^3 did not work.
Now it worked but when I go to Manage form display, the formatter doesn't show up in the list (screenshot attached).
It now gets installed but I can't get rid of this message:
Not installed
The fontIconPicker library could not be found. To use the Font Awesome Iconpicker, please verify that the fontIconPicker library is installed correctly. Please see the Font Awesome Iconpicker submodule README file for more details.
on the Status page although I added all the right stuff to composer.json file, including the updated library:
"d34dman/vanilla-icon-picker": {
"type": "package",
"package": {
"name": "d34dman/vanilla-icon-picker",
"version": "v1.1.3",
"type": "drupal-library",
"dist": {
"url": "https://github.com/d34dman/vanilla-icon-picker/archive/refs/tags/1.3.0.zip",
"type": "zip"
}
}
}
How would RTBC help if the composer command will always look at the latest release composer.json file on the d.o server?
I mean, let's say it gets into RTBC status. Then what? Get the MR patch, apply it locally? I did that. As soon as you then run:
composer require 'drupal/fontawesome_iconpicker:^3.0@alpha'
it will still look at the project's composer.json file and fail again.
Sorry but what am I missing here?
Could you please merge the MR so that we can actually install the module with composer?
Same here, after applying the MR patch, the error is gone.
Got it, thanks!
Strange, when I click Add content and the offcanvas opens, those buttons/links are not clickable.
Screenshot attached.
Great, the MR fixes also the Published checkbox (screenshot attached). All good on my tests, thank you!
Nice, it worked, thank you!
The only thing that still does not work is the Publish checkbox. It's just text, saying 'Not published'.
Yes, true.
How else did you test that modal/offcanvas node add/edit works?
But how? There is no Save button.
I used these steps:
- installed D10.3 standard and I only enabled Gin theme and admin_dialogs
- configured offcanvas for '/node/*'
- when I clicked Content > Add content > Basic page it loads the form in offcanvas with no submit button.
I've attached 3 screenshots.
This is still a problem.
Same problem with alpha2.
I can't test the patch at https://git.drupalcode.org/project/fontawesome_iconpicker/-/merge_reques... because it will always try to download the module and it will look at that composer.json first, right? Which means this MR has to get released in order to download the module in Drupal 10.
Actually, I've tested this a bit more and no matter what form I open in offcanvas, there's no action button (save, delete, etc.).
Thank you. This https://git.drupalcode.org/project/gin/-/merge_requests/430.patch got applied successfully but it didn't fix it.
I went one step further and installed D10.3 standard and I only enabled Gin theme and admin_dialogs and configured offcanvas for '/node/*' and when I clicked Edit on an existing node it still didn't show the Save node button (screenshot drupal-standard-offcanvas-test.png). Same thing with Modal.
Apologies, I should have clarified. I used the patch from:
-
https://www.drupal.org/project/gin/issues/3455080#comment-15650223
🐛
Save button missing in modal for editing media using Media Library Edit module
Fixed
- and from the MR https://git.drupalcode.org/project/gin/-/merge_requests/435.patch
and in both cases it errored out.
Using core 10.3 and latest gin dev from today (26.06).
Please see screenshots patch1.png and patch2.png.
Oh wait, scratch that. I just tried rc11 with the patch from https://www.drupal.org/project/gin/issues/3455080#comment-15650223 🐛 Save button missing in modal for editing media using Media Library Edit module Fixed and it applied successfully. Unfortunately, that didn't fix the problem. Please see screenshots offcanvas1.png and offcanvas2.png.
I checked, I'm not hiding any fields on Manage form display and I don't have any CSS with display none or anything.
andreic → created an issue.
As luck would have it, my VPS where the website is hosted got a system failure before that particular article was backed up.
Nevertheless, I recreated it and I updated the link above.
I found myself getting blocked by this error on a Drupal 9 to 10 upgrade and I was able to fix it. I documented the process here https://condurachi.ro/unknown-timediff-filter-twigexpressionparser-getfi....
Sorry, I'm not sure I understand.
All I did was add a checkbox in the View, which disables the double click action (screenshot attached).
That's what my client needed. Not sure what drop down box you mean.
Patch attached.
Never mind. I was doing a ksort() on hook_form_alter() to find the form keys easier. Apparently that doesn't sit well with Form API.
All fixed.
I've set this to Critical because the module is unusable.
The patch in #55 fixed the same error I had on a 10.1.7 installation.
Works fine and fixes the error on Drupal 10.1.5.
Yes, please commit.
I can confirm the cause was empty aliases. In my case, empty taxonomy aliases.
Obviously, the patch I uploaded is useless at this point.
I can confirm the patch works fine.
Updated patch.
Patch attached.
The existing code takes care of full URL already. Check out src/UnsplashFetcher.php line 54.
I enabled pathauto and created a node without alias on a clean Drupal 10.1.1 site but I couldn't get the error.
What were your steps?
andreic → created an issue.
I've just tested with a clean install of 10.1.1 and when accessing admin/structure/taxonomy/manage/tags/overview it does not display the error.
It must be something with that particular client.
If I go to admin/structure/taxonomy/manage/tags/overview I also get it:
Deprecated function: str_starts_with(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\path_alias\PathProcessor\AliasPathProcessor->processOutbound() (line 54 of core/modules/path_alias/src/PathProcessor/AliasPathProcessor.php).
This is weird, I'm getting the error when accessing paths like taxonomy/term/327.
I've upgraded to 10.1.1 and now I get:
Deprecated function: str_starts_with(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\path_alias\PathProcessor\AliasPathProcessor->processOutbound() (line 54 of core/modules/path_alias/src/PathProcessor/AliasPathProcessor.php).
Patch file attached. Must get applied after https://www.drupal.org/project/media_entity_unsplash/issues/3373586 ✨ Allow adding by photo URL Needs work .
andreic → created an issue.
After applying the patch to the latest module version with composer.json, I fixed all the remaining errors when it gets applied and finally it's ready to use.
Ok, the patch is all good to go.
Typos fixed, patch updated.
Patch added.
Title corrected.
Another error fix, updated patch.
Patch was incomplete, updated it.
I've updated the patch to include only the State API changes.
Thanks, I will try to debug that part.
Attaching patch
andreic → created an issue.
It works, that fixed it!
Patch works great!
1. Must be something I overlooked.
2. Well, first, the keys should not be in config/install/media.type.unsplash.yml file because that goes to Config. Then, some helper functions (e.g. unsplashGetKey and others) and then at the end, changes for the unsplash library because the library does not use access_key or secret_key, it uses applicationId, secret and utmSource as required keys when making call.
3. The links you gave offer the same solution: State API, which is what I'm doing, too.
Updated patch for all exceptions with appropriate message/hint.
Updated patch.
Typo fixed.
Patch file.
Patch file.
Patch file
andreic → created an issue.
Actually, you were perfectly right: "The client column in the db is NULL for all of them.".
I've encountered this myself and after a few hours of debugging, the problem was in the src/Normalizer/RefreshTokenEntityNormalizer.php file. It didn't include the client ID.
I've attached a patch.
#3 works for me. thanks.