How to exclude files/folders from code inspection in PHPStorm?

I have a project in PHPStorm, which contains a few libraries (Zend, Doctrine, ...) grouped under a library folder.

When running the code inspection, I do want the PHP code in these folders to be analysed (so that PHPStorm will know how Zend_Form is declared, for example).

However, I do not want the issues found in these folders to be reported, as they are out of my control.

The only workaround I've found so far is to mark the directories as "Test source", and uncheck the "Include test sources" box in the code inspection window. Needless to say that this is not the best solution!


If you just need to disable inspections on one or two files, you can disable it at the file level easily:

  1. Open offending file
  2. Click 'Code' -> 'Configure Current File Analysis'
  3. Set slider for offending language to 'None'

(Using PHPStorm 8.0.2)


Please refer to the Scopes feature. You can define a custom scope for just your code, without the library folder, then run inspections on this scope only.

In the Inspections settings it's also possible to add the scopes and enable/disable each inspection per scope.


If you need to completely exclude few files from any analyse (for example a compiled php file) like it not even exist, you can right click on file in source tree and select "Mark as Plain Text". This action totally remove any inspections on this file. With this I removed a lot of notifications about "source duplications" in Laravel 5.

If you need to activate it again - once more right click and "Mark as PHP".

This works nice for a few files. If you need to exclude whole directory with everything inside, use directory marking from settings or right click on directory and "Mark Directory As -> Excluded".


There is alternative solution. You can add «read-only» libraries to Include pathin Settings » PHP section.

It is not the same with php.ini include_path option, just referencing to some dirs as external, outside of your control. Exactly what you need.

As result

  • no problems with scopes defining, just inspect whole project, if needed
  • no useless version control overhead in libs