🇧🇪Belgium @redseujac

Another anomaly: the module Actions Permissions is still mentioned at the home page of the module VBO, while it has been dropped since 4.3.0-beta1.

Nowhere on that homepage it is mentioned that this particulare module Actions Permissions must be uninstalled and removed before installing a new version, because as far as I know that module is not removed automtically when installing a new version of VBO.

In addition to my initial post: you must take care of uninstalling and deleting the separate module actions_permissions beforehand. If not you will get problems when running "drush updatedb" or something similar. That module was distributed with previous versions of Views Bulk Operations and seems not being removed when upgrading. I had to manually uninstall and remove that module beforehand.

I had the error message:

[error]   (Currently using Missing or invalid module The following module is marked as installed in the core.extension
configuration, but it is missing:
* actions_permissions

I had to execute:

"drush config:delete core.extension module.actions_permissions"

and even:
drush php-eval "\Drupal::keyValue('system.schema')->delete('actions_permissions');"

@svenryen #41
I have tested 8.x-1.25-rc1 in Drupal 11.0.4 and I can confirm that the new release does not break anything that worked before the update.
Thank you.

redseujac → created an issue.

Well, I am working with Drupal core 11.0.4 and I installed manually EU Cookie Compliance 8.x.-1.24 after making it somehow compatible with D11.

In eu_cookie_compliance.info.yml i have added || ^11 to core_version_requirement and did the same in composer.json.

All is working properly without any error message nor warning in /admin/reports/dblog.

I see. Thank you.

That's too complicated for me. I will install the new version of Website Protected Downloads manually, leaving composer alone :)

This is the error messag when I try to install alpha 3 with composer:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/webform_protected_downloads 1.0.0-alpha3 requires drupal/webform ^6.2 -> satisfiable by drupal/webform[6.2.0, ..., 6.2.7].
    - drupal/webform_protected_downloads[1.0.0-alpha1, ..., 1.0.0-alpha2] require drupal/core ^9 || ^10 -> found drupal/core[9.0.0, ..., 9.5.11, 10.0.0, ..., 10.3.5] but the package is fixed to 11.0.4 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/webform[6.2.0, ..., 6.2.6] require drupal/core ^9.4 || ^10 -> found drupal/core[9.4.0, ..., 9.5.11, 10.0.0, ..., 10.3.5] but the package is fixed to 11.0.4 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/webform[6.2.5, ..., 6.2.7] require drupal/core ^10.1 -> found drupal/core[10.1.0, ..., 10.3.5] but the package is fixed to 11.0.4 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - Root composer.json requires drupal/webform_protected_downloads ^1.0@alpha -> satisfiable by drupal/webform_protected_downloads[1.0.0-alpha1, 1.0.0-alpha2, 1.0.0-alpha3].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

You may be right.

I am using webform 6.3.x-dev and made it compatible with D11 by editing the webform.info.yml tike this:
core_version_requirement: ^10.3 // ^11. So I added there ^11.

@james.williams
Cannot install alpha3 with composer because your root composer.json contains following:

"require": {
    "drupal/core": "^9.4 || ^10 || ^11",
    "drupal/token": "^1.0",
    "drupal/webform": "^6.2",
    "php": ">=7.4"
  }

Better would be "drupal/webform": ">=6.2" for users like me that are using another (higher) version than webform ^6.2.

@ito78x
It's working indeed only if site name and site slogan are selected, but unfortunately it doesn't work if site logo and site slogan are selected.

In that case only the slite logo is shown and the site slogan is not shown.

I guess it's caused by your code in templates\block--system-branding-block.html.twig.

@james.williams
I have uninstalled and removed the module and I installed and enabled it again with all the changes and improvements of MR !3.

So actually it's certain that I'm testing MR !3.

So far I didn't have any issues.

In any case I will continue using the MR !3 untill you will release a stable version of the module.

james.williams commented in #29

@redseujac Please could you confirm which merge request you've tested please? Was it MR !2 from this ticket; or MR !3 from #3426444: Resolve issue reported by PHPStan and PHPCS ?

I'm not sure anymore: I think MR !3, which combined the two according to your comment in #20.

To be sure I will compare the code from MR !3 with the code I'm using actually. If there are differences I'll aplly the full modifications and improvements from MR !3 and let you know my findings.

However look at my comment in #21.

@redseujac wrote in comment 27:

OK. I missed that one.
'Delete temporary files after' : 6 hours = setting on /admin/config/media/file-system
So I will test again and let you know the result.

Well the file didn't get removed after those 6 hours, though it is used in "0" places, but its status is marked as "permanent". I guess that's the reason. I don't know why that file isn't marked as "temporary".

So i have to remove the file manually.

@james.williams
OK. I missed that one.
'Delete temporary files after' : 6 hours = setting on /admin/config/media/file-system
So I will test again and let you know the result.

Is it possible to release a new dev version? Now in admin\reports\dblog I get each time a warning about my webform protected dowloads module. Not compatible.

I have deleted the protected file again and was able to upload it again. So this is working :)

