Tiempo de lectura: 8 min
Valencia, 31/10/2026, G.B.
El plugin Control y Reserva de Recursos (CRR v1.12.0) es una herramienta propia para gestionar salas, equipos y servicios con reservas, presupuesto automático, calendario y paneles de control, sin dependencias externas. Continuando con la serie de cuadernos técnicos, hoy hago un primer recorrido general por el plugin. Mi filosofía es siempre la misma: herramientas 100 % nativas, sin librerías pesadas de terceros y con los datos en mi propia base de datos. En las siguientes partes iré profundizando en cada pieza.
Table of Contents
Bloque 1: Cabecera y seguridad del archivo
Lo primero es la cabecera que lee WordPress para mostrar el plugin en el listado:
<?php
/**
* Plugin Name: Control y Reserva de Recursos (CRR)
* Plugin URI: https://indaga.net
* Description: Sistema completo e independiente para la gestión y reserva de recursos, salas y servicios con presupuestos automáticos, vista de calendario, ficha desplegable de detalles, selector por tipo con buscador, gestión de inventario y panel frontal de filtrado por responsable y exportación avanzada.
* Version: 1.12.0
* Author: Guillermo Beltrán Pilato
* Author URI: https://indaga.net
* Text Domain: crr
*/WordPress identifica un plugin por su ruta (carpeta y archivo principal), no por su nombre. Por eso mantengo siempre la misma carpeta y el mismo archivo entre versiones: si la ruta cambia, WordPress lo trata como un plugin distinto y no como una actualización. Entre versiones lo único que cambia es Version. El Text Domain crr está declarado, aunque ahora mismo el plugin no usa funciones de traducción.
Para evitar que alguien abra el archivo directamente, aplico la comprobación de siempre: si la constante ABSPATH no existe, el archivo se ha pedido por fuera de WordPress y corto la ejecución. A continuación defino una constante con la versión, que uso para controlar la base de datos:
if ( ! defined( 'ABSPATH' ) ) {
exit; // Seguridad: Salir si se accede directamente
}
define( 'CRR_VERSION', '1.12.0' );A diferencia de otros desarrollos, como Agenda Indaga, en el CRR no uso una clase con patrón Singleton. Es un conjunto de funciones con el prefijo crr_, lo que reduce muchísimo el riesgo de choques de nombres con otros plugins y mantiene todo directo. Expliqué mis motivos en este apunte sobre el patrón Singleton.
Bloque 2: Base de datos propia y actualización controlada
El sistema crea dos tablas propias, sin depender de nada externo: crr_recursos (el inventario de salas, equipos y servicios) y crr_reservas (cada reserva, enlazada a un recurso por recurso_id). Se despliegan al activar el plugin:
function crr_instalar() {
global $wpdb;
$charset_collate = $wpdb->get_charset_collate();
$tabla_recursos = $wpdb->prefix . 'crr_recursos';
$sql_recursos = "CREATE TABLE $tabla_recursos (
id bigint(20) NOT NULL AUTO_INCREMENT,
nombre varchar(255) NOT NULL,
tipo varchar(100) DEFAULT 'General' NOT NULL,
stock int(11) DEFAULT 1 NOT NULL,
precio_hora decimal(10,2) DEFAULT '0.00' NOT NULL,
email_propietario varchar(100) NOT NULL,
PRIMARY KEY (id)
) $charset_collate;";
$tabla_reservas = $wpdb->prefix . 'crr_reservas';
$sql_reservas = "CREATE TABLE $tabla_reservas (
id bigint(20) NOT NULL AUTO_INCREMENT,
recurso_id bigint(20) NOT NULL,
user_id bigint(20) NOT NULL,
email_solicitante varchar(100) NOT NULL,
fecha_inicio date NOT NULL,
fecha_fin date NOT NULL,
hora_inicio time NOT NULL,
hora_fin time NOT NULL,
cantidad int(11) DEFAULT 1 NOT NULL,
observaciones text NULL,
precio_estimado decimal(10,2) DEFAULT '0.00' NOT NULL,
fecha_creacion datetime DEFAULT CURRENT_TIMESTAMP NOT NULL,
PRIMARY KEY (id)
) $charset_collate;";
require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
dbDelta( $sql_recursos );
dbDelta( $sql_reservas );
update_option( 'crr_db_version', CRR_VERSION );
}
register_activation_hook( __FILE__, 'crr_instalar' );Un detalle clave: dbDelta es muy estricto y espera exactamente dos espacios entre PRIMARY KEY y el paréntesis. Además, para no depender únicamente del gancho de activación (que no salta cuando actualizo el plugin por FTP), compruebo la versión en cada carga con la acción plugins_loaded:
function crr_comprobar_actualizacion_db() {
if ( get_option( 'crr_db_version' ) !== CRR_VERSION ) {
crr_instalar();
}
}
add_action( 'plugins_loaded', 'crr_comprobar_actualizacion_db' );Bloque 3: Lógica de reservas, validaciones y presupuesto automático
El punto de entrada del formulario valida el nonce, limpia cada dato de entrada y delega todo el trabajo en crr_procesar_reserva():
if ( isset( $_POST['crr_nueva_reserva'] ) && check_admin_referer( 'crr_reserva_nonce', 'crr_reserva_nonce' ) ) {
$res_id = isset( $_POST['reserva_id'] ) ? absint( $_POST['reserva_id'] ) : 0;
$enviar_pres = isset( $_POST['enviar_presupuesto'] ) ? true : false;
$alerta = crr_procesar_reserva(
absint( $_POST['recurso_id'] ),
sanitize_email( $_POST['email_solicitante'] ),
sanitize_text_field( $_POST['fecha_inicio'] ),
sanitize_text_field( $_POST['fecha_fin'] ),
sanitize_text_field( $_POST['hora_inicio'] ),
sanitize_text_field( $_POST['hora_fin'] ),
absint( $_POST['cantidad'] ),
sanitize_textarea_field( $_POST['observaciones'] ),
$res_id,
$enviar_pres
);
}Antes de guardar nada, esa función comprueba la disponibilidad con crr_comprobar_disponibilidad(). Es la pieza que más me importa del plugin:
function crr_comprobar_disponibilidad( $recurso_id, $fecha_inicio, $fecha_fin, $hora_inicio, $hora_fin, $cantidad, $reserva_id_excluir = 0 ) {
global $wpdb;
$tabla_reservas = $wpdb->prefix . 'crr_reservas';
$tabla_recursos = $wpdb->prefix . 'crr_recursos';
$recurso = $wpdb->get_row( $wpdb->prepare( "SELECT stock FROM $tabla_recursos WHERE id = %d", $recurso_id ) );
if ( ! $recurso ) {
return false;
}
$sql = "SELECT SUM(cantidad) FROM $tabla_reservas
WHERE recurso_id = %d
AND id != %d
AND (fecha_inicio <= %s AND fecha_fin >= %s)
AND (hora_inicio < %s AND hora_fin > %s)";
$ocupacion = $wpdb->get_var( $wpdb->prepare( $sql, $recurso_id, $reserva_id_excluir, $fecha_fin, $fecha_inicio, $hora_fin, $hora_inicio ) );
$ocupacion_actual = $ocupacion ? intval( $ocupacion ) : 0;
return ( $ocupacion_actual + $cantidad ) <= intval( $recurso->stock );
}La consulta suma la cantidad de todas las reservas del mismo recurso que se solapan con la nueva, tanto en fechas como en horas, y comprueba que esa suma más lo solicitado no supere el stock. El parámetro $reserva_id_excluir permite editar una reserva sin que choque consigo misma.
Si hay disponibilidad, se calcula el presupuesto estimado con crr_calcular_precio_estimado(). Este es el extracto con la fórmula:
$dias = $f_inicio->diff( $f_fin )->days + 1;
$horas = $intervalo->h + ( $intervalo->i / 60 );
if ( $horas <= 0 ) {
$horas = 1;
}
$total = $dias * $horas * floatval( $recurso->precio_hora ) * absint( $cantidad );
return round( $total, 2 );Es decir: días × horas diarias × tarifa por hora × cantidad. El resultado se guarda en el campo precio_estimado. Tengo pendiente revisar este cálculo: ahora mismo no valido que la fecha de fin sea posterior a la de inicio ni que la hora de fin sea posterior a la de inicio, y con las horas invertidas DateTime::diff devuelve igualmente un valor positivo, así que el precio saldría incorrecto.
- Seguridad y sanitización: nonces con
check_admin_referer, limpieza de variables con funciones nativas de WordPress (absint,sanitize_email,sanitize_text_field) y consultas preparadas con$wpdb->prepare - Alta y edición: la misma función sirve para ambas, según venga o no el ID de la reserva
- Permisos: solo puede editar o cancelar una reserva quien la creó, un administrador o un usuario autorizado
- Control de stock: se contrasta lo solicitado con las reservas solapadas y el stock del recurso antes de insertar o actualizar
Bloque 4: Visualización en calendario interactivo y paneles avanzados
Con el shortcode [crr_calendario] cualquier página se convierte en una cuadrícula mensual con las reservas del mes. Al hacer clic en una de ellas se abre una ficha flotante (modal) con los detalles clave, sin recargar la página, porque los datos viajan en un atributo data-reserva que lee JavaScript. El cambio de mes sí recarga la página, ya que navega mediante parámetros por URL (crr_mes y crr_anio).
Por otro lado, el panel frontal de gestión lo ven los administradores y los usuarios autorizados (una lista de emails que configuro en la pestaña «Usuarios Autorizados» del panel de administración). Permite filtrar por fechas, categoría, responsable del recurso y texto libre, con soporte de comodín *.
La exportación admite dos formatos: un CSV estándar y una variante «Excel», que en realidad es también un CSV, pero con codificación UTF-8 con BOM y punto y coma como delimitador, para que Excel muestre bien los acentos. Y la descarga respeta los filtros que tenga aplicados en ese momento.
Para mostrar el calendario en cualquier página basta con insertar el shortcode, sin parámetros:
[crr_calendario]Y para el formulario de reservas con su panel de gestión, el shortcode es [crr_reservas].
Con esto cerramos este primer recorrido técnico por el CRR v1.12.0. Continuaré…