🇬🇧United Kingdom @sergiur

I think once this lands in a stable release the install info could be on the module page, like anchor_link has?

Yep, meant to mention that, it’s pretty much copy paste from your suggestion. Just wanted to push this forward so I don’t have to manually download the library. Thank you!

Please see this issue for how to get the library to install without downloading manually: 📌 Add composer.json file Needs work

Created a MR for adding the composer.libraries.json file. This file needs to be specified in the extra section of composer.json as follows (assuming your webroot is "web"):

"merge-plugin": {
    "include": [
        "web/modules/contrib/fitvids/composer.libraries.json"
    ]
},

Then, running composer require wikimedia/composer-merge-plugin will download the external library.

If you already have wikimedia/composer-merge-plugin installed, try running composer install. If this doesn't download the fitvids library, try unrequiring and re-requiring wikimedia/composer-merge-plugin.

Lack of upkeep is terrible, but incredibly common. If you don’t implement the new functionality as it becomes available (which is even harder to sell to clients), the major version upgrades still take a decent chunk of time and are not as painless as they should be. Versionless marketing may make it more difficult to explain this to clients.

Other than that, I do like the simplicity

created new MR from 3.1.x.

sergiur → changed the visibility of the branch 3189058-add-parameters-to to active.

sergiur → changed the visibility of the branch 3189058-add-parameters-to to hidden.

This appears to be fixed in dev. Using that for now, pending a release

sergiur → created an issue.

The patch at #4 doesn't apply to 3.x. Will change version and attempt a reroll

Suggestion in #9 is very useful and it covers our use case (thank you!), though it would still be nice to have a prefiltered entity browser for a more visual experience, especially if the library is extensive. A select will do fine for now though.

RE #12: I believe the issue is you can add any allowed paragraph type to the library, then you create a paragraph reference field on your node to allow, say, 2 different paragraph types to be referenced + the From library paragraph. Since you are allowing the From library paragraph in your parent field, there is no way to add validation to stop the user from referencing any paragraph type via the From library entity browser. No matter what paragraph type you select from the library, it will let you save it because you're allowing the From library paragraph in the parent field. Not sure what you mean by selecting items of the "wrong" type. Where do you define the wrong type is?

Rerolled to fix the conflict in LibraryItemsSettingsForm.php buildForm return

ahh sorry did this on v2.. will need to do again on v3

changed the $menuId param to be required, now that it's followed by other params it is effectively required anyway

Hello! Tried the latest MR and it seems to have solved the issue both small and xsmall dropbuttons:

we're experiencing the same issue, the patch in #6 fixes it. thank you!

Thanks for the patches, they're really helpful! The latest patch in this issue causes a deprecation warning with PHP 8.1 described here: 📌 Deprecated: Optional parameter $menuId declared before required parameter $depth in MenuItems.php on line 117 Closed: duplicate . I've closed the other issue as a duplicate, I believe the fix should happen here.

This deprecation warning is introduced by the latest patch in this issue: ✨ Add parameters to control starting point and depth for fetch Needs review

Changing title for better google indexing

Our clients use invisible anchors often, they are useful. I think that was the purpose of the old fake objects module. It would be good if they could be deleted without going to Source though

I'm not sure how the dynamic tokens are supposed to work, but if there are no post values matched, the token itself prints as a string inside the webform field e.g. [current-page:post:email].

This patch makes a simple change to print an empty string if the POST value doesn't exist, as seeing the token itself is not useful. I see the same happens for the "query" dynamic token, which is also arguably not expected behaviour for users. Thoughts?

sergiur → created an issue. See original summary → .

The last working patch for me is the one in comment #75 ✨ Support views data export using drush Needs review . None of the patches after that seem to save the export at the custom path defined.

I am using version 1.3 of the module which seems to be up to date with the dev version. The command I'm running is drush vde test_export data_export_1 "" private://test/test_export.csv. I have tried the public file system too, but still not saving at the path I set. In the end I am deleting the old file as part of the cron job, before running the drush command using the patch in #75 which works.

It does download correctly for me. You need to require
wikimedia/composer-merge-plugin then add the path to the composer.libraries.json file in the extra section, under “merge-plugin”. See instructions here https://github.com/wikimedia/composer-merge-plugin#usage

Just wanted to add I've noticed the same thing on my entry in the directory → : Member for 53 years 4 months. I was a member before, lapsed, then signed back up a few days ago, not sure if that would contribute to this but thought I'd mention in case it helps replicate

The update function references this issue ID so I assumed it was introduced here:

/**
 * Issue #3351348: '#multiple__no_items_message' added to every field.
 */
function webform_post_update_ckeditor01() {

Thanks all for your work on this! I got it working on my project and it's very close. I notice if I add an empty space character and select the space, I can add an anchor as it uses   as the content. Doesn't help with editing existing ones created without any content, but at least there's a way to achieve the same thing

beta5 is from January, this fix is in the latest 6.2 dev version

Yup, same issue even after cache clear (I clear caches before updb out of habit xD)

When I run this update I get Error: Class "WebformYaml" not found in webform_post_update_ckeditor01() (line 113 of /app/web/modules/contrib/webform/webform.post_update.php). Does this need to use Drupal\webform\Utility\WebformYaml; or maybe I'm missing something since the patch applied for others?

Thanks for confirming, please feel free to switch the issue status to reviewed and tested by the community if everything is working :)