However one remark: after deleting the file via the handler, saving the handler, running Cron an flushing all caches, the protected file is still present in the protected private file location. Is this normal or is it a bug?

I have tried again and now it works. I have been able to upload the protected file again.

I guess the problem was caused by a local temporary slow internet connetion with a really slow upload speed.

Hopefully it keeps working so you could continue working towards a stable version release of this module.

I have tested more deeply today.

I have a problem.

I have deleted the uploaded file from within the handler.

When I trie to upload again it fails, with the message:
"Oops, something went wrong. Check your browser's developer console for more details."

I looked in admin\reports\dblog and found nothing about it.

Maybe the upload runs out of time, I don't know.

I wiil stop now and test again tomorrow.

james.williams wrote in comment 20:

@redseujac would you be up for testing that?

I have tested the most recent MR build and I'm glad to tell you that it is working properly now in my environment D11.0.1 and the Webform module 6.3.x-dev which I made compatible with D11.

I am very pleased.

Thank you very much.

OK, I have read the guidelines and applied the patch from the merge request.

No luck.

When I try to add the handler to my form, I get the following warning and error in admin\reports\dblog

Warning: Undefined array key "#upload_validators" in Drupal\webform_protected_downloads\Plugin\WebformHandler\WebformProtectedDownloadsHandler->buildConfigurationForm() (line 224 of /data/sites/web/daproverbnbe/www/modules/contrib/webform_protected_downloads/src/Plugin/WebformHandler/WebformProtectedDownloadsHandler.php)

TypeError: Unsupported operand types: null + array in Drupal\webform_protected_downloads\Plugin\WebformHandler\WebformProtectedDownloadsHandler->buildConfigurationForm() (line 224 of /data/sites/web/daproverbnbe/www/modules/contrib/webform_protected_downloads/src/Plugin/WebformHandler/WebformProtectedDownloadsHandler.php).

Can you please fix this?

@james williams
I read your comment 14.

I am really sorry, but I am not a developer and I don't understand the fix in the merge request.

Could you please provide me here with a simple patch as in comment 7, the way I can continue testing the module as a simple user?

I don't understand quite well.

You wrote in @12:

and included the form element pointed out in comment 10

Well, that snippet in comment 10 is NOT A FIX. It's an element containing a deprecated function file_validate_extensions(), that should be fixed as explained in my comment 3.

Obviously I am missing something. Maybe @sarwan-verma could help.

I took a closer look and I guess that the issue from my post #3 has not been fixed.

In the following snippet there is still a call to deprecated function file_validate_extensions().

$form['protected']['protected_file'] = [
'#name' => 'protected_file',
'#type' => 'managed_file',
'#title' => $this->t('Choose file for protected download'),
'#multiple' => FALSE,
'#upload_validators' => [
'file_validate_extensions' => [$form_state->getValue('protected_file_allowed_extensions', $this->getSetting('protected_file_allowed_extensions'))],
],
'#upload_location' => 'private://webform_protected_downloads/' . PlainTextOutput::renderFromHtml($this->replaceTokens('[date:custom:Y]-[date:custom:m]')),
'#default_value' => $this->getSetting('protected_file'),
];

That's line 217.

@sarwan-verma

Thanks for the patch.

