Problem/Motivation
The 4.x branch of this module resolves a number of long-standing issues in the 3.x branch and fully supports all configuration options in the Programmable Search Element Control API. For background on 4.x development up till now, see
#3279974: 4.x release →
. The 4.x branch implements the same architecture as 3.x vis-à-vis the Google search relationship to the Drupal core search API: it defines Google PSE as an available search implementation, and therefore the core search form block can be used as-is; a separate block is provided by the module that can display both the search form and the search results together.
However, its integration with the Drupal core search API stops there. It doesn't populate search items within the Drupal core search API. It simply renders the results as provided by Google via JavaScript. We should therefore get consensus on the optimal architecture of this module's 4.x branch.
Architecture Pattern 1: more fully implement Google PSE as a Drupal core search
In this option, this module would provide Google's search results as a consumable object of items that could then be processed and themed via Drupal core's search API. This has effectively already been created by a module released in October 2022:
https://www.drupal.org/project/google_json_api →
. So the behavior of the Google PSE module within the larger Drupal ecosystem should probably remain as "just render the results as provided by Google". Patterns 2 & 3 below follow this approach.
Architecture Pattern 2: leave Google PSE as a core search implementation but just render Google output as-is
This is the current design of the 4.x branch. Site managers can use the Drupal UI to define configuration for the Programmable Search Element Control API, but developers cannot use Drupal core's search API to manipulate the order or markup of the results themselves. To style the results, developers must add CSS that targets the markup provided by Google.
Architecture Pattern 3: move Google PSE out of the core search API altogether and into a configuration entity
This approach would resolve the concern that the current implementation in 4.x only leverages core search API to integrate with core's search form block and search results page, but doesn't respect the search results part of that API.
This approach would improve the developer experience for the maintainers of this module, as it would reduce the overrides that this module currently does to the core search API and would be a "standard" configuration entity.
As with Pattern 2, developers wanting to style the results would still need to add CSS targeting the Google markup. Existing sites that are using this module (5,669 as of this writing) which have used the core search form block would need to update their sites' configuration to use the search form block provided by this module and add whatever site-specific styling is needed, but after making this change, it would be easier for their developers to further control the style of the search form block.
Remaining tasks
Settle on an architectural approach.
User interface changes
TBD
API changes
TBD
Data model changes
TBD