I'm trying to upgrade our app's Symfony 3.4 to 4.0, and going through fixing deprecation warnings (as recommended by Symfony devs), and I'm stuck trying to fix the Sensio warnings, as it's abandoned, and I'm not quite sure what the app is going to lose when I remove Sensio... all I know is it runs a bunch of scripts after composer install or update:
"post-install-cmd" and "post-update-cmd" lines:
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::prepareDeploymentTarget"
Whenever I look up those commands, I just end up in circular rabbit holes that don't explain what those commands do exactly, and my only option appears to be to just remove Sensio and hope for the best, or go through each script's PHP code... which are their own rabbit holes.
Was the documentation for this removed? Did it never exist?
I can sort of understand some of what it's doing (and I think cache is not relevant anymore), but there's some assets stuff in the app I'm not familiar with (like a committed vendor folder for node packages, which I know is a bad thing to commit), and without some heavy tracing, I don't know what all Sensio's doing.
Related
I've been trying to create and setup a project under Symfony 4.4 for a few hours now but it seems like i'm getting a problem when i'm downloading bundles or installing things (For example, Doctrine or FOSrest).
Multiple times in tutorials I've seen that all the people seemed to have files such as "Doctrine.yaml" which are supposed to be stored in config/packages. And it seems like these configuration files are automatically created upon downloading the files associated to it.
But in my case there's simply... nothing, I have to create manually all the files, and i'm not sure if that's normal and if not, how can I resolve this problem ?
And it seems like these configuration files are automatically created upon downloading the files associated to it.
You're looking for the Symfony recipes which allow composer packages via Symfony/flex to automate common tasks when you install a new bundle.
A more detailed explanation regarding how does flex work you'll find in the official documentation here when it was first introduced in Symfony 3.4, but note that is not maintained anymore for this version.
I corrected it. I simply was being too dumb. When I created the git repository, I did the installation wrong and I didn't immediatly notice that I was downloading things into the wrong repository.
Thanks for all the answers!
I am starting a new Symfony project. After I type:
symfony new project-name
I see that the new project is created but I don't find the Assetic bundle inside the project. Also if I try:
app/console
I don't find the following commands:
assetic:dump
assetic:watch
Could somebody help me? What am I doing wrong. Is something wrong with the files I download?
The Assetic Bundle isn't included since SF 3.2. I think this is caused by some compatibility issues.
You can add them manually to your composer.json
"symfony/assetic-bundle": "~2",
And add the new Bundle to your Kernel.
new Symfony\Bundle\AsseticBundle\AsseticBundle(),
Then it should work. I use SF 2.8 and its working. There are some deprecation warnings and i don't know if its working under SF3.
AsseticBundle was only removed from the standard distribution in 2.8. This means that if you wish to use Assetic, you may still do so, by including the dependency manually, by running:
composer require symfony/assetic-bundle
And adding the bundle in your AppKernel:
new Symfony\Bundle\AsseticBundle\AsseticBundle(),
One thing to know, though. AsseticBundle has not yet been migrated to 3.0.
Thus, you won't be able to use it (for now) if you wish to start a 3.0 project.
That's also the case for quite a few bundles (and among them the Sonata bundles), and even though some developers have started work on migrating to 3.0 release before the official release, last week, some bundles still need quite a lot work to be made compatible with 3.0.
Hopefully, AsseticBundle (and other) should be migrated over the next months. Or if you're impatient, you can still contribute to Assetic, or AsseticBundle! ;)
Edit: AsseticBundle should be tagged by the end of the month, if not before, as stof said in this issue: https://github.com/symfony/assetic-bundle/issues/401
I recently downloaded a new symfony2 package for websockets and included it into my composer file,
when I called
php composer.phar update
It automatically updated my Symfony version and I was wondering if updating Symfony2 will break the website in the long run, since part of my source code could become obsolete (deprecated)
Yes, if composer downloads a version of a dependency that's not backward compatible with the version that you used to develop your website, things might/will break.
However, you can limit the possibility by defining good rules in your composer.json.
First of all, it might be good to learn about semantic versioning if you haven't heard of it already. Many projects are following the rules of semantic versioning, which basically state that if a project/library has changed in a way that is not compatible with earlier versions, it's main version number should be incremented. For instance, if 1.5.x had a certain feature, and an update is made where that feature is changed or no longer available, the new version number should be 2.0.x instead of 1.6.x.
Knowing this, you can use Composer's tilde operator (~) to define useful version constraints. For instance, to add the dependency to symfony's files, you can add the following requirement to your composer.json:
"symfony/symfony": "~2.3"
which is equivalent to:
"symfony/symfony": ">=2.3,<3.0"
or, in plain English: 'give me a version of symfony/symfony, at least version 2.3 or higher, but lower than 3.0'. If Symfony follows semantic versioning correctly, no backward incompatible changes should be made in any 2.x versions (and, if any backward incompatible changes are made, they should come with version 3.0), so you should be fine.
This actually depends on how your composer.json is configured. If your dependencies use SemVer, and you are referencing them in your composer.json only allowing patch version changes (like "package-name": "1.1.x"), then everything should usually be fine.
Also, note that you can pass a package name as a parameter to the composer update command, e.g. php composer.phar update <vendor/dependency-name>. This will tell Composer to only check if there are updates available to <dependency-name> package, given your current composer.json version constraints.
If you want to check that nothing is broken after an update and you're not keeping the update scope as narrow as I specified, then something could break. The best way to detect and avoid this is by testing.
You should read about composer.lock file. This will make sure that Composer will not update any version of the repository and only what you specify in the lock file
I'm developing an application, using Symfony 2.3, which will have to be installed for different customers. We will offer different features so the idea is to have the features/bundles separate from the main app and load the into the project using composer. As we are using Doctrine Migrations to maintain DB changes across versions I'm unsure on how to go about using them from a bundle. We're using Capifony to deploy the app to the live server.
So my question is... how can I automatize the execution of migrations from composer loaded bundles?
I ended up creating a command that will copy all migration files from predefined directories in bundles to the default location and then executing doctrine:migrations:migrate from within the command.
For a complex deployment, I used phing. He easily integrate with the Symfony console. But in the end I use of a simple code on the Synfony console.
Composer can easily call Symfony app commands as "post-install-cmd"
I don't think "composer loaded bundles" is the issue here. For instance, you could have several bundles in src/ (part of the app or submoduled) and have the exact same problem. The issue is having multiple entity managers and databases for your different bundles. Where they actually reside is trivial.
Anyway, I'm having the exact same problem. After some searching, I discovered there is actually an open pull request to fix this: https://github.com/doctrine/DoctrineMigrationsBundle/pull/46
I'm hoping it gets fixed soon!
How can I create a new project that only uses the Symfony2 Console component?
I haven't been able to figure out the most basic setup I would need to do, to just use the Console component (and any other must-have dependencies).
Where should I place the component files, and what do I need to include in my own code file?
The online tutorials are seriously lacking in detailed step by step explanations on how to use the various components as stand-alone components, and not as a part of the Symfony standard distribution.
Solution Found:
I've created a detailed step-by-step guide on how to use the Symfony 2 Console Component in your project. I hope this helps fill the documentation void.
Well one of the easiest ways would be to use Composer. Youd set up a composer.json in the root of your project and then just invoke composer.phar install from the command line.
Example composer.json for console:
{
"require": {
"symfony/console": "2.*"
}
}
After that you can just include the composer autoloading and you should be good to go.
// in your bootstrap or what have you
require 'path/to/project/root/vendor/.composer/autoload.php';
That jsut gets everything set up and ready to use though... you still need to figure out how to integrate it in a way that makes sense within your project. You might actually take a look at Composer itself or Doctrine 2 for some idea of how to do that since they both use it as their console interface.
Also just some validation... you arent the only one annoyed by the lack of documentation on using the standalone components outside the full stack. :-)