I have applied the patch, but I get errors when working with te module.

I'm not able to upload and save a file. I'm trying to upload a .zip file. When I think the operation is finished andI click save, the file is not saved and I get an error message in /admin/reports/dblog lik this:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "file_validate_extensions" plugin does not exist. Valid plugin IDs for Drupal\Core\Validation\ConstraintManager are: Callback, Blank, NotBlank, Email, Choice, Image, BlockContentEntityChanged, CKEditor5Element, CKEditor5MediaAndFilterSettingsInSync, CKEditor5EnabledConfigurablePlugins, CKEditor5FundamentalCompatibility, SourceEditingPreventSelfXssConstraint, SourceEditingRedundantTags, StyleSensibleElement, CKEditor5ToolbarItemConditionsMet, CKEditor5ToolbarItem, CKEditor5ToolbarItemDependencyConstraint, UniqueLabelInList, CommentName, DateTimeFormat, FileExtension, FileExtensionSecure, FileImageDimensions, FileIsImage, FileNameLength, FileSizeLimit, FileUriUnique, FileValidation, LinkAccess, LinkExternalProtocols, LinkNotExistingInternal, LinkType, MenuTreeHierarchy, MenuSettings, PathAlias, TaxonomyHierarchy, ProtectedUserField, UserMailRequired, UserMailUnique, UserName, UserNameUnique, ContentTranslationSynchronizedFields, ConfigExists, LangcodeRequiredIfTranslatableValues, RequiredConfigDependencies, Bundle, EntityChanged, EntityHasField, EntityType, EntityUntranslatableFields, ImmutableProperties, ReferenceAccess, ValidReference, ExtensionExists, ExtensionName, UniquePathAlias, ValidPath, PluginExists, AllowedValues, ComplexData, Count, CountryCode, EntityBundleExists, FullyValidatable, Null, Length, NotNull, PrimitiveType, Range, Regex, UniqueField, Uuid, ValidKeys in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /data/sites/web/daproverbnbe/www/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Any help is welcome.

@james.williams

Could you please fix the issue indicated in #3 concerning the deprecated function file_validate_extensions()?

I am working actually with Drupal 11.0.1 and installed the Webform module 6.3.x-dev which I made compatible with D11.

I really would like to test the module in that environment, but I don't know how to fix WebformProtectedDownloadsHandler.php.

Could you provide me with a patch?

Please release a stable version for D11.

For now D11 websites (as mine) must be run without cookie banner at all, thus infringing EU law and rules.

The issue seems to be fixed now. Thanks!

@cilefen
It is fixed now. No more issues. Thanks!

@cilefen
It is fixed now. No more issues. Thanks!

@cilefen
It is fixed now. No more issues. Thanks!

Finally it is a bug relating to a core module that should be fixed in a next update?

We (users) can do nothing about the problem and it should be fixed by the Drupal developers?

I have exactly the samenproblem with D11.0.1

redseujac → created an issue.

@gorkagr
What is the infrastructure issue, please? I cannot reach drupal.slack and I have exactly the same problem in D11.0.1

I have applied the patch also and I confirm that it's working properly.

Thank you very much!

I understand, but maybe this module could already be made D11 compatible without waiting for the Weborm update.

Indeed, I'm afraid that the latter could take some (considerable) time to complete.

OK, but there is still another issue:

modules/contrib/webform_protected_downloads/src/Plugin/WebformHandler/WebformPro
tectedDownloadsHandler.php:
+-------------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| status | line | message |
+-------------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Now
fix | 257 | Call to deprecated function file_validate_extensions().
Deprecated in drupal:10.2.0 and is removed from
drupal:11.0.0. Use the 'file.validator' service instead.

redseujac → created an issue.

The patch is working properly.

The module maintainer should make this module compatible with D11 now.

I do not insist for that "Token text title" option, because it's working well as it is now.

Just one observation on translation: actually - as it is now - I have still to add a translation for the Token text title I'm using in the HTML construction (as in #18).

In Dutch I have now in the Confirmation message: Klikken op: <a href="[webform_submission:protected_download_url]">Bestand downloaden</a>.

In English this means: Click on: <a href="[webform_submission:protected_download_url]">Download file</a>..

