After Execute PHP Commands with bad code, menus do not work
In "Execute PHP Commands" box, put some code with a fatal PHP problem:
$x = badfunction(1);
The fatal PHP error is reported like in 2.2.* - good.
The top menus no longer open - System, Interfaces, Firewall...
That makes it a bit harder to get back to a working UI. In 2.2.* the menus keep working and you can select Diagnostics->Command Prompt and try again with better code.
In 2.3-ALPHA you can still click the pfSense logo (top ledft) and getthe dashboard, then the menus work again.
#1 Updated by Chris Buechler almost 5 years ago
- Status changed from New to Confirmed
I think the root cause here is more widely applicable than just this circumstance. For instance, if a dashboard widget fails to load (previous problems already fixed), the menus don't work. If you have widgets open that take a bit of time to load, the menus don't work until the dashboard fully loads.
#2 Updated by Steve Beaver almost 5 years ago
My testing has not uncovered an answer to this yet. Basically fatal PHP errors (as opposed to syntax errors) cause the script to halt execution, and the page breaks.
One possibility is to write the user's PGP code to a file and then execute the file. I may test that to see if it helps.
#5 Updated by Phillip Davis almost 5 years ago
built on Mon Oct 26 19:32:58 CDT 2015
That works nicely now. It still gives the "crash report" stuff, which is good, and the GUI now continues to work.
This is fixed for the Diagnostics->Command Prompt case that I reported.
If you want to also pursue the more general dashboard loading and possible widget error scenario that Chris mentioned, then go for it.
#6 Updated by Chris Buechler almost 5 years ago
- Status changed from Feedback to Resolved
The general issue Steve discussed earlier today as part of this, where PHP getting stuck making the remainder of the page fail to load, isn't easily solvable on the other pages because the type of solution applied here can't be applied in that circumstance. So that'll suffice for this.
#7 Updated by Chris Buechler almost 5 years ago
Phillip Davis wrote:
It still gives the "crash report" stuff, which is good
This part, I'm not sure that's good. :) We get a bunch of crash reports submitted caused by people's own bad PHP in exec.php, which are just useless noise to us. The way it's handled now maybe it'd be easier to silence PHP errors in this case (or at least not generate a crash report). Not really concerned about it though, not like we're getting inundated with it, a few dozen a month maybe.