@trickfun if you are still seeing this it is most likely because you are also running blazy_photoswipe and you need to go into blazy ui settings and in the extra settings section switch to Photoswipe 5.
Good point on the overhead of possibly having too items to modify on hook_uninstall. The alternate makes great sense, and now that I think about it is in use in a lot of other modules.
jackfoust β created an issue.
If the trashed page is in the search index and I visit the path incognito I get the following error:
The website encountered an unexpected error. Try again later.
Error: Call to a member function getTranslation() on null in Drupal\node\Plugin\Search\NodeSearch->prepareResults() (line 362 of core/modules/node/src/Plugin/Search/NodeSearch.php).
I have search404 enabled.
Hi @andileco, as far as I can tell this resolves exposed contains and starts with/end with filters.
Sounds great, thanks @andileco!
MR9 no longer works with 1.0.4, adding new patch.
Has anyone made any progress on this? I am seeing some console/js issues with payment_intents and haven't fully debugged, but wondering if this is related to the age of the 7x version and v1 API.
jackfoust β created an issue.
MR9 works for me. PHP 8.3 & Drupal 10.3.5. Not using BEF. I do believe there are also errors with the "starts with" and "ends with" when exposed, I'm debugging.
Also wondering about this, has anything been resolved outside of this issue?
Enabling encryption on a element that has existing data really gives you some wild logs to walk into after a long weekend!
As of 2.0.2 this patch no longer applies to 2.x
jackfoust β created an issue.
It appears this is also affecting the Stripe module.
jackfoust β created an issue.
Thanks @mparker17!
Anyone figure this out, seeing it as well?
It would be great to see 10.2.x supported until its security coverage expires in December 2024, but I understand the need to move forward!
Yes, this would be a great feature!
I believe this may also need to ignore the form_id "webform_ui_element_form" as well. With the patch I still see a missing Save button if the form element throws a validation error.
- Add Custom composite element
- Enter a title and press Save.
- A form validation error is presented and the Save button is no longer visible.
jackfoust β created an issue.
Latest Gin, Drupal 10.2.6, PHP 8.2.18 - Not able to replicate the double row headers some folks are seeing. Tested with left and top toolbar.
MR404 has resolved a lot of the issues I was having on various Webform tables.
@mattdanger are you using this patch on the latest 5.x version of the module, or have you switched to 6.x that has the upgrade to v5 of the library installed - https://www.drupal.org/project/fullcalendar_view/issues/3085884 β ?
This is night and day with my Views with flag attached. Is this production ready?
I've done some further testing and found... With AJAX enabled - you can submit the form, but you cannot use the previous button to go back to the first page since it is requiring the payment information to be completed. With AJAX disabled you can go back to the previous page to update data, but you cannot submit the form.
So, after some testing it does seem to work with AJAX enabled.
I've found that the element on a second page does not appear to work at all. No errors that I can see, just goes back to the first page with your information intact. Drupal 10.2.4 and Webform 6.2.2.
HI Sascha, logo appears now which is great. Any advice on how to test the changes for "Fix for Navigation chevron icon, hide empty region"?
jackfoust β created an issue.
Because this patch changes the .info.yml I don't believe it can be applied using composer patches and Drupal 10 can't be installed with this module the way it exists now. October 31 is so near, any word on this @jkamizato @mennomenno-maaktbe?
Am I correct in assuming that 2pha's comment above requiring the dev branch fixes both the "header already sent" issue and resolves the D10 compatibility issues?
I am also interested in this being in a v1 release so that I can properly focus on the Group v2 or v3 upgrade early next year!
jackfoust β created an issue.
@nmangold patch didn't apply for me, patches on info.yml can be tricky - typically need some extra line returns in there.
I got the error above when I ran a drush updb
after I updated via composer.
For D10, doesn't core: 8.x
need removed?
The 'core_version_requirement' constraint (^9.5 || ^10) requires the 'core' key not be set in modules/composer/migrate_devel/migrate_devel.info.yml
What is the size big on a text type? This does not install with MySQL or Maria.
@matthieuscarset #24 is nothing official, I was just noting the workaround I used to proceed on how I needed to use the module.
Interesting, I may have to experiment with that on my end.
I've been testing the following patch to at least get this going for my specific use case, which seems to be working.
- $and->condition($alias, $start->getTimestamp(), '>');
- $and->condition($alias, $end->getTimestamp(), '<');
+ $field_storage_config = FieldStorageConfig::loadByName('node', $field->field);
+ if (!empty($field_storage_config) && $field_storage_config->getType() == 'datetime') {
+ $and->condition($alias, $start->format("Y-m-d\TH:i:s"), '>');
+ $and->condition($alias, $end->format("Y-m-d\TH:i:s"), '<');
+ }
+ else {
+ $and->condition($alias, $start->getTimestamp(), '>');
+ $and->condition($alias, $end->getTimestamp(), '<');
+ }
So in my quick look at this where I am seeing the issue with a specific content type not being shown when performance mode is on. My first content type is a smartdate, my second (not shown) is a datetime. The query that is being built in performance mode is comparing timestamps. Smartdate is stored as timestamps, but datetime is stored as a date string.