Quelle est la nouvelle structure de répertoire de Symfony 3 ?

Question

Je viens de créer un nouveau projet Symfony 2.5 avec une commande normale de compositeur :

php composer.phar create-project symfony/framework-standard-edition path/ 2.5.0

Le Terminal me demande :

Vous souhaitez utiliser la structure de répertoire de Symfony 3 ?

Qu'est-ce que c'est ? Structure des répertoires de Symfony 3 ? Je ne l'ai jamais vu auparavant... C'est nouveau depuis la 2.5 ?

Quels sont les avantages de son utilisation ?

Y a-t-il un moyen de reproduire cette structure de répertoire ?

Answer 1

Je veux utiliser la nouvelle structure de répertoire de Symfony 3, mais je ne vois pas la question ?

La question Would you like to use Symfony 3 directory structure? a été supprimé lors de la création d'un nouveau projet en raison de la confusion qu'il provoquait. Vous pouvez forcer l'utilisation de la structure de répertoire en utilisant ce qui suit :

Si vous préférez la nouvelle structure, vous pouvez ajouter la variable d'environnement SENSIOLABS_ENABLE_NEW_DIRECTORY_STRUCTURE à votre .bashrc o .bash_profile comme ça :

Faire en sorte que tous les projets futurs demandent la nouvelle structure

# .bash_profile
# ALL new composer installs will ask `Would you like to use the new Symfony3 strucure?`
export SENSIOLABS_ENABLE_NEW_DIRECTORY_STRUCTURE=true

Faites que SEUL CE projet demande si nous voulons utiliser la nouvelle structure.

Si vous ne le voulez que pour un projet particulier (unique), vous pouvez l'utiliser :

SENSIOLABS_ENABLE_NEW_DIRECTORY_STRUCTURE=true composer create-project symfony/framework-standard-edition path/ "2.5.*"

Si la variable d'environnement SENSIOLABS_ENABLE_NEW_DIRECTORY_STRUCTURE est réglé et réglé sur true , composer vous demandera si vous voulez utiliser la nouvelle structure de répertoire.

Continuez à lire ci-dessous pour connaître tous les changements entre le Symfony2 y Symfony3 structure des répertoires.

---

Quelle est la nouvelle structure de répertoire de Symfony 3 ?

