Full Site Editing Search Results
The instantsearch result page is currently a PHP file. I'm wondering if it can be implemented using an html page template compatible with the block editor. Note that I don't actually need to edit the file in the block editor; I just need it to use the search.html template as recognized by Gutenberg. The reason I ask is because there is currently a bug in Gutenberg preventing the styles from being injected in a PHP file using do_blocks to include a FSE template part.
Hi @peiche
This would end up being an interesting and not the easiest request to work on. The template files we make use of include using things like get_header and get_footer in the template to make it compatible with WordPress themes — which are PHP functions. The only replacement of these functions that we can think of is manually copying and pasting the HTML of head and footer tags in the HTML file which makes it potentially very tedious.
This may also place us as maintainers in a very difficult position because often other users of the plugin — WebDevStudios included — customize the templates as well.
Also backbone.js is being used for templating purposes. Not sure how it would work if the framework is not loading correctly without WordPress.
Finding a way to take all those into account and still work with the instantsearch code gets hairy quickly.
I wondered how feasible it would be. It sounds like my best bet is to hope the bug is fixed in Gutenberg soon.
Willing to leave this open for the time being until someone else maybe has some ideas on how to make it all work together relatively easily.
I just found out that there is a workaround that allows the styles to get loaded on a PHP template. It requires all do_blocks() calls to be assigned to variables before calling wp_head() and then calling the variables when you need them. I can confirm this works on the most recent version of Gutenberg (13.2.2, as of this writing).
I have a feeling that this is going to likely be a documentation/tutorial case instead of shipping our instantsearch and autocomplete template files in FSE compatible by default
I haven't tried this out at all, but I do know https://wordpress.org/plugins/search-with-algolia-instantsearch-blocks/ exists, and they recommend installing our plugin as part of the process.
Moving #355 to this issue.
Extra thoughts: this probably won't be a case of modifying the existing PHP files, but making FSE compatible equivalents that we could perhaps ship with the plugin alongside the current PHP versions.
Been toying with this at least a little bit today. I am managing to get custom template files from a theme loaded by instantsearch, but it's definitely going to be a taller order than first anticipated.
At least with what work I've done thus far, the template file is being loaded as is, meaning this line from Twenty Twenty is simply being viewed as an html comment, and not something to be parsed:
<!-- wp:template-part {"slug":"header-small-dark","tagName":"header"} /-->
This is going the route of our traditional overrides with the algolia folder in your active theme/child theme. Because of that, the wp_head/wp_footer output isn't being handled like expected, and we're seeing javascript errors because our algolia variable is not defined.
Until template overrides are made really straightforward, I'm wondering if we're going to be in a rock and a hard place for this, at least when it comes to instantsearch.
Autocomplete seems to be working just fine.
Momentary last ditch effort failed when I tried to make a shortcode out of our template output, and include that as part of a block template. I believe it was getting wpautop'd and breaking our output.
Wouldn't necessarily be something we immediately ship with the plugin, but I believe I have an example setup working with TwentyTwentyTwo theme explained over at https://wordpress.org/support/topic/customize-instantsearch-php-with-fse-theme/#post-17319232
Basically it splits the instantsearch.php file into parts, with the top half being dropped into a search.html for a FSE theme, and then the bottom half with all the javascript being output via wp_footer or could alternatively be enqueued via a dedicated JS script, and ideally have dependencies on the registered algolia-instantsearch script. Wouldn't hurt to also use wp_enqueue_style( 'algolia-instantsearch' ); for the styles.