So I have to create a French translation for the string "Dowbload file" in the HTML construction.

This is done through "myWebForm" (name of my form) > Translate, where all the strings of my Webform can be translated in e.g. French in my case. See uploaded image "Confirmation_message_translation.png"

No, I do not use the token in confirmation mails, only in the confirmation message. I repeat I did never use confirmation emails.

It's perfectly possible to have the text translated via the form settings > translation. I have indeed a website with two languages: Dutch and French.

I would prefer to avoid jumping ahead too quickly!

Of course. I understand that perfectly.

Still one small thing about the link for downloading the protected file with the token included in the confirmation message.

In the "old" version there was no need to use HTML directly or throuhg the CKEditor link button for the Token text title. Indeed in the settings of the Weborm Protected Downloads module there was an option "Token text title" and the default was "Download file". So you just had to accept that or enter another text. Thus it was sufficient to enter the token in the confirmation message. For myself it looked like: Click on: [webform_submission:protected_download_url].

Now there is no option for the Token text title, although that was quite easy to use. Maybe a suggestion for a next version?

I have installed the updated alpha 2.

As to now it's working properly. The link for downloading the protected file is OK as you explained in #19.

Thank you very much for both the new module (working well in Drupal 10 and most recent Webform) and the explanation for linking.

Maybe the alpha can become definitive soon.

I have tried the alpha.

It works, but I have a problem with my confirmation message and the Protected download link webform submission token.

When a I complete the webform submission, in my message I do see the link in place of the token, but I cannot click it to download the protected file directly after. Clicking the link to download directly the file was possible in the previous version.

Maybe I'm missing something.

The syntax in the message looks like:
Click on: [webform_submission:protected_download_url]

@james.williams
Drupal 10 is out quite some time now (version 10.2.3), while Webform is on version 6.2.2 already.

Maybe the time has come to make this module work on Drupal 10 now so it can also be used in Webform 6.

Thanks and best regards.

mfb commented in #74

(or hire a developer if you don't have one)

I'm afraid that's an illusion: a common user will not be eager to hire a developer to test module patches or so.

jabeler commented in #72:

With that said, I think there are many who would be willing to support a handful of projects such as this that their sites rely on, but don’t have the development skills or time to make meaningful contributions. Instead, they may be willing to offer some sort of monetary support, either one-time or on recurring basis. I don’t know where this falls in the spirit of the Drupal project or organization, but compared to something like Wordpress which has countless paid/or subscription type modules I don’t think it’s too crazy of an idea.

see Webform module's Open Collective: https://opencollective.com/webform#section-contributors

With all my respect for the maintainers, but it seems to me that's not much honey left in the pot...

What's the worth of a module without users or when users are not allowed to report issues and humbly beg to fix them?

Not every user is supposed to be a developer, right? and not every user is supposed to be or become a maintainer? Is it the users' fault that a problem has not been solved after 5 years? I surely don't think so.

That being said, I have disabled and uninstalled again the empty honeypot.

+1 for Chris Matthews as commented in #19

I do agree. Please release a tagged release.

Grevil commented in #48:

@redseujac, you could also simply apply this MR's diff: https://git.drupalcode.org/project/honeypot/-/merge_requests/9.diff, as a patch inside your composer.json and the issue is fixed.

I have followed your advice and the issue is fixed indeed. Thanks a lot!

@masipila @Anybody: well, the issue is solved for me. I just uninstalled and removed the module. Thank you all :)

Never mind. In real life I do not use this module, but this one: https://www.drupal.org/project/ckeditor_font →

It's the "recommended" font module and it's working properly with Drupal 10.1.0.

Take a look at my post sub #16 above.

tjtj wrote in #20;

upgraded Drupal from 10.0.9 to 10.1.0 and now get this error.

Confirmed : CKEditor 5 - Font plugin version 1.1.2.-beta1 doesn't work in Drupal 10.1.0, leads into: The website encountered an unexpected error. Please try again later when trying to edit node text and is showing following error in dblog:

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "ckeditor5_codeBlock" CKEditor 5 plugin definition is configurable, has non-empty default configuration but has no config schema. Config schema is required for validation. in Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition->validateDrupalAspects() (line 186 of /data/sites/web/mysite/www/core/modules/ckeditor5/src/Plugin/CKEditor5PluginDefinition.php).

