[Tronlar]

3

He realizado una actualización importante del CMS PHPPost para adaptarlo a tecnologías actuales y mejorar tanto la estabilidad como la compatibilidad futura del sistema.

Entre los principales cambios realizados se encuentran:

• Actualización completa a PHP 8.X.X
  
• Integración de CKEditor 5 como nuevo editor visual
  
• Migración y adaptación a Smarty
  
• Corrección de errores heredados y mejoras internas del núcleo
  

Esta actualización no ha sido únicamente un cambio de versión, sino una modernización general del sistema para garantizar un mejor rendimiento, mayor seguridad y compatibilidad con servidores actuales.

¿Qué se ha mejorado?
Compatibilidad con PHP 8.X.X

El CMS ahora funciona sobre una versión moderna de PHP, eliminando funciones obsoletas y adaptando el código a los nuevos estándares del lenguaje. Esto permite:

• Mayor velocidad de ejecución
  
• Mejor gestión de memoria
  
• Más seguridad
  
• Compatibilidad con hosting actuales y futuros
  

Además, se han corregido numerosos avisos, warnings y errores que aparecían en versiones recientes de PHP.

Nuevo editor CKEditor 5

Se ha sustituido el antiguo editor por CKEditor 5, ofreciendo:

• Interfaz más moderna
  
• Mejor compatibilidad con navegadores actuales
  
• Edición más estable
  
• Mejor experiencia al crear publicaciones y contenido
  

También se han adaptado funciones internas relacionadas con la subida de imágenes y la edición avanzada de textos.

Actualización de Smarty a la versión 5.8.0
 El motor de plantillas Smarty ha sido actualizado y adaptado completamente para mejorar:

• Rendimiento del sistema de plantillas
  
• Seguridad en la renderización
  
• Compatibilidad con PHP moderno
  
• Organización interna del código
  

Durante el proceso se corrigieron múltiples incompatibilidades heredadas de versiones antiguas.
Correcciones y mejoras generales

Además de las actualizaciones principales, también se realizaron múltiples ajustes internos:

• Corrección de errores históricos
  
• Optimización de consultas y procesos
  
• Limpieza de código legado
  
• Mejoras de estabilidad
  
• Compatibilidad general con entornos modernos
  
• Nace Risus Nova 2.0
  

Con esta nueva etapa, el proyecto pasa a llamarse:

Risus Nova 2.0

El objetivo es mantener vivo el CMS, modernizarlo y convertirlo en una plataforma más sólida, rápida y preparada para seguir evolucionando durante los próximos años.
La comunidad también forma parte del proyecto.
Me gustaría conocer vuestra opinión y saber qué os gustaría ver en futuras versiones de Risus Nova 2.0.


Algunas ideas que ya tengo en mente son:

• Mejoras visuales y responsive
  
• Sistema de plugins
  
• Panel de administración modernizado
  
• Mejor SEO
  
• API REST
  
• Mejor sistema de usuarios y permisos
  
• Optimización de rendimiento
  
• Nuevas funciones sociales
  

Pero también quiero escuchar a la comunidad.

¿Qué funcionalidades os gustaría que tuviera?
¿Qué mejoraríais del CMS?
¿Qué echáis en falta actualmente?

Toda sugerencia, idea o reporte es bienvenida y ayudará a seguir mejorando el proyecto.

[img]Registrate o inicia tu sesión para ver este contenido[/img]

[img]Registrate o inicia tu sesión para ver este contenido[/img]

[moyo]

1

me gusta Risus Nova 2.0. necesito ver la demo y dar mi opinión. 

[Tronlar]

0

me gusta Risus Nova 2.0. necesito ver la demo y dar mi opinión. 

Hola Moyo, mañana le creo un dominio y la subo, para que la probéis y también subo ya la base actualizada, se puede usar sin problemas y si tiene alguno lo comentáis para solucionarlo.
Le he hecho una actualización bastante importante, ahora con la base los que tenga web ya funcionando, solo tiene que añadirle las funciones que le hayan puesto aparte y él teme o diseño. Ahora crearle un tema, actualizárle alguna librería es más fácil y siempre la tiene actualizada a lo último que salga.

[img]Registrate o inicia tu sesión para ver este contenido[/img]

[img]Registrate o inicia tu sesión para ver este contenido[/img]

[moyo]

0

Hola Moyo, mañana le creo un dominio y la subo, para que la probéis y también subo ya la base actualizada, se puede usar sin problemas y si tiene alguno lo comentáis para solucionarlo.
Le he hecho una actualización bastante importante, ahora con la base los que tenga web ya funcionando, solo tiene que añadirle las funciones que le hayan puesto aparte y él teme o diseño. Ahora crearle un tema, actualizárle alguna librería es más fácil y siempre la tiene actualizada a lo último que salga.

Genial, quedamos a la espera de ese dominio de pruebas para testear las nuevas funciones. Me parece un acierto total que ahora sea más fácil separar el diseño web de la lógica de la base. Esto ayuda mucho a quienes ya tenemos una web en producción y queremos implementar las últimas mejoras sin riesgo. Si surge algún error durante la migración o el testeo, lo comentaremos por aquí para pulir la versión final.