(et comment cela m'affecte-t-il, moi et mon flux de travail)

Je me suis penché sur la question en créant 2 projets, l'un avec symfony-2.5.0 structure de répertoires, l'un avec symfony-3 (changement de structure de répertoire uniquement).

Faites un exemplaire de chaque projet :

# say `N` to `Would you like to use Symfony 3 directory structure?`
$ composer create-project symfony/framework-standard-edition symfony-2.5.0/ 2.5.0

# say `Y` to `Would you like to use Symfony 3 directory structure?`
$ composer create-project symfony/framework-standard-edition symfony-3/ 2.5.0

Nous avons donc maintenant les deux répertoires différents que nous voulons comparer.

---

Trouvez le diff érence

Vous pouvez diff entre les 2 répertoires en utilisant :

$ diff -rq symfony-2.5.0/ symfony-3/
/** (Returned from the diff)
Files symfony-2.5.0/.gitignore and symfony-3/.gitignore differ
Files symfony-2.5.0/.travis.yml and symfony-3/.travis.yml differ
Only in symfony-2.5.0/app: bootstrap.php.cache
Only in symfony-2.5.0/app: cache
Only in symfony-2.5.0/app: console
Only in symfony-2.5.0/app: logs
Only in symfony-2.5.0/app: phpunit.xml.dist
Only in symfony-3/bin: console
Only in symfony-3/bin: symfony_requirements
Files symfony-2.5.0/composer.json and symfony-3/composer.json differ
Only in symfony-3/: phpunit.xml.dist
Only in symfony-3/: var
Files symfony-2.5.0/vendor/autoload.php and symfony-3/vendor/autoload.php differ
Files symfony-2.5.0/vendor/composer/autoload_real.php and symfony-3/vendor/composer/autoload_real.php differ
Files symfony-2.5.0/web/app.php and symfony-3/web/app.php differ
Files symfony-2.5.0/web/app_dev.php and symfony-3/web/app_dev.php differ
*/

Cela montre les fichiers qui diffèrent dans les 2 versions.

---

Répartition de diff

Voici la répartition de tout ce qui se trouve dans le différentiel.

# These files still exist in both versions (with different content)
.gitignore
.travis.yml
composer.json
vendor/autoload.php
vendor/composer/autoload_real.php
web/app.php
web/app_dev.php

# The following files have been removed from 2.5.0
# {RemovedFile2.5}      |  {ReplacedWith3.0}
app/cache               |  var/cache
app/logs                |  var/log
app/bootstrap.php.cache |  var/bootstrap.php.cache
app/console             |  bin/console
app/phpunit.xml.dist    |  phpunit.xml.dist

# The following files are new in 3.0
bin/symfony_requirements # run via CLI

---

Avantages de la structure de répertoire de Symfony 3

La nouvelle structure de répertoire présente un certain nombre d'avantages, qui sont tous mineurs et peuvent nécessiter des modifications minimes de votre flux de travail.

PHPUnit

phpunit peut être exécuté à partir de la racine du projet sans avoir à spécifier explicitement le chemin du fichier de configuration.

# Symfony2
phpunit -c app/phpunit.xml

# Symfony3 (no need to specify the configuration file location)
phpunit

Exécutables binaires

Tous les fichiers exécutables binaires se trouvent désormais dans un seul et même endroit - le fichier bin répertoire (similaire à un os de type unix) .

# you can update your `PATH` to include the `bin` directory
PATH="./bin:$PATH"

# From your project root you can now run executables like so:
console
symfony_requirements
doctrine

# else with no `PATH` update
bin/console
bin/symfony_requirements
bin/doctrine

Le nouveau /var répertoire

Le nouveau /var Le répertoire contient les fichiers dans lesquels le système écrit des données au cours de son fonctionnement. (similaire à un os de type unix) .

Cela permet également de faciliter l'ajout de permissions, l'ensemble de la /var doit être accessible en écriture par votre serveur web. Vous pouvez suivre le Guide Symfony2 pour la définition des permissions (en substituant app/cache && app/logs con var ), tous les autres fichiers que vous souhaitez écrire localement pourraient également être situés ici.

# default symfony3 `var` directory
var/bootstrap.php.cache
var/cache
var/logs

Vérification des exigences de Symfony

Running symfony_requirements affichera les configurations d'environnement obligatoires et facultatives.
par exemple

********************************
* 'Symfony requirements check' *
********************************

* Configuration file used by PHP: /usr/local/php5/lib/php.ini

/** ATTENTION **
*  The PHP CLI can use a different php.ini file
*  than the one used with your web server.
*  To be on the safe side, please also launch the requirements check
*  from your web server using the web/config.php script.
*/

** Mandatory requirements **
'
 OK       PHP version must be at least 5.3.3 (5.5.11 installed)
 OK       PHP version must not be 5.3.16 as Symfony wont work properly with it
 OK       Vendor libraries must be installed
 OK       var/cache/ directory must be writable
 OK       var/logs/ directory must be writable
 OK       date.timezone setting must be set
 OK       Configured default timezone "Europe/London" must be supported by your installation of PHP
 OK       json_encode() must be available
 OK       session_start() must be available
 OK       ctype_alpha() must be available
 OK       token_get_all() must be available
 OK       simplexml_import_dom() must be available
 OK       APC version must be at least 3.1.13 when using PHP 5.4
 OK       detect_unicode must be disabled in php.ini
 OK       xdebug.show_exception_trace must be disabled in php.ini
 OK       xdebug.scream must be disabled in php.ini
 OK       PCRE extension must be available
'
** Optional recommendations **
'
 OK       xdebug.max_nesting_level should be above 100 in php.ini
 OK       Requirements file should be up-to-date
 OK       You should use at least PHP 5.3.4 due to PHP bug #52083 in earlier versions
 OK       When using annotations you should have at least PHP 5.3.8 due to PHP bug #55156
 OK       You should not use PHP 5.4.0 due to the PHP bug #61453
 OK       When using the logout handler from the Symfony Security Component, you should have at least PHP 5.4.11 due to PHP bug #63379 (as a workaround, you can also set invalidate_session to false in the security logout handler configuration)
 OK       You should use PHP 5.3.18+ or PHP 5.4.8+ to always get nice error messages for fatal errors in the development environment due to PHP bug #61767/#60909
 OK       PCRE extension should be at least version 8.0 (8.34 installed)
 OK       PHP-XML module should be installed
 OK       mb_strlen() should be available
 OK       iconv() should be available
 OK       utf8_decode() should be available
 OK       posix_isatty() should be available
 OK       intl extension should be available
 OK       intl extension should be correctly configured
 OK       intl ICU version should be at least 4+
 OK       a PHP accelerator should be installed
 OK       short_open_tag should be disabled in php.ini
 OK       magic_quotes_gpc should be disabled in php.ini
 OK       register_globals should be disabled in php.ini
 OK       session.auto_start should be disabled in php.ini
 OK       PDO should be installed
 OK       PDO should have some drivers installed (currently available: mysql, sqlite, dblib, pgsql)
'

---

Conclusion

Il semble que Sensio Labs ait fait un bon nettoyage, toutes les modifications ci-dessus sont parfaitement logiques, elles devraient être faciles à mettre en œuvre lors de la mise à jour de l'application. 2.5 a 3.x ces derniers seront probablement le dernier de vos problèmes !

Lisez les documents

Documentation sur la mise à niveau de Symfony 2.x => 3.0 ici
Symfony 3.0 L'architecture

Date de sortie de Symfony 3

Il semble loin en regardant le processus de libération (à lire) :

http://symfony.com/doc/current/contributing/community/releases.html

_{(source : <a href="https://symfony.com/doc/current/_images/release-process.jpg" rel="nofollow noreferrer">symfony.com </a>)}

Answer 2

Voici une liste des changements entre l'ancienne et la nouvelle structure de répertoire :

• Une nouvelle var le dossier est introduit
• app/console est déplacé vers bin/console
• app/check.php est déplacé/renommé en bin/symfony_requirements
• app/phpunit.xml.dist est déplacé vers le dossier racine
• app/SymfonyRequirements.php est déplacé vers var/SymfonyRequirements.php
• le site app/cache y app/logs ont été déplacés vers var/cache y var/logs respectivement

(Actuellement, tous les anciens fichiers ne semblent pas être supprimés, vous pouvez donc le faire manuellement avant de valider tous les fichiers dans le contrôle de version. Voir cette question )

Alors, quel est l'avantage ?

Ces changements présentent un certain nombre d'avantages. Tout d'abord, tous les fichiers et dossiers qui devraient être accessibles en écriture pour Symfony se trouvent maintenant dans le répertoire de l'utilisateur. var dossier. Cela devrait rendre la configuration des permissions beaucoup plus facile : il suffit d'assurer l'accès en écriture au dossier var et le tour est joué. Ceci est suggéré dans cet article de blog - Je n'ai pas encore essayé moi-même.

Deuxièmement, tous les exécutables, y compris console sont maintenant dans le bin dossier. Cela permet aux utilisateurs de Bash, par exemple, de l'ajouter à leur dossier .profile fichier :

# set PATH so it includes current bin folder
PATH="./bin:$PATH"

Maintenant, vous n'avez même pas à taper bin/console plus, simplement console suffira (notez que j'ai dû redémarrer pour que cela fonctionne).

