These are the ones I know of:

  • PhpIncludeInspection
  • PhpDeprecationInspection
  • PhpUnusedLocalVariableInspection
  • PhpParamsInspection

What other supression codes are there? Also, some of these are no longer coming up automatically (mainly PhpIncludeInspection.) When I click the light bulb, Supression used to show up as an option, but no longer. Should I file a bug?


Like, how do I supress this?

if(!self::$rSQL[$sSQL]) self::$rSQL[$sSQL] = self::$oPDO->prepare($sSQL);

I'm getting undefined method on prepare(), yet it exists as part of the PDO.


Ok, bad example, that one just needed the property properly designated as PDO.


These "codes" should be never entered manually, but only via built-in suppression option.

If you suspect that suppression shold be available but its not but working or that its work improperly - file a bug.


You can always go by self-learning way ;) (quite long and inconvenient):

  • Create a test .php file with some code, each part of which will trigger one PHP inspection so that all inspections are covered (make sure first that they are turned on first).
  • Use that "bubble" thing to suppress each inspection

Alexey, If I have a bunch to supress (like invalid include warnings), the built-in method is WAY too slow. I need to copy and paste.

And the other thing is, since I don't know what should be allowed to be suppressed and what shouldn't, I don't know what bugs to file (you want me to guess?)


Nothing prevents you from copy-pasting the suppression marker right after it was inserted by IDE. You just should avoid doing that.

The idea is that you should use suppression really conservatively. Dont pollute your code with them. If some of current inspections (i.e. include evaluation) can't grok through the most of your current project you should tune the profile (disabling inspection or lower severity). This means that its buggy and we need to fix or improve it. May be even disable by default.

And yes, we do acknowledge that current incarnation of include inspection needs to be improved in many ways. Its scheduled to 2.0.x cycle

In future you can change code in a way that inspection migtht give you important error message but you already suppressed it directly in code. Or if inspection is improved.

That's the idea bihind suppressions.


Ok, I'll give you an example:


We use mysql_escape_string(). We have to use it. We've got major problems using mysql_real_escape_string() and are not likely to fix this soon. It's used 100's of times in the code. Yet, we want to be able to review and mark these as "Yes, we know this is a deprecated use and we consider this instance valid, so don't flag it."


Please sign in to leave a comment.