Not a bug xf-dev:generate-phpstorm-meta not skipping add-ons in $config['development']['skipAddOns']= [];

Affected version


Well-known member
when I execute php cmd.php xf-dev:generate-phpstorm-meta I get this error
Fatal error: Class 'KL\UserCriteriaExtended\Entity\XFCP_User' not found in /app/src/addons/KL/UserCriteriaExtended/Entity/User.php on line 15


The add-on named "KL\UserCriteriaExtended" has no _output directory because I'm not the owner of the add-on. It has coded by @Lukas W.

@Jake B. has faced the same kinda problem here
And according to @Liam W 's post
It would appear that XenPorta has extending entities in the root entity folder, rather than a sub directory like it recommended, so the tool thinks it’s a normal entity, and tries to instatiate it.
I'm getting this error because of @Lukas W. 's addon 'KL\UserCriteriaExtended'

So I thought skipping that add-on using config.php file would help with this problem but it didn't. I still get the error

xf2-docs config settings has mentioned about this line
  • $config['development']['skipAddOns] = null;
To use this setting, set the value to an array of add-on IDs, such as ['addOn1', 'addOn2']. Any add-ons specified within the skipAddOns array will be skipped when it comes to running development tools such as importing and exporting master data.

My config.php

$config['db']['host'] = 'xf2-dev_xf2db_1_4c4a73e07c7c';

$config['db']['port'] = '3306';

$config['db']['username'] = 'root';

$config['db']['password'] = 'devpw';

$config['db']['dbname'] = 'defaultxf';

$config['fullUnicode'] = true;

$config['cookie']['prefix'] = 'xf2dev_';

$config['development']['enabled'] = true;

$config['development']['fullJs'] = true;

$config['development']['defaultAddOn'] = 'Earl/Valve';

$config['development']['skipAddOns']= ['KL/UserCriteriaExtended'];

Lukas W.

Well-known member
Fwiw that add-on is outdated, no longer available for download and has been superseded by [TH] User Criteria Extended (with a different add-on ID).

Chris D

XenForo developer
Staff member
The skipAddOns option isn't actually designed to prevent this from being output. It literally just applies to master development data for the add-ons.

As Liam states in the post you quoted, this is really an issue with the add-on itself.

Regardless really of where an add-on puts its files, I think it's reasonable to expect that any classes which are referenced in the code are available, and exist, or the class extensions are applied.