I installed the following packages on a symfony 2.8 project because I want to upgrade to version 3.4 to take advantage of the LTS
"propel/propel-bundle" : "4.0.x-dev",
"propel/propel" : "2.0.x-dev",
I search how to declare a behavior, before I was on version 1 of Propel, and to declare a behavior, it was enough to do that in the config.yml :
behaviors:
my_behavior: MyBundle\MyBehavior
The problem is that this configuration does not work anymore with the version 2, I can not find quite precise documentation on how to declare a propel behavior because the goal here is to then use it in the schema.xml like this :
<behavior name="geo_location"></behavior>
The goal is to run : propel:model:build but when I run this command, I get this error message :
Unrecognized option "behaviors" under "propel.database"
Have a look at this manual page. Long story short, you have to create a composer package with the type "propel-behavior" to be able to use your behavior in your project.
If you are having trouble, figuring it out, look up some existing behaviors on github to see how it is done.
Examples of cusotm behaviors can be found here.
Related
I've installed D9 plus devel and created a custom theme (with all the necessary files, works nicely) and enabled all the necessary dev-centric settings, but it seems that the necessary functions like dd() or drupal_dump() are not found. I've already checked that everything related to the devel module (devel, devel generate, devel web profiler) is enabled in my Drupal.
Any help appreciated!
drupal_dump(), alias dd(), is not provided by devel, but by another module named twig_tweak. It requires Symfony's VarDumper component to work. You can install them using composer :
composer require --dev symfony/var-dumper
composer require drupal/twig_tweak
drush en twig_tweak
ddm() doesn't print anything to the screen but outputs a variable to a file named drupal_debug.txt in the site's temp directory.
More on devel functions here.
Long story
In drupal 7.x and up to version 8.6.0, dd() was indeed provided by the devel module, but it was an alias for drupal_debug() (d7) and DevelDumperManager::debug() (d8), but it has been deprecated and replaced by ddm() since 8.6.0, because Symfony's VarDumper component already has a function named dd().
Now to add further confusion, twig_tweak is using the alias dd() for drupal_dump() (source).
Even if both functions end up calling Symfony's VarDumper::dump(), Symfony's dd means "dump and die" and is meant to immediately ends the execution of the script after dumping the variables, whereas twig_tweak's drupal_dump/dd does not.
The exact same thing happens in Laravel : it uses Symfony's VarDumper and overrides its dd function with a function that doesn't behave the same, instead of using a different name.
As far as i can tell, i can't see any other questions that ask this, so here goes:
I've been running the latest Symfony, for a side project, and encountered this error as i was writing the app. Nothing i do now fixes it, not even re-installing symfony, and i have no idea what the problem even is. I am getting the error:
The parameter "doctrine_migrations.dir_name" has a dependency on a
non-existent parameter "kernel.root_dir". Did you mean one of these:
"kernel.project_dir", "kernel.cache_dir", "kernel.logs_dir"?
It seems that you are using the undefined kernel.root_dir variable in your config/packages/doctrine_migrations.yaml config file.
You should replace it by kernel.project_dir:
# config/packages/doctrine_migrations.yaml
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/Migrations'
See: https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html#configuration
Just to document the root cause.
Symfony 5 removed kernel.root_dir parameters. Doctrine Migrations Bundle uses it as default value for dir_name.
It's been discussed. See https://github.com/doctrine/DoctrineMigrationsBundle/issues/305 and https://github.com/doctrine/DoctrineMigrationsBundle/pull/295.
SOLUTION: right now (Symfony 5 and Migrations bundle 2.1.x), you should not delete doctrine_migrations.yaml. Leave it there with a dir_name that does not raise en error.
at this point i am assuming it is a symfony bug, so i will close this question. Thanks for everyone's help!
try
composer remove orm
composer require symfony/orm-pack
when I try to run a failed test with this command :
./vendor/bin/phpunit
I get this Fatal Error :
PHPUnit 5.7.20 by Sebastian Bergmann and contributors.
PHP Fatal error: Class 'PHPUnit\Framework\ExpectationFailedException'
not found in /var/www/zend/vendor/zendframework/zend-
test/src/PHPUnit/Controller/AbstractControllerTestCase.php on line 444
Your version of phpunit is probably too old for your version of Zend. The class PHPUnit\Framework\ExpectationFailedException have been renamed in PhpUnit 6.X from PHPUnit_Framework_ExpectationFailedException to ExpectationFailedException
Please check your PhpUnit version: phpunit --version, it should be 6.X. Update it to the last version to avoid this error.
This is "fixed" by a script in Zend\Test called phpunit-class-aliases.php but it's not configured properly IMHO since it's in the autoload-dev section (meaning it doesn't propagate out to other projects.)
So, in your project composer.json, do something like this:
"autoload-dev": {
"files": [
"vendor/zendframework/zend-test/autoload/phpunit-class-aliases.php"
]
},
Then composer install
N.B. Zend\Test has a pull request that fixes this very thing, but they're saying it's PHPUnit's fault (Shame on you PHPUnit 4 for... idunno... having the wrong class name according to Zend\Test) So, I've done it instead: composer require illchuk/phpunit-class-aliases
This is a configuration flaw in zend-test. It consumes classes from Phpunit 6 but per it's Composer requirements, Phpunit before that version are OK to require:
"phpunit/phpunit": "^4.0 || ^5.0 || ^6.0",
Most likely as your system because of the PHP version does not satisfy the requirements of Phpunit 6, the next lower version was installed.
As the code in the base test case (https://github.com/zendframework/zend-test/blob/master/src/PHPUnit/Controller/AbstractControllerTestCase.php#L444) makes use of Phpunit 6 classes, I strongly assume that when the configuration flaw is made aware to the Zend-Test project, you won't be even able to install on your system any longer.
Therefore upgrade to a recent PHP version and then run
composer update
If you're stuk with the PHP version, downgrade zend-test to a version that supports an older Phpunit version. I don't know that project well, so it's just a suggestion, I don't know if such a version exists or can't even recommend one.
I filed a report, perhaps using that one class was an oversight or there is a less hard way to resolve the dependency: https://github.com/zendframework/zend-test/issues/50
I'd like to install liip/imagine-bundle in my symfony 2 project. But in order to make barcodes, I installed previously MopaBarcodeBundle.
MopaBarcodeBundle requires "avalanche123/imagine-bundle" which requires imagine/imagine: v0.4.1
And
LiipImagineBundle requires imagine/imagine: ~0.5,<0.7
Obviously composer detects the conflict, as he cannot unistall v0.4.1, and that version is not enough for LiipImagine.
I'd like to know how I could bypass this. Create sorts of aliases in composer and keep the two versions on my project ? I'm not a pro in version management, so I guess this is not possible.
Thank you very much for any help.
Ok, after some code inspection i figured out a way around. MopaBarcodeBundle doesn't really requires avalanche123/imagine-bundle, but it uses it in the service declaration. (To make the link with Imagine classes).
So I changed the service.xml file containing the BarcodeService declaration.
<parameter key="imagine.gd.class">Imagine\Gd\Imagine</parameter>
<service id="imagine" alias="imagine.gd" />
<service id="imagine.gd" class="%imagine.gd.class%" />
I guess thoses lines could be factorised, but i chose to keep it as it was done in avalanche123.
Also a constant from avalanche was used in 5th argument, I changed it to :
<argument>%kernel.root_dir%../web</argument>
Finally I removed avalanche, and then install a newer version of imagine/imagine
After installing Yosemite and a new version of MAMP
and when I'm trying to execute
domain/app_dev.php/es/venues/3/show
This route is rendering a form containing a language type field, so it's requiring ICU.
being 'es' the locale i get errors. If I changed it to 'en' there's no problem.
The errors are:
[1/2] ResourceBundleNotFoundException: The resource bundle
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/root.php"
does not exist.
[2/2] Couldn't read the indices [Languages] from
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/es.res".
The indices also couldn't be found in the fallback locale(s)
"root.res".
My symfony version is 2.5, I'm running the MAMP PHP 5.5.10.
I updated dependencies via composer, including "symfony/intl": "*",
I have followed several webs in order to install icu and intl via pecl. But still get the error. I don't know how to check if the installations or the configs are ok. Maybe you can let me know how to test both via terminal and let you know what is the result...
This is because you are trying to get resources only for language es. But now (from the moment of importing to Symfony icu data) you need to get language resources via language and country codes es_ES.
You may not be able to just simply activate intl.so after the Yosemite update. I solved the issue installing intl.so following an excellent article by Danilo Braband http://dab.io/posts/getting-started-with-symfony-on-yosemite.html
Solved updgrading to Symfony 2.5.6