Builder_AttsclassPro only

Builder_Atts

Renders builder attributes through the CRP shortcode with the plugin’s saved settings restored as the fallback for any control the user left blank.

Namespace: WebberZone\Contextual_Related_Posts\Pro\Builders
Since: 4.4.0
Source: includes/pro/builders/class-builder-atts.php line 23

Methods

render() static

Run $atts through the CRP shortcode with the defaults filter in place.

Since: 4.4.0
Line: 62

static public function render( array $atts, $content = ... ): string;

Returns: string

fill_missing_shortcode_defaults() static

Make sure every control a builder element exposes survives Shortcodes::related_posts().

Shortcodes::related_posts() calls this filter on its own small, hardcoded $defaults array — before merging in crp_get_settings() — then does shortcode_atts( array_merge( crp_get_settings(), $defaults ), $atts ). Two distinct gaps follow from that, both fixed here:

1. A key core hardcodes into its own $defaults (include_words is the current example, always '') permanently shadows the saved plugin setting, since $defaults is merged after crp_get_settings() and therefore wins. Overwriting $defaults[ $key ] with the saved setting whenever one exists restores the intended precedence: a control the element leaves blank should fall back to the saved setting, not to core’s own shortcode default. An explicit non-empty value from the element’s own controls (already present in $atts at this point) still wins regardless, since shortcode_atts() prefers $atts over pairs.

2. shortcode_atts() silently drops any key present in $atts that isn’t already a recognised pair — i.e. not in $defaults and not in crp_get_settings(). The “Other attributes” control is explicitly documented as accepting arbitrary [crp] attributes, so on a site whose saved settings predate a given key, text typed into that field can vanish silently. Registering every key actually present in $atts closes that gap too.

Since: 4.4.0
Line: 102

static public function fill_missing_shortcode_defaults( $defaults, $atts ): array;

Returns: array

strip_empty_atts() static

Drop untouched controls from $atts so they fall back to the plugin’s saved settings.

Every builder hands over a value for controls the user never touched — Elementor’s get_settings_for_display() returns all registered controls, and WPBakery’s getMergedParams() writes every param into the shortcode string — so $atts arrives carrying ‘’ for blank fields. Shortcodes::related_posts() runs it through shortcode_atts(), which treats a present-but-empty key as an explicit override of the saved setting (e.g. wiping the site-wide “Exclude post IDs” list), unlike a [crp] shortcode, which only ever carries the attributes actually typed into it.

$preserve names the controls whose empty value is meaningful rather than absent: an unchecked checkbox/switcher is an explicit “off”, and must not be read as “not set”.

Since: 4.4.0
Line: 143

static public function strip_empty_atts( array $atts, array $preserve = ... ): array;

Returns: array

merge_other_attributes() static

Parse the free-text other_attributes field (attribute=“value” pairs) into $atts.

Since: 4.4.0
Line: 165

static public function merge_other_attributes( array $atts ): array;

Returns: array

resolve_exclude_categories() static

Resolve the exclude_cat_slugs free-text field into exclude_categories term_taxonomy_ids.

CRP_Core_Query only reads exclude_categories (term_taxonomy_ids) — exclude_cat_slugs is otherwise just a settings-page UI field that gets converted to exclude_categories on settings save, so it has no effect on its own at shortcode-render time.

A non-empty value replaces the saved exclude_categories setting rather than adding to it, matching [crp exclude_categories="..."] and every other control here: an explicit value wins over the setting. The merge below is only with an exclude_categories already sitting in $atts — i.e. one supplied through the “Other attributes” field — so the two ways of naming the same thing on one element don’t silently discard each other.

Since: 4.4.0
Line: 198

static public function resolve_exclude_categories( array $atts ): array;

Returns: array

ensure_style_enqueued() static

Enqueue the style an element actually resolved to, at render time.

Styles_Handler::get_style_ids_to_load() only scans the queried post — its post_content for shortcodes, its own meta for Elementor and Bricks data. An element placed in a theme builder template (a single/archive template, a header/footer, a Bricks popup, a WPBakery template) lives in a different post entirely and is never scanned that way, so without this only the site-wide style CSS would load.

Since: 4.4.0
Line: 242

static public function ensure_style_enqueued( array $atts, bool $skip_enqueue = ... ): void;

Returns: void