<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Php on Blog de Sergio Comerón</title>
		<link>https://sergiocomeron.com/blog/tags/php/</link>
		<description>Recent content in Php on Blog de Sergio Comerón</description>
		<generator>Hugo</generator>
		<language>es</language>
		
		
		
		
			<lastBuildDate>Fri, 28 Aug 2026 06:20:00 +0200</lastBuildDate>
		
			<atom:link href="https://sergiocomeron.com/blog/tags/php/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Degradado no es caída</title>
				<link>https://sergiocomeron.com/blog/posts/degradado-no-es-caida/</link>
				<pubDate>Fri, 28 Aug 2026 06:20:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/degradado-no-es-caida/</guid>
				<description>&lt;p&gt;Cuando alguien en España no entra a la web, la pregunta no es si está caído. Es si está caído, o si no se llega.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://sergiocomeron.com/status/&#34;&gt;/status/&lt;/a&gt; existe para eso. Para no discutir de memoria. Y para no pintar el servidor como apagado cuando lo que falla es el camino hasta él.&lt;/p&gt;&#xA;&lt;p&gt;Eso ya me pasó con &lt;a href=&#34;https://sergiocomeron.com/blog/posts/hoy-laliga-ha-apagado-mi-aula/&#34;&gt;LaLiga y el aula&lt;/a&gt;. El origen respondía. Desde España, no. Aquí va cómo lo pinto.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Quería Sign in with Apple. Puse una passkey</title>
				<link>https://sergiocomeron.com/blog/posts/queria-sign-in-with-apple/</link>
				<pubDate>Thu, 27 Aug 2026 19:20:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/queria-sign-in-with-apple/</guid>
				<description>&lt;p&gt;Quería entrar a &lt;a href=&#34;https://portal.sergiocomeron.com&#34;&gt;portal.sergiocomeron.com&lt;/a&gt; con Sign in with Apple. El portal es la cuenta del plugin de Jitsi: licencias, registro, telemetría. PHP propio, usuario y contraseña, sin SSO. Lo que yo quería no era federar identidad. Era Face ID y dentro.&lt;/p&gt;&#xA;&lt;p&gt;No lo puse. El 26 de agosto monté una passkey. Aquí va qué es, por qué no Apple, y cómo se añade, con lo que hay ahora en el portal.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Le puse OpenTelemetry a mi Moodle 5.2 y las trazas van a un Jaeger en casa</title>
				<link>https://sergiocomeron.com/blog/posts/observabilidad-moodle-opentelemetry-jaeger/</link>
				<pubDate>Wed, 08 Jul 2026 00:00:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/observabilidad-moodle-opentelemetry-jaeger/</guid>
				<description>&lt;p&gt;Moodle 5.2 trae una novedad que pasó bastante desapercibida y que a mí me hizo ilusión: &lt;strong&gt;soporte de serie para OpenTelemetry&lt;/strong&gt;. Traducido: Moodle puede emitir &lt;em&gt;trazas&lt;/em&gt; de lo que hace en cada petición —el enrutado, el controlador, cada tarea de cron, cada llamada a un webservice— para que veas, con detalle de milisegundos, &lt;strong&gt;por dónde se va el tiempo&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Llevaba tiempo con la espinita de no tener buena observabilidad de mi Moodle. Tengo &lt;a href=&#34;https://sergiocomeron.com/blog/posts/analitica-sin-cookies/&#34;&gt;analítica de visitas sin cookies&lt;/a&gt; y un &lt;a href=&#34;https://sergiocomeron.com/blog/posts/self-hosting-cloudflare-mac-mini/&#34;&gt;panel de monitorización&lt;/a&gt; que me dice si algo está caído, pero nada que me dijera &lt;em&gt;por qué una página concreta tarda&lt;/em&gt;. Así que aproveché el soporte nuevo. Y, fiel a la costumbre de esta casa, con el dato quedándose &lt;strong&gt;en casa&lt;/strong&gt;: nada de mandar la telemetría a un SaaS.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Saqué mi plugin de Moodle del árbol de Moodle (y se me rompió el git push)</title>
				<link>https://sergiocomeron.com/blog/posts/plugin-moodle-standalone-phpunit11/</link>
				<pubDate>Tue, 30 Jun 2026 17:00:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/plugin-moodle-standalone-phpunit11/</guid>
				<description>&lt;p&gt;Durante años, mi plugin &lt;strong&gt;&lt;code&gt;mod_jitsi&lt;/code&gt;&lt;/strong&gt; vivió donde viven casi todos: &lt;strong&gt;dentro&lt;/strong&gt; del propio Moodle, en &lt;code&gt;mod/jitsi&lt;/code&gt;. Funciona, pero arrastra un problema silencioso: el plugin queda atado a &lt;em&gt;ese&lt;/em&gt; checkout de Moodle. Si quiero probarlo en otra versión, toca copiar ficheros, o mantener el código duplicado, o acordarme de sincronizar a mano. Un lío.&lt;/p&gt;&#xA;&lt;p&gt;Así que decidí sacarlo a su &lt;strong&gt;propio repositorio&lt;/strong&gt;, fuera del árbol de Moodle, y enlazarlo con &lt;em&gt;symlinks&lt;/em&gt; dentro de las instalaciones donde lo necesito. Un único repo, varias versiones de Moodle apuntando al mismo código. Estaba decidido a atajar de una vez ese lío de tener el plugin atado a un solo checkout, así que hice un refactor grande, &lt;code&gt;git add&lt;/code&gt;, &lt;code&gt;git commit&lt;/code&gt;, &lt;code&gt;git push&lt;/code&gt;… y el push &lt;strong&gt;se rompió&lt;/strong&gt;.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Reutiliza auth_ldap en vez de hardcodear LDAP en Moodle</title>
				<link>https://sergiocomeron.com/blog/posts/reutiliza-auth-ldap-moodle/</link>
				<pubDate>Sun, 21 Jun 2026 21:00:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/reutiliza-auth-ldap-moodle/</guid>
				<description>&lt;p&gt;Tengo un plugin propio de Moodle, &lt;strong&gt;&lt;code&gt;mod_pledge&lt;/code&gt;&lt;/strong&gt;. Su función es sencilla: antes de poder hacer los &lt;strong&gt;exámenes online&lt;/strong&gt; de la universidad, el estudiante tiene que &lt;strong&gt;aceptar un código de honor&lt;/strong&gt;. Si no lo acepta, no ve los cuestionarios ni las actividades del examen — sin compromiso, no hay examen.&lt;/p&gt;&#xA;&lt;p&gt;Sobre esa base añadí algo más: cuando el alumno &lt;strong&gt;acepta el código de honor&lt;/strong&gt;, disparo una &lt;strong&gt;tarea&lt;/strong&gt; que genera su &lt;strong&gt;justificante de asistencia al examen&lt;/strong&gt; y se lo envía por email. Y justo esa tarea es la que un día empezó a fallar en silencio: cada ejecución terminaba con &lt;em&gt;&amp;ldquo;No se proporcionó ningún documento&amp;rdquo;&lt;/em&gt; y entraba en un bucle de reintentos (el &lt;code&gt;faildelay&lt;/code&gt; de Moodle subiendo y subiendo). Ningún error de conexión, ninguna excepción ruidosa. Solo justificantes que no salían.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Proteger una API casera de un flood sin gastar un euro</title>
				<link>https://sergiocomeron.com/blog/posts/proteger-api-de-floods/</link>
				<pubDate>Sun, 21 Jun 2026 11:00:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/proteger-api-de-floods/</guid>
				<description>&lt;p&gt;Tengo unas cuantas &lt;a href=&#34;https://sergiocomeron.com/blog/herramientas/&#34;&gt;herramientas&lt;/a&gt; en la web que, además de funcionar en el navegador, exponen una &lt;strong&gt;API pública y gratuita&lt;/strong&gt;: generar datos falsos españoles, validar un NIF, calcular un IBAN, generar UUID… Todo eso lo sirve un &lt;strong&gt;Mac mini en mi casa&lt;/strong&gt;, detrás de un túnel de Cloudflare. Funciona genial, pero hay una pregunta que da un poco de vértigo: &lt;em&gt;¿y si alguien se pone a machacar una de esas APIs?&lt;/em&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>Cómo sé qué se lee en mi blog sin Google Analytics ni cookies</title>
				<link>https://sergiocomeron.com/blog/posts/analitica-sin-cookies/</link>
				<pubDate>Sun, 14 Jun 2026 00:00:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/analitica-sin-cookies/</guid>
				<description>&lt;p&gt;El post más leído de este blog es el de &lt;a href=&#34;https://sergiocomeron.com/blog/posts/self-hosting-cloudflare-mac-mini/&#34;&gt;cómo me autoalojo en un Mac mini&lt;/a&gt;. Lo sé con certeza. Y lo sé &lt;strong&gt;sin Google Analytics, sin una sola cookie y sin entregar los datos de mis lectores a una empresa de analítica&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Lo sé porque la analítica de este sitio me la monté yo, y cabe en un beacon de veinte líneas, un fichero de texto y un panel que solo veo yo. Va de eso este post.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Pagando la deuda técnica de mi plugin de Moodle: troceando dos &#34;archivos-dios&#34;</title>
				<link>https://sergiocomeron.com/blog/posts/deuda-tecnica-mod-jitsi/</link>
				<pubDate>Fri, 05 Jun 2026 18:00:00 +0200</pubDate>
				<guid>https://sergiocomeron.com/blog/posts/deuda-tecnica-mod-jitsi/</guid>
				<description>&lt;p&gt;Si usas &lt;strong&gt;mod_jitsi&lt;/strong&gt; y has notado que últimamente no saca novedades, no es que lo haya aparcado: es justo lo contrario. Estos días estoy metido en la limpieza de deuda técnica más grande que le he hecho al plugin —el que integra videollamadas de Jitsi en Moodle—, y eso se está llevando todo el tiempo que normalmente iría a funciones nuevas. Todavía está todo en la rama &lt;code&gt;dev&lt;/code&gt;, sin publicar: es trabajo en curso.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
