I've got a problem with an extension in Typo3. My problem: An uncaught Typo3-Exception:
There is no #var annotation for property "enigma" in class "In2\Femanager\Domain\Model\User"
The exception is an "InvalidArgumentException" thrown by "...__core/typo3_src-6.2.15/typo3/sysext/extbase/Classes/Validation/ValidatorResolver.php". Looking into the code of Femanager/Domain/Model/User.php, there is a line
protected $enigma;
but without any
/**
* #var $enigma Enigma
*/
the variable $enigma is later filled by an object of the type "Enigma". But if I add this part, nothing happens. Anyone got an idea on how to solve this?
As per PHP doc for var states you need to place the type prior to the variable name.
That is:
#var Enigma $engima
Not:
#var $engima Enigma
Also; You may need to reload the op-code cache. (OpCache or the like).
Another possible solution is to disable the validation somehow, until your dev can get back it. (Maybe comment it out, seems complicated to predict the full effect but maybe worth a try if the repercussions of being down outweigh the risk)
Related
I have a variable declared in config/services.yaml
parameters:
login_url: '%env(string:APP_FRONTEND_DOMAIN)%'
I am accessing it in my controller like this:
$loginUrl = (string) ($this->getParameter('login_url') ?? "");
Everything works fine, but psalm is giving following error:
ERROR: PossiblyInvalidCast - src/Controller/MyController.php:57:31 - UnitEnum cannot be cast to string (see https://psalm.dev/190)
$loginUrl = (string) ($this->getParameter('login_url') ?? "");
Any suggestions, how to fix it, please?
Duplicated the question in the official github issue of the pslam-plugin-symfony: https://github.com/psalm/psalm-plugin-symfony/issues/272
Symfony started documenting that getParameter can return UnitEnum in specific cases. This throws up Psalm analysis because in most cases, this is not what happens and you just get a scalar in return.
Unfortunately, this is not something that can be easily handled on the user side (you'd have to make a proxy method to make sure you exclude the UnitEnum case). So ideally, it should be handled by the Psalm's Symfony plugin (even if I'm not sure how). I suggest creating an issue on the tracker on github as I don't see it yet.
Source: I'm a Psalm maintainer
As I mentioned, I duplicated the issue in github pages of the psalm and psalm-plugin and actually received the answer from one of them which solves my problem.
The answer is copied from: https://github.com/psalm/psalm-plugin-symfony/issues/272#issuecomment-1211802478
Here is the related part on Symfony side:
/**
* Gets a service container parameter.
*
* #return array|bool|string|int|float|\UnitEnum|null
*
* #throws ParameterNotFoundException if the parameter is not defined
*/
public function get(string $name);
According to the code, it means $login_url can be array, bool, etc. including \UnitEnum which cannot be casted to string. Thus the error is correct actually.
On the other hand, I know that you specified the type on parameters with environment variable which should be string. To be able to infer the type of parameter, the plugin needs to analyze compiled container XML (assuming that you already configured it) which is currently missing.
For now, you can rewrite it to tackle the error:
$loginUrl = $this->getParameter('login_url');
$loginUrl = is_string($loginUrl) ? $loginUrl : '';
The Error my website displays is below:
Fatal error: Access level to Molla_Element_Section::get_html_tag()
must be protected (as in class Elementor\Element_Section) or weaker in
web.com/public_html/wp-content/plugins/molla-core/elementor/elements/section.php
on line 3668
As per the directory above the code on line 3668 is below:
/**
* Get HTML tag.
*
* Retrieve the section element HTML tag.
*
* #since 1.0
*/
private function get_html_tag() {
$html_tag = $this->get_settings( 'html_tag' );
if ( empty( $html_tag ) ) {
$html_tag = 'section';
}
return $html_tag;
}
Please help me fix this issue , I tried playing with elementor version (downgraded to check if this was the issue) but didn't help.
Take a look at Object Inheritance in php documentation:
The visibility of methods, properties and constants can be relaxed, e.g. a protected method can be marked as public, but they cannot be restricted, e.g. marking a public property as private.
Most likely Molla_Element_Section class inherits from Elementor\Element_Section and overwrites method get_html_tag. But it uses wrong access level.
get_html_tag method cannot be 'private' it has to be 'protected' or 'public'. As documentation says visibility cannot be restricted.
So I went ahead and rolled back the Elementor version to 3.3.1. Currently, everything works stable and the temporary solution seems working fine. If you are facing the same problem, here is what you need to do to downgrade Elementor.
Login to WP-Dashboard > Elementor > Tools > Version Control and Rollback version to 3.3.1
Click “Save” and make sure to clean the browser cache.
You should get a working website now!
TYPO3 was from a very old version updated to TYPO3 6.2. The most things are working now, but I have one own written extension that give me the following error:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1297759968: Exception while property mapping at property path "":Could not find a suitable type converter for "String" because no such class or interface exists. | TYPO3\CMS\Extbase\Property\Exception thrown in file /srv/vhosts.d/typo3_src-6.2.9/typo3/sysext/extbase/Classes/Property/PropertyMapper.php in line 106.
I have a list Method in one of the controller that generates a link:
<f:link.action action="show" arguments="{id : course.id}"> {course.name}</f:link.action>
This list method works, but when I want to open this generated link in the website I get the error from above.
I delete all stuff in the showAction method and also change the template to a basic output without special things. The method looks than like this:
/**
* action show
*
* #param String Course-Id
* #return void
*/
public function showAction($id){
}
But the error is still there. I have absolutely no idea anymore what is the problem. It would be great when someone have a different view and properly have some ideas where I can try to find out what the problem really is.
I think it needs to be
/**
* action show
*
* #param string $id Course-Id
* #return void
*/
public function showAction($id){
}
string lowercase and the argument $id must be specified as well
I want to share my solution way:
The first problem was that I don't know that there is a new way to delete the cache of the core. That I find out because of Jost comment in my answer with the "clear the cache from install tool". So I go in the Backend of Typo3 to edit a user and edit there my own under Options the TSconfig field. I add there a row with options.clearCache.system = 1. Now I can clear the system core over the flash symbol in the Backend of Typo3.
After that I try to change the #param String in #param string. I deleted the core cache and then I got a different error. I found out that this new error say that only arrays or objects are as parameters are allowed in the action method (See: http://wiki.typo3.org/Exception/CMS/1253175643).
So I deleted the parameter and follow the instruction on the website where the error is explained. So my new method looks as follow:
/**
* action show
*
* #return void
*/
public function showAction(){
if ($this->request->hasArgument('id')) {
$id= $this->request->getArgument('id');
}
// Do stuff with the id
}
And that works now :)
So i have been assigned a task that would normally be trivial, but it has to work on a rather old Typo3-Website (4.5). I am very unexperienced with Typo3.
To make an AJAX call, i found out that i need an eID, my own class file, i found out how to call the main function and all that.
Now, i have a lot of configuration in many different locations, and i need to access that information.
In the class.tx_as_es_pi1.php the function main($content, $conf) has this very handy parameter $conf. It seems this is made available by some Typo3 magic. Trying to somehow mimick this behaviour, i have tried this answer, and it provides me with some of the configuration, using these lines:
$conf = $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_ases_pi1.'];
var_dump($conf);
I get this result:
'includeLibs' => string 'typo3conf/ext/as_es/pi1/class.tx_as_es_pi1.php' (length=46)
'userFunc' => string 'tx_ases_pi1->main' (length=17)
but the Typoscript Object Browser shows a lot more (including what i need):
[tx_ases_pi1] = USER_INT # TypoScript added by extension "as_es" # Setting as_es plugin TypoScript
[includeLibs] = typo3conf/ext/as_es/pi1/class.tx_as_es_pi1.php
[userFunc] = tx_ases_pi1->main
[config_template] = EXT:as_es/templates/results_elkwue.htm
[config_template_extended] = EXT:as_es/templates/extended_elkwue.htm
[config_searchaccesskey] = someAccessKey
[config_searchproxy] = someProxyUrl
[config_searchfilterurl] = soeSearchFilterUrl
[config_searchshowstat] = 1
[config_utf8decode] = 1
[config_maxtitlelength] = 50
[config_removefromtitle] = SomeString
[config_piwiktracking_host] = somePiwikHost
[config_piwiktracking_port] = 80
[config_piwiktracking_id] = SomeID
[config_fedebug_messages_search] = {$plugin.tx_ases_pi1.configuration.fedebug_messages_search}
So, obvously, there is something i do not really understand here. Could anyone point me in the right direction?
[EDIT] The answer in the related question only provides some of the configuration data, as shown above. I am looking for a hint on how to retrieve the rest of the data.
Okay. I found the answer to this, in this old post.
In the eID - class, add this method:
/**
* Initializes TSFE and sets $GLOBALS['TSFE'].
*
* #return void
*/
protected function initTSFE() {
$GLOBALS['TSFE'] = t3lib_div::makeInstance('tslib_fe',
$GLOBALS['TYPO3_CONF_VARS'], t3lib_div::_GP('id'), '');
$GLOBALS['TSFE']->connectToDB();
$GLOBALS['TSFE']->initFEuser();
$GLOBALS['TSFE']->checkAlternativeIdMethods();
$GLOBALS['TSFE']->determineId();
$GLOBALS['TSFE']->getCompressedTCarray();
$GLOBALS['TSFE']->initTemplate();
$GLOBALS['TSFE']->getConfigArray();
// Get linkVars, absRefPrefix, etc
TSpagegen::pagegenInit();
}
and in the main() method, call it: $this->initTSFE(); . Then this call:
$conf = $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_ases_pi1.'];
var_dump($conf);
will output the complete list.
I am not claiming i would really understand it... but since it might save others some trouble, i am posting it anyway.
[EDIT]
Apparently it was this line:
$GLOBALS['TSFE']->checkAlternativeIdMethods();
that made the difference. Removing it would result in the short output shown in the question.
As a side note: these lines:
$GLOBALS['TSFE']->initFEuser();
$GLOBALS['TSFE']->getCompressedTCarray();
TSpagegen::pagegenInit();
do not make a difference for me, so i assume that they can be omitted in my case to speed things up a little.I will leave them in here because they might help someone else in the future.
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;
....