[Miguel92]

0

Con el CKEditor 5, has configurado el adaptador de carga para las imágenes, no? Básicamente permite subir imágenes desde el ckeditor y no por fuera. Ese fue un tema de porque no lo implemente, además al momento que lo había probado era bastante lio, no sé ahora...
La ultima vez que toque el ckeditor 5 estaba recién salido del horno jaja (Es una duda que tengo, después no puedo opinar más si no veo o pruebo antes)

PD:
1 - Veo en el gif que dice "Markdown/HTML" usará markdown o bbcode?
2 - La carga del video de youtube es directa(iframe) o usas un plugin como "lite-youtube" (carga una vista previa del video y no el video hasta que se de clic, esto hace que se ahorren recursos al momento de entrar al posts)

[Tronlar]

0

Con el CKEditor 5, has configurado el adaptador de carga para las imágenes, no? Básicamente permite subir imágenes desde el ckeditor y no por fuera. Ese fue un tema de porque no lo implemente, además al momento que lo había probado era bastante lio, no sé ahora...
La ultima vez que toque el ckeditor 5 estaba recién salido del horno jaja (Es una duda que tengo, después no puedo opinar más si no veo o pruebo antes)

PD:
1 - Veo en el gif que dice "Markdown/HTML" usará markdown o bbcode?
2 - La carga del video de youtube es directa(iframe) o usas un plugin como "lite-youtube" (carga una vista previa del video y no el video hasta que se de clic, esto hace que se ahorren recursos al momento de entrar al posts)

Sí, le he configurado un adaptador que se comunica con un archivo upload.php en el backend.
El editor coge la imagen, la envía por POST vía AJAX , el servidor la procesa, la guarda en /files/uploads/ y devuelve un JSON con la URL, el usuario no sale del editor.

Ahora es mejor antes, yo he tenido no sé cuantos errores de todas clases, no publicaba, no borraba, en blanco, salía entidades, etiquetas... solucionaba uno le salía otro jajajajaja, pero ya a base de pruebas y error se lo he adaptado a todo.

Yo es el que me ha parecido que le va mejor y está muy bien, no inserta una imagen mediante una simple URL, sino que gestiona un ciclo de vida de subida, cuando pegas una imagen o la arrastras, el editor no la procesa como texto, sino como un objeto file de javascript.
Le he configurado un adaptador que implementa una interfaz, mientras la imagen se sube, el editor muestra una barra de progreso real sobre la imagen.  

El adaptador utiliza XMLHttpRequest para enviar la imagen a un archivo procesador al servidor upload.php, valida el tipo MIME para evitar archivos maliciosos y el tamaño.  

Guardada ya en el servidor, el PHP devuelve un JSON. El adaptador recibe la URL final y "reemplaza" la imagen temporal por la definitiva sin que el usuario tenga que refrescar o tocar nada de código.  
Y optimización automática, el sistema permite que el servidor genere automáticamente versiones tipo thumbnails para que la carga sea mucho más ligera.

