Bug #5288
closed
After Execute PHP Commands with bad code, menus do not work
100%
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.
Updated by Chris Buechler about 9 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.
Updated by Anonymous about 9 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.
Updated by Anonymous about 9 years ago
- 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.
Updated by Anonymous about 9 years ago
- % Done changed from 0 to 100
Applied in changeset pfsense:3e115dbf716a9bdb6b972a367c0f0a44f183f6ab.
Updated by Phillip Davis about 9 years ago
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.
Updated by Chris Buechler about 9 years ago
- 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.
Updated by Chris Buechler about 9 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.
Updated by Phillip Davis about 9 years ago
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.