There's a reason why we didn't.
All security exceptions are stored in the #__admintools_log table. This table typically has thousands to hundreds of thousands of rows. Trying to load them all in memory and convert them to HTML has three important problems:
- Memory. You need enough memory to load all rows and the generated CSV or HTML report. At about 500 rows you are reaching the limit of most servers. At 5,000 rows you are definitely exceeding the default WordPress memory limit. Asking you to increase the PHP memory limit to 4GB to generate a report is unrealistic.
- Time. Generating the report would take so long it's not practical. Even if PHP doesn't time out the web server will.
- It's already in the database. The data you're looking for is already in the database and be exported a few thousand rows at a time as CSV through phpMyAdmin.
Regarding the last point, the only column that needs translation is "reason". This correlates with all the COM_ADMINTOOLS_LBL_SECURITYEXCEPTION_REASON_* language strings you can find in wp-content/plugins/admintoolswp/language/en-GB.ini. For example, if the reason reads admindir then the corresponding language string is COM_ADMINTOOLS_LBL_SECURITYEXCEPTION_REASON_ADMINDIR
. You can create a short table in a second sheet and use VLOOKUP in Excel to create a translated version of that column in your report.
Moreover, you can very possibly use Excel to connect to your database directly and import the data into a worksheet. You can even apply Excel's automatic filters to sort and filter rows you want displayed in your report. Not to mention that Excel has nearly 40 years of formatting and print customization under its belt, something we can not realistically match.