Definición de regla de Content Security Policy e inserción en el header de cada página para Moodle para los archivos media, fuentes e imágenes.
Fomentemos la accesibilidad web para llegar a un mayor público objetivo
Os dejo aquí el PDF de la charla que dí en la WordCamp de Sevilla 2023 sobre Magento y sus características, frente a WooCommerce.
Magento WordCamp Sevilla 2023
Este es un error muy difícil de detectar, a no ser que te haya pasado ya alguna vez. La casuística es simple: un día dejas de poder subir imágenes de productos. Por más que intentas poner una imagen más pequeña, y después de comprobar que hay espacio en disco, nada, no hay forma de subir la imagen. Ninguna. A ningún producto. ¿Qué ocurre y cómo podemos arreglarlo?
Lo primero, como siempre, es ir a var/log/system.log y ver qué error da cuando intenta insertar la imagen. Una vez hayas comprobado que no hay ningún error que te diga a las claras que no puede subir una imagen, es el momento de mirar si tienes este error concretamente:
Session size of 294584 exceeded allowed session max size of 256000.
Si lo tienes (las cifras pueden variar), entonces esta es la solución:
Entra en la base de datos y mira el tamaño de la tabla catalog_product_entity_varchar, que es la encargada de relacionar producto con ruta de imagen. Y sobretodo, mira el tamaño del campo value_id. Lo más seguro es que tengas un índice tan alto que necesites pasarlo a big_int. Si es así, ejecutando esta instrucción en la base de datos, arreglarás fácilmente el error:
ALTER TABLE `catalog_product_entity_varchar` CHANGE `value_id` `value_id` BIGINT NOT NULL AUTO_INCREMENT COMMENT 'Value ID';
La configuración de Elasticsearch puede modificarse si el error de No alive clusters aparece, dejando de estar disponible el servicio de Elasticsearch
Nuestro Magento puede responder por varias URLs a la petición de la página de Home, de esta forma:
– https://dominio.com
– https://dominio.com/
– https://dominio.com/index.php
… y así con varias más
La solución está en añadir o bien entre las etiquetas
<link rel="canonical" src="https://dominio.com/" src_type="url" />
El tema de hoy es un problema de configuración de Postfix. Al configurar un servidor de correo, puedes llevarte la sorporesa de que se envían los correos al exterior bien, se reciben bien, puedes enviar un correo a alguien de tu mismo dominio, pero si pones dos destinatarios o más de tu propio dominio, el correo no llega a sus destinatarios.
Si haces un mailq, verás que la cola de correos tiene retenido ese correo con múltiples destinatarios de tu propio dominio, y no hay forma de que salga. Este comportamiento se debe a que en el archivo main.cf de Postfix, debes incluir esta línea, para que esos correos lleguen correctamente a sus destinatarios:
dovecot_destination_recipient_limit = 1
Listo. Simplemente con esta línea, esos correos llegarán correctamente. No olvides hacer un restart del servicio de Postfix para que coja el cambio en la configuración. Y si ves que la cola sigue sin moverse, haz un
postqueue -f
para forzar que los correos se vuelvan a intentar enviar.
Hasta ahora las reglas de envío en las plataformas de comercio electrónico han sido muy simples, pero con el encarecimiento del combustible, es cierto que los clientes han empezado a necesitar y demandar cada vez reglas más complejas para que el envío gratuito sea una opción válida tanto para el comprador como para el vendedor.
En Magento 2, si bien hay algunas extensiones para la creación de reglas de envío, no teníamos una Free Shipping Bar o Barra para el aviso de envío gratis que se ajuste a esas reglas que se salen de lo simple, pero los chicos de WebbyTroops tienen la solución, y creo que es el producto que se ajusta mejor a día de hoy a las necesidades de casi cualquier empresa que tenga una plataforma Magento 2:
Desde Esencial Sistemas recomendamos estos dos productos como la solución más económica y completa para un problema difícil de solventar actualmente. Además, su soporte es muy bueno (en inglés) y os ayudarán en lo que necesitéis.
Siguiendo la estela de los dos últimos artículos sobre securización de plataformas, en esta ocasión traemos un truco apuntado por uno de nuestros colaboradores, Fernando, que nos explica que para securizar la API de WordPress y evitar que la usen sin tener un acceso con usuario y contraseña, hay que añadir este filtro en functions.php del tema. De esta manera, podremos abrir nuestra API y usarla, pero no tendremos efectos indeseados por no tenerla securizada.
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_not_logged_in',
'No no no.',
array( 'status' => 401 )
);
}
return $result;
});
Como decíamos en el artículo sobre ocultar la versión de la plataforma de Magento 2, una medida de seguridad básica en las plataformas Open Source es ocultar la versión de la misma, con el objeto de que no sea posible explotar sus vulnerabilidades. En WordPress esto se consigue de diversas maneras, desde el uso de un plugin, como Wordfence o similar, a insertar en el archivo de functions.php una instrucción como esta:
remove_action('wp_head', 'wp_generator')
o una función como esta otra:
function remove_version_info() {
return '';
}
add_filter('the_generator', 'remove_version_info');
En WordPress es muy sencillo ver la versión de nuestra plataforma, simplemente chequeando nuestro código fuente, o a través del feed de RSS, o incluso, leyendo el archivo readme.html por lo que es una plataforma especialmente sensible a los ataques por vulnerabilidades en cada versión.
Una medida de seguridad básica en las plataformas Open Source es ocultar la versión de la misma, con el objeto de que no sea posible explotar sus vulnerabilidades. En Magento 2 conseguimos esto con una instrucción muy simple:
php bin/magento module:disable Magento_Version
Con esto conseguimos que si hacemos una llamada por navegador a
http://mi-tienda.com/magento_version
en lugar de devolvernos el número de versión de nuestro Magento 2, nos devuelva un error 404 en lugar de (por ejemplo)
Magento/2.4 (Community)
Esto realmente es un bug que debería haberse corregido ya, pero que misteriosamente sigue vigente en Magento 2.4. Cuando al grabar tus datos como administrador, da este mensaje de error:
«Invalid header value detected»
es porque estás escribiendo en tu nombre y/o apellidos una vocal tildada o una ñ o algún carácter parecido. En muchos sitios te dirán que toques código, sobreescribas core de Magento… lo más fácil y que funciona a la primera es ir al archivo di.xml (en app/etc) y añadir esta regla:
utf-8
Este no es un error tan común como parece, pero a la hora de desarrollar, puede ser algo fastidioso si te encuentras con él. Cuando en el momento de compilación, ésta se detiene y devuelve un mensaje parecido a este:
Errors during compilation:
Company\Extension\Model\Config\Structure\XXXX
Incompatible argument type: Required type: string. Actual type: array; File:
Y a continuación, indica el archivo donde se produce.
Lo mismo que pone Incompatible argument type: Required type: string. Actual type: array; File:, puede poner otros tipos. Lo importante en este caso es tener claro cuál es el tipo actual y el que debería estar.
La solución a este error es simple: editáis el archivo que nos indica, que tendrá un __construct. En él habrá unas líneas justo antes del __construct, que serán más o menos así:
/**
* Constructor
*
* @param \Magento\Framework\Config\FileResolverInterface $fileResolver
* @param Converter $converter
* @param \Magento\Config\Model\Config\SchemaLocator $schemaLocator
* @param \Magento\Framework\Config\ValidationStateInterface $validationState
* @param CompilerInterface $compiler
* @param \Magento\Framework\Module\Dir\Reader $dirReader
* @param array $idAttributes
* @param string $domDocumentClass
* @param string $defaultScope
*/
Y después, aparecerá el constructor en sí
public function __construct(
\Magento\Framework\Config\FileResolverInterface $fileResolver,
\Magento\Config\Model\Config\Structure\Converter $converter,
\Magento\Config\Model\Config\SchemaLocator $schemaLocator,
\Magento\Framework\Config\ValidationStateInterface $validationState,
CompilerInterface $compiler,
\Magento\Framework\Module\Dir\Reader $dirReader,
$fileName = ‘system.xml’,
$idAttributes = [],
$domDocumentClass = ‘Magento\Framework\Config\Dom’,
$defaultScope = ‘global’
)
En mi caso , faltaba la línea * @param string $fileName, por lo que generaba ese error. Añadiéndola en el orden correcto, funciona todo. En otras ocasiones, el error está en que los tipos no son los correctos, poniendo que es una cadena cuando lo que recibe es un array, así que este tipo de mensaje se debe corregir observando primero
/**
* Constructor
*
* @param \Magento\Framework\Config\FileResolverInterface $fileResolver
* @param Converter $converter
* @param \Magento\Config\Model\Config\SchemaLocator $schemaLocator
* @param \Magento\Framework\Config\ValidationStateInterface $validationState
* @param CompilerInterface $compiler
* @param \Magento\Framework\Module\Dir\Reader $dirReader
* @param string $fileName
* @param array $idAttributes
* @param string $domDocumentClass
* @param string $defaultScope
*/
y después, contrastándolo con la información que tenemos en
public function __construct(
\Magento\Framework\Config\FileResolverInterface $fileResolver,
\Magento\Config\Model\Config\Structure\Converter $converter,
\Magento\Config\Model\Config\SchemaLocator $schemaLocator,
\Magento\Framework\Config\ValidationStateInterface $validationState,
CompilerInterface $compiler,
\Magento\Framework\Module\Dir\Reader $dirReader,
$fileName = ‘system.xml’,
$idAttributes = [],
$domDocumentClass = ‘Magento\Framework\Config\Dom’,
$defaultScope = ‘global’
)
Vamos a realizar una serie de artículos breves donde iremos explicando por qué se generan algunos errores en Magento 2 y cómo corregirlos. Por ejemplo, hemos migrado de un servidor a otro y al intentar entrar en la página, nos encontramos con este error
PHP Fatal error: Uncaught Error: Call to a member function setActive() on boolean in vendor\magento\module-backend\Model\View\Result\Page.php:27
Stack trace:
#0 vendor\magento\module-backend\Controller\Adminhtml\Dashboard\Index.php(35): Magento\Backend\Model\View\Result\Page->setActiveMenu('Magento_Backend...')
#1 vendor\magento\framework\App\Action\Action.php(107): Magento\Backend\Controller\Adminhtml\Dashboard\Index->execute()
#2 vendor\magento\module-backend\App\AbstractAction.php(229): Magento\Framework\App\Action\Action->dispatch(Object(Magento\Framework\App\Request\Http))
#3 vendor\magento\framework\App\FrontController.php(55): Magento\Backend\App\AbstractAction->dispatch(Object(Magento\Framework\App\Request\Http))
#4 vendor\magento\framework\App\Http.php(135): Magento\Framework\App\FrontController->dispatch(Object(Magento\Framework\App\Request\Http))
#5 C:\WTServer\WWW\ma in vendor\magento\module-backend\Model\View\Result\Page.php on line 27
La solución más inmediata es ir a la carpeta generated/metadata y borrar el archivo global.php, pero este error indica otro problema: seguramente no tengamos los permisos de los archivos y carpetas correctamente puestos, y el sistema sea incapaz de generar los archivos para mostrar la web. Lo que nos indica este error es que debemos revisar el grupo y usuario propietarios de los archivos y directorios, porque el sistema es incapaz de actuar sobre ellos. Lo normal es tenerlos a www-data:www-data, y con unos permisos de 775 para carpetas y 664 para archivos, pero depende también de la configuración del servidor. En cualquier caso, este error señala más allá del borrado de global.php.
Errores más comunes al trabajar con Elasticsearch, por qué suceden y su solución más sencilla
Soluciones sencillas para errores complejos de Magento 2. Cómo corregir problemas recurrentes.