I'm using a framework which has method defined something like
class Abc {
public function doThis($what) {
...
}
}
Since I'm using PHP 7 and also fan of PHP codesniffer, it tells me to define function argument types, that said I have wrote class in my code:-
class Pqr extends Abc {
public function doThis(string $what) {
...
}
}
This code gives me warning Declaration of Pqr::doThis(string $what) should be compatible with Abc::doThis($what)
It seems PHP is treating $what in Abc class differently (not as string). Since Abc is part of framework and I cannot do anything about it. I do not want to remove argument types in my code and want to keep cngode more strict. Disabling all warnings would be bad idea.
Anything better we have to fix this issue ?
Code Sniffer may well be telling you to do something, and you may want to follow its advice, but if your framework isn't doing it then you may not be able to do it either. You can't dicatate the code rules to the framework; you have to live with what it imposes on you, even if that goes against Code Sniffer's rules.
My advice is to simply ignore this issue. Code Sniffer is a great tool, and its advice is worth following, but there are times when you simply can't do so.
If your goal is to get your system to show zero Code Sniffer warnings, then you can do so by explicitly adding markers to your code telling Code Sniffer to ignore specific rules at various points in your code. Code Sniffer has the ability to ignore sections of code; this is described in it's Advanced Usage documentation page.
I have just noticed that the object method autocomplete does not bring up a list of methods to autocomplete with. I saw it when I was using the $PDO->bindParam() method. Normally, I can just start typing "bi" after the method arrow and the autocomplete will come straight up with the method. Now, these methods do not appear, however methods and attributes in my personally defined classes will appear. Also, it says "PHPDoc not found".
It's strange because it has worked fine previously. The only thing I can think of is that I had to delete the project out of Netbeans and then recover it back using "new project from existing sources".
Is there a broken link to a documentation file I need to re-connect? How would I go about fixing this? Also, apologies if this is an asinine question.
Code completion
To get context sensitive code completion, follow these steps:
Include Yii folder (assuming it is properly placed outside project directory)
Open "File > Project properties > PHP Include Path" and add the Yii framework root path
Ignore yiilite.php to avoid doubled/missing documentation
Open "Tools > Options > Miscellaneous > Files"
Add to the front of "Files Ignored by the IDE" the file "^(yiilite\.php|CVS|SCCS|...."
Restart NetBeans
Code completion in view files
Add the following PHPDoc statement at the head of the file to use code completion in view files. (you may add additional passed parameters as well)
/* #var $this PostController */
/* #var $model Post */
$this->getSomeProValue(); // possible with code completion
$model->author; // possible with code completion
Usage:
Typing suggestions: Ctrl-Space
Show Function parameters: Ctrl-P
Comment your own code with PHPDoc style. Here's a good example.
I've installed phpDoc on our server, set up etc. It's producing documentation correctly.
We're using the 'Responsive' template, however this error occurs regardless of the template used.
Under the 'Errors', each file scanned seems to have the following error:
Type Line Description
error 0 No summary was found for this file
I've googled exhaustively for this, and can't find a solution. I've even gone through the effort of tracking down the server error code behind the message PPC:ERR-50000 and attempting to track back the condition which causes the error, but got a bit lost.
My Question:
What does this error mean? Why is it on line 0, and how the hell do I get rid of it?! Even if I have done the docblock correctly, can I hide this error? My error-free ocd is going crazy!
Many thanks
EDIT
Some extra information: Each of my files have the following docblock from line 1 of the file:
<?php
/**
* Short Description
*
* Long Description
*
* #package Some Package
* #subpackage Some Subpackage
* #category Some Category
* #author F Bloggs <gbloggs#email.com>
*/
?>
But does the top of your file have two such docblocks? The first docblock is expected to be the one for the file itself, and a second docblock should pair up with the first documentable code element that appears after it.
However, if you only have one docblock at the top of the file, it will get paired up with the first code element found, thus the "file itself" will seem to be missing its docblock. That is what that error is supposed to indicate.
#ashnazg is right but I want to improve your answer with an example.
A File-level DocBlock should be the first docblock and must have a Summary (in this example the summary is "Class Category | core/Category.class.php").
Then a Class-level DocBlock is placed before a class definition.
<?php
/**
* Class Category | core/Category.class.php
*
* #package MyApp XYZ
* #subpackage Categories
* #author Sandro Miguel Marques <sandromiguel#something.com>
* #version v.1.1 (06/12/2016)
* #copyright Copyright (c) 2016, Sandro
*/
namespace Myapp;
use \PDO;
use \Exception;
use \PDOException;
/**
* Class Category - active record
*
* Recipe categories
*/
class Category {
...
So after a lot of searching on the server, I have a semi-fix for the problem should anyone else be encountering the same issue.
I've found out how to hide the error from the documentation, but not what is causing it.
If the error you are receiving is on Line 0, and is no summary found for this file, then you will need to edit the following file:
phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/xml.php
You will then need to search for the protected method: createErrorEntry()
This is what the existing method looks like:
protected function createErrorEntry($error, $parse_errors)
{
$marker_obj = new \DOMElement(strtolower($error->getSeverity()));
$parse_errors->appendChild($marker_obj);
$message = ($this->getTranslator())
? vsprintf($this->getTranslator()->translate($error->getCode()), $error->getContext())
: $error->getCode();
$marker_obj->appendChild(new \DOMText($message));
$marker_obj->setAttribute('line', $error->getLine());
$marker_obj->setAttribute('code', $error->getCode());
}
This method needs to have an IF condition added. Wrap the entire body of the method in the following IF condition:
protected function createErrorEntry($error, $parse_errors)
{
if($error->getCode()!=='PPC:ERR-50000')
{
$marker_obj = new \DOMElement(strtolower($error->getSeverity()));
$parse_errors->appendChild($marker_obj);
$message = ($this->getTranslator())
? vsprintf($this->getTranslator()->translate($error->getCode()), $error->getContext())
: $error->getCode();
$marker_obj->appendChild(new \DOMText($message));
$marker_obj->setAttribute('line', $error->getLine());
$marker_obj->setAttribute('code', $error->getCode());
}
}
This will stop the error being recorded, in effect, it hides the error from the end user, it doesn't fix what I can only assume is a bug in phpDocumentor. So the original error still exists, it just hasn't been recorded.
One thing I did note while debugging, is the vsprintf() function produces an error for on the PPC:ERR-50000 error. The vsprintf() produces the error PHP Warning: vsprintf(): Too few arguments. If i find out how to fix the code to stop the false error (or fix the comments to ensure the error isn't given reason to log), I'll post it here.
For what it's worth, I've found that creating the documentation from the commandline using parameters rather than using parameters in :
phpdoc -d ./ -t ./docs --ignore=vendor/*
vs parameters in a phpdoc.dist.xml configuration file has resolved all of the issues raised in this thread.
I don't think this stops the need for two docblocks at the top of files but it does appear to resolve the "No summary was found for this file" error when building the documentation.
I got the same error because I use PHP > 7 and PHPDocumentor did not recognize the syntax, so this "default error" was provided.
In my code, PHPDocumentor isn't able to parse null returns (?) in functions.
I solved this issue going to this link
https://github.com/phpDocumentor/phpDocumentor/releases
I wgot the "PHP-7 Syntax support" and installed it
wget https://github.com/phpDocumentor/phpDocumentor/releases/download/v2.9.0/phpDocumentor.phar
sudo mv phpDocumentor.phar /usr/local/bin/phpdoc
sudo chmod +x /usr/local/bin/phpdoc
check version:
phpdoc --version
= phpDocumentor version v2.9.0
It works with this phpDocumentor version
I got the exact same error message. I got rid of it..
the solution is very simple. in the file block at the
top, the summary line has a period at the end of it. This indicates
its a summary line.
make sure that no other blocks that follow for attributes or methods or whatever have a summary line with a period at the end. Once I removed those, the error disappeared immediately (PHPDocumentor 2.8.5)
I came accross this issue when my site works with php v7.4 while phpDocumentor.phar is started with php v7.2.5 and there where strong typed properties in my class. Strong typed properties aren't allowed before php v7.4.0.
class Template
{
/**
* #var string The template with some replacement strings
*/
private string $template;
....
I work in a php project with multiple independent developers and recently we had case where a function getmicrotime() was twice defined.
all worked fine, because they were defined in different files that were not both included in a single call ... until some refactory.
in the standardcase php would just output a fatal error, but here the output was blocked. (because a thirdparty website called a website ...) so we did not get the output, just the information that nothing worked anymore.
To the point:
Is there any method, external script, etc to check if functions with the same name are defined twice in the project?
i thought about reg. expr search, but ofcourse class methods can have the same name like a::meth1 and b:meth1 .... so its not that easy.
i am talking about a project with ~100.000 lines of ugly code ... so manual checking is not possible
Thanks in advance.
Consider static code analysis. I would suggest Sonar + PHP plugin: http://docs.codehaus.org/display/SONAR/PHP+Plugin
Here is the life example how it works:
http://nemo.sonarqube.org/dashboard/index/net.php.pear.phpcodesniffer
You can always write a simple script (i.e. perl or python) which will find all duplicates. The algorithm would be simple...
In order to localize strings used within my javascript, I want scan all my js files for such strings.
I am using a t() function to request string translations as follows:
t("Hello world");
or with dynamic portions:
t("Hello #user", {"#user": "d_inevitable"});
I want to detect all calls to the t() function and thus gather the strings contained in the first argument in a php "build" script, but skipping the following:
function foo(t) {
t("This is not the real t, do not localize this!");
}
function bar() {
var t = function(){}; //not the real t either...
}
function zoo() {
function t() {
//This also isn't the real t() function.
}
}
t("Translate this string, because this is the real t() in its global scope");
So the simple rule here is that the t function being invokes must be in global scope in order for the first argument to qualify as a translation string.
As a rule, dynamic runtime data as first argument is not allowed. The first argument to t() must always be a "constant" literal string.
I think php codesniffer will help me do it, however all the documentation I could find on it is about enforcing code standard (or detecting violations of it). I need lower level access to its js lexer.
My question is:
Would the php codesniffer's js lexer be able to help me solve my problem?
If so how do I access that lexer?
Are there any other php libs that could help me find the calls to t()?
Please do not suggest stand-alone regular expressions as they cannot possibly solve my problem in full.
Thank you in advance.
What you are describing is basically a coding standard. Certainly, ensuring strings are localised correctly is part of many project standards. So I think PHPCS is the right tool for you, but you will need to write a custom sniff for it because nothing exists to do exactly what you are after.
The best thing to do is probably clone the PHPCS Git repo from Github and then create a new directory under CodeSniffer/Standards to contain your custom sniff. Let's say you call it MyStandard. Make sure you create a Sniffs directory under it and then a subdirectory to house your new sniff. Take a look at the other standards in there to see how they work. You'll also find it easier to copy an existing ruleset.xml file from another standard and just change the cotent to suit you. if you don't want to include any other sniffs from anywhere (you just want to run this one check over your code) then you can just specify a name and description and leave the rest blank.
There is a basic tutorial that covers that.
Inside your sniff, you'll obviously want it to check JS files only, so make sure you specify that in the supportedTokenizers member var (also in the docs). This will ensure PHP and CSS files are always ignored.
When you get down to the actual checking, you'll have full low-level access to the parsed and tokenised content of your file. There are a lot of helper functions to check things like if the code inside other scopes, or to help you move backwards and forwards through the stack looking for bits of code you need.
TIP: run PHPCS using the -v option to see the token output on your file. It should help you see the structure more easily.
If you want to really do things properly, you can even create a nice unit test for your sniff to make sure it keeps running over time.
After all this, you'd check your code like this:
phpcs --standard=MyStandard /path/to/code
And you can use a lot of integrations that exist for PHPCS inside code editors.
You might decide to add a new more sniffs to the standard to check other things, which you can then do easily using your ruleset.xml file or by writing more custom sniff classes.
I hope that helps a bit. If you do decide to write your own sniff and need help, just let me know.