D'autres améliorations ont également été apportées. app/check.php est maintenant un exécutable, donc vous pouvez l'appeler en utilisant bin/symfony_requirements au lieu de php app/check.php . (En utilisant le .profile l'astuce que j'ai décrite plus tôt, simplement symfony_requirements suffira également)

Et, last but not least, vous n'avez plus à spécifier l'emplacement du fichier de configuration lorsque vous exécutez PHPUnit. Ainsi, au lieu de phpunit -c app vous pouvez simplement exécuter phpunit .

Puis-je également mettre à niveau les projets existants vers cette nouvelle structure ?

Par défaut, vous n'obtiendrez la question "Voulez-vous utiliser la nouvelle structure de répertoire" que lors de la création d'un nouveau projet (en utilisant l'option composer create-project symfony/framework-standard-edition path/ "2.5.*" ).

Il est toutefois possible de mettre à niveau une application Symfony existante, mais il s'agit d'une solution un peu artisanale. J'ai réussi à le faire avec un certain nombre d'applications maintenant, et vous pouvez lire les étapes dans ce texte . Cependant, comme il n'a pas été conçu pour cela, je ne peux pas garantir qu'il fonctionnera toujours.

Mise à jour

Il s'avère que Symfony ne vous demande plus si vous voulez utiliser la nouvelle structure de répertoire, lorsque vous créez une nouvelle application Symfony via Composer. Cependant, il est toujours possible de créer des projets Symfony avec la nouvelle structure de répertoire, en utilisant une variable d'environnement. Pour plus d'informations, voir Comment puis-je créer un nouveau projet Symfony avec la nouvelle structure de répertoire ?