Bug #5288

After Execute PHP Commands with bad code, menus do not work

Added by Phillip Davis almost 4 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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.

Associated revisions

Revision 3e115dbf (diff)
Added by Steve Beaver over 3 years ago

Experimental: Fixes #5288


#1 Updated by Chris Buechler almost 4 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 over 3 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.

#3 Updated by Steve Beaver over 3 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.

#4 Updated by Steve Beaver over 3 years ago

  • % Done changed from 0 to 100

#5 Updated by Phillip Davis over 3 years ago

2.3-ALPHA (amd64)
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 over 3 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.

#7 Updated by Chris Buechler over 3 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.

#8 Updated by Phillip Davis over 3 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.

Also available in: Atom PDF