Fraenkiman
commented
1 month ago Hello @justrudra,
thank you for the bug report. I have passed the output from your FP_errors.txt file and the affected core.date.php file through a few hands. Over a coffee break, I was told: the date_strformat() function repeatedly uses the $timestamp parameter, but it assumes that this value is already correctly formatted and ready to be passed to strftime_replacement(). However, if $timestamp is null or another inappropriate value, this can lead to errors, as strftime_replacement() expects the timestamp in different formats (e.g. UNIX timestamp, DateTime object, or datetime string).
In PHP, 0 is a valid UNIX timestamp (corresponding to January 1, 1970), but often zero or a non-valid value is passed, which causes the function to fail.
If you can, replace the file core.date.php in the directory /fp-includes/core with this one and test whether the problem still occurs. Download from PR472
In issue #386 there was unfortunately not enough information available, e.g. an error log. The same applies to the Imunify 360 protected system. We do not use Imunify 360 protected systems. This makes traceability and reproducibility impossible. If you are able to access such error logs that are directly related to FlatPress, please create a separate issue. Possibly, not excluded, there is a solution here: https://docs.imunify360.com/faq_and_known_issues/
Let us know if you still get the Fatal error “Can only throw objects” or if the problem is solved.
With best regards Frank
justrudra
Hello,
I would like to draw your attention @Fraenkiman and @azett. Its been quite sometime that I have been trying to raise this strange issue that I have been facing in "some" shared hosting environments. I am able to run the setup and the installation happens successfully. After that when I try to go the blog home page, I greeted with a "WHITE SCREEN OF DEATH" on the browser. Now, from a command line terminal, if i use 'curl' to check the code returned, it is always 500 and 503. I mean at times 500 and sometime 503.
The server logs aren't helping much either. Just the generic 500 errors are logged.
To overcome this, I tried to enable the display of php errors on the browser via .htaccess rules. And then there is a plethora of information displayed. Please have a look below :
FP_errors.txt
What is interesting though is, I never find that happening with FP 1.2.1. Everything just runs fine. By the way, I am not sure if this issue https://github.com/flatpressblog/flatpress/issues/386 is the same as the one that I mentioned above.
Also there is a big bloodbath happening between Imunify 360 and Modsecurity rules with prettyurls rules inserted by the prettyurls plugins.. Always triggers the 403 rules. That needs to be looked at as well.
The usage of Apache webserver might have reduced as @Fraenkiman had mentioned in a different thread on prettyurl issues. But what needs to be kept in mind though is that modern shared hosting rig consists of Litepeed server, which is reads the .htaccess file and loads rules form there. And Modsecurity and imunify 360 plugins are active by default on most if not all shared hosting servers. And if this issue is not addressed, it will have a negative impression on people choosing Flatpress are a medium of blog/website, in the long run.
I wish I could help you folks in troubleshooting these issues, but my skills aren't that great beside linux/unix server administration.