Update to astro 5

3 files changed, 0 insertions, 223 deletions

diff --git a/src/content/blog/configurar-php-iis.md b/src/content/blog/configurar-php-iis.md
deleted file mode 100644
index 9f286ec..0000000
--- a/src/content/blog/configurar-php-iis.md
+++ /dev/null
@@ -1,111 +0,0 @@
----

-title: "Alojar aplicación PHP en servidor IIS"

-metaDescription: "Un breve tutorial de cómo alojar una aplicación PHP en un servidor IIS para desarrollo"

-publishedAt: 2024-08-21

----

-

-En este tutorial, aprenderás a alojar una aplicación PHP en un servidor IIS. IIS es un servidor web desarrollado por Microsoft que viene instalado con Windows y es usable tanto en Windows Server como en escritorios Windows 10/11 Pro y Enterprise.

-

-Si no tienes PHP instalado, puedes descargarlo desde [php.net](https://www.php.net/downloads) y seguir las instrucciones de instalación. También debes tener IIS activado como característica de Windows (en escritorio) o como rol de servidor (en Windows Server).

-

-Para este tutorial, suponemos que estamos usando lo siguiente:

-

-- Ruta de la aplicación: `C:\users\user\app\public` (usamos `public` al alojar una aplicación Symfony, pero debe ser donde estén los archivos PHP públicos)

-- Dominio de la aplicación: `app.internal` (`.internal` está reservado para uso interno)

-- PHP instalado en `C:\php`

-- IIS habilitado y funcionando (en `localhost:80` deberías ver la página de inicio de IIS)

-- [MKCert](https://mkcert.dev) instalado para generar certificados TLS autofirmados

-

-## Crear un certificado TLS autofirmado

-

-Para poder acceder a tu servidor de forma segura, necesitas un certificado TLS. Puedes usar un certificado autofirmado para propósitos de desarrollo. Para crear un certificado autofirmado, ejecuta los siguientes comandos en PowerShell:

-

-```powershell

-mkcert -install

-mkcert -p12 app.internal

-```

-

-Esto generará un certificado `app.internal.p12` en el directorio actual. Posteriormente, hay que ir a IIS e importar el certificado a nivel servidor (en Seguridad -> Certificados de servidor -> Importar y seleccionando "todos los archivos" para encontrar el archivo `.p12`).

-

-## Creación del site

-

-En la barra izquierda, en Sitios hacemos clic derecho y seleccionamos Agregar sitio. En el cuadro de diálogo, rellenamos los campos de la siguiente manera:

-

-- Nombre del sitio: `app` (o el nombre que prefieras)

-- Ruta de acceso física: `C:\users\user\app\public`

-- Enlace:

-    - Tipo: `https`

-    - Dirección IP: `Todas las direcciones no asignadas`

-    - Puerto: `443` 

-    - Nombre del host: `app.internal`

-    - Requerir indicación del nombre del servidor: `Sí`

-    - Deshabilitar [...] `No`

-    - Certificado: `app.internal`

-- Iniciar sitio web inmediatamente: `Sí`

-

-Hacemos clic en Aceptar y el sitio se creará. Pero aún hay que configurar PHP y la reescritura de URL (si el enrutamiento se hace por el propio framework, como en Symfony).

-

-Antes de eso, hay que pulsar en la parte derecha en "Configuración básica" y cerciorarse de que el grupo de aplicaciones es `DefaultAppPool`. Si no lo es, hay que cambiarlo para que el sitio funcione correctamente.

-

-## Configuración de PHP

-

-Dentro del Sitio, ir a "Componentes del servidor -> Asignaciones de controlador -> Agregar asignación de módulo" y rellenar los campos de la siguiente manera:

-- Ruta de acceso de solicitudes: `*.php`

-- Módulo: `FastCgiModule`

-- Ejecutable: `C:\php\php-cgi.exe`

-- Nombre: `PHP` (o el nombre que prefieras)

-

-Hacemos clic en Aceptar y el módulo se añadirá. Ahora, hay que configurar la reescritura de URL.

-

-## Configuración de la reescritura de URL

-

-Primero, hay que autorizar variables de servidor. Dentro del Sitio, ir a "Caracterísitcas de HTTP -> Reglas de reescritura" y hacer clic en la barra derecha en "Ver variables de servidor". Añadir las siguientes variables:

-

-- `HTTP_X_FORWARDED_SCHEMA`

-- `HTTP_X_FORWARDED_PROTO`

-- `HTTP_X_FORWARDED_HOST`

-- `HTTP_X_FORWARDED_FOR`

-

-Hacer clic en Aceptar y volver a la pantalla de reglas de reescritura. Hacer clic en "Agregar reglas" y seleccionar "Regla de blanco" dentro de "Reglas de entrada". Rellenar los campos de la siguiente manera:

-

-- Nombre: `Symfony`

-- Coincidir dirección URL:

-    - Dirección URL solicitada: `Coincide con el patrón`

-    - Usando: `Expresiones regulares`

-    - Patrón: `^(.*)$`

-    - Omitir mayúsculas y minúsculas: `Desmarcado`

-- Condiciones:

-    - Agrupación lógica: `Coincide con todas`

-    - Añadir condición:

-        - Entrada: `{REQUEST_FILENAME}`

-        - Comprobar si la cadena de entrada: `No es un archivo`

-    - Seguir los grupos de captura a través de condiciones: `Desmarcado`

-- Variables de servidor:

-    - Agregar...:

-        - Nombre: `HTTP_X_FORWARDED_PROTO`

-        - Valor: `https`

-        - Remplazar el valor existente: `Marcado`

-    - Agregar...:

-        - Nombre: `HTTP_X_FORWARDED_SCHEMA`

-        - Valor: `https`

-        - Remplazar el valor existente: `Marcado`

-    - Agregar...:

-        - Nombre: `HTTP_X_FORWARDED_HOST`

-        - Valor: `{HTTP_HOST}`

-        - Remplazar el valor existente: `Marcado`

-    - Agregar...:

-        - Nombre: `HTTP_X_FORWARDED_FOR`

-        - Valor: `{REMOTE_ADDR}`

-        - Remplazar el valor existente: `Marcado`

-- Acción:

-    - Tipo de acción: `Reescribir`

-    - Reescribir dirección URL: `/index.php`

-    - Anexar cadena de consulta: `Marcado`

-    - Dirección URL reescrita de registro: `Desmarcado`

-- Detener procesamiento de reglas: `Desmarcado`

-

-Hacer clic en Aceptar y la regla se añadirá. Ahora, la aplicación PHP debería estar alojada en el servidor IIS y accesible en `https://app.internal`.

-

-## Conclusión

-

-En este tutorial, aprendiste a alojar una aplicación PHP en un servidor IIS. Aprendiste a crear un certificado TLS autofirmado, a configurar PHP y a configurar la reescritura de URL para que la aplicación funcione correctamente. Ahora puedes alojar aplicaciones PHP en un servidor IIS y acceder a ellas de forma segura.
\ No newline at end of file
diff --git a/src/content/blog/gobierno-no-aprueba-leyes.md b/src/content/blog/gobierno-no-aprueba-leyes.md
deleted file mode 100644
index 0cf3bfa..0000000
--- a/src/content/blog/gobierno-no-aprueba-leyes.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: "El gobierno no 'aprueba una ley' sobre el derecho a rectificación"
-metaDescription: "Hablemos de la frase 'el gobierno aprueba una ley' y por qué no es correcta, poniendo como ejemplo la ley de derecho a rectificación en prensa"
-publishedAt: 2024-12-17
----
-
-Hoy leemos la noticia en la prensa española que dice que "El Gobierno aprueba la ley del Derecho de Rectificación ante bulos e incluye a 'influencers'" (ABC), con los demás periódicos diciendo lo mismo. Pero, ¿es correcto decir que el Gobierno aprueba una ley?
-
-La respuesta es sencilla: **no**. El Gobierno no aprueba leyes, sino que **las propone**. La aprobación de una ley en España es competencia de las Cortes Generales, por aquello de la separación de poderes que habló Montesquieu, y que de una forma u otra acabó en la Constitución Española de 1978 (que es la que está en vigor).
-
-¿Cómo llega una propuesta a ser ley? Pues es un proceso largo y complejo, y más si se trata de una Ley Orgánica, como es el caso de la "Ley Orgánica Reguladora del Derecho de Rectificación" que se quiere aprobar.
-
-1. El Gobierno, el Congreso, el Senado o 500.000 ciudadanos (a través de la Iniciativa Legislativa Popular) proponen una ley.
-
-2. La ley llega al Congreso, donde se debate y se vota. En caso de que se apruebe (con mayoría simple para las leyes normales, o absoluta para las orgánicas), pasa al Senado. Si no se aprueba, la ley se archiva, y se va a la papelera.
-
-3. El Senado debate y vota la ley: si la aprueba, saltamos al paso 5. Si en cambio la enmienda o la veta, vuelve al Congreso. El Senado tiene dos meses para debatir la ley, con lo que quienes lo controlan (en este caso, el PP) pueden retrasar la aprobación de la ley; como hicieron con la amnistía.
-
-4. El Congreso recibe la ley enmendada o vetada por el Senado, y vuelve a votar. Si el Congreso aprueba la ley enmendada, se queda con las enmiendas. Si el congreso vota CONTRA las enmiendas o el veto, la ley se aprueba tal cual estaba en el Congreso originalmente.
-
-5. El Rey sanciona la ley (es decir, la firma, sin más) y se publica en el BOE; entrando en vigor cuando la propia ley dice (por ejemplo, el día siguiente, o un mes después), o en su defecto a los 20 días de su publicación.
-
-En resumen, el Gobierno no "aprueba" leyes, sino que las propone. Lo que se ha aprobado es el ANTEPROYECTO de ley, que una vez aprobado se envía al Congreso para su tramitación. Solo es el primer paso, y aún pueden pasar semanas o meses hasta que se apruebe la ley; si es que se aprueba.
-
-## La ley de derecho a rectificación
-
-Y algo específico a esta ley: no es, como han dicho algunos, que el Gobierno tenga control sobre la prensa y los _influencers_ decidiendo qué es verdad y qué no. La ley de derecho a rectificación es una ley que ya existe, y que se quiere modificar para adaptarla a la era digital.
-
-La ley de derecho a rectificación es una ley que permite a cualquier persona que se sienta agraviada por una noticia publicada en un medio de comunicación a solicitar la rectificación de la noticia. Esto, como digo, no es nuevo, ya hay una [Ley Orgánica de 1984](https://www.boe.es/buscar/act.php?id=BOE-A-1984-7248) que regula este derecho.
-
-> Toda persona, natural o jurídica, tiene derecho a rectificar la información difundida, por cualquier medio de comunicación social, de hechos que le aludan, que considere inexactos y cuya divulgación pueda causarle perjuicio.
-
-Es decir, si un medio de comunicación publica algo que no es cierto, la persona afectada puede solicitar la rectificación de la noticia. Por ejemplo, si elpanfleto.com dice "Pepito es un ladrón", Pepito puede solicitar que elpanfleto.com rectifique la noticia, si considera que no es información exacta, y eso le puede perjudicar.
-
-Ahora bien, si Pepito realmente es un ladrón, aún así, puede solicitar la rectificación y el medio de comunicación está obligado a hacerlo. La rectificación, por tanto **no implica que la noticia original sea falsa, ni que la rectificación sea cierta**, como mencionan en este auto del Tribunal Constitucional:
-
-> Es preciso aclarar desde el primer momento que el derecho de rectificación regulado por la Ley Orgánica 2/1984, de 26 de marzo, no subordina el derecho del rectificante a que éste acredite la veracidad de su versión de los hechos sino que, conforme al art. 1 de la citada Ley, basta que considere inexactos los hechos que le aluden y cuya divulgación pueda causarle perjuicios, para que se le permita ejercitar el derecho de rectificación. No está en juego, por tanto, la veracidad de unos hechos, sino la difusión de informaciones contrapuestas, como dice la STC 168/1986 (fundamento jurídico 5, último apartado)
->
-> [Auto del Tribunal Constitucional 70/1992](https://vlex.es/vid/-58123318)
-
-O dicho de otro modo, el Gobierno no está decidiendo qué es verdad y qué no, y no se ha inventado este derecho; simplemente lo está adaptando a la era digital, donde los _influencers_ y las redes sociales tienen un papel importante en la difusión de información, y no solo los medios tradicionales con una redacción y un director.
-
-Y visto el panorama, de que los medios abusan del sensacionalismo, me parece de lo más normal del mundo que se quieran implementar medidas para evitar que se difundan bulos y mentiras. ¡Dejen de mentir, panda de mentirosos!
\ No newline at end of file
diff --git a/src/content/blog/shitshow-wordpress.md b/src/content/blog/shitshow-wordpress.md
deleted file mode 100644
index e7afb10..0000000
--- a/src/content/blog/shitshow-wordpress.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: "El espectáculo que está montando WordPress (o mejor dicho, Matt Mullenweg)"
-metaDescription: "Hablemos de la polémica que ha surgido en torno a WordPress y su fundador, Matt Mullenweg, contra WPEngine y todo lo que ha desencadenado."
-publishedAt: 2024-10-13
----
-
-Hace unas semanas que Matt Mullenweg comenzó una batalla contra WPEngine, uno de los mayores proveedores de hosting de WordPress. Pero para entender esta historia, primero hay que aclarar quien es quien:
-
-- **Matt Mullenweg**: Fundador del software WordPress, fundador y CEO de Automattic, y presidente de la WordPress Foundation.
-- **WPEngine**: Proveedor de hosting especializado en WordPress, fundado en 2010, y que ha crecido hasta ser uno de los mayores proveedores de hosting de WordPress. Es propiedad de un grupo de inversión llamado Silver Lake.
-- **WordPress.org (en adelante, WPO)**: Un sitio web propiedad de Mullenweg (y nadie más), donde se aloja el software WordPress, así como documentación, foros de soporte y EL directorio de plugins y temas de WordPress (no hay otro, y crearlo implicaría tener que cambiar el software WordPress para usar este otro directorio).
-- **WordPress Foundation (en adelante, WPF)**: Una organización sin ánimo de lucro creada por Mullenweg para proteger la marca WordPress y promover el software WordPress, así como la comunidad que lo rodea. Es la propietaria de las marcas WordPress (que no WP), WooCommerce y Woo.
-- **Automattic**: La empresa comercial de Mullenweg, que ofrece servicios como WordPress.com, Jetpack, WooCommerce y otros. Automattic es la propietaria de la marca Jetpack, y tiene un acuerdo exclusivo con WPF para usar la marca WordPress de forma comercial.
-- **WordPress.com (en adelante, WPC)**: Un servicio de alojamiento de blogs y sitios web propiedad de Automattic, que ofrece alojamiento de WordPress de manera comercial. Es un competidor directo de WPEngine.
-
-Con esto en mente, vamos a la historia.
-
-## El origen de la polémica
-
-WPEngine lleva existiendo desde 2010, y ha crecido hasta ser uno de los mayores proveedores de hosting de WordPress. Sin embargo, en 2024, Mullenweg decidió comenzar una batalla contra WPEngine, porque según él, WPEngine estaba aprovechando el software libre WordPress para su beneficio comercial, sin dar nada a cambio a la comunidad de WordPress. 
-
-Además, se supo que Mullenweg exigía una "compensación" a WPEngine por valor de varios millones de dólares (sobre el 8% de ingresos de WPE) para parar esta campaña de desprestigio. WPEngine, por supuesto, se negó a pagar esta cantidad, y Mullenweg decidió seguir adelante con su campaña de desprestigio, hablando mal de WPEngine en la edición de este año de WordCamp US.
-
-WPEngine decidió _contraatacar_ enviando a Mullenweg una carta de "cese y desista" (en inglés, _cease and desist_), en la que le pedían que dejara de difamar a WPEngine y que se retractara de sus declaraciones. Mullenweg, en lugar de retractarse, decidió seguir adelante con su campaña contra WPEngine y contra todo lo que representaba.
-
-Por ello, WPEngine decidió demandar a Automattic y Mullenweg por varios cargos:
-
-- Interferencia intencionada en relaciones comerciales.
-- Interferencia intencionada en posibles relaciones económicas
-- Fraude y abuso informático
-- Intento de extorsión
-- Competencia desleal
-- Difamación (verbal y escrita)
-
-Pero la historia no acaba aquí. Mullenweg decidió contraatacar, primero prohibiendo a WPEngine el acceso a WordPress.org (que todo el mundo creía que era un sitio web de la WPF, pero que en realidad es propiedad de Mullenweg a título personal, aunque se aloja en infraestructura de Automattic), por lo que WPEngine no podía acceder a los servidores para descargar actualizaciones del software WordPress, ni tampoco podía acceder al directorio de plugins y temas de WordPress. Esto no solo afecta a la empresa, también a todos los clientes de WPEngine, que no pueden actualizar sus sitios web de WordPress.
-
-Además, hace unos días añadió una casilla en el login de WordPress.org que todo el mundo debe marcar para iniciar sesión, donde debes afirmar que no tienes ningún tipo de relación con WPEngine, impidiendo el acceso a WordPress.org si no marcas la casilla.
-
-Y para culminar, el día de ayer (sábado 12 de octubre), se supo que Mullenweg había modificado el plugin Advanced Custom Fields (ACF), mantenido por WPEngine cambiándole el nombre pero manteniendo el "listing" del plugin en WPO, cambiando también el código fuente. De tal forma, el señor Mullenweg estaba tomando "control" de un plugin de un tercero sin avisar a los usuarios ni al maintainer.
-
-Es decir, si utilizabas ACF, recibiste una actualización no genuina que cambia el nombre del plugin, y pasa a ser mantenida por no-se-sabe-quién, en lugar de ser la versión oficial mantenida por WPEngine.
-
-## Mi opinión
-
-Siempre he sido defensor del Open Source, siempre lo he usado y he contribuido más de una vez a estos proyectos, así como mantener los míos propios. Es por ello que me parece una vergüenza lo que está haciendo Mullenweg, y que está manchando el buen nombre de WordPress y de la comunidad que lo rodea.
-
-WPEngine está en su derecho de usar un software libre como WordPress para su beneficio comercial, siempre y cuando cumpla con la licencia GPL (y hasta donde yo sé, la cumple). Lo que no se puede hacer es sacar un software bajo una licencia y luego esperar que los usuarios comerciales contribuyan de vuelta "obligados" bajo amenaza de una campaña de acoso y derribo.
-
-Si lo que no se quiere es que empresas como WPEngine se beneficien de WordPress, entonces que se cambie la licencia del software, como hicieron en el pasado empresas como Redis (de Apache2 a SSPL), y acabó con la [Linux Foundation creando un fork llamado Valkey](https://valkey.io/), MongoDB (de AGPL a SSPL) o Elastic Search, que cambió su licencia porque querían ganar dinero ofreciendo hosting pero AWS les estaba comiendo el pastel. Esto acabó, por cierto, con la creación de [OpenSearch](https://opensearch.org/), un fork de Elastic Search.
-
-El problema que tiene Mullenweg es que no puede hacer este "tirón de alfombra" porque la licencia de WordPress es GPL y no tiene el control total del software, ya que hay mucha gente que ha contribuído a él a lo largo de los años sin cederle los derechos a WPF, con lo que no puede cambiar la licencia sin el consentimiento de todos los contribuyentes. Y aún si lo hiciera "por sus narices", siempre habría un fork que seguiría con la licencia GPL y ganaría en popularidad.
-
-En cuanto al sistema de plugins, es un sistema que ha funcionado bien durante años pero que se ha demostrado que no es seguro, ya que un tercero puede tomar control de un plugin sin avisar a los usuarios ni al maintainer, o puede cortar acceso a millones de personas "por sus narices". Sería buen momento ahora para crear un "registry" de plugins realmente abierto, o un sistema descentralizado donde cualquiera pueda montar su repositorio de plugins y los usuarios puedan añadirlo a su WordPress.
-
-## El caso de Linux
-
-Linux es un sistema operativo enormemente conocido, y que ha sido usado por millones de personas en todo el mundo. Sin embargo, Linux es un software libre, y cualquiera puede usarlo para su beneficio comercial. Si no, que le pregunten a las miles de empresas que ofrecen "hosting Linux" o "servidores Linux" y que ganan dinero con ello sin donar dinero o recursos a la Linux Foundation, o a distribuciones libres como Debian.
-
-Sin hablar de que existen grandes empresas como Canonical y Red Hat (de IBM) que ofrecen servicios de soporte sobre Linux, y que ganan dinero con ello. ¿Vería alguien bien que un día la Linux Foundation decida montar su propia distro comercial, y prohibir a Canonical y Red Hat acceder a kernel.org para descargar actualizaciones salvo que paguen un 8% **de los ingresos** a la Linux Foundation?
-
-O por poner otro ejemplo, ¿vería bien alguien que la Apache Software Foundation decidiera montar su propio servicio de hosting, y prohibir a sus competidores acceder a apache.org para descargar actualizaciones del HTTPD, o al repositorio de Maven, o a actualizaciones de Tomcat, Kafka, etc.?
-
-## Conclusión
-
-El tarado de Mullenweg decidió empezar una guerra "nuclear" contra WPEngine porque es el principal competidor de Automattic en el mercado de hosting de WordPress, y porque no le gusta que WPEngine gane dinero con WordPress sin dar nada a cambio a la comunidad de WordPress. Sin embargo, lo que ha hecho Mullenweg es manchar el buen nombre de WordPress y de la comunidad que lo rodea, y ha demostrado que no le importa nada más que su propio beneficio.
-
-Y desde luego, demuestra que es un peligro que exista tal absolutismo en un proyecto, donde tanto el brazo comercial como el de la comunidad están en manos de una sola persona, que puede hacer lo que le dé la gana, sin importarle las consecuencias.
-
-Si no fuera porque a mí WordPress generalmente ni me va ni me viene, lo uso únicamente cuando me lo piden, haría un fork de WordPress realmente libre, implementaría el sistema de plugins abierto o descentralizado, y garantizaría que no se repitieran estos abusos en el futuro. Pero como no es mi problema, solo voy a quedarme al margen, agarrar palomitas 🍿 y disfrutar del show.
\ No newline at end of file