I'm new to Symfony and I'm looking at integrating a few bundles into my application, but all the bundles I find are for Symfony 2. How different are 2/3 and what sort of issues might I find myself in when I integrate them?
for example, i am looking at using this one: http://knpbundles.com/sonata-project/SonataAdminBundle
but it's only valid for Symfony 2 and I won't want to spend an age trying to integrate it and coming across incompatibility issues.
I will try to provide an answer although the question is very poor because it's much too broad.
Of course there is no general rule which Symfony based bundle will work in which Symfony version unless it's clearly stated in the available official documentation of the bundle.
A couple of indications:
Check the CHANGELOG, README etc files of your bundles. E.g. in the CHANGELOG of SonataAdminBundle you will find a lot of changes and bug fixes regarding Symfony > 3.0 - so this is a strong indication that Symfony > 3.0 is supported.
Check the composer.json of the bundle, if there's any. It might be the case that Symfony is required and you can find a semver version. E.g. for the Sonata Admin bundle there a lots of Symfony components required in composer.json. All of them state something like: "symfony/class-loader": "^2.3 || ^3.0" which means that it requires at least Symfony 2.3 or 3.0 - again a strong indication it'll work with Symfony > 3.0.
But in the end: dependency management is an all-timer issue and you'll have to check.
Most of Symfony 2.8+ bundles work out of the box with Symfony 3. Symfony 3 is not so different from the previous version.
You can easily check if a Bundle is not compatible with Symfony3 enabling it on version 2 and then looking for deprecations using the profiler.
[...] you can easily use a bundle from sf2 to sf3, but in deal with functionality of this bundle perhaps migration don't run correctly without upgrade of this bundle. The modification in bundle for run correctly in sf3 is not very important. But yes the migration is easy but not automatic. Warning at this point and read about which bundle for knowing is this bundle work with technical layer of sf3 and if little change code done for running into sf3.
The previous quote is taken from this SO answer about the same question
Related
The question:
Is a Symfony 3.4 project created with the Flex installer really Symfony 3.4? Or more a "Symfony 4 project with 3.4 core files?
The complete story:
I am working on migrating an existing Symfony 2.8 project to Symfony 3.4. At first I created a new Symfony 3.4 project using the Symfony installer:
symfony new MyProject 3.4
The file and folder structure is a bit different to Symfony 2.8 but overall everything is quite similar. It was not too difficult to migrate the config, files, etc. from the existing 2.8 project.
However, after some more research I thought it might be a good idea to start the new 3.4 project using the recommended Flex installer instead. This would give me the new folder structure which is also used in Symfony 4, which might make a future migration to this version easier.
composer create-project symfony/skeleton:3.4.* MyProject
Of course the directory structure is different in this project. But not only the folders are different but almost everything. The way the complete config is organized, how the routes are defined and managed, how bundles are organized (none at all), how parameters are defined and used, etc.
There is almost nothing left that looks like Symfony 3.4. This seems to be a Symfony 4 setup where only the files in vendor/symfony/... are from version 3.4
Migrating the 2.8 project to this setup would be way more complex.
Of course I know that a lot has changed in Symfony 4 while Symfony 3.4 is still quite similar to Symfony 2.8. But how is it possible that two Symfony 3.4 installations are so dramatically different?
I understood that Flex is a new workflow to manage projects but shouldn't be the end result - a new Symfony 3.4 project - be more or less the same no matter which workflow / install was used to create it?
Flex is more powerful when setting up and managing different project. However I want to setup the project once and run it for several years. Is there any advantage (in the near future) in proceeding with the Flex approach?
To answer your first question: Yes, a Symfony 3.4 project created using Flex is indeed a 3.4 project. "bin/console --version" will verify this.
As far as the directory structure goes, Symfony tries to strike a balance between maintaining backwards compatibility but at the same time keep moving forward and refining their design. For information on why things were done, it is useful to keep an eye in the Symfony blog and perhaps visit the slack channel. Especially the posts when Flex was introduced as well as the new directory structure.
One goal for Symfony is to make it as easy as possible to migrate from a long term support version to a newer version. Hence 2.8 is pretty much identical to 3.0 except that a bunch of depreciated functionality was removed. If you were following things at the time you would have noticed that there was quite a big jump between 2.7 and 2.8.
Same for 3.4 to 4.0 being easy but a few possible bumps going from 3.0 to 3.4.
Kind of meandered a bit. Sorry.
To address your second question of the value of using Flex, like all opinion based questions the only correct answer is: it depends.
In my case the choice to use the new directory structure was easy. I have a number of apps and use Symfony on a daily basis. Keeping up with the latest and greatest makes sense for me. Spending the time to port apps (some of them dating back to 2.3) to 4.0 makes my overall maintenance burden easier. The time spent experimenting how to port helped me understand the new functionality. Once I got comfortable with the process it was really just copy/paste/rename exercise for the most part. The hardest was making sure some of the 3rd party dependencies were properly updated.
In your case, it seem like you only have one app and you just want to get it updated and then forget about it for a few years. In that case, keep the old structure and move on. At some point you might need to move to the new structure but waiting a few years won't hurt anything. And hey, I suspect 5.0 will introduce more changes.
The choice is yours.
Symfony Flex is the new way to install and manage Symfony applications. Flex is not a new Symfony version, but a tool that replaces and improves the Symfony Installer and the Symfony Standard Edition.
Symfony Flex automates the most common tasks of Symfony applications, like installing and removing bundles and other Composer dependencies. Symfony Flex works for Symfony 3.3 and higher. Starting from Symfony 4.0, Flex should be used by default, but it is still optional.
Source : https://symfony.com/doc/3.4/setup/flex.html
I'm looking for some examples on how to set up a Symfony app with multiple kernels. I only found one example, but it's for Symfony 2.2 and not working for Symfony 3.x.
Does anyone have an example or some GitHub code to share on how to get that working with best practice approach?
I am developing a web application using Zend Framework 2 and Doctrine 2. I'm new to Doctrine 2 in general and Migrations in particular. I was wondering if there are any recommended best practices in using this. Some specific things I'm looking for:
A recommended workflow from development to deployment?
Do you include pre-populating data in migrations?
How to handle reverting to a previous version if migration fails.
Many thanks!
Doctrine has own library for migrations, that includes also Symfony bundle.
For Zend there probably is some bundle as well (maybe seek on Github a bit more)
As for your specific questions:
Nothing special. Basic workflow is nicely described in Symfony bundle documentation. We use it in pretty same way even in a different framework.
Yes, so every developer has fully operational system. For tests we use data-fixtures with minimal required data only.
It's managed by this package itself.
The Doctrine ORM module for ZF2 (DoctrineORMModule) has built-in support for Doctrine ORM migrations. There's a very brief blurb in the documentation about how to configure it. You can then access the migration commands (generate, migrate, etc) through the CLI interface that module provides (vendor/bin/doctrine-module)
As for my personal workflow I generally put initialization or pre-population data - the stuff you initially seed a new installation with - into database fixtures (which Doctrine ORM also supports and there is a ZF2 module for).
I am trying to upgrade the Doctrine library in my Zend application from version 2.0.6 to 2.3. I assumed this would just involve copying the over the newer library files over the existing library - provided there are no major changes which would require me to change my application code.
However, I downloaded a zip from their GitHub page and found that the directories in the 2.3 differ greatly to the Doctrine version I currently have installed (consists of Common, DBAL, ORM and Symfony folders whereas 2.3 is completely different). I can't find anything on the difference in these folders, maybe I'm just really slow.
In my existing set up, I am not using any third party libraries to integrate Doctrine, most of it is done through autoloading in Bootstrap.php.
After several unsuccessful attempts to upgrade the Doctrine library, I decided to follow this tutorial based on the assumption that it will handle the unfamiliar directory structure of the Doctrine I downloaded. However further down the page this tutorial also refers to the Doctrine library as having the four folders that I have in my existing set up, which doesn't match the newer version of Doctrine.
Would sincerely appreciate it if someone could point me in the right direction or tell me where I am going wrong.
ps I am using Zend 1.11
I see three ways:
Use composer.
You can use Doctrine as Git Submodule. You'll get only Doctrine\ORM. Other libraries you get through its Submodules.
Download all the libraries separately: Doctrine\ORM, Doctrine\Common, Doctrine\DBAL, Symfony\Component\Console, Symfony\Component\Yaml
It seems that Symfony 2 is finally stable (correct me if I'm wrong) and I wish to transfer my projects from 1.4 to 2.0.
I checked google and symfony.com but there is no info about this topic. My guess that the framework got rewritten so deeply that no automatized tool can handle this.
Any ideas or guidelines?
Your guess is right, there is no automated tool that can convert your 1.4 project to 2.0, because the structure of the framework, although still MVC of course, is quite different to the 1.X versions.
You can see some of the key differences in this page of the Symfony2 Cookbook.
Also, bear in mind that Symfony2 requires PHP 5.3.2 or higher.
My advice would be, if your projects are finished and running in Symfony1.4, let them be, they'll be just fine, and start learning Symfony2 ;)