El otro día me encontré con un sitio hecho en joomla 2.5 que por tema de compatilibidad y recursos aun no estaba actualizado a joomla 3. El problema era que no funcionaba recaptcha en los formularios de contacto. Cual fue la solución? Adaptar el plugin oficial recaptcha de joomla 2.5 a recaptcha v3. Bajé el plugin, instalé via composer la librería recaptcha v3 y adapté el plugin.

Si tenés un sitio en joomla 2.5 y no te funciona recaptcha, probá este plugin, es el mismo que el oficial, solo lo adapté para usar la libreria recaptcha v3. El código está para ver y descargar en github: Plugin recaptcha v3 para joomla 2.5.

Cómo se instala? Se bajan el repositorio (en zip o con git clone), toman todos los archivos y carpetas (menos .git) y los comprimen en un zip. Instalan el zip como cualquier otro plugin desde el gestor de instalación de joomla, configuran el plugin recaptchaj25, lo habilitan y listo.

Esto es un recordatorio de cómo cambiar de prefork a worker en apache 2.2. Básicamente se optimiza el usuario de memoria ram y cpu pasando a worker.

Edit: /etc/sysconfig/httpd

Uncomment:

HTTPD=/usr/sbin/httpd.worker

Restart, voila!

Saber si está funcionando worker ejecutar este comando y luego ver que diga "worker" y no"prefork".

$ apachectl -V | grep -i 'version\|mpm'

Antes que nada decir que esto está probado sobre un Prestashop 1.6 en desarrollo. Se clonó el sitio de producción y trabajó sobre el clon. Nunca realizar esto sobre un sitio en producción, siempre sobre un sitio de desarrollo (en este caso el clon).

Tenía en principio un Prestashop 1.5 que quería actualizar a la útlima versión de Prestashop (1.7.2.0). Queríamos realizar este proceso utilizando el módulo 1-Click Upgrade para que este haga la actualización de los archivos y la base de datos correctamente. Los pasos a seguir fueron:

• 1. Actualizar Prestashop 1.5 a 1.6. Este proceso se realizó correctamente con 1-click upgrade.
• 2. Intenté actualizar a Prestashop 1.7 desde PS1.6, pero falló. Intenté de diferentes manera: deshabilitando módulos, agregando mas tiempo de ejecución a PHP, cambiando la config del módulo, etc. pero no hubo caso.
• 3. Para poder actualizar tuve que modificar el módulo 1-Click Upgrade 1.6.7 para que no haga backup de la base de datos y de los archivos. Al estar trabajando sobre un clon, esto no hace falta (por eso la importancia de trabajar sobre un sitio de desarrollo). Una vez con la modificación, inicié la actualización, salteó los pasos de backup y actualizó correctamente.
• 4. Limpiar caché de Prestashop 1.7 y limpiar el historial/cache del navegador para que tomé bien los css y js del nuevo template del admin.

El archivo a modificar del módulo es ruta-a-mi-tienda/modules/autoupgrade/AdminSelfUpgrade.php

La funciónes a modificar son: ajaxProcessBackupDB() y ajaxProcessBackupFiles. Linea #3662 aprox. Reemplazamos ajaxProcessBackupDB y ajaxProcessBackupFiles por:

public function ajaxProcessBackupDb()
{   
        unset($this->nextParams['backup_loop_limit']);
        unset($this->nextParams['backup_lines']);
        unset($this->nextParams['backup_table']);
        $this->stepDone = true;
        // reset dbStep at the end of this step
        $this->nextParams['dbStep'] = 0;

        $this->next_desc = sprintf($this->l('Database backup done in filename %s. Now upgrading files...'), $this->backupName);
        $this->next = 'upgradeFiles';
        return true;
}

public function ajaxProcessBackupFiles()
{
        $this->stepDone = true;
        $this->next = 'backupDb';
        $this->next_desc = $this->l('All files saved. Now backing up database.');
        return true;
}

Con esta modificación se evitan los backups de archivos y base de datos y 1-click upgrade actualiza bien a Prestashop 1.7 en sitios grandes.

