It doesn't seem possible to disable the HTML report

[marcocesarato]

It doesn't seem possible to disable the HTML report

[marcocesarato]

Hi, probably the workaround could be to inverse the method call to:

->disableReportMode()
->disableReport()

In any case, the report mode is a mode in which all malware are skipped (to avoid user interaction on the CLI) and allows you to have a log (old version of the HTML report) of the detected malware and also to automatically enable the generation of the HTML report. I changed it to force the settings only on CLI and not on programmatic usage (but it will disable or enable the html report as well because these two features are linked).

I also change the default values of arguments checking if is running on CLI or not.
I will release it on next version. Let me know if you find any other issues about it.

[chrisdeeming]

I thought changing the order would work too but as I worked through it I think the stuff in the arguments method was overriding it anyway.

I'll try the fix when back at my desk. It looks good at first sight anyway.

Thanks!

[chrisdeeming]

Kind of ironic but because I now actually want to keep the HTML generated report the recent changes have nerfed that possibility.

I'm not 100% clear on what is going on but to debug I'm dumping out a copy of self::$settings in the isReportEnabled method.

Regardless of any methods I call programmatically both report and report-mode settings are always false. This is even if I call disableReportMode or enableReportMode and/or enableReport or disableReport. Essentially these methods have no effect by the time isReportEnabled is called.

Now the first thing to note if I've understood correctly is that this should disable report mode (the old log) but enable the report (the HTML report):

->disableReportMode()

However, setReportMode now contains the following if not on the CLI

self::setReport($mode);

So if you call enableReportMode then setReport(true) is called and if you can disableReportMode then setReport(false) is called.

So, no big deal, I can just call:

->disableReportMode()
->enableReport()

At least momentarily, after disableReportMode and enableReport are called self::$settings contains:

  "report-mode" => false
  "report" => true

So far, so good.

However, according to the fairly rudimentary debugging I'm doing (I don't have xdebug set up right now) disableReportMode is called three more times, each time the result is that "report" is set to false.

The calling sites for these are setPrompt and setSilentMode.

The final place where setReportMode is called and it results in disabling report mode and disabling the report is in the arguments method:

// Report mode
self::setReportMode(isset(self::$argv['report']) && self::$argv['report']);

When running programmatically self::$argv['report'] is null so this evaluates to setReportMode(false) which in turn calls setReport(false).

Finally the last issue is - and probably the most significant - that self::$argv['disable-report'] is always true so regardless of any of the above changing the report is always disabled. There doesn't appear to be a way to set this programmatically:

// Report
if (isset(self::$argv['disable-report']) && self::$argv['disable-report']) {
    self::setReport(!self::$argv['disable-report']);
}

EDIT: I guess I can pass [disable-report => false] into the run method when I call it.

So this time we've gone too much the other way. It doesn't seem possible to enable the HTML report.

Just to be clearer about my current requirements my aims are:

• Run programmatically
• Generate the HTML report
• But in case I change my mind again it may be ideal to have an option to not generate the HTML report or the old log

Sorry for all this trouble!

[chrisdeeming]

Also I've been hacking around a bit to try and get it to generate the report and output the correct data but it doesn't.

As well as generating the HTML report populated with the results of the scan, I want the run method to output the report object containing the details of scanned, infected and infectedFIles but that appears to have been lost in all cases since the update.