git.admin/roi-theme

Fork 0

Files

FrankZamora 0038ad502c backup: estado antes de limpieza de defaults

2025-11-13 21:51:06 -06:00

24 KiB

Raw Blame History

PROBLEMA: Defaults Hardcodeados en Algoritmo de Modularización

Fecha: 2025-01-13 Estado: 🔴 EN INVESTIGACIÓN Prioridad: ALTA

📋 CONTEXTO

Situación Actual

El tema WordPress tiene valores hardcodeados en múltiples archivos:

wp-content/themes/apus-theme/
├── *.php      → Valores hardcodeados
├── *.html     → Valores hardcodeados
├── assets/
    ├── css/   → Valores hardcodeados
    └── js/    → Valores hardcodeados

Objetivo del Sistema

El Admin Panel debe permitir personalizar la mayoría de valores que actualmente están hardcodeados.

Sistema de Persistencia Disponible

✅ Ya existe tabla personalizada: wp_apus_theme_components

Ubicación: Base de datos WordPress Documentación: Ver ANALISIS-ESTRUCTURA-ADMIN.md

Estructura:

CREATE TABLE wp_apus_theme_components (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    component_name VARCHAR(50) NOT NULL,      -- 'topbar', 'navbar', 'hero', etc.
    config_key VARCHAR(100) NOT NULL,         -- 'message_text', 'bg_color', etc.
    config_value TEXT NOT NULL,               -- Valor del campo
    data_type ENUM('string','integer','boolean','array','json'),
    version VARCHAR(20),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY unique_config (component_name, config_key)
)

🔴 PROBLEMA IDENTIFICADO

Descripción

El algoritmo de modularización ubicado en:

_planeacion/apus-theme/admin-panel-theme/100-modularizacion-admin/00-algoritmo/

❌ PROBLEMA CRÍTICO ENCONTRADO EN PASO 12:

El algoritmo instruye crear un objeto DEFAULT_CONFIG en JavaScript con TODOS los valores por defecto hardcodeados
Esto viola el principio de Single Source of Truth
Los defaults deberían venir de PHP (Settings Manager) vía AJAX, NO estar duplicados en JavaScript

Evidencia del Problema

Ubicación: 00-algoritmo/12-F03-IMPLEMENTACION-IMPLEMENTAR-ADMIN-JS.md

Líneas 43-51 y 169-177:

const DEFAULT_CONFIG = {
    enabled: true,
    campo1: 'valor default',
    custom_styles: {
        background_color: '#0E2337',
        // ... todos los campos del PASO 6
    }
};

Líneas 117-129 (método render()):

document.getElementById('topBarIconClass').value = config.icon_class || '';
document.getElementById('topBarShowLink').checked = config.show_link || false;
const bgColorInput = document.getElementById('topBarBgColor');
bgColorInput.value = config.custom_styles?.bg_color || '#000000';  // ← Fallback hardcodeado

Por Qué es un Problema

Duplicación de defaults:
- PHP Settings Manager tiene defaults
- JavaScript TAMBIÉN tiene defaults (duplicado)
- Tabla DB puede tener defaults (triplicado si se hace seed)
Violación de Single Source of Truth:
- Cambiar un default requiere editar JavaScript Y PHP
- Alto riesgo de inconsistencias
Arquitectura incorrecta:
- JavaScript NO debería tener fallbacks porque get_settings() de PHP ya hace merge con defaults
- AJAX siempre retorna datos completos (DB + defaults merged)

❓ PREGUNTAS PARA INVESTIGACIÓN

PREGUNTA 1: Ubicación del Problema ✅ RESPONDIDA

¿En cuál(es) paso(s) del algoritmo se guardan valores en archivos JS?

PASO 1: Crear issue
PASO 2: Análisis con Serena
PASO 3: Crear estructura de documentación
PASO 4: Documentar código real
PASO 5: Documentar campos configurables
PASO 6: Estructura JSON
PASO 7: Documentar código configurable
PASO 8: Referencia AJAX
PASO 9: Plantilla estructura HTML
PASO 10: Ejemplos componentes
PASO 11: Ensamblar admin HTML
PASO 12: Implementar admin JS ← ❌ AQUÍ ESTÁ EL PROBLEMA
PASO 13: CSS admin panel
PASO 14: Git commits
PASO 15: Testing
PASO 16: Cerrar issue

