Test Foro de elhacker.net SMF 2.1

Cita de: 3n31ch en  5 Agosto 2021, 16:24 PM
Comparto la idea contigo (soy muy de rehacer las cosas desde 0 cuando no me gusta algo). El tema está que que quizás para minimizar la resistencia al cambio se puede optar por una fase intermedia. Pasar de html4 a html5 tampoco es una locura, y por algo se parte. Arreglar un detallito como el menú absolute de la warzone es algo, infimo, pero es algo. Otra forma es en efecto, actualizar todo pero mantener el diseño.

La idea realmente no es empezar todo desde "cero". El sitio web debería ser el sitio web de ahora. No es remplazar el sitio web por otro vaya. Sin embargo, el diseño de la web va de la mano con el markup de la web. El markup de la web va de la mano con el backend de la web. Así se desencadenan cambios a través de todo el sitio web. Por eso uno de los primeros issues que abrí fue este:

Cita de: 3n31ch en  5 Agosto 2021, 16:24 PM
No me mal entiendas, evidentemente sé que es poner un parche sobre una hemorragia, pero bueno, supongo que peor es nada. En mas de una ocasión agradecería que la web tuviera una versión dark bien hecho para que mis ojos no estallaran por las noches.

Eh, yo creo que el foro y el sitio web están así por tener esa mentalidad. Se rompe algo, un pequeño parche aquí. Se rompe otra cosa, otro parche por aquí y al final acabas con un sistema de tuberías todo parcheado. ¿Funciona? Si... pero olvídate de incrementar la presión de agua porque te cargas todo.

La esencia de la web es lo que debe perdurar y en mi opinión su diseño no es parte esencial de la web. Esta bien dejar una versión archivada por ahí como contexto histórico pero nada más. Pero como dije, esa es solo mi opinión.

Cita de: 3n31ch en  5 Agosto 2021, 14:20 PM
Entiendo que un rediseño completo puede ser complejo, pero a lo que voy es mucho mas pequeño. Mantener el diseño e incluso mantener las tecnologías back-end. No obstante, retocar el front-end. No me refiero a aplicar react, angular o vue, sino mas bien, html5 y css3.

El front-end de la web y el warzone tiene como unos 15 años sin tocarse. Lo puedes revisar tu si quieres, solo es irse al sitio en cuestión, click derecho, inspeccionar código fuente y verás de lo que estamos hablando...

Simplemente, no tiene caso parchear el front-end como está ahora. Quizás una o dos cosas puntuales podríamos corregir pero realmente lo que hace falta es un rediseño completo. La web, como diría Indiana Jones, pertenece a un museo.

Ahora, si podemos trabajar la web sin un framework front-end pero realmente que ganamos con esto? React es una librería muy sencilla en mi opinión. ¿Se puede complicar el código? Claro... pero eso no es culpa de React.

Cita de: 3n31ch en  5 Agosto 2021, 14:20 PMA) Si, eso es un problema. (pero por lo que explicas pareciera que estarías hasta dispuesto a hacerlo tu solo hahahaa)

Realmente no estaría dispuesto porque mi intención no sería de crear un sitio nuevo y llamarle "elhacker.net". Si no es desde un punto de vista comunitario tendría que ser desde el punto de vista del creador. Como individuo yo no figuro.

Cita de: 3n31ch en  5 Agosto 2021, 14:20 PMB) Para eso se pueden aplicar otro medios que no sean github: slack, jira, el propio sitio web.

Si, estaba contemplando usar un issue tracker publico. Slack no tiene mucho sentido en mi opinión. Tenemos un canal de Telegram para discutir estas cosas entre los colaboradores pero las cosas se pierden muy fácilmente. La web no tiene una plataforma de comunicación, podríamos usar el foro pero es más de lo mismo, no es ideal. Encima tenemos el problema que lo que acabe en el foro no es visible desde github y viceversa. Jira cuesta dinero a menos que nos limitemos a 10 colaboradores. No es ideal pero pues es una opción. Trello también era una consideración. En fin, hay opciones pero nada es ideal.

Cita de: 3n31ch en  5 Agosto 2021, 14:20 PMC) Entiendo (o quiero entender) que si el back y el front no están separados una cosa sería la web, otra el foro y otra los retos de la warzone. (incluso cada retor podría tener su repo).

