Here I'm attaching the patch.
afsch → created an issue.
I had the same error, for my project, I had to update the module and create a patch to revert this file "src/Controller/ServerEndpointController.php" because looks like the change from cl_components to sdc is not fully compatible yet.
Hey Mark, Here I leave a custom code I added to resolve the extra query parameters.
It overrides the default redirect specifying the path and query only, making it cleaner.
File: google_cse/src/Form/GoogleCSESearchBoxForm.php
Instead of:
$form['sa'] = [
'#type' => 'submit',
'#id' => 'google-cse-submit',
'#value' => $this->t('Search'),
];
Use:
$form['actions'] = [
'#type' => 'actions',
'submit' => [
'#type' => 'submit',
'#value' => $this->t('Search'),
'#name' => '',
],
];
And for the submitForm() function add this code:
public function submitForm(array &$form, FormStateInterface $form_state) {
$settings = $form_state->getValue('google_search_settings');
$query_key = $settings['query_key'] ?? GoogleSearch::$defaultQueryKey;
$query = $form_state->getValue($query_key);
// TODO: Update to get `search_id` and set the correct path.
$url = Url::fromUserInput('/search/results', ['query' => [$query_key => $query]]);
$form_state->setRedirectUrl($url);
}
Probably this is the faster way to have it fixed. Let me know if that works. Thanks.
Looks like this is a known issue, the problem is pointing to the correct path to Tippy library.
I'm adding a small patch to fix it.
Hey @mark_fullmer, it works like a charm! I tested with the "Google" option for the block configuration.
For the same search block configured with "Drupal" option something weird happens, this is because it doesn't redirect to the Search Results page, but keeps the current URL adding extra parameters. E.g.:
- I'm on the homepage: https://mysite.com
- Using the search block configured with Drupal option for "Search input type".
- After submit the form it redirects to: https://mysite.com/?cx=450XXXXXXXXXXXc4844&query=department&op=Search&form_build_id=form-vDTRoATXXXXXXXXXXXXXXXkA8KLWQvBCB0&form_id=google_cse_search_box_form
- Expected: https://mysite.com/search/results?query=department
- When configured with Google, it just works as expected.
Hey @mark_fuller, it works, now I can see the Results Page with results. But, I had to do a small configuration update in the Search block, this is changing the "Search input type" to 'Drupal'. It was previously set to 'Google' option, when submitting for search it was again using the "keys" parameter hence no results.
Here are the screenshots:
Results:
Maybe it needs a small adjustment about that configuration with "Google" option when configuring the search block, but for now, I'm using your solution as a local patch because it works. If you need me for more testing please let me know :)
Hey Mark, effectively I'm using your patch and the screenshots are the result of using it in my project. The attached files (patches) are the custom solution I'm currently using to have the parameter updated.
Hey @markfullmer, thank you for this contribution, I was testing it (patch) but, it looks like there is a conflict with the Core Search code. Let me give you more context.
I do have the following scenario, Drupal 10.1.8, Web Server nginx/1.24.0, PHP 8.1.26, DB 10.3.39-MariaDB, google_cse 4.0.0-alpha3.
For this project, I had to create 2 patches (attached), the first for `google_cse` and another for `drupal:search`. The patches update the keyword used in the URL from `keys` to `query`. It works.
Now, after using your solution I could configure the `Query parameter key` value. Still, I saw something odd with the block added in the Block Layout and the Search form shown on the Search results page, using the first block for searching, effectively uses the `query` parameter, but using the form from the Search results page uses the `keys` parameter. NO RESULTS are displayed in either case.
- Block and configuration
- Configuring the parameter keyword
- Using the Form from Search Results page
- Using the block added via Layout Builder
As an important note, this module requires the `drupal:search` module, IMO I'd say to find a way to override the search class so we could have it configurable in this module only.
penyaskito → credited afsch → .
@jrockowitz you are right, most of the updated lines where libraries are being loaded are incorrect.
Anyway, I'm hiding the patch file for now and attaching the report generated by Upgrade Status.
I've been doing a review of deprecated code by using the Upgrade Status module report. I got around 47 issues for Webform (beta6), here I'm leaving some fixes hoping this will be reviewed and tested. It remains 13 issues that need review.
I'm gettings the same message, this is running a Behat test to delete a file, in some scenarios, it already exists but in others, it doesn't, the purpose is to make sure that before the tests run the file doesn't exist.
Given I delete a ABC video with ABC manager ID "2cbb517a-2f0c-4ddc-a113-73ea94bee253" if any
# tests/features/media/pbs_video/crud.feature:27
Warning: hash_file(public://gpb_remote_media_thumbnails/WdrbXZ_AzM_3MIlpYUcrnp-SeYxR26zZUWDTw0FS_mU.png): Failed to open stream: "Drupal\Core\StreamWrapper\PublicStream::stream_open" call failed in docroot/modules/contrib/filehash/src/FileHash.php line 257 (Drupal\Core\Entity\EntityStorageException)
I could not fix it locally, but I'm guessing the origin of the issue is a missing validation when a file doesn't exist.
Any update on this Issue? I can see the decision was to merge the patch and create a new release but there is no release or dev version. Should we consider re-opening this ticket to give a follow-up about the actual status?
Adding a patch updating the info.yml file.
Patches are not compatible with RC6, that version comes with compatibility with D10.
Adding the D10 compatibility in info.yml file.
Patch #5 is already added in the latest dev version. We can mark it as fixed.
Re-rolling patch 9 for the last updates in audiofield module.
Re-rolling patch for version 2.0.3.