#symfony3

[741ru5c0d3r]

Me gusta twig porque puedes organizar de mejor manera cada una de las partes visuales, así es mas fácil de mantener y modificar.

[kyleondemand]

Symfony and Docker gotcha #1

When mounting a Symfony 3 into a docker environment, make sure to not exclude the entire var folder in any way. Whether that’s through selective COPY / ADD commands, or the .dockerignore. Becuase if the {approot}/var folder is missing when running any composer command and composer then runs the post-cmd maintenance scripts, such as Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache or Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets, it will straight up spit out an error that says: 

Could not open input file: app/console Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets handling the symfony-scripts event terminated with an exception [RuntimeException] An error occurred when executing the "'assets:install --symlink --relative '\''web'\'''" command: Could not open input file: app/console

On close inspection, you may miss that it’s attempting to call the console via app/console instead of bin/console.  Why is this? 

Because in those two particular maintenance scripts, they call a function that acquires the directory of the console.

$consoleDir = static::getConsoleDir($event, 'install assets');

Inside of getConsoleDir() it calls a function inside of a conditional that looks like this:

if (static::useNewDirectoryStructure($options)) {

This useNewDirectoryStructure() static call poses a very simple question, "does this app have a var folder?"

protected static function useNewDirectoryStructure(array $options) { return isset($options['symfony-var-dir']) && is_dir($options['symfony-var-dir']); }

And if the answer is no, as in the var folder is indeed missing, well, getConsoleDir() returns back the old Symfony2 "app" directory

protected static function getConsoleDir(Event $event, $actionName) { $options = static::getOptions($event); if (static::useNewDirectoryStructure($options)) { if (!static::hasDirectory($event, 'symfony-bin-dir', $options['symfony-bin-dir'], $actionName)) { return; } return $options['symfony-bin-dir']; } if (!static::hasDirectory($event, 'symfony-app-dir', $options['symfony-app-dir'], 'execute command')) { return; } // ALL ELSE FAILS, USE APP DIRECTORY LOL ~Kyle return $options['symfony-app-dir']; }

Sometimes, backwards compatibility can be a true nuisance. I wonder what this looks like for Symfony 4?

[ikonenn-blog]

FETCH_CLASS, problème de namespace et de casse

Au commencement, un FETCH_CLASS qui échoue, au final un comportement inexplicable lié à la casse de namespaces.

Au commencement, un FETCH_CLASS qui ne fonctionnait pas

Alors je vous préviens tout de suite que j’ai résolu le problème de fond rencontré mais que ce dernier a fini par pointer du doigt un comportement pour lequel je n’ai aucune explication à donner. Je m’en remets donc volontiers à vous lecteurs et lectrices !

Ici, je me trouve dans une commande Symfony (3.3.9) qui utilise doctrine DBAL* pour…

View On WordPress

[majpi]

Brak primary key na tabeli przy imporcie do doctrine

[Doctrine\ORM\Mapping\MappingException]  Table _m_PPS01 has no primary key. Doctrine does not support reverse engineering from tables that don't have a prim  ary key.

Rozwiązanie

I've successfully imported some database entities by adding a schema_filter in the doctrine dbal config (~/app/config/config.yml)

# Doctrine Configuration doctrine:    dbal:        driver:   %database_driver%        host:     %database_host%        port:     %database_port%        dbname:   %database_name%        user:     %database_user%        password: %database_password%        charset:  UTF8        schema_filter: /^users_table/

app/console doctrine:mapping:import --force MyBundle yml

Then revert config.yml.

Link: https://stackoverflow.com/a/38645802

[ichabod-cms]

Green screen. Clear cache.

[novidades-symfony]

Novidade no Symfony 2.8: componente de autenticação Guard

O componente de Segurança do Symfony está dividido em duas partes principais: autenticação e autorização. O subsistema de autorização verifica se o usuário tem permissão para acessar o recurso informado. Esse sistema está relacionado aos papéis (roles) e voters e é poderoso e simples de usar.

O subsistema de autenticação verifica a identidade do usuário através de qualquer um dos métodos suportados: nome de usuário + senha, certificados, tokens de API, etc. Esse subsistema é poderoso e flexível, mas muitos desenvolvedores Symfony lutam com sua complexidade.

Um novo componente relacionado com a segurança chamado Guard visa simplificar o subsistema de autenticação. Essa nova abordagem radical tem como base a criação de apenas uma classe PHP que implementa GuardAuthenticatorInterface. Essa interface define os sete métodos a seguir:

interface GuardAuthenticatorInterface {    /**     * Get the authentication credentials from the request. If you return null,     * authentication will be skipped.     *     * For example, for a form login, you might:     *     *      return array(     *          'username' => $request->request->get('_username'),     *          'password' => $request->request->get('_password'),     *      );     *     * Or for an API token that's on a header, you might use:     *     *      return array('api_key' => $request->headers->get('X-API-TOKEN'));     */    public function getCredentials(Request $request);    /**     * Return a UserInterface object based on the credentials returned by getCredentials()     */    public function getUser($credentials, UserProviderInterface $userProvider);    /**     * Throw an AuthenticationException if the credentials returned by     * getCredentials() are invalid.     */    public function checkCredentials($credentials, UserInterface $user);    /**     * Create an authenticated token for the given user. You can skip this     * method by extending the AbstractGuardAuthenticator class from your     * authenticator.     */    public function createAuthenticatedToken(UserInterface $user, $providerKey);    /**     * Called when authentication executed, but failed (e.g. wrong username password).     */    public function onAuthenticationFailure(Request $request, AuthenticationException $exception);    /**     * Called when authentication executed and was successful (for example a     * RedirectResponse to the last page they visited)     */    public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey);    /**     * Does this method support remember me cookies?     */    public function supportsRememberMe(); }

Após implementar essa interface você poderá autenticar usuários através de formulários de login, Facebook, Twitter ou qualquer outro serviço que tenha como base OAuth, tokens de API, etc. Além disso, você poderá personalizar o comportamento de sucesso e falha muito facilmente.

Mostrar um exemplo completo do componente Guard em ação está além da finalidade deste artigo, mas você pode ler (e nos ajudar a terminar) a documentação em progresso do componente e seu tutorial oficial.

Tradução de: “New in Symfony 2.8: Guard authentication component por Javier Eguiluz”

[novidades-symfony]

Novidade no Symfony 2.8: Profiler Redesenhado

Algumas semanas atrás, apresentamos a barra de ferramentas para depuração redesenhada para o Symfony 2.8. A nova barra de ferramentas foi bem recebida pela comunidade, mas tinha uma falha: ao clicar em qualquer painel da barra de ferramentas, você era redirecionado para o profiler antigo.

É por isso que no dia seguinte da apresentação da barra de ferramentas, começamos a trabalhar na modernização do look and feel do profiler para coincidir com a nova barra de ferramentas. Um mês mais tarde, e depois de ter alterado mais de 5.000 linhas de código, estamos orgulhosos de apresentar o Profiler Symfony redesenhado.

O processo de redesenho

Esse redesenho intimidante, como a maioria dos projetos de design, começou na prancheta de desenho. Preparamos dezenas de mockups e esboços no papel para repensar todos os elementos renderizados nas páginas do profiler:

O próximo passo foi preparar o wireframe do layout no qual as páginas do profiler baseiam-se. Novamente, uma série de projetos foram testados e, eventualmente, decidimos utilizar o seguinte layout:

A etapa final foi redesenhar todas as páginas do profiler. Em vez de apenas atualizar sua aparência, passamos mais de 100 horas no total repensando todo e qualquer um dos seus conteúdos.

Explicar o conjunto completo de mudanças levaria muito tempo, então preferimos mostrar quatro comparações rápidas do profiler antigo e novo:

Confira o pull request original para saber todos os detalhes sobre o novo design.

Como você pode obter o novo profiler?

O novo profiler fará sua estréia no Symfony 2.8 e 3.0, que serão lançados em novembro. O redesenho também estará disponível nos próximos lançamentos do Silex. Enquanto isso, você terá que usar a dependência versão 2.8.*@dev em seu arquivo composer.json.

Se quiser testá-lo o mais rápido possível, crie um novo projeto Symfony executando o seguinte comando:

$ composer create-project symfony/framework-standard-edition new_profiler "2.8.*@dev"

Tradução de: “New in Symfony 2.8: Redesigned Profiler por Javier Eguiluz”

[novidades-symfony]

Transição do Symfony 2.7 para o 3.0... e o Symfony 2.8 está a caminho

O Symfony 2.7 beta 1 será lançado ainda hoje e será o próximo LTS (lançamento Long-Term-Support). Quem ainda estiver usando o Symfony 2.3 tem um ano (até maio de 2016) para atualizar para o Symfony 2.7.

O Symfony 2.7 é uma versão especial. Mesmo vindo com mais de 100 novos recursos (grandes e pequenos), muito trabalho foi realizado no framework em avisos de descontinuação. Esses avisos ajudam a atualizar facilmente para o Symfony 3.0 a partir de hoje, e eles também garantem que tudo funcionará como esperado no núcleo do framework: compatibilidade entre o Symfony 2.7 e o 3.0, quando aplicável, sem uso de recursos obsoletos no núcleo do framework, ...

Como já explicado há alguns meses, a versão 3.0 é uma versão colisão semântica. Na versão 3.0 é permitido quebrar a compatibilidade com versões anteriores; mas não pela adição de novos recursos ou por quebrar a compatibilidade; o Symfony 3.0 quebra compatibilidade porque a camada de compatibilidade introduzida em todas as versões 2.x será removida. Assim, todos os novos recursos da 3.0 já foram introduzidos nas versões 2.x. E porque 2.7 é agora uma versão com recursos congelados, isso significa que todos os recursos para 3.0 já são conhecidos e não podemos tornar mais nada obsoleto... e isso é um problema. Porque todo o trabalho feito na versão 3.0 não terá mais um caminho de atualização fácil a partir de hoje. É claro que existe uma solução.

Conversei com várias pessoas sobre a melhor solução para resolver esse problema e surgiu uma solução simples e eficiente: a necessidade de uma versão 2.8 do Symfony. Essa versão irá funcionar como quaisquer outras versões 2.x, poderemos adicionar novas funcionalidades, tornar obsoletas outras, e fornecer um bom caminho de upgrade para o Symfony 3.0.

O Symfony 2.8 será lançado em novembro de 2015 ao mesmo tempo que o Symfony 3.0. O Symfony 2.8 será uma versão LTS, bem como permitirá que as pessoas ainda tenham um ano para atualizar da versão 2.8 para a 3.2 quando ela for lançada (sendo 3.2 a próxima versão LTS e a primeira da branch 3.x).

Recapitulando:

O Symfony 2.7 será lançado como planejado em maio de 2015 e será uma versão LTS;

O Symfony 2.8 será lançado como planejado em novembro de 2015 e será uma versão LTS também;

O Symfony 3.0 será lançado como planejado em novembro de 2015 ao mesmo tempo que o Symfony 2.8.

Tradução de: “Transition from Symfony 2.7 to 3.0... Symfony 2.8 on its way por Fabien Potencier”