Thanks for the work on this! I was having the exact same issue with the Preview button showing even though it was disabled in the content type settings. Your change adding the #access fixes the issue
That works for me -- I haven't seen any negative impact of removing the class in this way, it still gets added to the actual details elements you see by default and on mobile, but it's just not needed on the horizontal tabs.
merged 8.x-1.x
into this branch, though I will admit I only addressed the merge conflicts and haven't checked the rest of the patch in detail
sergiur β created an issue.
Implemented the changes, please let me know if I missed anything!
Thank you for the review! I'll be honest I mostly rerolled what was there, I should've checked the code in more detail to see what it's actually doing, my bad. Will have a look now.
Merged in the latest changes from dev and fixed conflicts, switched to extend StripePaymentMethodTypeBase
instead of PaymentMethodTypeBase
and opened a merge request so we can patch via composer. Please review!
sergiur β made their first commit to this issueβs fork.
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 :)