We apologize for the instability of composr.app and appreciate your patience. We are working on the statistics addon and trying to find an optimal way to store and render data. Unfortunately, we have yet to find a solution that can handle the traffic (and therefore, tens of millions of statistical records) of composr.app. We're working hard on one.
We cannot just rename errorlog.php to errorlog.log and have access controls. It is possible the controls in htaccess and web.config may get disabled or never exist (especially with shady web hosts).
A possible solution is to make a new _config.php directive defining the filename. By default, it is a randomly-generated crypto-hash upon installation. That way we can use the .log extension with a reasonable amount of confidence that no spider or human will guess what it is and access it.
Then upon this process, we will no-longer need to access the error log on every page load to check for return.
Another potential solution is only to check the error log just before we plan to write to it. The return statement would therefore always be in there when something gets written to the log unless someone physically removes that line (and only until something else gets written).
"Another potential solution is only to check the error log just before we plan to write to it. The return statement would therefore always be in there when something gets written to the log unless someone physically removes that line (and only until something else gets written)."
We don't do that due to the possibility of it PHP creating the log, and somehow injecting PHP code into the error messages PHP itself generates.
A possible solution is to make a new _config.php directive defining the filename. By default, it is a randomly-generated crypto-hash upon installation. That way we can use the .log extension with a reasonable amount of confidence that no spider or human will guess what it is and access it.
Then upon this process, we will no-longer need to access the error log on every page load to check for return.
Another potential solution is only to check the error log just before we plan to write to it. The return statement would therefore always be in there when something gets written to the log unless someone physically removes that line (and only until something else gets written).
We don't do that due to the possibility of it PHP creating the log, and somehow injecting PHP code into the error messages PHP itself generates.