[core] Added IGNORE_CUSTOM_CACHE_TIMEOUT option

[em92]

Explaining my usecase. For some reason I enabled custom_timeout in my config, but forgot to disable it back. Meanwhile some users already generated feed urls with _cache_timeout parameters. So if I disable custom_timeout back, those feed urls become invalid, which is not good.

So, I added option to ignore _cache_timeout param in url.

[logmanoriginal]

Thanks for the PR 👍

So if I disable custom_timeout back, those feed urls become invalid, which is not good.

I agree, this is a server-side issue.

So, I added option to ignore _cache_timeout param in url.

This doesn't feel right to me and is confusing to new users. Users might also question if the parameter is even applied in their specific situation, which adds a layer of uncertainty.

An alternative to this is replying with the "301 Moved Permanently" header. Feed readers and browsers will automatically follow the location provided in the header. Here is some code for reference:

header('Location: index.php?action=...', true, 301);

Would that work for you?

[em92]

Would that work for you?

Yep. Implemented that.

[logmanoriginal]

Almost. Maybe I should have explained myself better.

You can remove ignore_custom_timeout entirely and just assume, that custom_timeout = false implies ignore_custom_timeout = true. That way, you only need to replace this line:

rss-bridge/index.php

Line 129 in 78c69b0

throw new \HttpException('This server doesn\'t support "_cache_timeout"!');

by this:

unset($params['_cache_timeout']);
header('Location: ' . parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH) . '?' . http_build_query($params), true, 301);
die();

So, if custom_timeout = true, everything works fine.
If custom_timeout = false, everyone gets redirected.

[logmanoriginal]

Merged. Thanks for keeping it updated! 👍