Tag: debugging

Read the Testing : Location Categories article for background on this feature.

The setting to display the category selector on the front end stopped working. The Power add on is active, but with SLP 5.13.X prerelease the drop down no longer appears.

This is very likely due to escaping of output that is overly aggressive on what it filters out on the front end.

Tech Overview

The base plugin renders the map , search form and results on the front end using shortcodes. The [slplus] shortcode renders the entire UX based on a combination of HTML and secondary shortcodes. These secondary shortcodes are parsed by the SLP base plugin to do things like “put the search form here” or “put the results here”. Within each of those custom shortcodes is another set of shortcodes, for example for the search form “put the address input box here” or “put the radius selector here”.

One of those additional shortcodes is provided by the Power add on to “put the category selector drop down here”.

That is not being processed.

Code Path

SLP_Power_UI.php

This attaches the method for rendering additional SLP search form features. This method is getting called.

public function add_hooks_and_filters() 
...
add_filter( 'shortcode_slp_searchelement'   , array( $this , 'process_slp_search_element_shortcode' )   );

This method is not getting called when the [slplus] shortcode is rendered…

public function process_slp_search_element_shortcode( $attributes ) {

The shortcode_slp_searchelement filter is only fired from this piece of code:

SLP_UI.php

Provided by the base plugin, this handles most of the front end initialization and execution.

This line of code is being called to apply filters…

public function create_SearchElement( $attributes, $content = null ) {
$attributes = apply_filters( 'shortcode_slp_searchelement', $attributes );

Checking Call Order

⚠️ Evaluating the call execution order, the above apply_filters is being called BEFORE the power add on has run the SLP_POWER_UI add_hooks_and_filters() , noted above, to hook onto that filter call.

Power Add Hooks & Filters

Here is the call stack when Power add_hooks_and_filters is run…

The call to SLP_BaseClass_Addon->createobject_UserInterface() is fired during the execution of the ‘wp_enqueue_scripts’ action hook as defined in base_class.addon.php in the slp_init() method…

// User Interface?
//
if ( ! empty( $this->userinterface_class_name ) ) {
 add_action( 'wp_enqueue_scripts' , array( $this , 'createobject_UserInterface' ) );
}

Base Plugin Create Search Element

Here is the call stack , CALLED FIRST, for creating the search element:

That means do_shortcode() is being called very early —

This is due to a side effect of all the fuckery WordPress Core has been doing to deal with the block mode editor. In order to support new block themes (like Twenty Twenty Two) WP_Block->render() calls render_block_core_post_content() super early. Before any script enqueue.

WP Core: render_block_core_post_content() calls the “the_content” filter way earlier than non-block themes:

$content = apply_filters( 'the_content', str_replace( ']]>', ']]>', $content ) );

Remedies

Lance.bio : WP Hooks & Filters Reference

Attach creatobject_UserInterface Calls To New Hook

With the block theme, firing that method via the ‘wp_enqueue_scripts’ method is too late for WP Block Themes.

There are multiple methods that could be used to hook this, but which one will be BEFORE the WP Block rendering calls the ‘the_content’ filter AND still work for older themes?

Option 1 : Hook to ‘the_content’ filter with an earlier precedence on the weight

Replace

// User Interface? 
// 
if ( ! empty( $this->userinterface_class_name ) ) {  add_action( 'wp_enqueue_scripts' , array( $this , 'createobject_UserInterface' ) ); }

With the call order weight parameter added (the default WP action weight is 10 if not specified)

// User Interface? 
// 
if ( ! empty( $this->userinterface_class_name ) ) {  add_action( 'the_content' , array( $this , 'createobject_UserInterface' ), 5 ); }

Concerns

The main concern here is that a ‘the_content’ script does not get called everywhere a ‘wp_enqueue_scripts’ hook gets called. The question is whether AJAX and REST calls run through here.

Results

Did not work, broke a lot of features and setup in the plugin.

Option 2 : Attach to an earlier hook…

Candidates…

• block_parser_class — in function parse_blocks() probably not called on non-block themes.
• template_include — before template_canvas.php which appears to be before template_canvas where the first line is get_the_block_template(); the assumption is template_canvas is only called for block based themes.

Concerns

‘template_include’ hook may get called too often, but it is a classic filter that has been around for a while and should work for both block and legacy templates.

Results

Seems to be working, needs more testing.