Fresh Articles feed not updating in shared hosting env

Everything else
1

I updated to git head of tt-rss and my Fresh feeds stopped working. (after I updated the config.php).
I found that my hosting environment has disable_functions as follows (extracted from phpinfo() output)

disable_functions	show_source, system, shell_exec, passthru, exec, popen, proc_open, allow_url_fopen	show_source, system, shell_exec, passthru, exec, popen, proc_open, allow_url_fopen

tt-rss/classes/rssutils.php does not expect this, function function_enabled() uses explode(’,’, …)
which results in an array of functions with a trailing space, which causes in_array() to not find ‘passthru’, and as a result, update.php tries to use passthru and fails (silently).

Changing the explode to explode(’, '…) (note the space after the comma) fixed my problem but is technically a hosting issue, over which I have no control.

So, would it be possible to ‘strip spaces’ from the disable_functions list prior to exploding the list, thus giving compatibility with hosting environments that do not have spaces in the disable_function list, and those that do?

2

sure, i’ll try to take a look at this later today.

3

https://git.tt-rss.org/fox/tt-rss/commit/eadaaebd588471b5df54123d29e115df3320177b

untested but should work, i think.

4

Yep, works in my hosting environment and in my local environment, which has no disabled functions. I have yet to test where the disabled functions list has no spaces.

Tested by running php update.php --force-update --feeds on both my local (which has no disabled functions) and hosted environment (which has a more secure disable_functions list).

Each feed now takes longer than a couple hundredths of a second and I am informed by the output that it is not using a separate process. (so it has detected that passthru is disabled).

[10:07:56/4011364] Base feed: https://data.eso.sa.gov.au/prod/cfs/criimson/cfs_current_incidents.xml [10:07:56/4011364] => Country Fire Service - South Australia - Current Incidents (ID: 200, U: saw [3]), last updated: 1970-01-01 00:00:00 [10:07:57/4011364] <= 0.4286 (sec) (not using a separate process)

Thanks for the prompt fix. Much appreciated.