I don't know if this is a Symfony issue or a FOSUserBundle issue so I'll report here and hope get some help. I have two development instances:
CentOS 6.5, PHP 5.5.16, MySQL 5.5.37
CentOS 7, PHP 5.6.0, MariaDB 5.5.37
I tried the same project in both instances and by same project I mean the same: copied without any vendor and in both instances run "composer update" at first. After composer updates the vendor I tried to access admin area, which is handled by, FOSUserBundle and surprise in the first instance it works without any problem but in the second one it does not work and I get this error:
Error! Warning: Erroneous data format for unserializing
'Tanane\UserBundle\Entity\User' in
/var/www/html/tanane/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php
line 872
Can any give me some advice around this? Is a Symfony bug or a FOSUserBundle bug? Or it's other thing and I don't see it?
Yes, this is a known problem, though it's not in FOSUserBundle. This problem is caused by Doctrine 2, the deserialization is broken there on creating a ClassMetadataInfo.
However, fixing this problem involves introducing some incompatibilities in Doctrine's architecture, so this won't be fixed until Doctrine 2.5 release at least.
Currently, the options are to switch back to PHP 5.5 or less or use a master version of Doctrine (the pull request fixing this does not seem to be tagged yet)
See this Doctrine Jira ticket for more info.
Related
I got the following error when trying to do composer install --no-progress within deployment:
1 packages have known vulnerabilities.
!!
!! symfony/http-kernel (v5.0.7)
!! ----------------------------
!!
!! * [CVE-2020-15094][]: Prevent RCE when calling untrusted remote with CachingHttpClient
!!
!! [CVE-2020-15094]: https://symfony.com/cve-2020-15094
Following this link provided in my error: https://symfony.com/blog/cve-2020-15094-prevent-rce-when-calling-untrusted-remote-with-cachinghttpclient
It navigates me to the following github link here: https://github.com/symfony/symfony/commit/ba3975329149cddebfe969f70b2577b0e37d1e76
What does that mean for local development and the fix associated to it? I tried following the link: src/Symfony/Component/HttpClient/Tests/CachingHttpClientTest.php
My project doesn't have that link
So how do I fix this issue? How does one update issues that come up moving forward? I'm using a mac set up.
The best way to move forward is to update to a later Symfony version. 5.0 is not maintained anymore, you can use 5.1 or 5.2. If you are not the one responsible for updating dependencies on the project, you may want to report this to the person who is.
If you look at the page linked in the error itself (https://symfony.com/cve-2020-15094) you can read:
The issue has been fixed in Symfony 4.4.13 and 5.1.5. Symfony 4.3 and 5.0 won't be patched as they are not maintained anymore.
To update Symfony you can follow this link: https://symfony.com/doc/current/setup/upgrade_minor.html
After the release of TYPO3 9.5.1, I have problems with my functional tests.
The package "backend" depends on "recordlist" which is not present in the system.
In TYPO3 9.5.0 there was a missing requirement in ext:backend for ext:recordlist
https://review.typo3.org/#/c/58575/
This is now merged into TYPO3 9.5.1 but this exactly gives me a problem on how I do my tests.
I shouldn't be needed for me to boot a full-blown TYPO3 to run my tests should it?
The tests and how it's done can be seen here:
https://travis-ci.org/AOEpeople/TYPO3-Google-Tag-Manager/jobs/448321932
https://github.com/AOEpeople/TYPO3-Google-Tag-Manager/blob/typo3v9/.travis.yml
Please help elaborate if I'm doing something wrong, or if the is a problem with the latest TYPO3?
The unittests isn't a Problem by the way, and ^7.6 and ^8.7 don't have any problems either.
It looks like this was an issue in nimut/testing-framework and was fixed 2 days ago. So you just need to update to version 4.1.4 or add recordlist to the $coreExtensionsToLoad in the meantime. Make sure to explicitly require typo3/cms-recordlist in case you test against older TYPO3 versions too.
I develop in symfony2 but am no sym2 wiz, brought in help to set everything up with the framework, and now it's throwing me a sudden error message I can't resolve.
I have two development environments, and one that I hadn't been using for a couple of months suddenly hit me with this error message upon trying to log in to my sym2 webapp locally:
"Erroneous data format for unserializing [user entity]"
I have not changed the code for logging in, I have not updated my vendors, and I have not changed any settings in MAMP (could it have updated itself though and done that?)
I don't understand what is going on.
I can google the error and I am suggested to hack one of the vendor source files. I would not know exactly what I would have done, so I am not comfortable with doing that just following some step-by-step instruction.
The application is running on symfony 2.3.9 and MAMP is set to PHP 5.6.27, the other option is 7.0.12 which produces the same error.
Ok, I changed my doctrine version to
"doctrine/orm": "~2.2,>=2.2.3,<2.5",
and it resolved the issue. Now I don't know what other issues THAT might have introduced seeing sym2 isn't always too backwards compatible, but fingers crossed =)
I am getting the infamous Doctrine "PHP Rename Access Denied Code 5" error in my Symfony2 project when logging in using the User entity:
\\app\\cache\\dev/doctrine/orm/Proxies\\__CG__AcmeDemoBundleEntityUser.php): Access is denied. (code: 5)
I will log in OK, and if I am lucky, I can load a page before the session is killed as a result of the user authentication failing as a result of this error. It only happens with this one entity.
My colleague, with the same set up and same project has the same error but for a different entity (and ONLY that entity).
This problem has been reported on here before, with a link to the bug on Doctrine's GitHub which was confirmed fixed as of 2.5 (confirmed in Doctrine ORM 2.5 Release Notes).
My Symfony2 project is running with Doctrine ORM 2.5.4 yet I am still getting the same error.
Attempted Fixes
Reinstall XAMPP;
Deleted project & pulled project from git;
Updated vendor projects (maybe an old Doctrine ORM package remained);
Closing PHPStorm (maybe it's locking the files for indexing);
Disabled Windows indexing (same reason as above).
Changing the value of auto_generate_proxy_classes from %kernel.debug% to false in config_dev.yml prevents the problem, but this hides the issue instead of fixing it.
Has anyone managed to actually fix this?
Have you tried to set up auto_generate_proxy_classes to a underlying constant value for AbstractProxyFactory::AUTOGENERATE_EVAL or AbstractProxyFactory::AUTOGENERATE_FILE_NOT_EXISTS.
According to this documentation section Advanced Configuration > Auto-generating Proxy Classes this should fix the access denied problem in development environment.
Also, you should make sure your production configuration follows this recommendation:
In a production environment, it is highly recommended to use AUTOGENERATE_NEVER to allow for optimal performances. The other options are interesting in development environment.
I am trying to update my project written in Symfony 2.0 into Symfony 2.2.
Moving source codes into 2.2 project ended with config.yml and security.yml incompatibiliy.
Is there way how to properly migrate Symfony 2.0 project into Symfony 2.2?
It better to wait until Symfony 2.3 before migrating. It will be released somewhere in May. It's the first LTS (Long Time Support) release, meaning that it's maintained for three years. So: You don't have to worry about BC breaks for 3 years!
For the migrating of Symfony 2.0 to 2.3: There is nothing you can do. Read the UPGRADE-*.md files (which are stored in the root of the symfony/symfony package) and fix anything that is in their in your code. Every BC break that's important for normal users will be put in those UPGRADE files.
If you can't solve it after the fixing everything in the UPGRADE files, you should take a look at the CHANGELOG.md files in the root of the package (e.g. the symfony/security package). Try to find something that is changed and cause your code to break.
Finally, if you don't get your script working, there are a lot of active Symfony2 users who are waiting to help you. Take a look at the community page and find your place to ask questions.