I develop a PHP project in Eclipse. Before updating to last version (2020-06), I used to had no warnings... Since I made this update, it is spamming me with two warnings.
First is about class files, like MyClass defined in MyClass.inc.php : Eclipse says me I must name my file "MyClass.php" or name my class MyClass.inc ... -__________- But I want to continue naming them MyClass.inc.php !!!
Second is about namespaces... I don't use them, and Eclipse says me that << The declared namespace "" does not match the expected namespace "path\folder" >> (path\folder is an exemple for this post).
I use PHP 7.4... I tried filters, but it don't work correctly (may be my bad), and I do not find how to disable this warnings specificaly.
Thanks for helping, I hope some update will fix it it if it's a bug T_T
The new namespace validation rule, although valid, is cumbersome. I guess it's nothing unusual or wrong to have namespaces which don't exactly match the directory structure.
I am working on a mezzio-based application, where this is the usual case, since the framework uses composer for autoloading.
After the upgrade there is no file in my project where Eclipse wouldn't warn that, eg.: The declared namespace "App\Middleware" does not match the expected namespace "project\src\App\src\Middleware".
This warning states the truth but by any means this case should be a reason for a warning in my opinion...
EDIT:
There seems to be an option which allows to change the reported level or to mute the "problem" completely:
Preferences->PHP->Validation->Error/Warnings: Unexpected namespace name
To configure custom paths for namespaces in Eclipse:
Install "PHP Development Tools (PDT) Composer Support"
Right click on the project → Configure → Add Composer Support
A Composer configuration dialog should open
In the "Autoloading" tab, you can assign namespaces to paths (relative to project root)
That would create a composer.json in the root of the PHP project with the following contents:
{
"name" : "my project",
"autoload" : {
"psr-4" : {
"some\\namespace" : "src/some/namespace"
}
}
}
You can define multiple mappings from namespaces to directories. See composer documentation for more information.
For your other problem, I think I would give in and move all files from .inc.php to .php. You'll probably have less problems in the future if you do so.
Related
NOTE: PHP Inspector EA Extended version 4.0.6.3
I have a new project with some existing imported classes, and PHP Inspection (EA Extended) plugin for PHPStorm is coming up with:
Case in namespace reference doesn't match the case in declaration
when setting a namespace on a PHP page. Yet the case is identical to the filepath, class references and all usage cases that I can find.
I can't find any useful reference when searching for this term.
PHP Class:
<?php
namespace myVendorName\ProjectName;
Class AbstractClass {
}
Filepath:
/classes/vendor/myVendorName/ProjectName/AbstractClass.php
/classes/vendor/autoloader.php
(etc)
Endpoint PHP File:
<?php
use myVendorName\ProjectName\AbstractClass;
$dropValue = new AbstractClass();
What does it claim is correct?
PHP Inspection EA Extended wants to change my namespace call in my class files to namespace myvendorname\ProjectName. It wants to lower the case of the primary vendor name to all lower case.
Yet the Autoloading standard states:
Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case.
Inconsistency?
The namespace declaration of namespace myVendorName; (with no project subname) in the class file raises no flags with the Inspector. Yet with the project name it suddenly wants to change the case of the vendor name prefix. The projectname is required for the autoloader pathing so.... ?
I have looked over the whole project and I can't find anywhere where anything references this namespace, I believe I have checked and confirmed all the settings and values both in PHPStorm as well as on the live server.
Am I being really stupid and missing something?
Is this an issue with the plugin?
What is the "declaration" that the Inspector is referencing as the source for its complaint?
Found it.
The issue was that PHPStorm has an "include Path" listing of, er, include paths, and within this listing was a path to a server folder for a few shared files.
Within this server side file structure was one root leveled class that had a namespace declared on it which was a lowercase duplication of the vendor namespace.
PHP Inspection (EA Extended) was detecting this and concluding somehow that the files in the server shared folder was taking precendent over the project-specific /vendors/ folder.
The class file that was in the shared folder is not used by this project and is not referenced by this project, the reference is entirely within PHPStorm's settings only.
Removing this reference (acutally, removing the erroneous namespace call to myvendorname) clears up all these issues.
I am currently trying to build a new PHP project from scratch (inside a git repository), using Composer (for the very first time), on Eclipse Neon PDT with Composer Eclipse Plugin and EGit.
In order to start with something quite simple, I first installed the well-known library PHP Markdown Lib. I think that I had not getting problem for configuring the require setting, as running Composer correctly updates dependencies using:
"require" : {
"php" : ">=5.3",
"michelf/php-markdown" : "~1.7"
},
As described in the Usage section of the documentation of PHP Markdown Lib, I setup a PSR-0-compatible autoloader in my composer.json and generated the autoload file:
"autoload" : {
"psr-0" : {
"Michelf\\Markdown" : "vendor/michelf/php-markdown/Michelf"
}
},
On my PHP file, I have simply included the following:
$input = file_get_contents('input.md');
use Michelf\Markdown;
$output = Markdown::defaultTransform($input);
All seem to be correctly recognized by Eclipse Neon:
the namespace and class rightly appear as autocomplete propositions (first screenshot)
the library is displayed in the outline of the document as import declarations (second screenshot)
But, despite all my testings with these settings, the page is still displaying:
Fatal error: Class 'Michelf\Markdown' not found
I have tested other formulations, such as use \Michelf\Markdown;: it is equally recognized by Eclipse Neon (autocomplete feature and document outline, as displayed on previous screenshots), but I still get the fatal error.
To ensure the autoload file was updated correctly, I have also executed the CLI dump-autoload command. Unfortunately, without more success at this time.
Right now, I suppose this problem seems to be not directly related with PHP Markdown Lib, but that I certainly forgot a step or made a mistake within my settings, which seem to fail to correctly set up the PSR-0 autoloader, even if all seem to be correctly detected by the Eclipse IDE.
Did you remember to include composer autoload at the beginning of the file?
require __DIR__ . '/vendor/autoload.php';
I try to lookup the declaration of File but PhpStorm says Cannot find declaration to go to.
I also tried it with netbeans, it can't find the declartion too.
I also tried to lookup the alias use File;
I get No usage found in project files.
How does my code even know what it has to do if It can't find any declarations? This makes no sense to me.
How can I find out where File is declared?
How does my code even know what it has to do if It can't find any declarations?
By using an autoloader. This is basically a function which is called whenever an unknown class is referenced, and attempts to define it, usually by including a file according to some naming convention. You will need to find how your particular framework manages this.
Note that it's possible it's including a file from outside the directory you have set up as the "project" in your IDE. Once you've figured out where it is, you may be able to configure your IDE to know about these extra files.
How can I find out where File is declared?
Find a place where the class is used, and using a debugger or just "dump value and die", you can use ReflectionClass::getFilename() to find out about it:
$r = new \ReflectionClass(File::class);
$r->getFilename();
Note that the File::class syntax (available since PHP 5.5) gives you the fully qualified name of the class, ignoring any aliasing or namespace imports.
It's also possible for an extension (a library written in C, not PHP) to define a class. In that case, ReflectionClass::getFilename() will return false, and you'll need to use ReflectionClass::getExtensionName(), then track down the documentation for that extension.
Laravel is quite "opinionated" in the way they use facades.
Apart from the PHPStorm gudelines how to deal with it, I find artisan tinker a simplest IDE-independent way to get familiar with new codebase.
The command provides a REPL shell, so if you are curious of where the File is actually defined, just invoke it, to get some information from the error message:
>>> File::delete()
PHP warning: Missing argument 1 for Illuminate\Filesystem\Filesystem::delete(), called in /path/to/project/app/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php on line 213 and defined in /path/to/project/app/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php on line 118
PHPStrom scans all files in Project Root folder. Add an external library (framework) you use to Project Root folder. Maybe you should instal dependecies via composer.
I am seeing namespace errors all over the place and I am not sure why.
For exampe I have:
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
and Configuration is in red and the error reads:
Undefined namespace Configuration less... (Ctrl+F1)
Referenced namespace is not found.
How do I fix this?
Since you say "Configuration is in red" I assume the problem you are experiencing is related to the IDE
If you are using PHPStorm there's a specific Symfony plugin that handle all the namespacing pretty much automatically, as long as your setup is standard.
By standard I mean a project dir containing the app/ src/ web/ ... dirs (if you're using the 2.x Symfony dir layout)
This link will tell you everything you need, in great detail
It may be your .idea folder which is corrupted. Close your project, delete the .idea folder and restart the IDE. It worked for me.
I have a problem with composer auto loader. Currently working on a application which was developed about 10 years back. The folder structure of 2 libraries which are currently used in the project do not comply the psr0 and psr4 auto loading rules.
The structure after the composer install looks as follows
Example 1
Folder path: /vendor/AppBook/ORS/class/model/Country
Filename: class.Country.php
PHP Class name: Country
Example 2
Folder path: /vendor/AppBook/ORS/class/model/Country
Filename: class.CountryCollection.php
PHP Class name: CountryCollection
Please advise what should I do in order that composer auto loader can detect these files.
Thank you in advance
From the docs:
You can use the classmap generation support to define autoloading for all libraries that do not follow PSR-0/4. To configure this you specify all directories or files to search for classes.
Example:
{
"autoload": {
"classmap": ["src/", "lib/", "Something.php"]
}
}
You can still add composer.json to your legacy libraries and define classmap autoloading type for them.
You can rename these files to make them compatible to PSR-4 (unlikely because that requires using namespaces - in 10 years old code?) or PSR-0. Additionally, you have to remove any explicit loading of these files via include, include_once, require or require_once because the file names changed.
PHP will autoload these classes by their class name. This will possibly run into issues if the case sensitivity in the class name is not respected everywhere. Example:
class UpperCase {}
$a = new upperCase();
The autoloading would try to find a file ending with upperCase.php, which will not match the PSR-0 required UpperCase.php, so the code will fail. However, this will work, making the situation not better:
class UpperCase {}
$b = new UpperCase();
$a = new upperCase();
The reason is that PHP treats class names case insensitive, so once a class is loaded, you can use any case in it's name. It is only the first occurrence in your code path that has to match. The problem is to be sure where this really is, so essentially it has to be correct everywhere.
Yes, the classmap feature is the easier way. But you'd still want to remove include/require calls to optimize the performance a bit, so you have to touch the code anyway. And despite it's age, it has to be maintained - so why not do it fully, switching to a well-known autoloading standard. It will help you in the long run when you have to maintain PSR-0/4 compatible classes and this old code in parallel.