fidzu : php

22 Jul 2026 5:59pm GMT

Some downtime during a platform migration is inevitable. Data, sometimes huge amounts of data, has to be transferred. Domain records need to be updated. The final checklist before launching is extensive.

However, any reputable agency will minimize this inevitable downtime, because every hour an eCommerce site is offline costs money. A migration that drags on for days is unacceptable, causing a direct hit to revenue and customer trust.

We've migrated eCommerce operations ranging from several thousand orders to several million, with product catalogs spanning a few hundred to several hundred thousand SKUs and customer records well into the hundreds of thousands. Through that work, we've developed a set of practices that consistently keep actual site downtime to a few hours, even on the most complex projects.

Here's how to minimize your downtime.

Start migration planning as soon as the architecture is set

When do you start thinking about data migration? As soon as the architecture is nailed down. As soon as entities and fields are defined, old data stores can be mapped to the new database.

Read more

22 Jul 2026 2:54pm GMT

I kept running into the same small frustration. My site has its own search, but when I ask an AI agent whether I have written about a topic before, it searches Google instead of using my site's search directly. As a result, it often misses relevant posts that Google has not indexed.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://dri.es/search/json",
      "service-desc": [
        {
          "href": "https://dri.es/openapi.json",
          "type": "application/openapi+json"
        }
      ]
    }
  ]
}

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

22 Jul 2026 2:22pm GMT

We are thrilled to announce that SymfonyCon Warsaw 2026 will take place on November 26 and 27, 2026, in Warsaw (Poland)! Join us for an extraordinary worldwide conference with 3 parallel tracks and community events. 🎤 Speaker announcements We…

22 Jul 2026 1:30pm GMT

This week, Symfony published Symfony UX 3.3, which adds support for Symfony Reprise and includes several improvements to the toolkit. In addition, SymfonyCasts announced a new course on upgrading to Symfony 8. Finally, the upcoming SymfonyCon Warsaw 2026…

19 Jul 2026 7:23am GMT

SymfonyCon Warsaw 2026, our next annual international Symfony conference, will take place on: November 24 & 25 with two days of hands-on workshops to learn, practice, and enhance your skills in small groups. November 26 & 27 with three English-speaking…

15 Jul 2026 8:00am GMT

Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT