Qué es PrizeX
PrizeX es una plataforma de premios, juegos y marketplace hecha en PHP: subastas, lotería, cajas misteriosas, un conjunto de minijuegos, una tienda de comercio electrónico multivendedor y una economía de monedero y monedas, todo en una sola aplicación autoalojada. Se entrega con una arquitectura de plugins y temas, un panel de administración y 38 plugins de pasarela de pago que cubren tarjetas, monederos, cripto y procesadores regionales, además de 3 métodos de pago manuales que crea el propio núcleo.
No hay dependencia de ningún SaaS: lo instalas en tu propio hosting, la base de datos es tuya y la licencia incluye actualizaciones de por vida. Cada vertical (subastas, lotería, cajas misteriosas, juegos, tienda) se activa o desactiva de forma independiente desde el panel de administración: una instalación nueva puede funcionar como producto de una sola vertical o como la suite completa.
El código del núcleo nunca depende de forma rígida de un plugin. Cada vertical, cada pasarela de pago y cada inicio de sesión social es un plugin dentro de plugins/ que se puede activar, desactivar o eliminar sin romper el resto del sitio.
Prefijo de tabla tbl_, sin ORM y con sentencias preparadas en la mayoría de los casos. Cada plugin es dueño de sus propias tablas y las migra con un instalador idempotente db_delta().
Qué necesita para funcionar
PrizeX funciona en hosting compartido estándar o en un VPS, sin más configuración de servidor que un servidor web capaz de reescribir URL.
* Varios archivos de database/migrations/ usan la extensión ADD COLUMN IF NOT EXISTS, exclusiva de MariaDB. MySQL 8.0/8.4 la rechaza: usa MariaDB como base de datos, tanto en desarrollo como en producción.
Poner en marcha una instalación nueva
No hay asistente de instalación para una configuración desde cero: importas el esquema directamente y configuras el archivo de entorno.
- Instala las dependencias de PHP:
composer install - Copia la plantilla de entorno y rellena las credenciales de tu base de datos:
cp .env.example .env - Importa
database/production.sqlen la base de datos indicada en tu.env: así se crea el esquema completo. - Sustituye la cuenta de administrador precargada (mira el aviso de abajo) y luego inicia sesión en
/admin/.
database/production.sql incluye una fila tbl_admin (admin@wowcodes.in) cuyo hash de contraseña es idéntico en todas las instalaciones. Bórrala e inserta la tuya antes de salir a producción:
php -r "echo password_hash('your-password', PASSWORD_BCRYPT), \"\n\";"DELETE FROM tbl_admin;
INSERT INTO tbl_admin (username, email, password, image, status, permission_settings)
VALUES ('yourname', 'you@example.com', '<hash from the command above>', '', 1, 1);Para desarrollo local, el servidor integrado de PHP funciona sin Apache: php -S localhost:8000 router.php. Ten en cuenta que ese servidor ignora por completo .htaccess, así que router.php reimplementa a mano las mismas reglas de enrutado (mira Configuración del servidor web).
Variables de entorno
Todos los ajustes propios de cada entorno viven en .env, que se carga con vlucas/phpdotenv. Copia .env.example a .env (ignorado por git) y define valores reales para cada entorno: las credenciales de la base de datos, como mínimo, antes de importar el esquema.
Los ajustes generales del sitio que no dependen del entorno (nombre de la aplicación, divisa, plugins activos, tema activo y los interruptores de cada vertical) viven en la base de datos, en tbl_settings, y se gestionan desde el panel de administración en lugar de en archivos.
Configuración del servidor web
Las reglas de enrutado y seguridad —URL amigables, bloqueo del acceso directo a .env/connection.php/registros y la prevención de que el contenido subido se ejecute como PHP— están definidas en los archivos .htaccess repartidos por todo el proyecto. Apache y LiteSpeed/OpenLiteSpeed los leen de forma nativa.
En nginx, usa nginx.conf.example, que replica todas esas reglas en un bloque server{} de nginx: ajusta server_name, root y el socket de PHP-FPM para tu entorno.
.htaccess (producción), router.php (servidor de desarrollo local php -S) y nginx.conf.example (nginx) reimplementan por separado las mismas reglas de enrutado. Añadir una nueva URL amigable implica actualizar los tres.
Arquitectura de las peticiones
Cada página de la tienda (index.php, item.php, …) arranca a través de includes/header.php, en este orden:
connection.php inicia la sesión, conecta por mysqli con las credenciales de .env, carga tbl_settings en constantes como APP_NAME y CURRENCY, e inicia la sesión del usuario actual junto con una fila de huella del dispositivo. plugins_load() arranca todos los plugins activos y dispara el hook plugins_loaded: ese es el momento en el que se conoce el conjunto real y actual de verticales activas, y por eso header.php vuelve a contrastar después los antiguos indicadores de ajustes (tienda, multivendedor, subastas, lotería) con el estado real de los plugins activos.
El panel de administración no duplica este arranque: admin/includes/connection.php define la configuración de sesión y errores propia del administrador y luego incluye el mismo includes/connection.php raíz.
Sistema de plugins
Un plugin es plugins/<slug>/plugin.php —metadatos en un comentario de cabecera que se leen sin ejecutar el archivo— más un plugin.json opcional con información de catálogo más rica. Los plugins activos se guardan como un array JSON en tbl_settings.active_plugins.
- Propiedad de las tablas: cada plugin define su propio
includes/schema.php, que se llama al activarlo, con la función idempotentedb_delta()(CREATE TABLE IF NOT EXISTS+ soloALTER TABLE ADD COLUMNaditivos). Un plugin nunca toca las tablas de otro. - Los registros se cargan primero:
add_admin_page,add_route,add_cron_job,add_api_routeyregister_modulese definen antes de que se cargue ningún plugin, así que las llamadas de primer nivel de un plugin nunca provocan un error fatal aunque el plugin acabe inactivo. - Eliminación limpia: al borrar un plugin se ejecuta su
uninstall.phpy se elimina su carpeta; nada fuera deplugins/<slug>/debería depender de forma rígida de sus archivos, así que el resto del sitio sigue funcionando sin él.
Sistema de temas
Un tema vive en assets/themes/<slug>/: un manifest.php, un theme.css, un functions.php para los hooks del tema y una carpeta components/ opcional. El tema activo se guarda en tbl_settings.active_theme, con editorial como reserva si no hay ninguno definido.
La resolución de componentes comprueba, en este orden: la carpeta components/ del propio tema activo, después el directorio de componentes que declare un plugin con register_module() y, por último, la carpeta components/ raíz compartida. En la práctica esto significa que el componente compartido por defecto vive una sola vez en components/, y que cualquier tema —o cualquier plugin vertical activo— puede sustituir la ruta de un componente concreto con su propia copia.
Base de datos
Prefijo de tabla tbl_, mysqli directo y sentencias preparadas en la mayoría de los casos. Archivos SQL, por orden de autoridad:
database/core-schema.sql: solo las tablas del núcleo, mantenidas a mano; las tablas de las verticales y de los plugins se excluyen a propósito.database/production.sql: generado (esquema del núcleo + la rutina de instalación de cada plugin, volcado desde una base de datos vacía). Es el que importas para una instalación nueva.database/sandbox.sql: conjunto de datos de demostración para el desarrollo local.database/migration.sql: script de actualización consolidado e idempotente para instalaciones ya existentes.database/migrations/<slug>/up.sql(+down.sqlcuando es reversible): un archivo por cada migración.
Módulos
Todos los módulos vienen en la misma instalación y se activan o desactivan de forma independiente desde el panel de administración.
Subastas
Pujas en vivo con un portal del vendedor multivendedor y motor de comisiones. Plugin principal: plugins/auction.
Lotería
Sorteos con boletos, con calendarios, premios y avisos a los ganadores configurables. Plugin principal: plugins/lottery.
Caja misteriosa
Bolsas de premios configurables con animaciones de apertura: el usuario compra una caja y ve al instante lo que le ha tocado. Plugin: plugins/mystery-box.
Juegos y recompensas
Un conjunto de minijuegos en games/ más los plugins de enganche y recompensas:
Tienda y marketplace
Una capa de comercio electrónico multivendedor con promociones y herramientas de merchandising. Plugins principales: plugins/shop, plugins/multivendor.
Monedero, monedas e inversión
Un monedero común a toda la plataforma, compartido por todos los módulos.
Referidos y recompensas
Autenticación, confianza y cumplimiento
Utilidades
Panel de administración
El panel de administración vive en admin/ y no duplica el arranque de la tienda: define la configuración de sesión y errores propia del administrador y luego incluye el mismo includes/connection.php raíz. Las páginas se registran con add_admin_page(), que se encarga de la entrada en la barra lateral, el control de permisos, el CSRF y el marco de autenticación; las acciones JSON exclusivas del administrador se registran con add_admin_ajax() y se despachan a través de admin/ajax.php?action=<slug>.
Artículos, banners, páginas, menús y blog.
Gestión de pasarelas automáticas y manuales, revisión de pagos manuales y exportación de pagos a vendedores.
Grupos de usuarios, roles, datos del vendedor y suplantación de identidad.
Exportación de transacciones, pedidos y usuarios, registros de cron, seguimiento de errores y registro de actividad del administrador.
Campañas de correo, plantillas, boletines, notificaciones push y registro de notificaciones.
Activar y desactivar plugins y temas, ajustes SEO por página y ajustes generales del sitio.
Temas de la tienda
Se entregan cinco temas en assets/themes/, intercambiables en cada instalación desde el panel de administración. Cada tema guarda su propia copia de los componentes compartidos en su propia carpeta components/.
Un aspecto sencillo y moderno, con tarjetas blancas y sombras suaves: una opción segura y versátil para casi cualquier tipo de tienda.
Un aspecto limpio, de estilo editorial, con tonos cálidos de papel y una tipografía nítida, para una tienda cuidada y de confianza.
Tema de reserva por defectoUn tema oscuro, atrevido y lujoso, con detalles dorados: diseñado para transmitir emoción y categoría.
Un aspecto cálido y muy decorado, inspirado en los mercados tradicionales, con soporte para idiomas de derecha a izquierda.
Un aspecto festivo y tenebroso de temporada: fondos morados intensos con destellos naranja calabaza.
Pasarelas de pago
Las 38 pasarelas automáticas pertenecen a plugins: cada una vive en su propia carpeta plugins/gateway-<slug>/ y se registra en el núcleo mediante add_payment_gateway(). Basta con activar una para que funcione; nada del despachador del pago (payment_processor.php) está fijado a una pasarela concreta.
Los 3 métodos manuales son filas con gateway_type = 'manual' que crea el propio núcleo, sin código de init/verify que configurar: solo muestran instrucciones de pago o un código QR. El plugin manual-gateway-builder permite al administrador añadir más métodos de pago manuales a medida sin tocar código.
Algunas pasarelas (Stripe, Razorpay, Midtrans, Venmo) registran además un hook render para los flujos de pago que necesitan JS en el cliente: el arranque de Stripe Checkout, o un SDK de Razorpay/Midtrans/Braintree que necesita un ID de pedido o un token generado antes en el servidor. Todas las demás pasarelas funcionan sin ningún cableado extra en el núcleo.
Capas de API y AJAX
api/v1/: API REST autenticada con JWT para la aplicación móvil y para consumidores externos.api/v1/middleware/*.phpvalida la cabeceraAuthorization: Bearer <token>. Los plugins añaden sus propios endpoints medianteadd_api_route().ajax/: AJAX interno autenticado con la cookie de sesión para el JS de la propia tienda (carrito, cupones, notificaciones). Sin capa de tokens: se apoya en la sesión PHP que creaconnection.php.api/suelto en la raíz: endpoints varios sin versionar, comogeo_location.php,exchange-rate.phpyofferwall_postback.php.
Aplicación móvil
mobile/ es un proyecto aparte de Capacitor + Ionic: un envoltorio WebView sobre el sitio en producción, no una SPA independiente ni únicamente un consumidor de api/v1. Su capacitor.config.ts apunta server.url a tu dominio. Tiene su propio package.json y no se compila desde la raíz del proyecto:
cd mobile
npm run sync
npm run open:ios
npm run open:androidActualizaciones y migraciones
Haz una copia de seguridad antes de ejecutar database/migration.sql o cualquier database/migrations/<slug>/up.sql contra una base de datos en producción:
mysqldump --single-transaction -u<user> -p<pass> <db> > pre-deploy-$(date +%Y%m%d-%H%M%S).sqlLa mayoría de las migraciones incluyen un down.sql equivalente para revertir solo ese cambio. Unas pocas, las que transforman datos existentes en lugar de limitarse a añadir estructura, incluyen un down.sql que documenta por qué no hace nada: en esos casos, restaura desde el volcado previo al despliegue si necesitas dar marcha atrás.
Notas de seguridad
- Cambia las credenciales de administrador precargadas justo después de importar (mira Instalación).
.env,connection.phpy los archivos de registro tienen bloqueado el acceso directo por HTTP gracias a las reglas de.htaccess/ nginx que se incluyen: no elimines esas reglas.- El contenido subido se sirve de forma que no pueda ejecutarse como PHP, algo que se impone en la configuración del servidor web y no en la aplicación.
- Las credenciales de las pasarelas de pago se configuran pasarela a pasarela desde el panel de administración y se guardan en el servidor: nunca se exponen en la tienda.
Pruebas
No hay una suite de PHPUnit. composer test ejecuta bin/run-probes.php, que reúne todos los archivos probe_*.php de includes/_probes/ y de la carpeta _probes/ de cada plugin, ejecutando cada uno como subproceso de CLI y comprobando su código de salida.
composer test # run every probe
php plugins/<slug>/_probes/probe_*.php # run a single probe directly
php bin/run-probes.php --all # also run destructive probes (skipped by default)Preguntas frecuentes
Soporte y recursos
¿Sigues atascado o necesitas algo que esta página no cubre?