DEV Community: Hamdi LAADHARI

Deprecating My Symfony Profiler MCP Bundle: Right About the Problem, Half-Wrong About the Solution

Hamdi LAADHARI — Wed, 16 Sep 2026 21:02:13 +0000

In March 2025 I built mcp-profiler-bundle, a Symfony bundle that let AI coding agents read the Symfony Profiler: the requests your app just served, the queries they ran, the exceptions they threw. The bet was simple. An agent that can see what the app actually did should debug it better than one that can only read the source.

This week I deprecated it. Symfony now ships the official version of that idea, and rereading my code for the deprecation notice left me with an uncomfortable verdict: I was right about the problem, and half-wrong about the solution.

What the bundle did

MCP, the Model Context Protocol, is a JSON-RPC protocol that lets a client like Claude Desktop, Cursor or Cline call tools on a local server. My bundle added a bin/console mcp:server:run command that spoke it over stdio and exposed four tools: profiler:list, profiler:get_by_token, profiler:get_collectors and profiler:get_collector.

There was no official PHP SDK back then. My first commit leaned on a community library, james2037/mcp-php-server, which only existed as dev-master. By the 0.1.0 tag on 31 March 2025 it was gone, and the whole protocol fit in one match:

// Command/RunMCPServerCommand.php
$payload = json_decode($line, true, JSON_THROW_ON_ERROR);
$method = $payload['method'] ?? null;

$response = match ($method) {
    'initialize' => $this->sendInitialize(),
    'tools/list' => $this->sendToolsList(),
    'tools/call' => $this->callTool($payload['params'] ?? []),
    'notifications/initialized' => null,
    default => $this->sendProtocolError(\sprintf('Method "%s" not found', $method)),
};

Hold on to that first line. It comes back later.

It found some users: 11 stars, 2 forks and roughly 5,900 Packagist installs. Version 0.2.0 added multi-kernel (APP_ID) support a week after launch, and in February 2026 an outside contributor, Rhodri Pugh, sent a PHP 8.4 fix.

Right about the problem

The idea is official now. In September 2025, Symfony announced the official PHP MCP SDK, built with The PHP Foundation and Anthropic's MCP team. On 23 December 2025, Symfony AI Mate shipped its first release, about nine months after my 0.1.0: an MCP dev server giving coding agents access to a Symfony app's internals. The container came first, profiler access landed in 0.3 in January 2026, and it handles multi-kernel apps too.

Symfony's spotlight on Mate opens on the same premise: an agent can read all your code and still not know what happened on the last request. Mate is past 100,000 installs a month.

Half-wrong about the solution

In August 2026, Mate 0.13 deleted its MCP server (PR #2380). It no longer depends on mcp/sdk, and the agent runs plain commands instead, like these from Mate's docs and its profiler skill:

vendor/bin/mate tools:list
vendor/bin/mate tools:call symfony-profiler-list --statusCode=500 --limit=5
vendor/bin/mate resources:read symfony-profiler://profile/<token>

A bare CLI has a problem an MCP server doesn't: nothing tells the agent it exists. Mate's answer is Agent Skills — SKILL.md files installed into .agents/skills/ (mirrored into .claude/skills/) that say when to reach for which tool. The profiler skill reads like a triage procedure: filter for the failing request instead of scrolling, check which collectors it has, then read them in symptom order. exception first for a 5xx; time, db, then memory for a slow request.

Johannes Wachter, who made that change, then measured it: Claude Haiku, two tasks with injected performance bugs, ten runs per setup, counting whether the agent touched Mate at all. The bare CLI: 0 runs out of 20. The MCP server: 5 out of 20. The CLI with Skills and project instructions: 10 out of 10 on one task, 5 out of 10 on the harder one. He calls it a pattern from a small sample, not a proven effect, and concludes that "transport alone wasn't the deciding variable. Visibility was."

That's the half I got wrong. I treated exposing the data as the product. Tools give the agent eyes; skills tell it where to look. My bundle handed over four tools with one-line descriptions ("Lists available profiler tokens.") and left the agent to work out the rest.

Before / after

	`mcp-profiler-bundle` (2025)	Symfony AI Mate 0.13 (2026)
How the agent calls it	MCP over stdio, hand-written JSON-RPC	plain CLI, no server process
Needs the app to boot	yes, it's a `bin/console` command	no, reads the profiler and the dumped container from disk
Finding a profile	the last N (`limit`)	method, URL, IP, status, date range, kernel context
Collector output	raw collector data or VarDumper dumps	formatters for Doctrine, exceptions, logs, mail, memory, requests, timing and translations
Secrets	no redaction	cookies, session data, auth headers and secret env vars redacted
Prompt injection	nothing	output wrapped and marked as untrusted data
Telling the agent what to do	four one-line tool descriptions	Agent Skills plus `AGENTS.md` / `CLAUDE.md`
Beyond the profiler	nothing	service container, Monolog logs

The catch: my own bundle

Rereading the code was humbling. PHPStan flags the first two of these problems in CI, on a step I'd marked continue-on-error: true the day I set up CI:

 ------ -----------------------------------------------------------------------
  Line   Command/RunMCPServerCommand.php
 ------ -----------------------------------------------------------------------
  40     While loop condition is always true.
         🪪  while.alwaysTrue
  61     Unreachable statement - code above always terminates.
         🪪  deadCode.unreachable
  68     Constant JSON_THROW_ON_ERROR is not allowed for parameter #3 $depth
         of function json_decode.
         🪪  argument.invalidConstant

It never exits. The MCP spec expects a stdio server to quit when the client closes its input. Mine can't: on EOF, fgets() returns false, and the loop sleeps a millisecond and tries again, forever.
It gets JSON-RPC wrong. JSON_THROW_ON_ERROR sits in json_decode()'s $depth parameter, not $flags, so bad input decodes to null. Instead of a -32700 parse error with a null id, the client gets -32601 Method "" not found with id 0. And any other notification, like notifications/cancelled, gets an error reply, which JSON-RPC 2.0 forbids.
The tool names don't travel. They all contain a colon, which MCP's 2025-11-25 spec says to avoid. The Cursor screenshot in my own README shows them as profilerlist and profilerget_by_token, and the README documented different names altogether.
The filters got lost. My first version exposed ip, url, method and status_code. The rewrite kept them in ProfilerList::execute() but put only limit in the tool schema.
Nothing was redacted. The request collector holds cookies, headers and the server bag, and since Symfony's Dotenv copies .env values into $_SERVER, that includes APP_SECRET and DATABASE_URL. profiler:get_collector dumped whatever the agent asked for, unfiltered, and the optional bin/run-mcp.sh wrapper (adapted from JoliCode's MCP article) appended every response to var/mcp/stdout.log.
It needed a booting app. If the container didn't compile, bin/console didn't start, and neither did the server. Mate reads everything from disk, so it still answers when the app won't boot.
The test suite is one test. It checks that the bundle class is a bundle.

The protocol has moved on, too. MCP's 2026-07-28 revision removed the initialize handshake my match is built around and made a new server/discover method mandatory.

None of this is a verdict against MCP, by the way. symfony/mcp-bundle, for building your own MCP servers, does over 600,000 installs a month. The shift is narrower: for a dev tool the agent runs on your machine, a CLI plus skills got picked up at least as reliably, without a server process to babysit.

Wrapping up

So I retired it properly. PR #14 puts a deprecation notice at the top of the README, with the migration:

composer require --dev symfony/ai-mate
vendor/bin/mate init
composer require --dev symfony/ai-symfony-mate-extension symfony/ai-monolog-mate-extension
vendor/bin/mate discover

mate discover also installs the skills. For frontend work, Simon André's Symfony UX skills cover Stimulus, Turbo, Twig Components and Live Components.

