Freshrss: OPML export has PHP warning at the bottom: "Cannot modify header information"

Created on 5 Jun 2020  路  4Comments  路  Source: FreshRSS/FreshRSS

When I export my list of feeds (under Import/Export > Export list of feeds (OPML)), the resulting file has the following at the bottom:

<br /> <b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/www/freshrss/app/Controllers/importExportController.php:930) in <b>/var/www/freshrss/lib/Minz/ActionController.php</b> on line <b>63</b><br />

  • Version 1.16.3-dev
  • PHP 7.1.33
  • MySQL
Important

Most helpful comment

It's actually a bit more complicated to fix than I thought initially because we also export files via the CLI. I can't see a simple solution to fix it properly without reorganizing a bunch of things and it might be time to refactor this part in a more comprehensive controller (which is actually 932 lines long with a lot of indirections, pretty unmaintainable).

I'll focus on extracting the methods related to the export feature to generate files individually. Generation of headers and content will be delegated to the exportAction and to the CLI export commands (i.e. a bit higher in the call stack)

All 4 comments

Regression probably introduced by https://github.com/FreshRSS/FreshRSS/pull/2708

I can confirm the issue, it's because we use print() in the importExportController. It's not the role of the controller to ouput the content, so I'll see to move this in a view file.

In the mean time, I'm not sure you're supposed to have this issue happening in production (it should only be logged): is environment set to production in your data/config.php file?

In the mean time, I'm not sure you're supposed to have this issue happening in production (it should only be logged): is environment set to production in your data/config.php file?

That was it:

<?php return array ( 'environment' => 'development',

I've switched to production and all is well.

It's actually a bit more complicated to fix than I thought initially because we also export files via the CLI. I can't see a simple solution to fix it properly without reorganizing a bunch of things and it might be time to refactor this part in a more comprehensive controller (which is actually 932 lines long with a lot of indirections, pretty unmaintainable).

I'll focus on extracting the methods related to the export feature to generate files individually. Generation of headers and content will be delegated to the exportAction and to the CLI export commands (i.e. a bit higher in the call stack)

Was this page helpful?
0 / 5 - 0 ratings