✅ Respuesta encontrada:

PASO 12 instruye crear objeto DEFAULT_CONFIG en JavaScript con todos los defaults hardcodeados
Líneas problemáticas: 43-51, 169-177, 117-129, 223-229
Archivos afectados: component-[nombre].js (uno por cada componente)

PREGUNTA 2: Archivos JS Afectados ✅ RESPONDIDA

¿Qué archivos JavaScript están siendo modificados con valores hardcodeados?

Opciones probables:

admin/assets/js/admin-app.js ← Fallbacks en método render()
admin/assets/js/component-navbar.js ← Si se siguió PASO 12
admin/assets/js/component-*.js (otros componentes) ← Si se siguió PASO 12
Archivos JS del tema (fuera de admin)
Otro: _______________

✅ Respuesta encontrada:

Patrón del algoritmo: CADA componente debe tener su propio archivo component-[nombre].js
Cada archivo debe tener: Objeto DEFAULT_CONFIG con todos los defaults
Ubicación: admin/assets/js/component-*.js
Comprobación en código actual: admin-app.js:357 tiene fallback hardcodeado para Top Bar

PREGUNTA 3: Tipo de Valores ✅ RESPONDIDA

¿Qué tipo de valores por defecto se están guardando en JS?

Opciones:

Textos (ej: "Accede a más de 200,000...")
URLs (ej: "/catalogo")
Colores (ej: "#0E2337")
Iconos (ej: "bi bi-megaphone-fill")
Configuraciones booleanas (ej: enabled: true)
Todos los anteriores ← CORRECTO
Otro: _______________

✅ Respuesta encontrada:

Según PASO 12 líneas 169-177, el objeto DEFAULT_CONFIG debe contener TODOS los campos del PASO 6
Esto incluye: strings, booleans, URLs, colores (custom_styles), números, selects
Ejemplo real encontrado: admin-app.js:357 tiene 'Accede a más de 200,000...' hardcodeado

PREGUNTA 4: Propósito de los Valores en JS ✅ RESPONDIDA

¿Para qué se usan esos valores hardcodeados en JavaScript?

Opciones:

Fallbacks cuando AJAX no retorna datos ← USO PRINCIPAL
Valores iniciales al renderizar formulario
Placeholders de campos de formulario
Valores de preview/demo
No estoy seguro
Botón "Reset to Defaults" ← USO SECUNDARIO

✅ Respuesta encontrada:

Uso 1 (líneas 117-129): Fallbacks en método render() → config.field || 'default'
Uso 2 (líneas 196-204): Botón reset llama loadConfig(DEFAULT_CONFIG)
Problema: ❌ Los fallbacks son INNECESARIOS porque Settings Manager ya hace merge con defaults

PREGUNTA 5: Comportamiento Esperado ✅ RESPONDIDA

¿Cómo DEBERÍAN manejarse los valores por defecto?

Tu visión:

Guardar en tabla wp_apus_theme_components_defaults (NUEVA tabla, NO la misma)
Formato: Normalizado - un INSERT por campo (Opción A)
JavaScript NUNCA debe tener defaults hardcodeados
JavaScript debe leer defaults vía AJAX desde PHP
PHP lee de tabla de defaults, NO tiene get_defaults() hardcodeado

✅ Respuesta del usuario: "opocion A, no debe ser en la msima tabla personalizada wp_apus_theme_components, debe ser en wp_apus_theme_components_defaults"

Arquitectura definida:

Algoritmo extrae valores hardcodeados → Son los defaults
Se insertan en tabla wp_apus_theme_components_defaults (un row por campo)
Settings Manager lee de tabla de defaults
JavaScript NO tiene DEFAULT_CONFIG
JavaScript lee vía AJAX desde PHP

PREGUNTA 6: Comparación con Sistema Actual ✅ RESPONDIDA

¿El componente Top Bar (que ya está implementado) tiene este problema?

Verificación necesaria:

// ¿Existe esto en admin-app.js?
topBar.message_text || 'Accede a más de 200,000...'

SÍ - Top Bar tiene defaults hardcodeados en JS ← CONFIRMADO
NO - Top Bar lee defaults correctamente de PHP
NO ESTOY SEGURO

✅ Respuesta encontrada:

// admin-app.js:357
document.getElementById('topBarMessageText').value = topBar.message_text || 'Accede a más de 200,000...';

Archivos con defaults de Top Bar:

admin/includes/sanitizers/class-topbar-sanitizer.php (línea 37)
admin/includes/class-settings-manager.php (línea 84)
admin/assets/js/admin-app.js (línea 357)
admin/pages/main.php (líneas 243-244, 495)
admin/components/component-top-bar.php (línea 190, 2 veces)
header.php (línea 34)

Total: ❌ 7 lugares con el MISMO valor hardcodeado

PREGUNTA 7: Alcance del Problema ✅ RESPONDIDA

¿Cuántos componentes están afectados?

Todos los componentes futuros que se modularicen ← PREOCUPACIÓN PRINCIPAL

✅ Respuesta:

Actual: Código existente está MAL implementado - se debe eliminar y rehacer
Futuro: TODOS los componentes que se procesen con el algoritmo PASO 12/14 tendrán el mismo problema
Crítico: Si no se corrige el algoritmo PRIMERO, cada nuevo componente duplicará defaults en JS y PHP

Acción requerida:

❌ NO usar código actual como referencia (está mal hecho)
✅ Corregir algoritmo PRIMERO
✅ Limpiar panel de administración (eliminar rastros de componentes mal implementados)
✅ Limpiar tema (eliminar código duplicado)
✅ LUEGO ejecutar algoritmo corregido para cada componente

PREGUNTA 8: Dónde Debe Estar la Única Fuente de Verdad ✅ RESPONDIDA

¿Dónde deben definirse los defaults UNA SOLA VEZ?

Tu preferencia:

Tabla personalizada wp_apus_theme_components_defaults ← ÚNICA FUENTE DE VERDAD
Formato normalizado: un row por campo
Se pobla mediante algoritmo al procesar cada componente
❌ NO en Settings Manager::get_defaults() (eliminar método hardcodeado)
❌ NO en JavaScript DEFAULT_CONFIG (eliminar objeto hardcodeado)

✅ Respuesta del usuario: Nueva tabla wp_apus_theme_components_defaults con estructura normalizada

Flujo correcto:

Algoritmo PASO 2-4
      ↓
Extrae valores hardcodeados del tema
      ↓
INSERT INTO wp_apus_theme_components_defaults
      ↓
Settings Manager lee de tabla
      ↓
JavaScript lee vía AJAX (sin fallbacks)

🎯 OBJETIVO DE LA SOLUCIÓN

Una vez respondidas las preguntas, definiremos:

Modificaciones al algoritmo - Qué pasos cambiar
Nueva arquitectura de defaults - Dónde y cómo guardarlos
Plan de migración - Cómo corregir código existente
Validación - Cómo verificar que la solución funciona

📝 CÓMO EL ALGORITMO EXTRAE DEFAULTS (REVISIÓN COMPLETA)

Flujo Documentado en el Algoritmo

PASO 2-4: Extraer valores hardcodeados del tema actual

Usa Serena MCP para analizar archivos PHP/CSS/JS del tema
Identifica valores hardcodeados (textos, URLs, colores, iconos)
Documenta estos valores en 01-DOCUMENTACION-ANALISIS-CODIGO-REAL.md

PASO 6: Definir estructura JSON con defaults

Toma los valores extraídos en PASO 2-4
Los define como valores por defecto en estructura JSON
Colores se extraen del CSS: background-color: #0E2337 → custom_styles.background_color: '#0E2337'

PASO 14 (Líneas 88-123): Implementar defaults en Settings Manager

public function get_defaults() {
    return array(
        'version' => APUS_ADMIN_PANEL_VERSION,
        'components' => array(
            'component_name' => array(
                'enabled' => true,
                'field1' => 'Valor por defecto',  // ← Del código hardcodeado actual
                'custom_styles' => array(
                    'background_color' => '#0E2337',  // ← Del CSS original
                    'text_color' => '#ffffff'          // ← Del CSS original
                )
            )
        )
    );
}

❌ PROBLEMA: Defaults NO se insertan en tabla

Lo que el algoritmo NO tiene:

❌ Script de inicialización que inserte defaults en wp_apus_theme_components
❌ Paso que ejecute INSERT en la tabla al activar tema
❌ Migrador que convierta defaults de PHP a DB