Even deprecating it took a fix. CI had been red since June, failing on the PHP CS Fixer step, and the log on the deprecation PR showed the culprit: with no config file, PHP CS Fixer 3.95 opens an interactive init wizard, which crashes in CI with Failed to read template file. A .php-cs-fixer.dist.php turned it green.

0.2.1 is the final release, Rhodri's fix included, and the repository stays public. The lesson I'm keeping: access was the easy half. The half that makes it useful is deciding what the agent should look at, in what order, and what it must never see.

References

Symfony AI Mate documentation and Symfony AI
Symfony AI Spotlight: Mate, an Agent's Way into Your Runtime — Symfony blog
Mate repositories: symfony/ai-mate (CHANGELOG), symfony/ai-symfony-mate-extension, symfony/ai-monolog-mate-extension
The Mate Lab: does an agent actually use a dev tool? — Johannes Wachter
Introducing AI Skills for Symfony UX — Symfony blog
killerwolf/mcp-profiler-bundle and its final release

From 289 MB to 15 MB: What Migrating from Electron to Tauri Actually Cost

Hamdi LAADHARI — Fri, 11 Sep 2026 09:48:39 +0000

WatchMe is a small macOS menu-bar app I built: it lists your running processes, you tick the ones you care about, and it notifies you the moment one of them exits. Start a long build, go do something else, get told when it's done. That's the whole product.

It was an Electron app for about two years. Last week I moved it to Tauri 2, and the number that started the whole thing was this one:

$ du -sh dist/mac-arm64/WatchMe.app
289M    dist/mac-arm64/WatchMe.app

289 MB. To list processes and show a notification.

Why bother

I want to be precise about the motivation, because "Electron is bloated" is a lazy reason to rewrite something that works.

The app does three things that touch the OS: enumerate processes, own a tray icon, and post a notification. Everything else is a table and two checkboxes. Electron was shipping an entire Chromium build so that I could render that table — and on macOS, there is already a perfectly good webview sitting in the OS that every other app uses for free.

That's the actual Tauri pitch, and it's narrower than the marketing suggests. Tauri doesn't make your app fast. It makes your app small, by not shipping a browser. For something that lives in the menu bar and runs all day, small was the thing I wanted.

What actually changed in the code

The Electron version had a three-part IPC dance. A JSON file of channel names, a preload script bridging them, and handlers in the main process:

// ipc-channels.json
{
  "GET_PROCESSES": "get-processes",
  "GET_PREFERENCES": "get-preferences",
  "SAVE_PREFERENCES": "save-preferences",
  "UPDATE_TRAY_TOOLTIP": "update-tray-tooltip",
  "QUIT_APP": "quit-app"
}

// preload.js
contextBridge.exposeInMainWorld('electronAPI', {
  getProcesses: () => ipcRenderer.invoke(IPC_CHANNELS.GET_PROCESSES),
  // ...four more of these
});

// main.js
ipcMain.handle(IPC_CHANNELS.GET_PROCESSES, async () => {
  const processes = await psList();
  return processes;
});

In Tauri, ipc-channels.json and preload.js are both gone. The channel name is the function name:

#[tauri::command]
fn get_processes() -> Result<Vec<ProcessInfo>, String> {
    let mut system = System::new_all();
    system.refresh_all();

    Ok(system
        .processes()
        .iter()
        .map(|(pid, process)| ProcessInfo {
            pid: pid.as_u32(),
            name: process.name().to_string_lossy().into_owned(),
            cmd: process.cmd().iter()
                .map(|part| part.to_string_lossy())
                .collect::<Vec<_>>()
                .join(" "),
        })
        .collect())
}

// renderer.js
const getProcesses = () => invoke('get_processes');

The ps-list npm package went away too — sysinfo does it in the Rust core. My frontend still reads the same three fields it always did (pid, name, cmd), so the renderer barely noticed.

