feed-io v2.4 : Json serialisation

In version 2.4, feed-io introduces the ability to convert feeds in valid JSON string :

$feedIo = \FeedIo\Factory::create()->getFeedIo();

$feed = $feedIo->read('http://php.net/feed.atom')->getFeed();

echo json_encode($feed);

The whole feed is exported in the JSON string, including medias, categories and additional elements.

PHP and design patterns : a smart way ?

Thanks to Jon Lemaitre’s excellent article “A Response to PHP the wrong way“, I recently discovered http://phpthewrongway.com self-exposed as the counterbalance of http://phptherightway.com. Then came the need to write an answer on the subject, my views on framework, OOP, standards and the rest but I realized I would end up with a very long article full of obvious arguments or at least statements many people already know. Boring. Seriously who wants to read another pros and cons on frameworks and OOP ? Is it really worth discussing it nowadays, knowing how many classes are offered by PHP itself and how its own syntax is object oriented ? I just think that if you don’t want to write OOP code with PHP, you’re free to use another language or to fork PHP 3.

The only subject I will cover in this post is the usage of design patterns. It could have been the wisest part of “PHP the wrong way” but the author failed to provide relevant arguments by focusing on a philosophical point of view. My goal here is to bring a more objective point of view with technical facts.

The wrong way: Looking for a pattern to solve a problem

True, this is a dogmatic approach we must stay away from. Patterns were designed to implement common needs like separation of responsibilities, open/close principle and to save some precious time finding design solutions. However, it has some drawbacks and the use of design patterns requires skills and common sense.

Continue reading

Feed-io v2.3 : the CLI is here

From now on, feed-i is a little bit more than a library. Since version 2.3, it comes with a basic client you can use through your terminal :

./bin/feedio read http://php.net/feed.atom -c 1

The instruction above will fetch php.net’s feed and display its latest item. I used the “count” option to get only one, but this is not mandatory; without it, feed-io displays all the items included in the feed.

The command line interface will probably be the main subject of the next few releases. I’m thinking about features like JSON output or items ordering and if you have any suggestion, feel free to submit a new issue on Github.

How to fix Composer’s slowness

You may have notice that Composer can get really, reaally slow on some setups. This is the case at my office, so I tried to find a solution. Let’s run Composer in very verbose mode :

# composer -vvv require phpunit/phpunit
Reading ./composer.json
Loading config file ./composer.json
Checking CA file /etc/ssl/certs/ca-certificates.crt
Downloading https://packagist.org/packages.json
Writing /root/.composer/cache/repo/https---packagist.org/packages.json into cache
Downloading http://packagist.org/p/provider-2013%24fabc3be20d24d6af724445e1f9f6cf7a891f5e0d752c3ee50e5de928877bf21e.json

And it seems to get stuck here. In fact, it’s not. If you wait for a little while (let’s say, 2 or 3 minutes), Composer stores the file in cache and downloads the next provider-*.json file. Which takes 3 more minutes and Composer won’t finish its downloads soon because, it will download more than 10 files after that.

But Google is great and it (he ?) gave me the solution :

# composer config --global repo.packagist composer https://packagist.org

And now it runs fast. Just because sometimes, Packagist is slow through HTTP without SSL.

Please note : PHP must support SSL for this to work.

A successful upgrade from Symfony 2 to 3

As Feed-io-bundle is now Symfony 3 compliant, the next logical move was to upgrade its demo. The application is just composed of the bundle itself and Bootstrap so the upgrade process should be easy to follow. Let’s see what’s in the documentation :

There are a couple of steps to upgrading a major version:

  1. Make your code deprecation free
  2. Update to the new major version via Composer
  3. Update your code to work with the new version

Three steps and every thing seems cristal clear, here we go.

Replace deprecated code and configuration

According to the cookbook, you’ll have to replace everything that became deprecated during Symfony 2’s evolution. To go through the first step, Symfony provides a package called symfony/phpunit-bridge which detects deprecated parts of your code and shows you the way to correct it. Another way to go is to pay attention to deprecations Symfony notices to your application’s log, which means to manually test the whole application. Good luck with that. feedio-demo has unit tests (well in fact, one), I’ll use the bridge :


OK, that’s easy. Only one configuration to fix and feedio-demo is ready for the dependencies upgrade.

Continue reading

A factory in feed-io v2.2

In feed-io 2.2, I introduced a Factory class built to get a FeedIo instance in one single line of code :

$feedIo = \FeedIo\Factory::create()->getFeedIo();

Obviously this works assuming that you installed feed-io using Composer and you have included vendor/autoload.php before.

Factory’s main method : Factory::create()

The factory comes with the ability to configure feed-io before getting its main class. For that, you will provide one or two configuration arrays depending on which dependency you want to configure.

Continue reading

feed-io-bundle 3.0 to support Symfony 3.0

Edit : the bundle is no longer supported, see this announcement

I recently released version 3.0 of feed-io-bundle. Symfony 3.0 introduced a backward compatibility break in forms support, so it became impossible to maintain a code base compatible with both versions.

Symfony 2.x support

I created a branch called release/2.x to maintain feed-io-bundle version 2. It will last until the end of the Symfony 2.x official support. This branch will be used for bug fixes only, all the new features will be committed to the master branch.