La idea inicial era separar el backend del frontend precisamente porque podríamos dejar el frontend público de forma que no había necesidad de exponer el código backend al público. Así, si alguien ve un error puede crear un PR y si le damos el visto bueno se incorpora inmediatamente al sitio web.

Pero mantener los repositorios y sus issues de esta forma se vuelve más complicado.

Cita de: 3n31ch en  5 Agosto 2021, 14:20 PMD) Me remito a lo que dije anteriormente. Para iniciar no es necesario modificar las tecnologías, solo optimizar lo que hay.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Cita de: 3n31ch en  5 Agosto 2021, 14:20 PMSaludos,

Modifico: Se me olvido mencionar, tu diseño está genial.

Gracias, por desgracia solo la cabecera esta "bien". El layout necesita mucho trabajo más.

Cita de: 3n31ch en  5 Agosto 2021, 05:41 AMHola, tenía una duda sobre la website de elhacker.net. ¿En algún momento se han planteado la posibilidad de hacerle alguna pequeña mantención de código o upgrade de algún tipo?. Quiero decir, entiendo la estética del foro y de la pagina, de hecho resulta hasta nostálgico el mantener el mismo diseño y todo eso, pero a nivel de código hay algunas cosas que se podrían mejorar.

Cita de: 3n31ch en  5 Agosto 2021, 05:41 AMNo sé hasta que punto sería viable (o seguro) subir ese código a algún repo (incluso privado, al que solo tengan acceso miembros del staff) y poder hacer pull request o algo que permita optimizar o mejorar esos detallitos de forma paulatina y con la ayuda de la propia comunidad.

Yo creo que varias veces han salido propuestas así. De momento tenemos acceso al código del warzone, de la web y del foro unos 3 o 4 individuos. El código del foro se utiliza para darle mantenimiento solamente, cuando sale un problema puntual.

En cuanto al warzone y a la web, los dos representan un reto significante. Yo estaba trabajando sobre el sitio web hace un año ya:



Realmente estaba configurando el repositorio y el layout que cree no es más que una propuesta.

El problema en sí es que no hay dirección. Por mi parte yo podría hacer lo que quisiera con el nuevo repositorio y si por mi fuera yo eliminaba muchas cosas del sitio, hacer los cambios que yo quisiera y de la forma que yo quisiera. Pero obviamente no es mi sitio web.

Como se que no todos en el foro tienen acceso al código o incluso a la organización de github de elhacker.net (al cual son libres de unirse los miembros del staff realmente, así que si pueden...) lo he puesto también en un foro visible al staff. Muy poca gente han dado su opinión acerca del tema. Y no es que se buscara una opinión técnica (ni tampoco es que no hubiéramos querido una). Ni siquiera confirmación de que les pareciera bien (o mal).

El warzone de una o otra forma también esta ligado con la web. Y es que hay BASTANTE código correspondiente al warzone. Muchos archivos duplicados y cosas por el estilo. Pero en esencia, tenemos los mismos problemas que con el rediseño de la web. Es difícil realizar cambios si no estamos de acuerdo en que cambios son los pertinentes. Nuevamente, podríamos hacer los cambios que quisiéramos sobre el repositorio... pero si estos cambios no terminan gustando una vez que demos por completado todo pues tocaría reescribir los cambios. Vamos que no tiene sentido escribir código para que al final vengan diciendo que tienes que reescribirlo. Si en cambio, recibiéramos la dirección adecuada podríamos evitar estar reescribiendo el código frecuentemente.

Otros problemas:

A) Somos muy pocos involucrados en el rediseño.
B) Github tiene sus limitaciones. Por ejemplo, a mi me gustaría poder exponer los problemas y metas que los repositorios con más miembros del foro sin tener que darles permiso de lectura sobre el código.
C) Problemas organizaciones (que va en que repositorio)
D) No hemos concluido que stack de tecnologías a utilizar (yo prefiero node.js, otros prefieren PHP, docker?, bases de datos? framework?).

Cita de: WHK en  3 Agosto 2021, 22:27 PM
Yo no apostaría por ningún sistema hecho en php porque siempre vamos a tener el problema del uso de recursos desmedidos cuando vengan ataques ddos, php se hecha a memoria todo el framework del sistema cms por cada petición http, en cambio un lenguaje ejecutado en memoria como node, java o ruby consumen únicamente las funcionalidades necesarias y no tiene que cargar todo el core por cada petición, esto ahorra mucha memoria ram y hace que todo ande muchisimo mas rápido y no depende de la velocidad del uso de disco.