En el GIF ves "Markdown/HTML" porque ckeditor 5 es nativo en HTML, pero le he habilitado el plugin de autoformat.
El usuario puede escribir en Markdown (por ejemplo, escribir # Título) y el editor lo convierte en tiempo real a HTML visual.
Lo que se guarda en la base de datos es HTML puro, esto es mucho mejor para el SEO y para evitar los pesados parsers de BBCode que ralentizaban la carga del sitio.

La mayoría de los plugins de YouTube para editores cargan librerías pesadas, archivos CSS extra y, a veces, dependencias de terceros que tú no controlas.

El editor detecta la URL de YouTube y la convierte en un contenedor responsivo, no soltará el código pesado, sino que generará automáticamente una "Fachada Dinámica".

Los plugins suelen venir con un diseño rígido, si quieres cambiar el color o hacerle algo, te tienes que pelearon el código del autor.
Cuando usas un plugin que inserta el iframe directamente, youTube planta cookies de rastreo en el navegador de tu usuario apenas entra al post, lo cual es un lío por las leyes de privacidad (GDPR).

Con el pluging YouTube ni siquiera sabe que el usuario está viendo el post hasta que este hace clic en el video, es la forma más limpia y ética de gestionar contenido externo.

[Miguel92]

0

Es lo más típico que pase, que arreglas un problema y se genera otro, si me habrá pasado!

Con respecto a la validación MIME, ojo que ahí igualmente puede haber riesgos si solo se valida el encabezado/tipo enviado por el usuario malintencionado. Un archivo PHP puede renombrarse como .jpg, .png, etc y enviar un MIME aparentemente válido. Imagino que también estarás validando desde el servidor:

• MIME real (finfo)
  
• extensión permitida
  
• reescritura del nombre
  
• bloqueo de ejecución en uploads
  
• y posiblemente reprocesando la imagen
  

Entonces, lo que entiendo es que ya no dependerá más de JBBCode y el contenido quedará directamente en HTML generado por CKEditor?

El plugin que había visto va por esa idea de usar una preview y recién cargar el iframe al hacer clic. De hecho usa youtube-nocookie.com, lazy-load y prácticamente no tiene dependencias ni archivos extra raros, y ni siquiera es pesado. 
Por eso te preguntaba más que nada cómo lo habías resuelto vos internamente, porque pensé que quizá estabas usando algo parecido o una implementación propia basada en esa idea. 

Lo puedes ver tranquilamente Debes agradecer para ver el contenido...

[Tronlar]

1

Es lo más típico que pase, que arreglas un problema y se genera otro, si me habrá pasado!

Con respecto a la validación MIME, ojo que ahí igualmente puede haber riesgos si solo se valida el encabezado/tipo enviado por el usuario malintencionado. Un archivo PHP puede renombrarse como .jpg, .png, etc y enviar un MIME aparentemente válido. Imagino que también estarás validando desde el servidor:

• MIME real (finfo)
  
• extensión permitida
  
• reescritura del nombre
  
• bloqueo de ejecución en uploads
  
• y posiblemente reprocesando la imagen
  

Entonces, lo que entiendo es que ya no dependerá más de JBBCode y el contenido quedará directamente en HTML generado por CKEditor?

El plugin que había visto va por esa idea de usar una preview y recién cargar el iframe al hacer clic. De hecho usa youtube-nocookie.com, lazy-load y prácticamente no tiene dependencias ni archivos extra raros, y ni siquiera es pesado. 
Por eso te preguntaba más que nada cómo lo habías resuelto vos internamente, porque pensé que quizá estabas usando algo parecido o una implementación propia basada en esa idea. 

Lo puedes ver tranquilamente 

Le he actualizado todos los validadores y agregagos otros, le implementado un sistema de seguridad por capas que supervisa cada subida en tiempo real.

Inspeccion real del archivo (MIME real con finfo), aunque un archivo se llame imagen.jpg, le pasa un escáner interno (finfo) que lee sus bytes originales, si detecta que en realidad es un script PHP camuflado, el servidor lo rechaza automáticamente antes de que toque el disco.

Se le aplica una identidad aleatoria (Hashing), por seguridad, le he configurado el sistema para que nunca guarde un archivo con su nombre original, le asigno un nombre único y aleatorio mediante un hash, esto lo neutraliza cualquier intento de "Path Traversal" (sobrescribir archivos del sistema) y evita que un atacante sepa cómo llamar a su archivo desde el navegador.

Un lavado profundo (reprocesamiento de imagen),  no mueve los archivos directamente, los vuelve a dibujar, el servidor lee únicamente los datos de color (píxeles), crea un lienzo nuevo y genera una imagen propia desde cero.

Elimina por completo cualquier código malicioso o virus que pudiera estar oculto en los metadatos o comentarios de la foto original.
He asegurado la carpeta de destino con órdenes estrictas para el servidor, le he configurado reglas vía .htaccess o configuración de servidor que prohíben la ejecución de cualquier script en ese directorio.

Si un archivo lograra saltarse los filtros, el servidor lo tratará como una imagen inerte, al ejecutarlo, el sistema lo ignorará por completo, anulando cualquier riesgo de ejecución remota.

Le he creado el código nativo y a medida, es mucho más rápido porque no carga basura innecesaria, y es impenetrable porque procesa 
y limpia cada dato que entra.

[Tronlar]

1

Sistema de logs y rss en la administración

[img]Registrate o inicia tu sesión para ver este contenido[/img]

[img]Registrate o inicia tu sesión para ver este contenido[/img]

[Tronlar]

0

Hola, le acabo de terminar de cambiar de MD5 a password_hash que es lo que me faltaba, la tengo en el hosting ya haciéndole pruebas y funciona perfecta, va un montón de rápida con todo el cambio que le he hecho, le voy a revisar los archivos por si he dejado alguna basura, y subo la demo y el script para descargar este fin de semana.

Antiguo Método (MD5)

Característica:

Longitud del Hash --> Siempre 32 caracteres (fijo).

Velocidad de procesamiento --> Ultra rápido (Esto hoy en día es una debilidad).

Misma contraseña, mismo hash --> Sí. "123456" siempre da e10adc3949ba59...

Protección contra Rainbow Tables --> Ninguna. Existen bases de datos gigantes con hashes MD5 ya resueltos.

Resistencia a Fuerza Bruta --> Muy baja. Una computadora estándar puede probar miles de millones de hashes por segundo.

Estándar Actual --> Obsoleto y roto. Prohibido para seguridad desde hace años.



Nuevo Método (password_hash)

Característica:

Longitud del Hash --> Entre 60 y 255 caracteres (variable/futuro).

Velocidad de procesamiento --> Lento por diseño (Ajustable para ralentizar ataques).

Misma contraseña, mismo hash --> No. Cada vez que se encripta genera un hash único.

Protección contra Rainbow Tables --> Total. Al ser dinámico, las tablas de hackeo no sirven para nada.

Resistencia a Fuerza Bruta --> Muy alta. Requiere un alto uso de CPU/Memoria por cada intento, frenando en seco a los atacantes.

Estándar Actual --> Estándar de la industria. Recomendado por expertos de seguridad hoy en día.