Please fix.

I upgraded to Drupal 10.1.0 and error is showing about missing primary key in the table 'honyeput_user'.

I'm using Honyepot version 2.1.2.

Please fix.

That makes sense.

I am using Drupal 10.0.9, PHP 8.2.6, Webform 6.2.x-dev (most recent build).

jrockowitz commented in #9:

I think for 6.2.x we should require PHP 8.1+.

So do I.

Agreed. Isn't it time to have a new stable release for D10?

D10 is out since quite some time and so is 6.2.0-beta5 (released 12 jan 2023).

So, please...

Wim Leers commented in #70:

Note that per #3357678: The block editor menu havent the "editor" (see #19 + #20 + #21) that this is causing CKEditor 5 to fail to load correctly in certain contexts too. This issue fixed it. It first shipped in a release in 10.0.9.

I'm working with 10.0.9 and I'm glad to tell that my problems with Webforms/CKEditor5 are solved now. Before it was impossible to write/edit text in some textboxes managed by CKEditor5 there.

I have installed version 3.4.0 successfully on Drupal 10.0.9. No error messages. I used Composer to install the module.

Harish1688 commented in #36

Based on comment #34, I have tested the webform module by setting it as a top-level item in the toolbar. I did not encounter any issues during testing. The functionality is working perfectly fine.

I see on your screenshot that the blue arrows are NOT enabled at the admin toolbar.

My problem with the splitting of the toolbar occurs when the blue arrows are enabled.

Maybe I could have found the cause of my problem.

I have an additional toolbar item in my menu: 'Webforms'.

