Thanks guys, both the patch itself worked as well as the latest dev version. Time to wrap this all up in my branch and get it in front of the client to see. Woot!
@bbu23, just to help clarify here, when you configure the "Swiper images Dialog", do you actually see the setting for "Caption source field"? for me, this doesn't even display so I can't select any option. You can see this on #24, first screenshot.
[OK Drupal.org issue queues, I'll retype this yet again! (always copy what you type here before saving or previewing)]
I too can confirm that the latest 2.0.x-dev works great for the site this is on. It took some time to get the view mode configured correctly since I only wanted to show one image in the pop - see screenshot.
Thanks for all the work here guys!
jcl324 β created an issue.
I too ran into this issue. Tried various things to get DatePickers.php
to show the initial date that was set in the filter, but no luck. What I ended up doing instead was to set the exposed date filter to a static value but actually left it blank - your mention that the picker does work without an offset date gave me this idea. Then I added a form alter to set the initial date and voila! Note it's important to have the view value initially empty so you can test for it on first load.
function recurring_date_formatter_form_views_exposed_form_alter(&$form, FormStateInterface $form_state, $form_id) {
// Set the default value for the date filter to the current date +2 days.
if ($form['#id'] == 'views-exposed-form-event-promotion-page' ||
$form['#id'] == 'views-exposed-form-event-promotion-page-1') {
$default_date = new \DateTime('+2 days');
// Set the default value only if the exposed filter is empty.
$user_input = $form_state->getUserInput();
$filter_value = $form_state->getUserInput()['field_dates_value'];
if (empty($filter_value)) {
$user_input['field_dates_value'] = $default_date->format('Y-m-d');
$form_state->setUserInput($user_input);
}
}
}
If/when I get a chance, I think the solution for DatePickers.php
might lie in the $user_input = $form_state->getUserInput();
pulling from $form_state.
xjm β credited JCL324 β .
Why is this marked fixed if there is no 2.0 release? I'm currently trying to get `dev-2.0.x` to work but getting this error:
TypeError: strlen(): Argument #1 ($string) must be of type string, int given in template_preprocess_field_orbit() (line 38 of modules/contrib/field_orbit/field_orbit.module).
I'm on core 10.1.7, PHP 8.1.
JCL324 β created an issue.
Add me to this list. merge-plugin is installed, but even tried to add the libs manually. Nothing seems to work.
JCL324 β created an issue.
I just tried patch #8 and it completely broke Masquerade! Before this patch I was able to masquerade as a non-admin and only got the error when trying to do as admin (user 1).
I'm currently on Drupal core 9.5.11, simpleSAMLphp Authentication 8.x-3.3, and Masquerade 8.x-2.0-rc4.
Re-rolled patch.
JCL324 β created an issue.
@komlenic thanks for pointing this out to me! We are in fact still on PHP7.4, working through the upgrade plan to 8.1/8.2 now. Yes it should have a PHP dependency like gangu mentioned. I'll revisit this in a couple weeks to see if there's a newer release. But rc3 + patch is just fine for now.
So this patch worked for me yesterday on 2.0.0-rc3. Noticed today rc4 is released, so updated it. Now my field with this widget doesn't even show! Completely blank. I did remove the patch since it's now included. Guess there's a new bug now?
@asherry, sorry, just getting back to this, yes time gets away from us all! In reviewing my issue/patch for Message won't dismiss β , I noticed in my writeup that I said I only changed 3 files so the snippet that was included about the time zone issue was probably just a hold over from me fixing something else. I totally agree that it shouldn't be in there, has nothing to do with fixing the dismissal issue. Once I have a chance to get back to this, I'll redo it and incorporate your patch here so no need to update the title :)
Sure, I'm kind of new at all this forking/issue stuff and have been finding all these little issues and bugs while trying to use this module on a site that's about to launch. I am up to 3 issues now and it's all getting really hard to manage, especially on my end. We really need the maintainers to chime in here and help corral all these changes and give feedback. Aren't they also at Aten like you?
JCL324 β created an issue.
@asherry, I actually found this bug back in October and fixed it as part of this issue: https://www.drupal.org/project/notification_message/issues/3315255 π Message won't dismiss Fixed . See my commit here: https://git.drupalcode.org/project/notification_message/-/merge_requests...
Our code is very similar, I'm sure yours works fine, but know that my issue has already been RTBC by solideogloria and ready to be merged into dev. Maybe take a look at this patch and see if it works for you? https://git.drupalcode.org/project/notification_message/-/merge_requests...
This is still happening in 1.4.0. I installed on a new D10 site to evaluate, disabled and removed with composer. Link on Content page still there as well as the view defining the path. Good to know I can just delete this view if I want.
@clayfreeman, please do tell me how this violates the policy. Contrib modules add links all the time! It could easily go under admin/config/development or admin/config/system.
JCL324 β created an issue.
Just got this too with Drupal 10 core, Paragraphs 8.x-1.15:
Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: No link template 'canonical' found for the 'paragraph' entity type in Drupal\Core\Entity\EntityBase->toUrl() (line 196 of core/lib/Drupal/Core/Entity/EntityBase.php).
Ran into this too while building out a new site. I couldn't delete anything, let alone an event with a recurring date. I added this line to function smart_date_recur_entity_delete($entity)
so I could at least delete that event and disable the recur module. Still getting this error now in the calendar View that the Smart Calendar Kit installed. Guess this all is not quite ready for prime time :(
In my version 3.7, I added this at line 68:
->accessCheck(TRUE)