Es más bien un problema de arquitectura realmente, no es un problema especifico con PHP. Y realmente no se que tan escalable sea Discourse si esa es una consideración. Por ejemplo, ahora mismo estoy corriendo Discourse dentro de un contenedor e inspeccionando el contenedor te das cuenta que TODO está dentro del contenedor. Postgress, Rail, Nginx, Redis, etc. Así que por lo menos el contenedor que tengo no es escalable. Ahora no veo razón por la cual estos no puedan estar en sus contenedores correspondientes...

Al final, da lo mismo si remplazamos RoR con PHP o NodeJS (excepto quizás por websockets y aún así). Es más importante ver como diseñaron el foro antes que cualquier otra cosa.

He estado jugando un poco con Discourse para ver que tan fácil podemos adoptarlo, que es nuevo, que es diferente, etc. Hasta ahora en general, ha sido algo sencillo manejar el software. Su instalación fue un poco complicada casi estrictamente por el método de instalación que elegí. De entrada necesitas tener un dominio y un servidor de correo. Tengo mi dominio por supuesto pero el servidor de correo no es exactamente algo que se utilice para esto aunque no tuve problemas para configurarlo. Estoy utilizando WSL2 con docker para instalar discourse y su script de instalación comprueba que el servidor sea accesible por el dominio dado. Un autentico dolor de cabeza porque el script tiene un bug que he "tenido" que corregir. Sin embargo, la ip de mis contenedores de docker no es la misma que la ip de mi instancia WSL2 entonces obviamente la prueba no va a funcionar. Así que después de arreglar el susodicho error ahora resulta que tengo que optar fuera de este chequeo porque simplemente no iba a funcionar. Por suerte saltarse el chequeo es muy fácil. La herramienta de configuración procede, los contenedores se crean exitosamente pero ahora nginx empieza a fallar porque no tiene un certificado de SSL. El mismo contenedor puede crear el certificado por tí con Lets Encrypt pero para eso necesito hacer el portfowarding correcto del puerto 80 a mi equipo. Mi proveedor de internet se queja porque ellos usan ese puerto para su servicio de cable pero me deja. Nginx ahora arranca pero no puedo acceder al sitio por el puerto 80, la aplicación regresa 301s hacia https (puerto 443). Mi proveedor de internet ahora si que no me deja usar ese puerto por las mismas razones. Discourse no me deja cambiar el puerto de la aplicación (en mi opinión, una tontería pero es lo que hay). Encontré una forma de deshabilitar SSL en los foros de discourse (realmente la encontré yo porque lo que dicen ellos es "simplemente desactivala en este archivo" *surprised pikachu*). Y por problemas con mi proveedor de internet al final tuve que acabar poniendo una entrada en /etc/hosts... pero finalmente logre instalar discourse.  Instalar discourse no ha sido sencillo, es cierto, pero yo también tengo la culpa por no usar un stack normal (una vm con algún proveedor).

Configurar discourse ha sido relativamente sencillo pero si me he topado con algunos problemas. Antes quiero mostrar algunas de las cosas que he visto que me han agradado bastante. Primero, los onebox por ejemplo el de twitter:



Lo único que hecho es copiar el link de twitter y listo me arma todo el html por mi.

Fiddles de Codepen, aquí uno que tenía de hace mucho tiempo:



Podemos hacerlo con cualquier link también, pero ciertamente no es lo mismo. Debe haber servicios con sandboxs para VMs o así (por ejemplo para correr node.js).

Después su sistema para crear posts... Digamos que quiero contestar citas en especifico, incluso a traves de varios temas...



Con lo difícil que es recrear citas para un solo mensaje y este hace mucho más. Y la ventana a la derecha también tiene una vista previa (lastima que no haya hecho el gif bien).

Tiene un sistema de likes que es precisamente como lo querían para el foro (sin poder dar dislike pero sin remover el like creo). No he probado extensivamente las funcionalidades de moderación pero tiene unas cosas interesantes. Por ejemplo, hay un registro visible de una acción de moderación. Es decir, si cierro un tema, dice ahí que fuí yo el que ha cerrado el tema.



Como dicen en mis tierras ya no hay más que a chuchita la bolsearon. La moderación es pública y cada quien puede saber quien cerro o borro algún tema. Es posible dejar un mensaje de porque se llevo acabo la acción de moderación. Por otro lado, también se pueden ocultar estas acciones a miembros que no son moderadores.

