[TYPO3-core] RFC: #11843 Add a reports module

[Rupert Germann]

hi Ingo

I had a look at the reports module, here're some remarks:

- reports is registered at the autoloader but there are still 
require_once() calls
- reports is not needed in FE set doNotLoadInFE=1 in emconf
- tx_reports_reports_status_InstallToolStatus has a misleading name. it 
does much more.
- some checks from befunc::displayWarningMessages() are missing
- in class tx_reports_reports_Status there are 2 foreach loops with 
unused $key
- the installtool reports are - as Masi already mentioned - partly 
useless. eg. If the PHP version doesn't match you'll never see this module.
- why are the reprts wrapped in tables - we have nice div styles for the 
flashmessages, let's use them here too
- and don't forget the moduleicon.gif when committing

besides this all works as advertised.
extending the reports is easy - I used the reports implementation from 
the installtool as example and it worked as it should.

greets
rupert




Ingo Renner schrieb:
> Hi all,
> 
> This is an SVN patch request.
> 
> Type: New feature (yes!)
> 
> 
> Bugtracker references:
> http://bugs.typo3.org/view.php?id=11843
> 
> 
> Branches:
> Trunk
> 
> 
> Problem:
> 
> Currently there's no quick and easy way to get an reports concerning the 
> systems's health or several modules doing that are spread through the BE.
> 
> 
> Solution:
> 
> Add an extensible module to show different kinds of reports. As a first 
> report add a system status report giving an overview of the system's 
> "health".
> 
> The extension provided in the patch basically only acts as a container 
> for many more reports to come, consolidating them in a single, central 
> place.
> The system status report is only the first report that plugs into the 
> reports module. The status report itself is also extensible so that 
> other extensions can show statuses there. The scheduler could show 
> whether it's been set up properly when it ran last f.e. Or the recently 
> release EXT:solr (shameless plug! ;) ) will provide a status reporting 
> whether it can connect to the Solr search server, whether its index is 
> optimized, how many documents are pending to be indexed and so on.
> 
> Also the system status is not complete yet in the sense that there can 
> be checks against a required minimum MySQL version, gd version and so on 
> for example. These can be provided even after beta1 I guess.
> 
> Concerning the current structure of the checks in status report: Checks 
> concerning the install tool are located in the reports extension as it 
> would feel strange if the install tool would check its own status 
> itself. General checks concerning the overall system health are located 
> in the install tool though for reasons of reusability (see below).
> 
> 
> Notes:
> 
> This feature has also been inspired by Drupal.
> 
> The table of the status report is using the styles of the flash 
> messages, so this is a convergence of features.
> 
> Further possible reports:
> 
> * move the BE Log to the reports module (done already, separate RFC 
> after the base EXT is in)
> * update report showing available updates for the core and extensions. 
> Highlighting critical and security relevant updates.
> * security report checking all kinds of security related things
> * statistics
> * indexed search index overview
> * ... (feel free to post more ideas at the bugtracker entry)
> 
> Due to the extensibility of the reports module some of these can be 
> provided even between 4.3 and 4.4. Candidates for that would be the 
> security and update reports, both will probably require changes on 
> typo3.org's infrastructure and will thus not make it into 4.3.
> 
> Documentation on how to extend the mmodule and the status report is 
> going to follow, this RFC is just meant to meat the feature freeze 
> deadline. This has been agreed on with Olly already.
> 
> Further ideas:
>  * A scheduler task could be set up to regularly run the status checks 
> and whenever something turns "red" will send a notification email.
>  * The status class and the existing checks are already implemented in a 
> way so that they can (and should) be reused by a new installer.
> 
> 
> 
> All the best
> Ingo
> 
> 
> ------------------------------------------------------------------------
>