<?php
/**
 * Make patterns genuinely editable: let editors add blocks inside a pattern, and
 * reach the two row/column settings that would otherwise force a pattern edit.
 *
 * BACKGROUND — the rule, from WordPress core (wp-includes/js/dist/blocks.js and
 * block-editor.js):
 *
 *   isContentBlock(X)      = X has supports.contentRole, or any attribute with
 *                            role: "content"
 *   canInsert(X into R)    = R is the page root
 *                            OR ( R is a content block AND X is a content block )
 *
 * Inside a pattern (content-only editing) `kadence/column` was NOT a content
 * block, so NOTHING could be inserted into a pattern's column — no button, no
 * list, no extra paragraph. That single missing declaration is what made patterns
 * feel like locked boxes. `kadence/advancedheading` had the same gap, so the
 * heading style the patterns use couldn't be added either. Everything an editor
 * would want to add (core paragraph/heading/list/buttons/image, bw/card-gallery)
 * already qualifies, so declaring these two is enough.
 *
 * WHY THE TOOLBAR CONTROLS — content-only editing hides the Settings sidebar, so
 * a row's background colour and a column's curve were unreachable in a pattern.
 * Without them, every colour variant needs its own pattern; with them, one
 * pattern covers all of them. That is the difference between a handful of
 * patterns and dozens.
 *
 * @package Kadence-Child
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * The blocks a pattern's contents are built from.
 *
 * Everything here is something an editor legitimately edits or adds INSIDE a
 * section: the photo, the heading, the button, a table cell. Anything not on
 * this list is inert inside a pattern — WordPress renders it read-only and
 * refuses to insert it. That is why the list is derived from what the site
 * actually uses (an audit of all 1,132 rows), not from guesswork: a photo-led
 * pattern whose photo can't be swapped is worse than no pattern at all.
 *
 * Core blocks (paragraph, heading, list, image, buttons) already qualify on
 * their own, so only Kadence's and ours need declaring.
 */
function bw_pattern_content_blocks() {
	return array(
		// Structure — so a section can hold another row, and columns are editable.
		'kadence/rowlayout',
		'kadence/column',
		// The things inside a section.
		'kadence/advancedheading',
		'kadence/image',
		'kadence/advancedbtn',
		'kadence/singlebtn',
		'kadence/spacer',
		// Tables, which are three nested blocks and need all three.
		'kadence/table',
		'kadence/table-row',
		'kadence/table-data',
		// Ours that don't already carry a content attribute.
		'bw/course-table',
		'bw/team-modal',
	);
}

/**
 * Declare those blocks as content blocks.
 *
 * Done through the registration filter rather than by editing the plugin, so it
 * survives Kadence updates. Additive: it changes no attribute, markup or output.
 */
add_filter(
	'register_block_type_args',
	function ( $args, $name ) {
		if ( ! in_array( $name, bw_pattern_content_blocks(), true ) ) {
			return $args;
		}
		$supports = isset( $args['supports'] ) && is_array( $args['supports'] ) ? $args['supports'] : array();
		$supports['contentRole'] = true;
		$args['supports'] = $supports;
		return $args;
	},
	10,
	2
);

/**
 * Patterns are STARTING POINTS, not locked components.
 *
 * By default WordPress treats an inserted unsynced pattern as a "section": the
 * layout is frozen, the Settings sidebar is hidden, and the only way out is an
 * "Edit pattern" button that opens the shared pattern rather than the page you
 * are on. For a site whose sections genuinely vary — a photo on the left here,
 * on the right there, a colour swapped, a column dropped — that lock is the
 * thing standing between "insert a section" and "make it look how I want".
 *
 * Turning it off makes an inserted pattern behave like any other block: change
 * anything, add anything, delete anything.
 *
 * To go back to guard-railed patterns, set this to false. Both modes work
 * correctly — that is what the content-block declarations above are for.
 */
add_filter(
	'block_editor_settings_all',
	function ( $settings ) {
		$settings['disableContentOnlyForUnsyncedPatterns'] = true;
		return $settings;
	}
);

/**
 * Toolbar controls for the row background and the column curve — plus the
 * client-side half of the content-block declaration.
 *
 * Priority 1 matters: the script registers a `blocks.registerBlockType` filter,
 * which only takes effect on blocks registered AFTER it. Kadence registers its
 * blocks from its own editor bundle, so this has to be in place first — the same
 * reason assets/bw-redborder-editor.js is enqueued early.
 */
add_action(
	'enqueue_block_editor_assets',
	function () {
		$theme = get_stylesheet_directory();
		$file  = $theme . '/assets/bw-pattern-editing.js';
		if ( ! file_exists( $file ) ) {
			return;
		}
		wp_enqueue_script(
			'bw-pattern-editing',
			get_stylesheet_directory_uri() . '/assets/bw-pattern-editing.js',
			array( 'wp-blocks', 'wp-element', 'wp-block-editor', 'wp-components', 'wp-compose', 'wp-hooks', 'wp-data' ),
			filemtime( $file ),
			true
		);
		// The same list the server uses, so the two halves can never drift apart.
		wp_add_inline_script(
			'bw-pattern-editing',
			'window.bwContentBlocks = ' . wp_json_encode( bw_pattern_content_blocks() ) . ';',
			'before'
		);
	},
	1
);