Lo que el algoritmo SÍ tiene:

✅ Defaults en PHP (Settings Manager)
✅ Settings Manager hace merge: wp_parse_args($db_data, $defaults)
✅ Cuando tabla está vacía, usa defaults de PHP como fallback

✅ ENTENDIMIENTO CORRECTO DEL FLUJO:

El algoritmo se ejecuta MANUALMENTE componente por componente:

Ejecutar algoritmo para "Top Bar":
- PASO 2-4: Extrae valores hardcodeados actuales de header.php, CSS, JS
- Estos valores SON los defaults del Top Bar
- PASO 14: ❌ Los pone en Settings Manager (PHP hardcodeado)
- PASO 12: ❌ Los pone en JavaScript (DEFAULT_CONFIG hardcodeado)
- ✅ DEBERÍA: Insertarlos en tabla wp_apus_theme_components
Ejecutar algoritmo para "Navbar":
- PASO 2-4: Extrae valores hardcodeados actuales del navbar
- Estos valores SON los defaults del Navbar
- ✅ DEBERÍA: Insertarlos en tabla wp_apus_theme_components
Y así con cada componente...

❌ LO QUE ESTÁ MAL EN EL ALGORITMO:

PASO 12: Pone defaults en JavaScript PASO 14: Pone defaults en PHP Settings Manager

✅ LO QUE DEBERÍA HACER:

Agregar un NUEVO PASO (o modificar PASO 14) que:

Tome los valores extraídos en PASO 2-4
Los inserte en wp_apus_theme_components con INSERT INTO
JavaScript NO tiene defaults hardcodeados
PHP lee de tabla, NO tiene get_defaults() hardcodeado

📝 NOTAS ADICIONALES

[Espacio para el usuario agregar información adicional]

📊 RESUMEN EJECUTIVO DE HALLAZGOS

✅ Preguntas Respondidas (8 de 8) - INVESTIGACIÓN COMPLETA

#	Pregunta	Respuesta
1	¿Dónde está el problema?	PASO 12 y PASO 14 del algoritmo
2	¿Qué archivos JS afectados?	`component-*.js` (uno por componente)
3	¿Qué tipo de valores?	TODOS (strings, booleans, URLs, colores, etc.)
4	¿Para qué se usan?	Fallbacks + Botón Reset
5	¿Cómo DEBERÍAN manejarse?	Tabla `wp_apus_theme_components_defaults` normalizada
6	¿Top Bar tiene el problema?	SÍ - 7 lugares con mismo default
7	¿Cuántos componentes afectados?	Top Bar actual + TODOS los futuros
8	¿Única fuente de verdad?	Nueva tabla `wp_apus_theme_components_defaults`

🎯 Decisión Arquitectónica Final

ÚNICA FUENTE DE VERDAD:

Tabla: wp_apus_theme_components_defaults (nueva)
Formato: Normalizado (un row por campo)
Poblamiento: Vía algoritmo al procesar cada componente
❌ Eliminar: DEFAULT_CONFIG en JavaScript
❌ Modificar: get_defaults() en PHP para leer de DB

🗄️ ESTRUCTURA DE NUEVA TABLA DE DEFAULTS

Tabla: `wp_apus_theme_components_defaults`

Propósito: Almacenar valores por defecto extraídos del tema mediante el algoritmo de modularización

Características:

✅ Estructura normalizada (un row por campo)
✅ Misma estructura que wp_apus_theme_components para consistencia
✅ Se pobla automáticamente al ejecutar algoritmo para cada componente
✅ Single source of truth para todos los defaults del sistema

SQL Schema

