- What is rumenx/php-feed and does it work with Laravel?
- rumenx/php-feed is a framework-agnostic PHP library that generates RSS 2.0 and Atom 1.0 feeds and can be used in Laravel, Symfony, or plain PHP projects. It is built around an adapter pattern with FeedCacheInterface, FeedConfigInterface, FeedResponseInterface, and FeedViewInterface seams that map onto Laravel's container, cache repository, and view factory. It works in Laravel, but the Laravel integration is manual rather than a packaged first-party integration.
- How do I install rumenx/php-feed and generate an RSS feed in a Laravel controller?
- Install it with composer require rumenx/php-feed. In a controller, call FeedFactory::create(), set channel metadata with setTitle, setDescription, and setLink, add entries with addItem, then call render('rss') and return the XML string through response() with a Content-Type of application/xml. There are no migrations or external services to configure.
- Does this package require PHP 8.3 or later?
- Yes, the package declares a PHP 8.3+ requirement, which is aggressive for a feed generator whose core job is string templating. That floor restricts it to Laravel 11/12-era applications and blocks use in services still running PHP 8.1 or 8.2. Confirm the constraint in the installed package's composer.json before committing.
- Is laravelium/feed the same package as rumenx/php-feed?
- No, they appear to be different artifacts. The evaluation metadata names laravelium/feed, while the repository, badges, install command, and Rumenx\Feed namespace all belong to rumenx/php-feed, and laravelium/feed is a well-known older Laravel feed package with a different namespace and maintenance history. Confirm which Composer package you are actually installing and whether laravelium is a fork, a rename, or an intake error before writing any code against it.
- How does caching work, and is there a first-party Laravel cache adapter?
- Caching is exposed through FeedCacheInterface plus isCached() and clearCache(), and the README documents custom adapters rather than a shipped Laravel adapter or a documented cache-key and invalidation strategy. In practice you would write an adapter that delegates to Illuminate\Contracts\Cache\Repository and define your own key convention. Treat the full caching support claim as unproven until you verify it in a spike.
- Do I need to register a service provider, facade, or publishable config file for Laravel?
- No, because the package does not ship any of those. There is no ServiceProvider, no package auto-discovery, no facade, and no publishable config file, and FeedFactory::create() is a static constructor. You own the Laravel wiring, including a config array and cache adapter, which is roughly half a day of glue code that becomes your maintenance burden across Laravel upgrades.
- Can I customize feed output with Blade views?
- Yes, the FeedViewInterface adapter and the included Blade templates let you control how feeds are rendered, which is useful when you need precise XML structure. Be aware that render() returns mixed, so depending on which response adapter is set you get either a framework response or an XML string. Wrap the call in a thin helper that type-checks the return value to keep static analysis and call sites clean.
- Does the package support JSON Feed, podcasting tags, or iTunes namespaces?
- No, it only generates RSS 2.0 and Atom 1.0. There is no JSON Feed output and no podcast or iTunes namespace support, which blocks two of the most common syndication requests. If you need those formats you will have to extend the view templates or look at a different package.
- Does it support ETag, Last-Modified, or conditional GET requests?
- No, conditional GET handling is not built in, so ETag, Last-Modified, and 304 responses must be added at the HTTP layer yourself. WebSub and PubSubHubbub push syndication are also not supported. On hot feeds this leaves real bandwidth and scaling costs that you need to account for in your caching strategy.
- Is rumenx/php-feed tested and actively maintained enough for production?
- The library reports 100 percent test coverage with Pest and follows PSR-12, and its rendering is a pure function of channel metadata plus an item array, so it is easy to unit test in your own suite. The risk profile is less comfortable: it is a single-maintainer project with only a few v1.0.x releases, dependabot-driven updates, and zero dependents on Packagist, so there is no downstream production signal. Pin the version and expect a possible breaking change at 2.0.