5

After deleting a plugin from my CakePHP Framework and all the lines of code associated with it I get an error in the getInitializer function of the autoload_static.php in my vendor->composer folder:

public static function getInitializer(ClassLoader $loader)
{
    return \Closure::bind(function () use ($loader) {
        $loader->prefixLengthsPsr4 = ComposerStaticInit8835d383dd0f2dc92619594332e8ea7e::$prefixLengthsPsr4;
        $loader->prefixDirsPsr4 = ComposerStaticInit8835d383dd0f2dc92619594332e8ea7e::$prefixDirsPsr4;
        $loader->prefixesPsr0 = ComposerStaticInit8835d383dd0f2dc92619594332e8ea7e::$prefixesPsr0;
        $loader->classMap = ComposerStaticInit8835d383dd0f2dc92619594332e8ea7e::$classMap;

    }, null, ClassLoader::class);
}

All the prefixes and the classMap are underlined and the error message says:

"Member has private access"

I'm fairly new to PHP, so my question would be how to handle this error? I suppose it's not safe to just delete this 4 lines of code.

I already tried to update composer and invalidate caches/restart in PhpStorm.

EDIT 1

I surely shouldn't have deleted the lines of code related to the old plugin manually out of the composer files.

composer diagnose: Checking composer.json: FAIL require.cakephp/plugin-installer : unbound version constraints (*) should be avoided Checking platform settings: FAIL The OpenSSL library (0.9.8y) used by PHP does not support TLSv1.2 or TLSv1.1. If possible you should upgrade OpenSSL to version 1.0.1 or above. Checking git settings: OK Checking http connectivity to packagist: Warning: Accessing packagist.org over http which is an insecure protocol.

As the project isn't too old, it might be the easiest way just to delete it completely and restart from scratch or is there an easy solution to that?

Rich Steinmetz
  • 1,020
  • 13
  • 28
  • You should not worry about code in your `vendor/composer` folder at all, especially if it does not throw errors during run time. And you definitely should not edit such files manually. P.S. You may try running `composer diagnose` in terminal/console to see if composer will spot any obvious issues. – LazyOne Aug 25 '16 at 08:12
  • You right, I shouldn't have touched the files manually. Have updated my post with the diagnose. I get some warnings there but only the first one might be connected with my issue. – Rich Steinmetz Aug 25 '16 at 11:43

1 Answers1

8

The lines are technically incorrectly highlighted as errors, and they were highlighted as errors even before you've modified the code.

The code will bind a specific object and scope to a closure, in this case it will bind the $loader object (an instance of ClassLoader) with the ClassLoader::class scope. This will cause the closure to be bound to the $loader object in a way that makes private methods visible to it, and hence things won't error out at runtime.

So the problem is just that the PhpStorm parser isn't smart enough (yet) to recognize this.

See also http://www.php.net/manual/en/closure.bind.php

As far as your other composer problems are concerned, vendor files should always be safe to delete, ie the vendor folder should normally only contain code installed through composer, which means that in case you screw things up big, you should be able to simply delete the vendor folder, fix up your composer.json file (and delete the composer.lock file) if necessary, and then just run the composer update or composer install command again.

ndm
  • 59,784
  • 9
  • 71
  • 110
  • The directory is `vendor` instead of `vendors`. Besides, I run into this problem too. Now is 5/23 2017 and the latest PHPStorm has not solved this issue yet. – UnixAgain May 23 '17 at 02:24