Indeed 'Webforms' can be displayed as a main toolbar item (with a dedicated icon), instead of being displayed under 'Structure'.
( https://www.drupal.org/node/3168118#:~:text=To%20move%20the%20Webforms%2... → .)

So, with that extra menu item, my admin toolbar became longer, all the more because I'm using the Dutch language and the text of the menu items are also a bit longer in Dutch.

However, when I'm using the original admin toolbar with the blue arrows, in spite of the extra menu item, the toolbar is displayed on just one row, while after applying the patch the toolbar with the blue arrows is displayed on 2 rows.

Could you try to replicate with 'Webforms' displayed as a main toolbar item?

aziza_a commented in #32:

Checked on 3.3.2 not able not replicate it.

OK. I will try again with the patch #32.

If I remember correctly, there is a database update needed after the patch? Could you confirm this please?

Harish1688 commented in #30

3. Also tried with version 10.0.9, as per comment #28, but not facing any issue with after apply the patch with enable mode.

I tested in version 3.3.2 of admin toolbar and not in 3.x-dev.

Hmm! after applying the patch, my admin toolbar with the blue arrows is splitted on 2 lines. The "Help" is on the second line. So there is something wrong with some patch settings for me.

When I click the checkbox for disabling the blue arrows, it works as expected.

When I uncheck the box to return to the toolbar with blue arrows, the toolbar is splitted again on 2 rows.

So, I went back to the original admin toolbar 3.3.2 on Drupal 10.0.9

mistergroove wrote in #19:

+1 for making it a config option. Installed the patch. Anyone else have double arrows showing on submenus too?

No, I do not have double arrows on submenus.

I'm using Olivero theme and Claro admin theme.

I applied the patch #14 and it's working properly. Those blue arrows are gone from the admin toolbar.

I think the user shoud be able to decide about the visibility of those buttons. In the toolbar settings there should be a possibility to disable them. That's not that difficult?

troesler wrote in #4:

Please can you add an checkbox in the config interface to disable this feature ?

I do agree. I do not like those "blue arrows" either. There should be a way to hide them.

All credit for that ckeditor font module goes to Webbeh who really did a great job!

Take a look at e.g. this "issue" history:
https://www.drupal.org/project/ckeditor_font/issues/3239667 📌 Drupal 10 & CKEditor 5 readiness Fixed

Take a look at this ckeditor 5 font module (works also on Drupal 10):

https://www.drupal.org/project/ckeditor_font →

https://www.drupal.org/project/ckeditor_font/releases/2.0.0-beta3 →

It's working fine and contains not only font color (foreground and background) but also font size and family.

For the font color you have to enter color values and save them. So the colors are not contained automatically when installing and enabling the module.

It's also recommended as 'official' CKeditor 4/5 plugin here;
https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckedito... →

Hello neighbor, me waves from Ieper (Ypres) / Menin Gate 🖐😊

In the meantime I'm glad to tell you that the CKEditor 5 Font module is nearly ready. Issues fixed.
https://www.drupal.org/project/ckeditor_font/issues/3239667 📌 Drupal 10 & CKEditor 5 readiness Fixed

Have a nice day.

I have tested the beta3: it's working properly now!

Thank you for the fix and the whole font module.

As far as I'm concerned I would go for the new full release.

Wim Leers wrote:

https://ckeditor.com/docs/ckeditor5/latest/framework/guides/deep-dive/ui... does provide answers, but offers multiple choices. What is the choice we recommend?

The method window.CKEDITOR_TRANSLATION object, the second option explained here: https://ckeditor.com/docs/ckeditor5/latest/framework/deep-dive/ui/locali... , is working well in ckeditor_font module.

Look here:

https://www.drupal.org/project/ckeditor_font/issues/3346729 🐛 Buttons are not translatable Fixed

https://www.drupal.org/project/ckeditor_font/issues/3346729#comment-1497... 🐛 Buttons are not translatable Fixed

Webbeh commented in #5

Before I cut a new release, please let me know this works and I'll release -beta3

I have installed 2.0.x-dev updated 21 Mar 2023 at 00:15 UTC.

It works properly now. So just go for the beta3.

Thank you.

PS: I had worked out another fix scheme based on your original ckeditor_font.libraries.yml, but as all is working now properly, let's forget it.

redseujac → created an issue.

Unfortunately NOT fixed in version 2.0.0-beta 2

The file ckeditor_font.libraries.yml is not updated correctly.

It contains the followng code in js part:

font:
  js:
    js/build/font.js: { preprocess: false, minified: true }

while the correct code should be:

font:
  js:
    js/ckeditor5_plugins/ckeditor5-font/build/font.js: { preprocess: false, minified: true }

The path to the font.js is not correct and does not work.

So please fix it.

I have found the solution! It's simple and it works great. I tested with my languages Dutch and French.

The translations are already integrated in the module. So nothing to change or add here.

Just edit the ckeditor_font.libraries.yml file like this:

font:
  js:
    js/ckeditor5_plugins/ckeditor5-font/build/font.js: { preprocess: false, minified: true }
  dependencies:
    - ckeditor5/ckeditor5
    - core/ckeditor5.translations

As you can see I have edited the first line of the js part and added a third line to the js part and that's it!

The whole file is looking as this now:

font:
  js:
    js/ckeditor5_plugins/ckeditor5-font/build/font.js: { preprocess: false, minified: true }
  dependencies:
    - ckeditor5/ckeditor5
    - core/ckeditor5.translations

admin.font:
  css:
    theme:
      css/fontsize.admin.css: { }
      css/fontfamily.admin.css: { }

admin.fontcolor:
  css:
    theme:
      css/fontcolor.admin.css: { }

admin.fontbackgroundcolor:
  css:
    theme:
      css/fontbackgroundcolor.admin.css: { }

Do not look any further: it's fixed!!!

Please create a patch and/or update the module. I think it's ready now for updating the beta to

@Webbeh #8

The proposed strategy indeed opens a path for a solution. If possible just give it a try if you can't find any other possibility mentioned in the f #5:

but I'm checking in the #ckeditor5 channel in Drupal Slack to check the right way forward.

I'm curious if this is a larger issue across CKE5 contrib space, but I'll let you know what I hear back.

Good luck!

I found this about interface translation properties

https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.api.p...

https://medium.com/limoengroen/how-to-deploy-drupal-interface-translatio...

https://www.rodrigoaguilera.net/provide-interface-translations-custom-mo...

So I applied "interface translation project" and "interface translation server pattern" to ckeditor_font.info.yml.

Then with drush locale:check and drush locale:update and /admin/reports/translations > check manually, I was able to import the translatable/translated strings and view them in /admin/config/regional/translate > Filter translatable strings, but unfortunately they still are not showing on the buttons nor dropdown items.

So, although the strings and their translation are imported now, the translation is still not showing.

Problem not solved.

Webbeh commented in #5:

I believe that [#3264983] may solve the issue

Cannot find that. Could you specify a more concrete link, so I am able to read it?

redseujac wrote in #20

I will temporary remove the 2.0.0-beta 1 and replace it with the newest 2.0.0-dev so I can check the fix.

Well, I have done so and actually the issue is fixed in 2.0.0-dev.

Congrats!

Now only try to fix this translation issue 🐛 Buttons are not translatable Fixed and it's done.

@Webbeh

Thank you! Unfortunately I cannot test the 2.0.0-dev because I'm only working with a production site.

However if this translation issue 🐛 Buttons are not translatable Fixed could be fixed, then I assume that a new stable release instead of 2.0.0-beta 1 could be put out.

smustgrave commented in #63:

Enabling all the buttons.
As I'm filling in the font values "Font background colors" is showing as error even though I haven't filled anything in

I assume this is not a bug.

When the "Font background color" button is activated (= dragged to the bar with active buttons), at least one valid color value must be entered in the box "Font background colors" before saving, otherwise it doesn't make sense => button activated without any color value assigned.

It seems easy enough to copy and paste (all) the color values from the box "Font colors".

In addition to my comment #3:

There are also translation files in /libraries/font/lang. These are .js - files.

In Drupal 10 > CKEditor 5 > Font Colors :

In the Font Colors box you have to enter e.g. the following color values to be correct:

hsl(0,0%,0%)|Black
hsl(0,0%,30%)|Dim grey
hsl(0,0%,60%)|Grey
hsl(0,0%,90%)|Light grey
hsl(0,0%,100%)|White
hsl(0,75%,60%)|Red
hsl(30,75%,60%)|Orange
hsl(60,75%,60%)|Yellow
hsl(90,75%,60%)|Light green
hsl(120,75%,60%)|Green
hsl(150,75%,60%)|Aquamarine
hsl(180,75%,60%)|Turquoise
hsl(210,75%,60%)|Light blue
hsl(240,75%,60%)|Blue
hsl(270,75%,60%)|Purple

So, indeed in your guidelines below the box you need hsl(0,0%,0%)|Color. Inclusion of percentages for second and third parameters is correct.

smustgrave commented in #63:

I think this is a bug with ckeditor but when I highlight text and change the font size. Press enter to go to the next line. That font is still being used. Verified with other buttons too.

I tested with some basic CKEditor 5 buttons (such as Underline, Italic, Bold) and they are also causing the same issue: highlight text and change the font property (Underline/Italic/Bold). Press enter to go to the next line. That font property is still being used.

So, finally it's a CKEditor 5 issue that should be fixed. Can someone report this under CKEditor 5 issues?

You're welcome! But don't forget the issues reported by smustgrave in #63. I can confirm these.

I have examined this issue further.

I have found that the module contains two kind of translation files.

ckeditor_font > js > cleditor5_plugins > ckeditor5-font > lang > translations : contains .po-files

ckeditor_font > js > cleditor5_plugins > ckeditor5-font > build > translations : contains .js - files

However, as I wrote in my initial post, the buttons and dropdown list items are not translated and always are showing in English in spite of those existent translation files. Somewhere there must be something wrong in the code not pointing (properly) to those translation files.

Installed version 2.0.0.-beta1 on Drupal 10.0.4.

Same comments as in #63.

Apart from that working fine.

However a couple of little issues:

• Buttons are not translatable: see https://www.drupal.org/project/ckeditor_font/issues/3346729 🐛 Buttons are not translatable Fixed
• Wrong syntax for hsl color values: see https://www.drupal.org/project/ckeditor_font/issues/3346485 🐛 Wrong syntax for hsl color values Fixed

redseujac → created an issue.

redseujac → created an issue.

redseujac → created an issue.