Alexandre Debril

web programmer & open source contributor

In version 4.3, feed-io now gets the ability to discover feeds included in the head section of a HTML page. For instance, browse to https://php.net and take a look at the page's sources. You'll see something like this in the head section :

  <title>PHP: Hypertext Preprocessor</title>

 <link rel="shortcut icon" href="https://php.net/favicon.ico">
 <link rel="search" type="application/opensearchdescription+xml" href="http://php.net/phpnetimprovedsearch.src" title="Add PHP.net search">
 <link rel="alternate" type="application/atom+xml" href="https://php.net/releases/feed.php" title="PHP Release feed">
 <link rel="alternate" type="application/atom+xml" href="https://php.net/feed.atom" title="PHP: Hypertext Preprocessor">

The interesting parts of it are the two <link rel="alternate" type="application/atom+xml" /> tags.

Continue reading

On February 1st, I moved on the blog from a WordPress instance to a Symfony-based application hosted by OVH. Why ? There are many reasons for this :

  • I can do it. Yes it sounds stupid, but a personal blog can be built upon a few tables and a reasonable amount of code. Unless you really want to do something big, you don't need more
  • it was the perfect opportunity to work with Symfony 4 on a live but harmless project (seriously, who cares if I break my own blog ?)

But these are not the only reasons I decided to leave WordPress. The idea came when this news came out. Then this one made me think it probably was a wise decision. And recently this one came as another nail in the coffin (yes, I read The Hacker News). All these flaws are representative of something really bad : Security is not a major matter for Wordpress developers and that's the main reason I left Wordpress.

Because as an IT professional, I consider that Security MUST be an important topic in every development project. Period.

With PHP 5 reaching its end of life at the end of 2018, it's time for modern libraries to move on and take advantage of PHP 7 features such as return types and scalar type declarations. So I did it to feed-io in the next release to come, tagged 4.0 and in beta phase until mid-September followed by a two weeks RC phase and then a final release in early October.

What will change in feed-io 4.0 :

  • PHP 5 will no longer be supported in this version
  • Return and argument types are declared in function declarations
  • Some bugs due to past versions' design are fixed
  • Memory usage optimization

Users of feed-io 3 will have to adapt all classes implementing interfaces like FeedInterface to add the type hints in functions' declarations. By the way : feed-io 3 will be supported until the end of 2018 so don't panic if you didn't plan to upgrade soon.

I am looking for testers and feedback will be highly appreciated. You can submit your issues in the project's Github repository, I will give you an answer as soon as possible.

In my previous post I introduced JSON Feed, a new syndication standard published on May 17, 2017.

And now feed-io supports this new format since the last release. It was tagged 3.0 as it breaks compatibility with the previous version, which was a necessary evil because FeedIo::format() returned a DomDocument, no longer relevant. Now this method returns a string you can display without calling saveXML() anymore. This is the main change from 2.x to 3.0 and if you need to know everything on how to upgrade your code, please refer to the upgrade guide.

For those how don't know feed-io yet, it is a PHP library built to read and write feeds initially written with RSS and Atom formats in mind. I sometimes had the feeling that one day a JSON standard will come this way, but I always ended thinking "nay, not that year". Good news : I'm finally wrong ! And I guess nobody cares about what I am thinking, so now I'll get to the point : the code.

Continue reading

With Atom and RSS being the major syndication formats since more than a decade, there's not much room for another one. In fact, trying to introduce a new one in 2017 is a real challenge as those XML-based formats are used by billions of websites and known by every web developers.

But maybe that's the problem : two XML-based formats. Working with both of them is tricky, as there both share the same goal using similar schemas on top of a complex markup language. Look at feed-io's \Rule namespace, you may see by yourself that sometimes I had some headaches writing this library.

So, in order to offer an easier way to serve feeds, two web veterans (Brent Simmons and Manton Reece) proposed a new standard based on JSON with the following motivations :

We — Manton Reece and Brent Simmons — have noticed that JSON has become the developers’ choice for APIs, and that developers will often go out of their way to avoid XML. JSON is simpler to read and write, and it’s less prone to bugs.

So we developed JSON Feed, a format similar to RSS and Atom but in JSON. It reflects the lessons learned from our years of work reading and publishing feeds.

Here's the example provided in JSON Feed's specifications :

{
    "version": "https://jsonfeed.org/version/1",
    "title": "My Example Feed",
    "home_page_url": "https://example.org/",
    "feed_url": "https://example.org/feed.json",
    "items": [
        {
            "id": "2",
            "content_text": "This is a second item.",
            "url": "https://example.org/second-item"
        },
        {
            "id": "1",
            "content_html": "<p>Hello, world!</p>",
            "url": "https://example.org/initial-post"
        }
    ]
}

Really easy to read. So easy I decided to implement this standard in feed-io.