🇧🇪Belgium @joevagyok

@vladimiraus I am not sure if the new issue is really necessary. This issue is perfectly describes the problem. I think a new MR would be sufficient, but I can create a new issue if you insist.

joevagyok → made their first commit to this issue’s fork.

I think it would be very useful to have actual clickable actions under /admin/content/shorthand table besides "Update story", like "Delete story" and "Delete story versions" that would take you to a confirmation page where you can select with checkboxes the version the user wish to delete.

Changed the approach to check for default_formatter key in the definition before we render any field relying over that.

Adding patch file for composer.

joevagyok → created an issue.

Rebased the content of the previous MR and opened a new MR against 3.x since I was unable to change the target branch to 3.x.

Re-rolled the patch from #18 over the latest 3.0.0-alpha3 release.

I re-rolled the contents of the MR over the 11.2.x branch. Currently fails to apply over 11.2 release.

Merged, thank you all!

Good work! Thank you everyone.

Sadly, we decided to pursue a different path in our project. I withdraw my proposal and closing this issue.

Tested, works well now. Thank you!

Thanks for reporting the issue and looking into it with a proposed solution. Tests are failing, so some more work is needed.

joevagyok → created an issue.

Thanks for the report on that! I opened a new MR with the fix.

Thanks for the work!

joevagyok → created an issue.

joevagyok → created an issue.

Thanks for the review comments. The MR is in a work in progress.

joevagyok → made their first commit to this issue’s fork.

Anyhow, rebased the MR over 8.x-2.x.

I think this issue should be closed in favour of Drush 13 update where Drush 12 should be the minimum version required. https://www.drupal.org/project/extra_field/issues/3511072 📌 Drush 13 compatibility Active

joevagyok → made their first commit to this issue’s fork.

The MR had missing pieces from the patch, I pushed it.
I attached a patch file for composer patching against 1.19 version.

joevagyok → made their first commit to this issue’s fork.

Thank you all!

Already fixed. Thank you.

Thank you all!

joevagyok → made their first commit to this issue’s fork.

Thank you all!

joevagyok → made their first commit to this issue’s fork.

Thank you all!

joevagyok → made their first commit to this issue’s fork.

Thank you all! :)

Thanks for the fix, can we have some assertions for this please?

Thank you all!

Thank you all!

Thank you for the proposal! Test coverage for this would be much appreciated!

Thank you!

Thank you all!

@neclimdul can we have a merge request with this please?

joevagyok → made their first commit to this issue’s fork.

Also some basic test coverage of the code would be much apprechiated!

I like the proposal and the patch! Can we get a merge request with it please? :)

Thank you!

joevagyok → made their first commit to this issue’s fork.

joevagyok → made their first commit to this issue’s fork.

Thank you!

Thank you all!

Thank you all!

Thank you all!

The solution is looking good for me! Thanks @scott_euser

greggles → credited joevagyok → .

Opened another MR against the 3.x branch as well.
Uploading the patch file against the 3.0.0-rc20 release for composer patching.

Approved the MR, ready for merge.

MR looks good, we are using the patch in our project.

Thank you all for the contribution!

Removed the big border to have only the image.

Thank you for the simplified version, I find it way too simple. :)

I fixed the numbering on the previous.

I recently merged a fix related to this. I believe it is fixed by 3478937 🐛 CkEditor5 Counter gets attached in the wrong place after ajax call Active .

Can you please confirm?

I understand that you would expect from the config to act as a definitive limit when turned on and truncate the string once it is switched on.
However, it implies that the field can hold more characters just well, before the option was not turned on, so having the string truncated on form load, would render part of your pages unreadable due to the loss of strings after the save operation. I find that a bit harsh and disturbing from the editor point of view.

Thank you for the fix!

Reviewed and tested by our organisation.

joevagyok → made their first commit to this issue’s fork.

Ready to merge upstream.