The other thing that vanished was the test harness. Testing a packaged Electron app meant 579 lines of scaffolding — booting the app, driving it, tearing it down. All of it deleted. The logic worth testing was always plain JavaScript; it just hadn't been separated from Electron.

The numbers

	Electron	Tauri 2
`.app` bundle	289 MB	15 MB
`.dmg`	—	3.7 MB
npm packages in lockfile	309	73
Main process	`main.js`, 220 lines JS	`lib.rs`, 371 lines Rust
IPC plumbing	`preload.js` + `ipc-channels.json`	none
Packaged-app test harness	579 lines	0

18.9× smaller. A 94.7% reduction in what a user downloads.

Where AI actually helped — and where it didn't

The last Electron commit in the repo is dated 9 September. The migration landed on the 10th, as a single commit: 34 files, +12,154 / −4,875. Claude Code did most of the typing. Worth being specific about which parts that actually sped up, because it wasn't uniform.

What it was genuinely good at was the mechanical translation. Porting 220 lines of Electron main-process JavaScript into Rust is exactly the kind of work where a model earns its keep: the shape is known, the target API is well documented, and every mistake shows up as a compiler error in seconds. Rust's type checker is a brutal reviewer, and having one is what makes AI-written Rust tolerable — it can't quietly hand you something that half-works.

What surprised me was that the most valuable thing it did had nothing to do with the migration. While rebuilding the UI afterwards, it read the renderer and pointed out this:

row.classList.add('highlighted-row');

That class marks a process as being watched. It has never been defined in any stylesheet. I checked every commit in the repository's history — it was added on 19 September 2024 and no CSS rule for it has ever existed. For 721 days, roughly two years, the only feedback that a process was being watched was the checkbox you'd just ticked yourself. I shipped releases with that bug and never noticed, because I wrote the code and my eyes slid straight over it.

That's the part I'd point at if someone asked what AI is actually for. Not the typing. Reading code nobody has read in two years, without any of the assumptions that made it invisible to me.

Where it didn't help is worth saying just as plainly. It verified the redesigned UI by driving it in a Chromium-based browser. But Tauri doesn't render in Chromium on macOS — it renders in WKWebView. So the verification covered a browser the app never actually runs in, and I had to close that gap by hand. An agent that can't see the real target can only tell you a thing probably works.

The catch

Here's the part the "Tauri is smaller" posts tend to skip.

The dependency count didn't go down. It went up. I removed 236 npm packages and added 499 Rust crates:

$ grep -c '^\[\[package\]\]' src-tauri/Cargo.lock
499

309 npm packages became 73 npm packages plus 499 crates. What shrank is what I ship, not what I depend on. If your reason for migrating is supply-chain surface area, look at that number again before you start.

The build cost moved onto the developer. node_modules is 105 MB. The Rust build directory is 5.8 GB:

$ du -sh node_modules src-tauri/target
105M    node_modules
5.8G    src-tauri/target

Clean release builds take minutes rather than seconds. I traded a big download for my users against a big build for me — which is the right trade for an app with more users than developers, but it is a trade.

You don't ship a browser, so you don't control the browser. Tauri uses WKWebView on macOS, WebView2 on Windows and WebKitGTK on Linux. On macOS the webview is a core OS component, which means, per Tauri's own docs, unsupported macOS versions don't get WebKit updates. My minimumSystemVersion is 13.0, so my CSS floor is whatever Safari shipped with macOS 13 — not whatever's current. Every appearance: none and :focus-visible in my stylesheet is a bet on that floor. On Electron I never had to think about it, because I was shipping the renderer.

Wrapping up

WatchMe is on Tauri 2.11.5, wry 0.55.1 and sysinfo 0.39.6, built with rustc 1.98.1 and Node 22. The app is 15 MB instead of 289 MB, and the code that does the interesting work is smaller and better tested than it was.