Es recomendable una vez que se está en Prestashop 1.7 actualizar el módulo porque estas modificaciones quedarían obsoletas (a menos que el módulo en 1.7 también falle).
No hice un debugeo a fondo, pero sospecho que falla por la cantidad de archivos a copiar. La tienda tiene mas de 1000 productos, con mas 1 una foto por producto, además hay 5 tipos de imágenes en Prestashop, por lo tanto existen un total aprox. de 10.000 archivos de imágenes como mínimo. Muchisimas imágenes para hacer backup, sospecho que por ahí viene el problema y efectivamente salteando el paso del backup el módulo funciona. No hizo falta debugear más porque la actualización a Prestashop 1.7 con 1-click upgrade funcionó.

Es una lástima que el equipo de Prestashop no deje hacer la actualización paso por paso, de esta manera se resolvería el problema sin tener que modificar el módulo. Es claro que no tienen ganas de hacer esta modificación para que tengas que comprar un módulo de migración...

¿Tenés la versión de Firefox Quantum 57 con este error?¿El inspector de Firefox no te funciona? ¿El inspector te tarda mas de 10 segundos en responder? ¿Abris la consola de desarrollo, intentas inspeccionar y tarde mucho en responder?

La solución a mi problema fue:

• 1. Abrir una pestaña con la url: "about:config" (sin las comillas).
• 2. Buscar la variables: "devtools.debugger.source-maps-enabled" (sin las comillas).
• 3. Setearla en "false".
• 4. Listo

En caso de no haber solucionado tu problema podes chequear el thread del problema aca dónde presentan otras posibles soluciones: Ir al thread del problema

Les comparto en esta ocacisón un tutorial muy completo que encontré sobre como configurar los registros SPF para los mails.

La página en cuestión es: Neeonez

La manera de bloquear ip por iptables, o rango de ip, es con los siguientes comandos:

iptables -A INPUT -s 180.76.15.0/24 -j LOG --log-prefix "IP DROP SPOOF A:"

iptables -A INPUT -s 180.76.15.0/24 -j DROP

El primer comando lo que hace es generar el log al bloquear la ip o rango de ip, mientras que el segundo es el que bloquea la/s ip.

En este ejemplo bloqueamos el rango de ip pertenecientes a Baiduspider.

Lista con ejemplos de uso del comando find, en ingles, pero se entiende perfecto: Useful Linux find Commands.

Una vez mas como comentaba en el post me encontre con que un usuario habia subido imagenes de gran tamaño por lo tanto cuando el Zoo (Joomla) intentaba redimensionar daba error de exceso de memoria. Se me vinieron 2 soluciones inmediatamente a la mente:

• 1. Aumentar la memoria ram de la cuenta.
• 2. Redimensionar las imagenes

Sin dudar por se un servidor que comparten varias cuentas, fui por la segunda opción. Cómo lo hice? Busqué algun comando que redimensione imagenes que sean mayores a un ancho mayor que 1280px (elegí este ancho porque era lo maximo que se mostraba en la web, podria haber sido 800px, 2000px, etc.). El comando que encontre fue:

# mogrify -resize '1280x960>' *.jpg

El comando anterior redimensiona (manteniendo la relacion de aspeco) las imagenes que tengan un ancho mayor que 1280px o 960px de alto a un ancho de 1280px o a un alto de 960px.

Encontre este artículo (en ingles) que nos enseña como funciona angular a nivel código, desde las entrañas. Me parecio muy practico para poder entender los conceptos que encierra el framework y poder optimizar mejor el código de nuestras apps en angular js

El enlace en cuestion: ¿Cómo funciona Angular JS a nivel código?

Me vi en la necesidad de buscar archivos php vacios. Buscando como encontrar esos archivos vacios dentro de carpetas y sus respectivas subcarpetas di con lo siguiente:

find PATH -empty -type f -name "*.php"

Dónde PATH es la ruta de la carpeta. Por ejemplo /home/pepito/, quedando el comando asi:

find /home/pepito/ -empty -type f -name "*.php"

Si por alguna razon quisieramos buscar por ejemplo imagenes jpg vacias, podriamos cambiar el comando por: