TBH I have been thinking of deprecating the Classic widget. Can I ask why you decided to use that one?
I'm not entirely sure. I think it's simply because we've been using Smart Date since this was the only option. I just tried using Inline Range instead and, after some minor changes to the form_alter() hook we're using to set custom default values, I think it will work just fine--and it avoids the problem described above.
1. Set up a test site using the evaluator guide:
https://www.drupal.org/node/2997977 →
2. Install smart_date: composer require 'drupal/smart_date:^4.2@beta'
3. Create a new content type with a Smart Date Range.
4. Change the form display mode to Smart Date|Classic and move the date field to the top of the page. These are the options I used, to match my original site:
5. Add a new node using this content type. The default theme is Claro. This is what I see:
When attempting to run the quick-start command, I get the error:
Resolve all issues below to continue the installation. For help configuring your database server, see the <a href="https://ww
w.drupal.org/docs/installing-drupal">installation handbook</a>, or contact your hosting provider.<div class="item-list"><ul><
li>The database server version <em class="placeholder">3.43.2</em> is less than the minimum required version <em class="place
holder">3.45</em>.</li></ul></div>which is not at all helpful since it doesn't tell me what specifically needs to be upgraded or how to go about doing it. This needs to be more bullet-proof. (MacOS 14.7.1)
gribnif → created an issue.
For the record, this was fixed in 🐛 Fix PHP 8.2 deprecation issue with WidgetSelectorBase-class Fixed
I believe this is no longer an issue in D10, due to changes in core.
I'm closing this issue, as it no longer applies to D8+.
Your solution didn't quite work, because we also need to call the setExposedInput() method to copy the user-submitted form data into the union display.
I also added code to do a sanity check to be sure that the union display doesn't have exposed form elements that are not present on the main view, as these won't appear to the user without me writing a bunch more code.
The problem with using UNION ALL is that it creates new rows for every row that each subquery has in common. So if the main query returns entity IDs (1,2,3,4) and the first UNION returns (2,3,5), the result set will be (1,2,3,4,2,3,5). While there might be a rare case where this is the desired result, it would break backward compatibility.
Instead, I have added a dummy HAVING clause so that the built-in query constructor won't try to remove the entity ID field from the UNION query. This fixes pagination.
I could see the argument for relying on the Distinct option in Query Settings to determine which behavior is used. But I wouldn't want to do this in a minor version because of the BC problem.
Thanks for the report. I've committed 8f2780d and 620f0d6 to fix the problem.
The CR looks good to me, @Tanuj. I'll let others chime in, though.
Gribnif → created an issue.
I have now tested this module with D10 and it works, so a new release has been created.
We have nearly 12,000 webforms on our site that worked fine in D7, but since moving to D9 we're hitting this exact performance problem due to calls to Webform::loadMultiple(). I've had to comment-out webform_query_webform_submission_access_alter(), webform_library_info_build() and \Drupal\webform\Plugin\Condition\Webform::buildConfigurationForm() in order to avoid this problem.
It's a pity that such a useful and popular module doesn't scale well. Please consider addressing this issue across the entire codebase.
I believe all you have to do is apply the suggested patch and it should work. That said, I don't have a D10 installation to test with, so if you could, please do so and let me know the results.
Gribnif → created an issue.
Here's a patch that does what was requested. I find it very helpful.