The API already returns image_affiche_scale/image_full_scale for every
item (news and events alike), no extra request needed — just wasn't
being used. Embedded as an <img> at the top of the HTML description so
feed readers display it inline with the article.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Recurring events share one UID across all occurrences (confirmed via
the API: same UID, different start dates), which produced duplicate
<guid> values the RSS spec forbids. Suffix the guid with the
occurrence's start date to make it unique per occurrence.
- Add atom:link rel="self" to the channel, per the validator's
recommendation, in both the PHP and Python implementations.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mirrors the fixes made to the PHP feeds: correct link format
(/actualites|agenda/<slug>?u=<UID> instead of the wrong ?news=/?event=),
and full rich-text body + attachment links instead of the short teaser
only. Keeps both implementations in sync even though only the PHP one
is currently deployed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two bugs found by testing real links from the feed:
- Link format was wrong (?news=<internal-id>), landing on the general
listing instead of the article. Traced the real network call the site
makes when opening an item and found the actual pattern:
/actualites/<slug>?u=<UID> (agenda: /agenda/<slug>?u=<UID>), where the
JS router reads the `u` query param to fetch @results?UID=...&fullobjects=1.
- Description only used the short teaser (description_fr) even though the
API response already includes the full rich-text body (text_fr.data) and
attachments (items[].file.download) in the same call — no extra request
needed, just wasn't being used.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Browsers (Firefox in particular) force-download application/rss+xml and
application/atom+xml instead of rendering them, which is confusing for
site visitors who click a feed link directly rather than pasting it into
a reader. text/xml renders inline as an XML tree in every major browser.
Feed readers (FreshRSS included) sniff the actual XML content to detect
RSS/Atom, so this has no effect on subscription behavior.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Security review found no exploitable issue — none of the 3 endpoints
accept user input, so there's no injection surface (upstream URLs are
hardcoded constants, output is XML-escaped). These are defense-in-depth
only: deny direct HTTP access to cache/, and cap CURLOPT_MAXREDIRS to
avoid a hung request on a misbehaving upstream.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
/rss is already taken by FreshRSS on this domain, so the Python+cron
variant serves under /silly-rss/ instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same imio.smartweb JSON API as the Python script, but each feed regenerates
on demand (15 min file cache) instead of via cron, so it works on plain
PHP shared hosting with no server config access. Also adds facebook.php,
a caching proxy for the user's FetchRSS Atom feed so all three feeds live
under one domain and can be shared as stable URLs.
Tested with PHP 8.3 CLI: valid XML, real data (40 news, 12 events, proxied
Facebook feed).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Scrapes the imio.smartweb JSON API used by www.silly.be (found via the
smartweb-news/smartweb-events web components in the raw HTML) instead of
needing a headless browser. Shells out to curl since Cloudflare silently
blocks Python's urllib/requests TLS fingerprint. Includes Yunohost cron
and nginx deployment snippets.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