Las cosas que no me han gustado hasta ahora:

1) El índice no es muy bonito que digamos. Aquí unas cuantas tomas dependiendo de como se muestren las categorías:





Y bueno, yo intente darle una apariencia parecida al foro en cuanto a colores y así (no mucho realmente). Me imagino que tocará leer más acerca de como crear un tema en discourse porque realmente lo único que hice fue modificar una paleta de colores. Yo creo que debe ser posible tener un índice mucho más vistoso.

2) La traducción no es la mejor y hay muchas partes que no están traducidas. Por ejemplo, los menus de administración tienen todas las configuraciones en ingles (las descripciones por lo menos están en español). Alguna que otra palabra que está mal traducida (por ejemplo, "uploads" son "subidos"). No creo que sea mucho problema.

3) Cuando estaba configurando las categorías, llego un momento en el que no se como termine creando dos categorías del mismo nombre y una vino siendo una subcategoría de la otra. Tenía "Dudas Generales" dentro de "Dudas Generales". No me dejaba borrar ninguna de las dos categorías hasta que me di cuenta de mi error. Perdí como unos 10 minutos aquí y realmente no encontré ayuda en ninguna parte de lo que estaba pasando.

4) Cuando estaba configurando las categorias, configure una url con una ñ. No pude editar la categoría ni borrarla a la hora de tratar de acceder a su menu correspondiente. Decía que no existía. Tuve que meterme a la aplicación desde una terminal para poder reconfigurar la url para quitar la ñ. Batalle un poco en encontrar la razón y la explicación no es muy intuitiva fuera de que tienes que correr código en la terminal (tienes que usar ruby).

5) Estaba intentando configurar mi perfil para usar un link de imgur para mi perfil. Simplemente no he podido hacer eso. Como tengo entendido discourse te provee un avatar o tu tienes que subir al sistema tu propio avatar. No puedes enlazarlo con un sistema externo como imgur o similar.

6) Estaba queriendo revisar los logs de errores y me sale una pantalla donde efectivamente hay errores pero realmente no se si lo que se muestran son errores al tratar de acceder a los logs o si son realmente logs de errores. Como no sigue el mismo tema que las demas partes del sitio yo quiero creer que en efecto, tratar de acceder a los logs de errores provoca un error (pero no estoy muy seguro de eso).

Me gustaría poder compartir esta instancia con ustedes pero por desgracia mi proveedor de internet simplemente no me dejará mostrar nada por el puerto 443. Quizás alguien quiera compartir una VM con unos  2 o 4GB de RAM para probar. Creo que también podría probar con ngrok... en fin, si están muy interesados veré por ahí que puedo hacer. Por lo pronto si tienen alguna pregunta acerca de esta instancia de discourse me pueden preguntar por aquí.

Justo después que autentificas y antes de tocar cualquier cosa de la sesión de preferencia.

Eh, si tu destruyes la sesión te genera una nueva sesión si vuelves a visitar el sitio. A menos que el visitante no vuelva a visitar el sitio después de haber cerrado la sesión. Entonces si tu cierras la sesión por ejemplo a las 2 de la tarde, vuelves a visitar el sitio inmediatamente (se genera una sesión nueva) y te autentificas al día siguiente a las 12... la cookie expira a las 2 por lo que te "sacaría" del sitio (la sesión probablemente siga ahí). Dando la apariencia que solo ha durado 2 horas.

Si quieres puedes usar:


session_regenerate_id();

Una vez que te hayas autentificado. De esta forma la cookie también debería regenerarse para obtener otras 12 horas.

Edit: Realmente no se genera una sesión después de destruirse una vez que revisites el sitio, aquí lo que me refiero es que muy probablemente tengas session_start en varios archivos que estos a su vez generan una sesión nueva.

El primer foro no creo que sea discourse. El foro de xda-developers es XenForo. Migraron de vBulletin a XenForo el año pasado. Pero por lo menos el tema se nota que si está muy tocado.

No he podido probar Discourse todavía (fuera del demo que tienen que no permiten hacer cambios en la administración) pero si pude probar XenForo. Solo que no me han dejado ponerlo en español ni instalar ningún addon (porque será? ). Siguen con BBCode pero el editor se ve mucho mejor.

También está Flarum. No lo he probado muy bien. Este es más parecido a Discourse pero está hecho en PHP.