Would I do it again? For a menu-bar utility, yes, without hesitating. For anything with a complex canvas-based UI, I'd think much harder — three webview engines means three sets of rendering quirks, and the more unusual your rendering is, the more of them you'll find. That's the same trade as above, with a lot more at stake.

The repo is at github.com/killerwolf/watchme if you want to see what 371 lines of Rust and a table of checkboxes look like.

References

Tauri 2 — Webview Versions — which engine on which platform, and how versions track the OS
tauri-apps/wry — the webview abstraction underneath Tauri
sysinfo — the crate that replaced ps-list

Put Your Docker Images on a Diet with Alpine Linux (2015)

Hamdi LAADHARI — Sat, 22 Aug 2026 09:13:11 +0000

Archival repost — originally published on my old blog on June 21, 2015, back when Alpine was still a dark-horse pick rather than the default. Already in English, lightly cleaned up for dev.to (fixed a few typos). Alpine did go on to become the mainstream slim-base choice — but it's not the automatic right answer anymore either: its musl libc trips up some native Node/Python modules, and DNS resolution has had known issues, which is why multi-stage builds and distroless images are now common alternatives for the same "smaller image" goal. My Dockerfiles and Docker Hub images are still up if you want to see what this looked like in practice.

Run docker images and you'll typically see images weighing several hundred MBs — even a simple container providing a single service ends up heavy. Why? Because the base images people reach for — Ubuntu, CentOS, Debian — are themselves very heavy.

Images based on BusyBox could have been an alternative, but they're too far from the full-featured Linux OSes we're used to, and building from BusyBox isn't straightforward — it often requires compiling from source.

Let me introduce Alpine Linux, a lightweight Linux distribution. Its popularity is growing fast in the Docker community. Once people discover it, they rebase their Dockerfiles onto it and are amazed how simple the switch was. I started using Alpine well before it became official on Docker Hub, building my own PHP/nginx/MariaDB containers instead of relying on the heavy official ones.

More and more images using Alpine as a base are showing up on Docker Hub. My own builds are public on Docker Hub — feel free to use and fork them on GitHub.

Supercharging Dev VMs with Vagrant and Ansible (2014)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:31:23 +0000

