I've had a report of a similar issue. From reading the linked issue, I'm wondering in my case if it's my use of scheduled_transitions → is causing this issue with either node access OR due to the different status types that aren't strictly published or unpublished ("Draft", for example).
Oh, looks like that may be the exact issue!
There are a few instances - in their icons.yml they have it under plus and plus-large:
plus:
aliases:
names:
- add
unicodes:
composite:
- '2795'
- f067
primary:
- f067
secondary:
- 102b
- 10f067
changes:
- 1.0.0
- 5.0.0
- 5.0.13
- 6.0.0-beta1
- 6.2.0
- 6.3.0
- 6.4.0
- 6.5.0
label: Plus
search:
terms:
- 0
plus-large:
changes:
- 6.1.1
- 6.2.0
- 6.3.0
- 6.4.0
- 6.5.0
label: Plus Large
search:
terms:
- 0
There are similar lines in the icon-families.yml for the same icons too!
Alright, after some more testing and putting this on another site, I've started encountering the "e.trim() is not a function" error again.
After logging the value of term on line 89 in iconutils.ts, it prints them all up to 0 - which prints as a number, not a string. I believe this is why we're getting the "e.trim() is not a function" error.
Should that line be modified to only trim strings?
(iconDefinition as IconDefinition).search = { terms: (iconDefinition as IconDefinitionAlt).search_terms.map(term => typeof term === 'string' ? term.trim() : term) };
Alternatively, it might be being imported as a number instead of a string - but this is still with a brand new download of FA6 Pro from Font Awesome, so it might just be how they populate some of the Pro icons vs Free?
I had updated the Font Awesome library with a fresh download, so the metadata was straight from them - but maybe it was just a secondary issue from the main index issue.
Yeah, originally I had logged the index variable and it printed twice as 1 and then once as -1, which CKEditor didn't seem to like. After looking at CKEditor documentation, it says that not providing an index would add it to the collection (and assumedly create an index value). Just to get something working, it made sense to let them handle the index versus providing a value that threw an error.
The patch in #7 changes the logged index value in _startTracking() from 1, 1, -1 to 1, 2, undefined, but CKEditor doesn't throw an error and continues working!
So overall, the patch provided in #7 seems to solve the issue - the icon picker now displays and inserts icons! Thanks for the patch!
Alright, was able to take a look at this and found the spots that were throwing errors. It seems like it ended up passing -1 as the index, when CKEditor will assign one for us if it doesn't have an index. That, and not calling trim on an empty or void seemed to fix my issues and got it working for me.
Oh, interesting - after updating from Font Awesome Pro 6.4.2 to 6.5.1, the previous error goes away - but I now get the "trim is not a function" error from the comment above!
agbockus → created an issue.
This seems vaguely similar to an issue that I had created previously - I have created a partial solution, but it may need more tweaks: https://www.drupal.org/project/fontawesome/issues/3380581 🐛 Iconpicker does not render classes appropriately Needs work
I believe I found the issue - I've attached my current patch as a starting point, but it doesn't take into consideration other work or changes that might exist in other areas of the module - and also ignores FA5 compatibility.
Mostly, the issue (in the latest 8.x-2.x branch) is at line 639 in src/Plugin/Field/FieldWidget/FontAwesomeIconWidget.php. This seems to prepend the selected icon style with fa- which is giving us the incorrect class(es) on the icon when printed. Related: the available options are on line 119, but the following lines of code seem to be removing styles without checking if their Sharp alternatives are still enabled.
---
Since the module is prepending fa- it either needs to change the available style values to the words of the styles (e.g. 'solid' instead of 'fas') or remove the prepending functionality on line 639. Either way, we could check to see which value is added, and simply add the _additional_ class for the previous or next version.
Example: If the module implements the full word option, then if the value is set to 'solid', prepend fa- and then append fas.
This would make it work for both FA5 and FA6, I think.
Throwing in my experience - I have a similar issue with <hr class="top-shadow"> which should be allowed as HRs are listed to allow global attributes as well as documented on MDN here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hr.
I'll thumbs up the issue on GitHub as well.
This is from inserting using the actual icon field.
When I inspect the select dropdown, all the values are still "fas", "fab", etc. Are they supposed to be showing "solid" and "brands"?
During testing, I made sure to test on a new page and inserted a new icon ("fa-house") which resulted in <i class="fa-fas fa-house"></i> being printed.
agbockus → created an issue.
Ah, created the patch from an incorrect folder, fixed in new patch.
Since mixed is not available in PHP 7, I've changed the variable type to be string since that's what the errors during testing mentioned as the variable type provided when uploading a CSV.
I've created a tiny patch to set the variable type to string, but it may need to be tested with other delimiters.
Speaking with another developer (
Ghazlawl →
), they mentioned that the mixed type isn't available in PHP 7.
PHP.net states that the mixed type was not introduced until PHP 8.0.0.
This module lists support down to Drupal 9.3 and Drupal 9.x supports down to PHP 7.3 → .
Thank you so much for your help! Appreciate it!
agbockus → created an issue.
Created a patch with the recommendation from Daniel!