Por cierto el sistema para publicar en Discourse y Flarum es muy innovador realmente. Por ejemplo puedo empezar a escribir una respuesta en un tema y puedo salirme del tema, abrir otro tema, citar a alguien más seleccionando el texto con el cursor y sigo escribiendo el mensaje para el tema inicial.

Cita de: Serapis en  1 Agosto 2021, 18:03 PM
Creo que sería aceptable, hacer x día un backup del foro, trabajar sobre dicho backup para la adaptación de Discourse y ponerlo a prueba.

Esto es, darles una dirección accesible de forma provisional donde probarlo.

Por lo menos para probar podemos poner un demo para los colaboradores y demás, pero poder usar un backup para probar la herramienta de migración de SMF a discourse sería lo ideal.

Cita de: Serapis en  1 Agosto 2021, 18:03 PMEn lo personal me interesa la compatibilidad con navegadores y S.O. viejos. Yo entro al foro con un viejo tablet que calza un win-XP, pues tanto el otro PC como el portátil son de uso exclusivo para el trabajo, están monitorizados por la empresa y aunque aceptan que el portátil me lo traiga a casa (para trabajar desde casa fuera de horarios), no aceptan ningún otro uso. Y no estoy por la labor de comprarme otro aparato al menos hasta el próximo año o así... en fin que tiro de este viejo tablet-pc para el ocio en casa.
Si no es compatible, me limita el acceso, e imagino que habrá mucha gente en situacion similar, quizás con diferentes razones, pero tirando de un equipo viejo para el ocio...

Ese podría ser un problema aunque no he visto bien que tantas funcionalidades son compatibles con navegadores y sistemas antiguos. La última versión de Chrome para Windows XP fue liberada en el 2016, la última versión para Firefox fue en el 2018... Y como yo tengo entendido, ambos navegadores han pasado por varias actualizaciones de seguridad importantes.

Debe funcionar pero a que grado difícil de saber. Es difícil ofrecer una solución moderna cuando la gente todavía depende de tecnologías obsoletas. Y tenemos demasiados bots para decir que tantos afectados tenemos aunque yo creo que deben tener UAs más modernos que Windows XP por lo menos.

Cita de: Randomize en 30 Julio 2021, 18:34 PM
¿Y qué tal un SMF a su versión actual (que debe ser la 2.8 o la 3.2, no las sigo)?

Las dos ramas actuales de SMF son 2.0.x y 2.1.x. Yo creo que ninguna actualización de SMF ofrece una experiencia moderna. Desde el punto de vista del usuario, se verán dos o tres nuevas funcionalidades importantes. Y mientras el software sería más reciente, no está exactamente hecho a estándares modernos (es batallar más para modernizar otros sistemas como la web y el blog).

Claro que el stack de Discourse no es exactamente moderno y si me preocuparía un poco por RoR porque no se si vaya a desparecer en un futuro mientras que stacks en Node o PHP dudo mucho que corran un peligro.

Aquí un resumen de sus funcionalidades

Los puntos que yo veo a favor:

1) Se nota que está pensado para dar una mejor experiencia al usuario (cosa que el foro necesita).
2) Tiene una arquitectura decente (el frontend se puede separar del backend)
3) Mucha más flexibilidad para poder integrar el foro con otros de los sistemas.
4) Soporta Markdown y BBCode.
5) Tiene un sistema de migración para SMF2 (del cual creo que ya hemos probado que si podemos migrar)
6) Tiene un sistema de moderación mucho más elaborado.

Los puntos en contra:

1) Usa Ruby on Rails.

No se cuantos de los devs aquí hayan usado RoR en un pasado. Por mi parte, yo he tenido muy poca experiencia con Ruby mucho menos con RoR. Así que sería algo difícil de dar mantenimiento sin empezar a aprender el lenguaje y la plataforma.

2) Tenemos etiquetas BBCode que pueden no estar disponibles en el core o en otros plugins.

Habría que probar que se puede hacer al respecto. Alguna extensión quizás o simplemente eliminarlas de los posts :/

3) Usa Ember.js de FrontEnd

No es que este en contra de Ember.js pero lo cierto es que es muy viejo. No he trabajado con el personalmente pero no me molestaría aprenderlo. En cuanto darle un tema personalizado no creo que eso sea un gran problema... al final solo es CSS.

4) No es un foro convencional.

Por un lado es bueno que sea así porque los foros como los conocemos se están extinguiendo. Por otro lado puede alienar a los usuarios del foro que esperan un foro tradicional. Moderadores y Administradores incluidos.