Archival repost — originally published on my old blog on April 30, 2014. Already in English, lightly cleaned up for dev.to (fixed a few typos and reworded one sentence about Ansible's learning curve that read backwards in the original). Vagrant was the default way to spin up local dev VMs before Docker ate that space — most teams now reach for containers instead, but if you do need full VMs (kernel-level testing, OS-specific work), the Vagrant + Ansible combo below still works exactly like this. My example project is still up on GitHub.

Vagrant was the de facto standard for managing development machines. It lets you spin up a multi-VM development environment in seconds. For more details, see Vagrant Up.

Vagrant isn't a provisioning tool itself — it leverages existing ones, like Puppet and Ansible. Ansible was the new kid on the block at the time. Its learning curve isn't too steep: you just write your playbooks in YAML, and it's DevOps-friendly.

Give it a try — clone my example project, vagrant-lamp-ansible, and get started.

Naming eZ Publish Web Transactions in New Relic (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:29:02 +0000

Archival repost — originally published on my old blog on October 5, 2013. Already in English, lightly cleaned up for dev.to. New Relic's PHP agent and API have evolved a lot since, but the underlying idea — naming transactions manually instead of dumping everything into one bucket — is still exactly how you'd solve this today. The ezpublish-newrelic extension is still up on GitHub and Packagist if you want to see the actual code.

When using the New Relic PHP agent with an eZ Publish stack, every profiled transaction shows up under /index.php. Not exactly helpful when you're trying to figure out what's actually making your app struggle.

New Relic provides a self-explanatory PHP API. It lets you send additional metrics and data alongside whatever the agent already gathers — including a custom transaction name.

The eZ Publish extension I wrote, ezpublish-newrelic, hooks into that API to track modules and their views under separate, meaningful transaction names instead of one big /index.php bucket.

The source is on GitHub and installable via Composer from Packagist — feel free to contribute.

Uninstalling BlueStacks from Mac OS X, the Undocumented Way (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:20:52 +0000

Archival repost — originally published on my old blog on May 28, 2013. Already in English, lightly cleaned up for dev.to (I quoted the space-containing path, which the original left unquoted — it would have broken in a real shell). BlueStacks has changed a lot since 2013, and macOS's security model has too (notarization, System Integrity Protection), so these exact paths almost certainly won't match a current install. The instinct — dig into ~/Library for the app's own bundled uninstaller — is still the right one if a modern macOS app leaves debris behind.

For some reverse engineering needs, I installed a full-featured Android environment called BlueStacks. I decided to remove it after playing with it for a couple of hours. I searched the web and found no up-to-date way of getting rid of it — BlueStacks is a pretty intrusive app.

After digging deep into ~/Library, I found out how.

Here's how

Open a terminal
cd "~/Library/BlueStacks App Player/Uninstall/Clear BlueStacks User Data.app/Contents/MacOS"
Run sh uHD-ClearUserData
Hit Delete in the confirmation popup

You're all set.

Revamping the Blog... Done (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:18:36 +0000

Archival repost — originally published on my old blog on May 27, 2013, right on the heels of the "in progress" post. Already in English, lightly cleaned up for dev.to. NodeJitsu shut down in 2015, so the hosting details here are historical only — the "ditch WordPress for a flat-file Node.js blog" idea still holds up fine today.

I'm done revamping the blog with Lectroid. This blog engine offers all the basic features you'd need. It's currently hosted on NodeJitsu on their cheapest plan. The frontend is fully responsive, built with Twitter Bootstrap.

So — what's your take on the new setup?

Revamping the Blog... In Progress (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:15:33 +0000

Archival repost — originally published on my old blog on April 6, 2013, already in English (this was the post announcing the blog would go English-only going forward). Lightly cleaned up for dev.to. Pagodabox shut down in 2015, and Cloud9 IDE was acquired by AWS and rebuilt into something very different, so neither is usable the way described here — Lectroid, the Node.js blog engine, still exists as historical software.

From now on this blog will be held in English only. Despite not being a native English speaker, I find it easier writing in the language of Shakespeare. I'm writing this post to announce the upcoming blog revamp.

The blog was running WordPress with a full LAMP stack on my own dedicated server — a total overkill setup. On top of that, WordPress kept getting heavier release after release. I only needed a personal blog system, not a whole CMS engine.

I went with a lightweight Node.js-based blog engine that does only what I need. It's called Lectroid — no database required, posts are stored as markdown files.

I also decided to fully lighten up the dev process and give a PaaS a try. I played with a few of them for a couple of days and settled on Pagodabox, which fit my needs. I'll be using Cloud9 IDE and Git for versioning and deploying to Pagodabox. I'll keep you all posted.

eZ Publish's Native RSS Import: Making It Actually Import Media (2012)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:11:51 +0000

Archival repost — originally published on my old blog on July 20, 2012. Translated from French, lightly cleaned up for dev.to — I also fixed smart-quote encoding issues throughout the PHP code blocks that would have made them fail to parse. eZ Publish is now Ibexa DXP, but the kernel mechanism described here (and the "quick and dirty vs. extension hook" tradeoff) is unchanged.

eZ Publish lets you import content from an RSS feed into eZ Publish content objects without writing a single line of code. But that native feature doesn't import the media referenced in the <enclosure> tag:

<enclosure url="http://www.example.com/images/voiture.jpg" length="" type="image/jpeg"/>

I'll show you how to fetch that media (image, or any other file like PDF, DOC, or FLV) and insert it transparently into your eZ Publish content. This feature is a bit hardcoded in eZ Publish and isn't cleanly extensible out of the box. I'll show you the quick and dirty way to get there first, then the cleaner way — you decide how much time it's worth spending.

Quick and dirty implementation

Here are the core files affected by our changes:

The setObjectAttributeValue() function in cronjobs/rssimport.php (the PHP script called by cron to fetch new items from the RSS feeds configured in the back office)
The rssFieldDefinition() method in kernel/classes/ezrssimport.php

setObjectAttributeValue() handles fetching the different attribute types (text line, XML block), so that's naturally where we add handling for the ezimage attribute (this also works with ezfile). We add a case 'ezimage':

function setObjectAttributeValue( $objectAttribute, $value )
{
    //...
    switch( $dataType )
    {
        //...
        case 'ezimage':
        {
            $file = pathinfo($value);
            $image = eZHTTPTool::getDataByURL( $value );
            if ($image !== false)
            {
                $fp = fopen('/tmp/'.$file['basename'], 'wb');
                fwrite($fp, $image, strlen($image));
                fclose($fp);
                $objectAttribute->fromString( '/tmp/'.$file['basename'] );
            }
        } break;
        //...
    }
}

Once eZ Publish knows how to handle ezimage, we need to add Item – Enclosure – Url to the mapping <select>. That's the rssFieldDefinition() method:

case '2.0':
case '0.91':
case '0.92':
{
  return array( 'item' => array( 'elements' => array( 'title',
                                                      'link',
                                                      'description',
                                                      'author',
                                                      'category',
                                                      'comments',
                                                      'guid',
                                                      'pubDate',
                                                      'enclosure' => array( 'attributes' => array( 'url' ) ) ) ),
                'channel' => array( 'elements' => array( 'title',
                                                         'link',
                                                         'description',
                                                         'copyright',
                                                         'managingEditor',
                                                         'webMaster',
                                                         'pubDate',
                                                         'lastBuildDate',
                                                         'category',
                                                         'generator',
                                                         'docs',
                                                         'cloud',
                                                         'ttl' ) ) );
}

Cleaner implementation

Instead of editing the rssimport.php cron script directly, you can copy it into your own extension, make the ezimage changes there, and have that run instead of eZ Publish's default rssimport.php.

rssFieldDefinition() is called from another method in the same class, and there's a hook there that lets you extend the definition from classes living in your custom extensions. Here's the hook, inside fieldMap():

$fieldDefinition = eZRSSImport::rssFieldDefinition();

$ini = eZINI::instance();
foreach( $ini->variable( 'RSSSettings', 'ActiveExtensions' ) as $activeExtension )
{
    if ( file_exists( eZExtension::baseDirectory() . '/' . $activeExtension . '/rss/' . $activeExtension . 'rssimport.php' ) )
    {
        include_once( eZExtension::baseDirectory() . '/' . $activeExtension . '/rss/' . $activeExtension . 'rssimport.php' );
        $fieldDefinition = eZRSSImport::arrayMergeRecursive( $fieldDefinition, call_user_func( array( $activeExtension . 'rssimport', 'rssFieldDefinition' ), array() ) );
    }
}

So all we need is a class in extension/myextension/rss/ezrssimage.php with a method of the same name, rssFieldDefinition():

class ezrssimagerssimport
{
    static function rssFieldDefinition()
    {
        return array( 'item' => array( 'elements' => array( 'enclosure' => array( 'attributes' => array( 'url' ) ) ) ) );
    }
}

And declare that class in myextension/settings/site.ini.append.php:

[RSSSettings]
ActiveExtensions[]=ezrssimage

That's it for this one. If I ever find the time I'll package this as a proper extension and publish it on GitHub (unless someone beats me to it).

Let me know if you spot errors or improvements. The PHP snippets above are also up on this gist.

Custom ImageMagick Filters for eZ Publish Thumbnails (2011)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:08:12 +0000

Archival repost — originally published on my old blog on July 13, 2011. Translated from French, lightly cleaned up for dev.to. eZ Publish has since been rebranded/rebuilt as Ibexa DXP, but the image.ini filter mechanism and the underlying ImageMagick flags below are unchanged.

eZ Publish's default filters don't let you crop images down to precise dimensions. The image.ini config file lets you hook into eZ Publish anything the ImageMagick CLI tools can do.

Here are two filters that do the same job — crop and resize an image to an exact size — in two different ways. Use whichever fits your image aliases:

Filters[]=geometry/thumbnailize=-thumbnail "%1x%2^" -gravity center -extent %1x%2
Filters[]=geometry/thumbnailize2=-geometry %1x%2^ -gravity center -crop %1x%2+0+0 +repage

My First UWA Widget for Netvibes and iGoogle (2009)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:04:16 +0000

Archival repost — originally published on my old blog on January 18, 2009. Lightly cleaned up for dev.to (translated from French; I also dropped my personal TVRage feed hash from the example URL rather than repost a token — TVRage itself shut down years ago anyway). Netvibes and iGoogle are both long gone as platforms and the UWA widget format died with them, but the "aggregate a messy feed into something clean" approach still holds up.

Originally this project was meant for the same rabbit from my Nabaztag hack, but I ended up wanting to play with Netvibes' UWA widget framework instead. This widget shows the air times for the TV shows I watch regularly.

I'm a sucker for mashups, so instead of manually listing out every show, I used a service from TVRage. Once you created a TVRage account and added your favorite shows to it, TVRage gave you a personalized RSS feed of everything airing during the current week.

The feed was pretty messy — hard to work with, the items were inconsistent in structure — so aggregating it into the shape I wanted took more effort than expected.

Wanting to get the widget working as fast as possible, I wrote a small PHP5 API that aggregates the feed and sorts the data properly. You could also use the UWA/JS parser that Netvibes provided directly, and that's honestly the better approach — as it stood, the widget depended on an API I'd written and hosted on one of my own sites. But it didn't matter much: I wasn't planning to distribute the widget, so the PHP solution worked fine for my own use.

The widget takes three parameters: the tid and hash you'd find in your own personalized feed URL, and a third one pointing at my API.

Nothing about this stack survives today — Netvibes, iGoogle, TVRage, and UWA are all gone — but "aggregate a messy feed into a clean personal widget" is a shape I still reach for.

GreaseMonkey, or How to Enhance Your Web Experience (2008)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:00:58 +0000

Archival repost — originally published on my old blog on December 21, 2008. Lightly cleaned up for dev.to (translated from French, and I fixed a smart-quote encoding issue in the code block that would have made it fail). GreaseMonkey itself has since been discontinued for Firefox — Tampermonkey and Violentmonkey are the modern equivalents — and Google's markup has changed completely since 2008, so the exact selectors below won't match today's page. The userscript technique itself still works exactly the same way.

GreaseMonkey is a Firefox extension that lets you take control of the web. You find a site interesting despite it being plastered with ads. Thanks to GreaseMonkey and a script that's just a few lines long, you can change the visual rendering of your favorite site however you want.

To illustrate, here's a small JS script I wrote — it removes the "Sponsored Links" that show up in Google search results. Knowing JavaScript is obviously a requirement, but so is knowing the DOM and/or XPath.

// ==UserScript==
// @name           Google Sponsored Links remover
// @namespace      http://www.laadhari.fr
// @description    remove google sponsored links from SERPS
// @include        http://www.google.com/*
// ==/UserScript==

(function() {
  var sidebarads = document.getElementById('mbEnd');
  var skyads = document.getElementById('tads');
  if (sidebarads) {
    sidebarads.parentNode.removeChild(sidebarads);
    }
  if (skyads) {
    skyads.parentNode.removeChild(skyads);
    }
  }
)();

Hopefully this convinces you to write your own scripts — if you do, consider sharing them on UserScripts.org in case they're useful to someone else. My Google Sponsored Links remover is up there, open to any criticism.