<?php
/**
 * Shared base for the plugin's REST controllers.
 *
 * The free plugin's own controller (ABDS_SEO_Rest_Controller) and the ABDS SEO
 * Pro add-on's controller (ABDS_SEO_Pro_Rest_Controller) both extend this so
 * they register under the same namespace and reuse the same permission
 * callbacks — without the free build shipping any Pro route, and without the
 * Pro build duplicating the shared capability checks.
 *
 * @package ABDS_SEO
 */

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

/**
 * Common namespace + permission callbacks for every abds-seo/v1 controller.
 */
abstract class ABDS_SEO_REST_Base {

	/**
	 * REST API namespace.
	 */
	const NAMESPACE_V1 = 'abds-seo/v1';

	/**
	 * Permission callback for per-post routes: the current user holds the
	 * plugin's content capability AND can edit the target post.
	 *
	 * @param WP_REST_Request $request REST request.
	 * @return bool
	 */
	public function can_edit_post( WP_REST_Request $request ) {
		$post_id = (int) $request->get_param( 'post_id' );

		return current_user_can( ABDS_SEO_Activator::CONTENT_CAPABILITY )
			&& current_user_can( 'edit_post', $post_id );
	}

	/**
	 * Permission callback: current user can manage the plugin.
	 *
	 * @return bool
	 */
	public function can_manage_plugin() {
		return current_user_can( ABDS_SEO_Activator::CAPABILITY );
	}

	/**
	 * Permission callback: current user holds the plugin's audit capability
	 * — same gate as the Dashboard/SEO Audit/Monthly report admin pages
	 * (F1.5), used by R3's Audit screen routes.
	 *
	 * @return bool
	 */
	public function can_audit() {
		return current_user_can( ABDS_SEO_Activator::AUDIT_CAPABILITY );
	}

	/**
	 * M3 2.2: the on-page highlight overlay's own permission callback --
	 * the same intersection ABDS_SEO_Audit_Frontend_Overlay::can_see_audit_for()
	 * already gates the admin-bar node and the enqueue itself on, kept in
	 * one place rather than re-derived here: the plugin's audit capability
	 * (this is audit data) AND edit rights on the specific post the request
	 * names (so the "Edit" action the overlay offers actually works for
	 * them).
	 *
	 * @param WP_REST_Request $request REST request.
	 * @return bool
	 */
	public function can_audit_post( WP_REST_Request $request ) {
		$post_id = (int) $request->get_param( 'post_id' );

		return current_user_can( ABDS_SEO_Activator::AUDIT_CAPABILITY )
			&& current_user_can( 'edit_post', $post_id );
	}

	/**
	 * Permission callback for the one route that deactivates another plugin
	 * (POST /migration/deactivate-source). Requires BOTH the plugin's own
	 * management capability AND WordPress's core `activate_plugins` capability.
	 *
	 * Deactivating a plugin is a plugin-management action that WP core always
	 * gates behind `activate_plugins`. The plugin's own `manage_abds_seo`
	 * capability is deliberately also granted to the non-Administrator
	 * "SEO Manager" role (which is NOT allowed to activate or deactivate
	 * plugins), so `manage_abds_seo` alone must never be enough to reach
	 * deactivate_plugins() — this route additionally requires `activate_plugins`.
	 *
	 * @return bool
	 */
	public function can_manage_plugin_activation() {
		return current_user_can( 'activate_plugins' )
			&& $this->can_manage_plugin();
	}
}