# ATENCION: WordPress YA NO ESTA EN public_html  (cambio del 2026-08-04, TI DYEPHSA)

Si llegaste aqui buscando los archivos de WordPress, estan en:

    /home/bolsascu/nuevo_cuervo/tienda/        <-- WordPress + WooCommerce completo

Esta carpeta (public_html) quedo SOLO como puente de redirecciones. Su unico
contenido es el .htaccess que manda el subdominio viejo a la ubicacion nueva.

## Que cambio y por que

La tienda se consolido DENTRO del dominio principal, que era lo que se pedia:
no queriamos seguir usando un subdominio.

    ANTES                                  AHORA
    tienda.cuervobags.com/carrito/    ->   cuervobags.com/tienda/carrito/
    tienda.cuervobags.com/mi-cuenta/  ->   cuervobags.com/tienda/mi-cuenta/
    tienda.cuervobags.com/wp-admin/   ->   cuervobags.com/tienda/wp-admin/

El subdominio SIGUE FUNCIONANDO: todo lo que le llegue se redirige con 301 a su
destino nuevo, asi que ningun enlace viejo se rompe. Tambien se redirigen los
enlaces sin prefijo (cuervobags.com/carrito -> cuervobags.com/tienda/carrito/).

La portada de cuervobags.com sigue siendo el sitio en PHP (no WordPress), que
vive en /home/bolsascu/nuevo_cuervo/ y tiene su propio catalogo estatico.

## Donde entrar ahora

    Panel:  https://cuervobags.com/tienda/wp-admin/
    Login:  https://cuervobags.com/tienda/wp-login.php

## Sobre el mu-plugin zz-fix-siteurl.php  (el que pusiste el 04-ago 15:18)

SE CONSERVO, no se borro. Solo se le cambio la URL que fuerza:

    antes:  https://tienda.cuervobags.com
    ahora:  https://cuervobags.com/tienda

Se respeto tu diagnostico de que el valor de la base de datos se revierte solo
cada ~5 min. Ahora la BD y el mu-plugin dicen lo mismo, asi que aunque algo
revierta el valor, WordPress sigue resolviendo bien.
Tu version original esta guardada en:
    /home/bolsascu/respaldos/consolidacion_2026-08-04/zz-fix-siteurl.php.bak

## Un detalle que costo encontrar, por si tocas el .htaccess

En /home/bolsascu/nuevo_cuervo/.htaccess hay reglas 301 que mandan los enlaces
viejos a /tienda. OJO: la palabra "tienda" NO puede aparecer en el patron de
origen de esas reglas, o /tienda/carrito/ se redirige a /tienda/tienda/carrito/
y se hace un bucle infinito.

Tampoco hace falta "ayudar" a WordPress con reglas en el .htaccess del dominio:
su propio .htaccess (con RewriteBase /tienda/) ya hace todo el trabajo. Los
parches que se le agregaron al principio eran justamente lo que lo rompia.

## PENDIENTE IMPORTANTE (no se pudo probar)

No hay NINGUN producto publicado (119 en borrador, 5 privados), asi que no se
pudo hacer una compra de prueba de extremo a extremo.

Antes de vender hay que revisar en cada pasarela que las URL de retorno y los
webhooks no sigan apuntando a tienda.cuervobags.com:
Stripe (checkout-plugins-stripe-woo + woocommerce-gateway-stripe),
MercadoPago y WooPayments.

## Como revertir todo, si hiciera falta

    mv /home/bolsascu/nuevo_cuervo/tienda /home/bolsascu/public_html
    restaurar los .htaccess y el mu-plugin desde
        /home/bolsascu/respaldos/consolidacion_2026-08-04/
    UPDATE wpbcs_options SET option_value='https://cuervobags.com'
        WHERE option_name IN ('siteurl','home');

Respaldo previo verificado (gzip OK, 73,249 archivos, BD con 89 tablas):
    /home/bolsascu/respaldos/consolidacion_2026-08-04/

