Oc Rssfetcher Plugin Laravel Package

Getting Started

This release (4.0.0) exists for one reason: October CMS 4.x compatibility. October 4 runs on Laravel 11/12, so treat the plugin as a Laravel package with an October skin — same scheduler, queue, HTTP client, and container semantics.

Minimal steps:

1. Confirm your platform. composer require vdlp/oc-rssfetcher-plugin:^4.0 on October CMS 4.x only. If you are still on October 3.x, stay pinned to ^3.3 — do not let a floating constraint drag you across the platform boundary.
2. Align the dependency the plugin actually writes into: RainLab.Blog must be the version that targets October 4. Install/upgrade Blog before the fetcher, or the import step will fail at runtime rather than at install time.
3. Migrate: php artisan october:migrate, then clear caches (php artisan cache:clear, php artisan october:util compile assets if you touched backend assets).
4. Look first at the plugin's Plugin.php (registerSchedule, registerConsoleCommands) and its backend settings controller. Those two files tell you how feeds are configured and how fetching is triggered in your install — the exact command name is visible via php artisan list | grep -i rss.
5. First use case: add one feed pointing at a low-volume source, run the fetch command manually in a console, then inspect the created Blog posts. Only after a clean manual run should you wire it into the scheduler.

Implementation Patterns

Schedule in code, not in the UI. Wire fetching into Plugin::registerSchedule() using $schedule->command(...)->hourly()->withoutOverlapping()->onOneServer(). withoutOverlapping() is the single most important modifier here — a slow feed plus an aggressive interval is the classic way to get duplicate posts.

Queue the import. For any feed with more than a few dozen items, dispatch the fetch to a queue worker so the backend request and the scheduler tick stay fast. October 4 inherits Laravel's queue config, so QUEUE_CONNECTION and a supervised worker are all you need.

One feed per source, mapped by category. Configure each feed to land in a distinct Blog category rather than post-processing afterwards. It makes dedupe, unpublishing a bad source, and per-source author attribution far simpler than trying to sort mixed imports later.

Extend the Blog post, don't fork the plugin. Use RainLab\Blog\Models\Post::extend(function ($model) { ... }) or model events (afterCreate) to attach your own metadata, rewrite the slug, or push to a search index. Keep the plugin's import path untouched so future patch releases stay cheap.

Idempotency is your responsibility. Treat the feed's GUID/link as the natural key and enforce it. Re-running a fetch must be a no-op for already-imported items; verify that explicitly in a test.

Test with a faked HTTP layer. October 4's Laravel HTTP client supports Http::fake(), so you can point a feed at a fixture URL and assert post creation without network access. Run your CI matrix against October 4 only for this branch.

Gotchas and Tips

• Version pinning is the whole story of this release. 4.0.0 is a platform-compatibility major, not a feature release. Any custom code that reaches into October 3-era APIs, event signatures, or the old asset pipeline needs auditing before you upgrade. Read the changelog as "supported platform changed," and budget for that, not for new behaviour.
• Dependency drift. The most common upgrade failure is RainLab.Blog being one major behind. Composer may happily resolve a combination that installs fine and breaks on first import.
• Feed content is untrusted input. Titles, excerpts, and full-body HTML come from a third party. Sanitize before it lands in a Blog post body, and be deliberate about whether you import remote images at all — it turns a text import into a storage-disk and bandwidth problem.
• Malformed feeds are normal. Missing pubDate, CDATA-wrapped descriptions, non-UTF8 encodings, and timezone-less timestamps all appear in the wild. Parse dates through Carbon with an explicit fallback rather than trusting the feed.
• Media/storage paths changed across Laravel majors. If you import images, verify the configured disk and any hardcoded storage/ path assumptions still resolve under October 4.
• Debugging order: log channel output from the fetch command first, then the plugin's stored "last run" state in the backend, then the raw feed response (Http::withOptions(['debug' => true]) or a straight curl). Most "it doesn't import" reports are a 403 from the feed host on the server's egress IP.
• Config changes need a cache clear. October caches plugin config and backend navigation; editing settings and seeing no change is almost always stale cache, not a bug.
• Extension points to prefer: model events and Post::extend above; subclassing the plugin's fetcher or mapper below. Subclassing couples you to internals that this major release just demonstrated are not stable across platform versions.