Bug #5288
closed
After Execute PHP Commands with bad code, menus do not work
Added by Phillip Davis about 9 years ago.
Updated about 9 years ago.
Description
Diagnostics->Command Prompt
In "Execute PHP Commands" box, put some code with a fatal PHP problem:
$x = badfunction(1);
Press Execute.
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.
- 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.
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.
- Status changed from Confirmed to Feedback
- Assignee set to Phillip Davis
Changed the code to write the user's PHP to a file and execute it with a new instance of PHP.
Seems to fix the problem at hand.
- % Done changed from 0 to 100
2.3-ALPHA (amd64)
built on Mon Oct 26 19:32:58 CDT 2015
FreeBSD 10.2-STABLE
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.
- Status changed from Feedback to Resolved
thanks Phil.
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.
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.
I can understand that! I am happy to see the results of the crud code that I typed, and press "No" to not submit the crash report. But I can understand how others would just press "Yes" without looking and thinking.
Also available in: Atom
PDF
Updated by 
Updated by Anonymous 
Updated by