CREATE TABLE IF NOT EXISTS wp_apus_theme_components_defaults (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    component_name VARCHAR(50) NOT NULL COMMENT 'Nombre del componente (top_bar, navbar, hero, etc.)',
    config_key VARCHAR(100) NOT NULL COMMENT 'Clave de configuración (message_text, bg_color, etc.)',
    config_value TEXT NOT NULL COMMENT 'Valor por defecto extraído del tema',
    data_type ENUM('string','integer','boolean','array','json') NOT NULL COMMENT 'Tipo de dato del valor',
    version VARCHAR(20) DEFAULT NULL COMMENT 'Versión del tema cuando se insertó el default',
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 'Fecha de creación del registro',
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Última actualización',

    UNIQUE KEY unique_default_config (component_name, config_key),
    INDEX idx_component_name (component_name),
    INDEX idx_config_key (config_key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='Valores por defecto de componentes del tema';

Estructura Genérica de Datos

-- Estructura GENÉRICA para insertar defaults de CUALQUIER componente
-- Se puebla al ejecutar algoritmo para cada componente

INSERT INTO wp_apus_theme_components_defaults
(component_name, config_key, config_value, data_type, version)
VALUES
-- Campos booleanos
('[component_name]', 'enabled', '[1|0]', 'boolean', '[version]'),
('[component_name]', '[boolean_field]', '[1|0]', 'boolean', '[version]'),

-- Campos de texto (extraídos del código hardcodeado)
('[component_name]', '[text_field]', '[valor_extraído_del_código]', 'string', '[version]'),

-- Campos numéricos
('[component_name]', '[number_field]', '[valor_numérico]', 'integer', '[version]'),

-- Custom styles (extraídos del CSS del componente)
('[component_name]', 'custom_styles.[propiedad_css]', '[valor_del_css]', 'string', '[version]');

Notas:

[component_name]: Nombre del componente (ej: 'navbar', 'hero', 'footer')
[config_key]: Clave del campo según PASO 6 del algoritmo
[config_value]: Valor extraído del código/CSS actual del tema
[data_type]: Tipo según el campo (string, integer, boolean, array, json)
[version]: Versión del tema al momento de extraer defaults

Propósito de Cada Tabla

wp_apus_theme_components (configuraciones personalizadas)

Se guardan cuando el usuario modifica valores en el Admin Panel
Si existe config personalizada, se usa esta

wp_apus_theme_components_defaults (valores por defecto)

Se pueblan al ejecutar el algoritmo para cada componente
Se usan SOLO cuando NO existe config personalizada
Son los valores extraídos del tema actual (hardcodeados)

Ambas tablas tienen la MISMA estructura - la diferencia es solo su propósito.

🔄 FLUJO DE LECTURA DE DATOS

¿Por qué se necesitan Settings Manager (PHP) Y JavaScript?

NO están duplicados - tienen propósitos diferentes:

Settings Manager (PHP)

Propósito: Para que archivos PHP del tema lean configuraciones

Uso:

// En header.php, footer.php, etc.
$settings_manager = new APUS_Settings_Manager();
$navbar_config = $settings_manager->get_component_config('navbar');

// Usar $navbar_config en el HTML del tema
echo $navbar_config['logo_url'];

Lee de:

Tabla wp_apus_theme_components (config personalizada) - PRIORIDAD ALTA
Si no existe → Tabla wp_apus_theme_components_defaults (defaults)

JavaScript + AJAX

Propósito: Para que el Admin Panel (interfaz de administración) lea/guarde configuraciones

Uso:

// En admin-app.js
// Leer configuración vía AJAX
axios.get(ajaxUrl + '?action=get_component_config&component=navbar')
    .then(response => {
        // Renderizar formulario con los datos
        renderForm(response.data);
    });

// Guardar configuración vía AJAX
axios.post(ajaxUrl, formData)
    .then(response => {
        // Mostrar mensaje de éxito
    });

Lee/Escribe vía AJAX a:

Endpoint PHP que usa Settings Manager
Guarda en tabla wp_apus_theme_components

Flujo Completo

FRONTEND (tema):
header.php → Settings Manager (PHP) → Lee de DB → Muestra en tema

ADMIN PANEL:
JavaScript → AJAX → Endpoint PHP → Settings Manager → Lee/Escribe DB → Respuesta JSON

Conclusión: Se necesitan AMBOS porque sirven a partes diferentes del sistema (frontend vs admin).

🎯 PRÓXIMOS PASOS

✅ INVESTIGACIÓN COMPLETA - 8/8 preguntas respondidas

ORDEN CORRECTO DE IMPLEMENTACIÓN:

FASE 1: LIMPIAR CÓDIGO ACTUAL (PRIMERO)

El código actual está MAL implementado y debe eliminarse ANTES de corregir el algoritmo

1.1. Limpiar Panel de Administración

Eliminar completamente cualquier rastro de componentes mal implementados:

Eliminar archivos JS de componentes: admin/assets/js/component-*.js
Eliminar archivos CSS de componentes: admin/assets/css/component-*.css
Eliminar archivos PHP de componentes: admin/components/component-*.php
Eliminar sanitizers de componentes: admin/includes/sanitizers/class-*-sanitizer.php
Limpiar admin/pages/main.php de secciones de componentes
Limpiar admin/includes/class-admin-menu.php de encolamiento de componentes

1.2. Limpiar Tema

Eliminar valores hardcodeados duplicados:

Revisar header.php y eliminar valores duplicados
Revisar otros archivos del tema con valores hardcodeados
Dejar SOLO el código original del tema (antes de modularización)

1.3. Limpiar Base de Datos

Eliminar datos de componentes mal implementados:

Vaciar tabla wp_apus_theme_components o eliminar componentes específicos
Preparar para empezar desde cero

FASE 2: CREAR TABLA DE DEFAULTS

2.1. Crear Tabla `wp_apus_theme_components_defaults`

Ejecutar SQL CREATE TABLE (ver estructura arriba)
Verificar que tabla existe y tiene estructura correcta

FASE 3: CORREGIR ALGORITMO (DESPUÉS DE LIMPIAR)

3.1. PASO 12: Implementar Admin JS (CORREGIR)

Archivo: 00-algoritmo/12-F03-IMPLEMENTACION-IMPLEMENTAR-ADMIN-JS.md

Cambios:

❌ ELIMINAR: Objeto DEFAULT_CONFIG (líneas 43-51, 169-177)
❌ ELIMINAR: Fallbacks en método render() (líneas 117-129)
✅ MODIFICAR: Botón reset debe llamar endpoint AJAX para leer defaults de DB
✅ JavaScript NUNCA tiene valores hardcodeados

3.2. PASO 14: Settings Manager (CORREGIR)

Archivo: 00-algoritmo/14-F04-CIERRE-GIT-COMMITS.md

Cambios:

❌ ELIMINAR: Método get_defaults() con array hardcodeado (líneas 88-123)
✅ MODIFICAR: DB Manager para leer de tabla _defaults

3.3. NUEVO PASO: Poblar Tabla de Defaults

Ubicación: Después de PASO 7

Contenido:

Leer valores extraídos en PASO 6 (estructura JSON)
Generar script SQL con INSERTs para tabla wp_apus_theme_components_defaults
Ejecutar script SQL
Verificar que defaults están en DB

FASE 4: USAR ALGORITMO CORREGIDO PARA DOCUMENTAR COMPONENTES

El algoritmo NO implementa código - solo DOCUMENTA

Una vez el algoritmo esté corregido:

4.1. Ejecutar Algoritmo Completo (16 pasos) para UN Componente

Ejemplo: Navbar

Pasos 1-13: DOCUMENTACIÓN (genera 7 archivos MD)

PASO 1: Crear issue en GitHub
PASO 2-4: Analizar código actual del Navbar (Serena MCP)
PASO 5-8: Diseñar campos configurables y estructura JSON
PASO 9-13: Documentar cómo implementar (plantillas, ejemplos, HTML, JS, CSS)

OUTPUT: Carpeta navbar/ con 7 archivos MD de documentación

4.2. PASO 14: Implementar Código Real

AQUÍ es cuando se modifica código PHP/JS/CSS del tema/admin

⚠️ NOTA IMPORTANTE: El PASO 14 actual del algoritmo tiene el problema que identificamos:

Instruye crear método get_defaults() con array hardcodeado en Settings Manager (líneas 88-123)
Esto es lo que necesitamos CORREGIR en FASE 3

Con el algoritmo CORREGIDO, el PASO 14 debe hacer:

Usando la documentación generada en pasos 1-13:

Modificar PHP del tema (ej: header.php) según 04-IMPLEMENTACION-COMPONENTE-NAVBAR.md
Agregar HTML admin en admin/pages/main.php según 05-IMPLEMENTACION-ADMIN-HTML-NAVBAR.md
Agregar JavaScript en admin/assets/js/admin-app.js según 07-IMPLEMENTACION-JS-ESPECIFICO.md
MODIFICAR DB Manager: Agregar método para insertar/leer defaults de tabla wp_apus_theme_components_defaults
MODIFICAR Settings Manager: Leer de tabla defaults (NO array hardcodeado)
INSERTAR defaults en DB: Ejecutar script SQL con valores extraídos en PASO 4
Commits por cada archivo modificado

4.3. PASO 15-16: Testing y Cierre

Testing post-implementación
Cerrar issue en GitHub

4.4. Repetir para Cada Componente

Una vez completado Navbar (pasos 1-16):

Ejecutar algoritmo para siguiente componente (ej: Hero)
Generar documentación (pasos 1-13)
Implementar código real (paso 14)
Testing y cierre (pasos 15-16)

Componentes del tema a procesar:

Navbar
Hero Section
Footer
etc.

Última actualización: 2025-01-13 - INVESTIGACIÓN COMPLETA - 8/8 preguntas respondidas Estado: 🟢 LISTO PARA IMPLEMENTACIÓN

24 KiB Raw Blame History

PROBLEMA: Defaults Hardcodeados en Algoritmo de Modularización

📋 CONTEXTO

Situación Actual

Objetivo del Sistema

Sistema de Persistencia Disponible

🔴 PROBLEMA IDENTIFICADO

Descripción

Evidencia del Problema

Por Qué es un Problema

❓ PREGUNTAS PARA INVESTIGACIÓN

PREGUNTA 1: Ubicación del Problema ✅ RESPONDIDA

PREGUNTA 2: Archivos JS Afectados ✅ RESPONDIDA

PREGUNTA 3: Tipo de Valores ✅ RESPONDIDA

PREGUNTA 4: Propósito de los Valores en JS ✅ RESPONDIDA

PREGUNTA 5: Comportamiento Esperado ✅ RESPONDIDA

PREGUNTA 6: Comparación con Sistema Actual ✅ RESPONDIDA

PREGUNTA 7: Alcance del Problema ✅ RESPONDIDA

PREGUNTA 8: Dónde Debe Estar la Única Fuente de Verdad ✅ RESPONDIDA

🎯 OBJETIVO DE LA SOLUCIÓN

📝 CÓMO EL ALGORITMO EXTRAE DEFAULTS (REVISIÓN COMPLETA)

Flujo Documentado en el Algoritmo

❌ PROBLEMA: Defaults NO se insertan en tabla

✅ ENTENDIMIENTO CORRECTO DEL FLUJO:

❌ LO QUE ESTÁ MAL EN EL ALGORITMO:

📝 NOTAS ADICIONALES

📊 RESUMEN EJECUTIVO DE HALLAZGOS

✅ Preguntas Respondidas (8 de 8) - INVESTIGACIÓN COMPLETA

🎯 Decisión Arquitectónica Final

🗄️ ESTRUCTURA DE NUEVA TABLA DE DEFAULTS

Tabla: wp_apus_theme_components_defaults

SQL Schema

Estructura Genérica de Datos

Propósito de Cada Tabla

🔄 FLUJO DE LECTURA DE DATOS

¿Por qué se necesitan Settings Manager (PHP) Y JavaScript?

Settings Manager (PHP)

JavaScript + AJAX

Flujo Completo

🎯 PRÓXIMOS PASOS

✅ INVESTIGACIÓN COMPLETA - 8/8 preguntas respondidas

FASE 1: LIMPIAR CÓDIGO ACTUAL (PRIMERO)

1.1. Limpiar Panel de Administración

1.2. Limpiar Tema

1.3. Limpiar Base de Datos

FASE 2: CREAR TABLA DE DEFAULTS

2.1. Crear Tabla wp_apus_theme_components_defaults

FASE 3: CORREGIR ALGORITMO (DESPUÉS DE LIMPIAR)

3.1. PASO 12: Implementar Admin JS (CORREGIR)

3.2. PASO 14: Settings Manager (CORREGIR)

3.3. NUEVO PASO: Poblar Tabla de Defaults

FASE 4: USAR ALGORITMO CORREGIDO PARA DOCUMENTAR COMPONENTES

4.1. Ejecutar Algoritmo Completo (16 pasos) para UN Componente

4.2. PASO 14: Implementar Código Real

4.3. PASO 15-16: Testing y Cierre

4.4. Repetir para Cada Componente

24 KiB

Raw Blame History

Tabla: `wp_apus_theme_components_defaults`

2.1. Crear Tabla `wp_apus_theme_components_defaults`