Dudas: el equipo de TI de DYEPHSA hizo este cambio y el del 30-jul.

---

# COSAS DEL ENTORNO QUE AHORRAN TIEMPO (medidas el 2026-08-04)

## 1. ⛔ El .htaccess de nuevo_cuervo DEBE SER ASCII PURO
Un comentario con tildes o un emoji hace que Apache devuelva **500 en TODO el
sitio**. Ya paso el 2026-08-01: 35 bytes no-ASCII lo tumbaron entero. El propio
archivo lo advierte en su cabecera. Comprobar antes de guardar:

    LC_ALL=C grep -c '[^ -~\t]' /home/bolsascu/nuevo_cuervo/.htaccess    # debe dar 0

## 2. cuervobags.com es un dominio ADDON
Su vhost NO se llama como el dominio. Buscar "ServerName cuervobags.com" en
httpd.conf no devuelve NADA. El vhost real es:

    ServerName cuervobags.bolsaspersonalizadas.com.mx
    ServerAlias cuervobags.com www.cuervobags.com ...
    DocumentRoot /home/bolsascu/nuevo_cuervo

## 3. No hace falta WHM para editar las reglas del sitio
Las redirecciones NO estan en la configuracion del servidor: estan en
/home/bolsascu/nuevo_cuervo/.htaccess, que es de bolsascu y se puede editar por
SSH o desde el Administrador de archivos de cPanel.
Ojo con la confusion facil: public_html era el docroot de tienda.cuervobags.com,
NO el de cuervobags.com. Por eso las reglas no aparecian al buscarlas ahi.

## 4. Los certificados SSL no estan en conflicto
    cuervobags.com        -> wildcard *.cuervobags.com   (vence 28-oct-2026)
    tienda.cuervobags.com -> el suyo propio              (vence 31-oct-2026)
Cada dominio presenta el que le corresponde; Apache elige el mas especifico.
Que convivan un wildcard y uno especifico es normal, no un choque.

## 5. El catalogo que se ve NO sale de WooCommerce
/coleccion y las fichas /bolsa/<slug> se generan de un catalogo ESTATICO:

    /home/bolsascu/nuevo_cuervo/includes/catalogo.php   (75 KB)

Publicar productos en WooCommerce NO los hara aparecer solos en /coleccion.
Estado actual de Woo: 0 publicados, 119 en borrador, 5 privados, 16 en papelera.

## 6. wp-cli: hay que invocarlo con el PHP correcto
/usr/local/bin/wp existe, pero el php por defecto es CGI y falla con un mensaje
confuso ("WP-CLI only works correctly from the command line"). Lo correcto:

    sudo -u bolsascu /opt/cpanel/ea-php82/root/usr/bin/php /usr/local/bin/wp \
        --path=/home/bolsascu/nuevo_cuervo/tienda option get siteurl

El prefijo de tablas es **wpbcs_**, no wp_. HPOS esta activo (wpbcs_wc_orders)
pero vacio; los 2 pedidos viejos estan en wpbcs_posts.

## 7. Para depurar rewrites, usar el log, no la intuicion
Lo que resolvio la mudanza fue activar el trace de mod_rewrite como include de
cPanel y probar en una CARPETA AISLADA, no en produccion:

    # /etc/apache2/conf.d/userdata/{std,ssl}/2_4/bolsascu/cuervobags.com/zz-trace.conf
    LogLevel alert rewrite:trace3
    # aplicar: /usr/local/cpanel/scripts/ensure_vhost_includes --user=bolsascu
    #          apachectl configtest && apachectl graceful
    # leer:    grep 'la-ruta' /etc/apache2/logs/error_log
    # ⛔ QUITARLO al terminar: genera muchisimo log.

Muestra linea por linea que hace Apache con la URI. Sin el se pierden horas
adivinando; con el, el diagnostico sale a la primera.
