Desenvolvimento Odin v3.0.0

[adammacias]

Depois da discussão #328 sobre as possíveis features da versão v3.0.0 criei esse issue para que possamos nos organizar sobre o que precisa ser feito antes de tornar esta versão um release-beta.

TO-DOs

Etapa 1: Bower branch: v3-dev

• Criação do arquivo Bower.
• Adicionar dependências

Etapa 2: Gulp.js. branch: v3-dev-gulp

• Remover Grunt
• Atualizar Pacotes Node
• Adicionar Gulp
• Task: gulp styles SASS/SCSS => CSS (compress)
• Task: gulp scripts JS (validação/compress)
• Task: gulp images Imagens JPG/PNG/GIF (compress)
• Task: gulp fonts Fonts (copia fonts para assets)
• Task: gulp watch Assiste alterações nos arquivos
• Task: gulp start Cria serve com browsersync (Assistir exemplo)
• Task: gulp dist Cria pacote do tema para ser distribuído.

Etapa 3: Refatorar Core Odin (Classes/Functions).

• Depreciar ou remover a classe Theme Options Depreciar ou remover a classe Theme Options #414
• Mais em breve...

Etapa 4: Estrutura/organização de arquivos/diretórios.

• Mais em breve...

Etapa 5: Documentação (website). branch: v3-gh-pages

• Introdução (Bem-vindo, caracteristicas...)
• Instalação
• Pré-requisitos
• Comandos (Gulp)
• Pacotes front-end (Bower)
• Estrutura de arquivos/diretórios
• Libraries (Post Types, Metaxbox, Theme Options...)
• Shortcodes
• Widgets
• Hooks
• Helpers

c/c:
@wpbrasil/owners
@wpbrasil/developers
@wpbrasil/contribuidores

[raisiqueira]

Seria uma boa uma tarefa para gerar sprites de svg também, e aproveitar e incluir no tema.

[kvnol]

Não seria interessante utilizarmos um code-guide para o front? Não temos uma padronização no SASS.

http://diegoeis.github.io/code-guide/

[claudiosanches]

Porque remover o Grunt e usar Gulp?
Alias, quem é Bower, ninguém mais usa isso.

[allysonsouza]

@claudiosanches pergunta de quem tá um pouco por fora do assunto: o que você tem visto a galera utilizar para fazer as vezes do Bower? Webpack, Yarn, o próprio NPM?

Sobre o Grunt/Gulp, não tenho muita informação, mas acho que optaram por trocar pro Gulp por performance, mas eu sinceramente não senti grande diferença (possa estar equivocado). Acho que um ponto positivo do Grunt é sua maior comunidade e módulos ainda.

[claudiosanches]

@allysonsouza qualquer coisa é melhor que bower, além que galera tem usado npm mesmo, quase tudo já esta no npm.

[adammacias]

@claudiosanches concordo, podemos dar tchau para bower, o npm já dá conta do recado.

Em relação ao gulp/grunt, na discussão #328 você mesmo disse que era a favor do Gulp haha

Mas pelo que ando observando quem está em "alta" no mercado é o Webpack ou nenhum deles

[fdaciuk]

@adammacias gulp e webpack são ferramentas diferentes.. se não for usar ES6 (que vai precisar do babel), e o teu JS não for muito grande, o gulp ainda é a melhor opção pra resolver as tarefas mais comuns =)

[claudiosanches]

@adammacias a favor do Gulp, mas Grunt é o que até o core do WordPress usa.

Além que nessas tasks tem coisas faltando, como comandos para grunt-checktextdomain e grunt-wp-i18n (tem opções de ambos para gulp).

[allysonsouza]

Task Runners
Eu acho que não temos grandes diferenças entre Grunt/Gulp no momento, mas já que no momento já foi modificado para o Gulp, que é uma ferramente tão boa quanto Grunt, poderia ficar com ele mesmo, só implementar as tasks. O que acham?

Package Manager
Aqui eu realmente não sei opinar, como que é usar o NPM apenas? E o Yarn que vejo que estão usando bastante?

[claudiosanches]

Eu ainda prefiro seguir o que o WordPress faz, usando Grunt. Apesar de gostar de como Gulp funciona.
Pense que isso que estamos discutindo aqui é novidade para muita gente, conheço uma porrada de pessoas que começaram a usar Grunt por causa do Odin, pegar e trocar agora é bem treta.

No caso do Yarn vai conseguir instalar as mesmas coisas que tem no npm, da para usar ele se quiser seguir a moda, mas para este projeto não seria algo realmente necessário.
Enfim, qualquer um que seja escolhido, da para seguir isso daqui: http://blog.npmjs.org/post/112064849860/using-jquery-plugins-with-npm
Se quiser evitar usar mais uma lib como o browserify e não quiser levar os arquivos de dev para produção, podemos copiar os arquivos baixados no node_modules para assets/js.

[allysonsouza]

Tava olhando aqui o que o @adammacias fez, hoje temos os scritps no diretório /src que compilam para /assets/js, e vi que há uma sintaxe de include, que desconheço em minha humilde ignorância:

//=include('../../bower_components/bootstrap-sass/assets/javascripts/bootstrap/transition.js')

...que faz o include dos scripts na hora de compilar. No fim, dos scripts compilados lidamos com seu carregamento e dependências com a wp_enqueue_scripts() ainda. Não poderíamos utilizar o npm para instalação dos scripts na node_modules e então fazer sua inclusão, tal como está sendo feito da bower_components? (Poderíamos instalar o Bootstrap com npm também)

Me corrijam se eu estiver falando besteira.

[brunolimadevelopment]

seguindo as boas práticas, não é recomendável instalar bootstrap, jquery...etc; com o npm.
porque npm é é um gerenciador voltado para backend.
já o bower_components é um gerenciador especifico, voltado para o client-side ou seja front-end.

[fdaciuk]

Para coisas mais simples, essa configuração atual resolve bem. Agora, se for usar algo mais "pesado" de JS no frontend, dá pra pensar em algumas outras soluções, talvez até fazendo como o odin-gulp, em um projeto separado, para adicionar no odin conforme a necessidade. Aí abre várias possibilidades pra usar além do Grunt: gulp, webpack, etc.

porque npm é é um gerenciador voltado para backend.

Na verdade não. Essa foi a ideia inicial do NPM. Hoje você pode instalar até CSS via NPM (exemplo do normalize.css =)

[brunolimadevelopment]

não é porque é possível instalar via npm que é obrigado a utilizar.
vai depender do workflow do dev. como disse anteriormente, seguindo boas práticas e padrões de desenv...o ideal seria utilizar bower. ¬¬

[fdaciuk]

Concordo @brunolimadevelopment, depende do workflow. Por isso a ideia de criar um odin-gulp, odin-webpack, etc., mas - pode ser questão de gosto - vejo que o NPM é muito mais maduro ao trabalhar com essas ferramentas que o bower, inclusive por poder usar o yarn =)

[claudiosanches]

Não vamos usar bower, isso esta resolvido.
Se complicar, não usamos nenhum outro script e pronto, pelado igual o underscores.

[adammacias]

@allysonsouza isso mesmo :)

Essa nomeclatura //=include... é devido ao pacote gulp-file-include, foi uma solução adotava para inclui os outros arquivos na hora de compilar, assim conseguimos para colocar todos os vendors em um só arquivo JS, além de poder personalizar fácilmente os scripts, como é o caso do Bootstrap, se você não quiser por exemplo usar o carousel do bootstrap, é só tirar 2 linhas de código, uma no arquivo sass outra no js :)

Mas talvez seja interessante a gente dar suporte para ES6 e começar a usar import.

@fdaciuk é uma mesmo o "gulp-odin" e só passar os parâmetros (variables, caminhos e etc) algo tipo o Laravel Elixir né?

[fdaciuk]

@fdaciuk é uma mesmo o "gulp-odin" e só passar os parâmetros (variables, caminhos e etc) algo tipo o Laravel Elixir né?

@adammacias não necessariamente.. a ideia seria fazer separado mesmo, só ter um starter pra quem quiser usar o Odin e ter um caminho base pra não precisar gerar um frontend zerado.

[claudiosanches]

Mas eu estou serio nesse lance de não usar nada e deixar pelado, principalmente porque hoje em dia ninguém usa mais Bootstrap ou tem odio dele, talvez conseguimos fazer a ideia inicial e ter apenas algumas classes e CSS padrão para ajudar com elementos basicos do WordPress e deixar a galera usar o que eles quiserem.

[matheusgimenez]

Pessoas, se for pra fazer uma copia do underscores não é mais fácil usar o underscores? O Odin tem uma trajetoria diferente, e acredito que tem que continuar trazendo alguma ferramenta de gerenciamento de assets pro front-end. Foi o que me fez finalmente começar a usar algum padrão novo, se o Odin não tivesse isso, talvez eu estaria até hoje sem usar essas coisas em projetos WP.

[allysonsouza]

A galera não tá usando Bootstrap e tá usando o quê?

[Rahmon]

@allysonsouza eu acho que ainda usam bastante o bootstrap. Mas concordo em tirá-lo do Odin e fazer o que o @claudiosanches.

[claudiosanches]

@matheusgimenez tem espaço para ser melhor que o underscores, mesmo que seja pelado, mas sempre Bootstrap e outras coisas aqui foram um problema e a galera esta removendo já várias coisas que não fazem parte do território de temas.

[claudiosanches]

@allysonsouza @Rahmon falando de remover porque galera sempre xingou bastante por causa do Bootstrap, além que deve ter algo mais na moda que a galera vai gostar por alguns meses xD
Mas acho que dava para simplificar e deixar mais livre para quem quiser usar qualquer coisa, direto em WordCamp ouço alguém falando que criou algo baseado no Odin, mas sem o Bootstrap, sem contar uma vez um comentário de um "famoso" sobre não usar Odin por ter muitas "divs" pra usar o Boostrap 😜

[matheusgimenez]

Não é bem sobre o bootstrap que to falando. Acho que quanto a isso existe alternativas de libs dentro do SASS para tal que funciona bem e é mais leve.

To dizendo quanto ao gerenciamento de assets do front-end, acho necessário termos algo como o grunt ou gulp (ou alternativas mais modernas) para isso e que já venha com tarefas para o SASS.
Talvez até podendo ser fora do tema por padrão, mas fazendo de alguma forma com que consiga ser instalado de forma rapida sem muita configuração se necessário.

[claudiosanches]

@matheusgimenez ahh sim, quanto a isso concordo que precisamos ter algo para facilitar.

[marioernestoms]

Eu sou da mesma opinião que o @claudiosanches, tirar logo essas merdas todas de bootstrap, bower, sass e bla bla bla e deixar igual ao underscore. Até pq falaram ai que se tirar o front-end e deixar igual ao underscore, porque nao usar o underscore? simples a resposta disso o odin tem o core dele com diversas classes, métodos e funções e isso que faz dele um framework bom. Front-End cada um tem a suas ideias e visões e formato de trabalhar. sempre falei com a galera da comunidade que seria maravilhoso ter um odin light so com o core dele.

[mariovalney]

Concordo com o @marioernestoms e @claudiosanches ... Quanto menos front melhor, porque atrapalha menos gente. Se quiser incluir algum front pra facilitar a vida de alguém, pode fazer numa versão à parte.

[marioernestoms]

fato @mariovalney deixa o front pra galera incluir o que quiser e como quiser. e na raiz do framework um minimo reset e um style basição contemplando só basico do WordPress.

[mariovalney]

Eu acho que nem isso... HTML apenas.
Pode até incluir um JS pra ser exemplo no functions, mas arquivo vazio.. haha

[allysonsouza]

@marioernestoms o core com as classes e funcionalidades que entram no plugin territory estamos movendo para um plugin, Odin Toolkit: https://github.com/wpbrasil/odin-toolkit

[marioernestoms]

da hora @allysonsouza mas acho um pouco desnecessário mover para um plugin, o que poderia ficar essencialmente nele mesmo. sem precisar de algo paralelo, bastando remover o front-end.

[allysonsouza]

Eu já acredito que é essencial remover coisas do plugin territory (tanto que já está removido no branch da v3) para até promover melhores práticas de desenvolvimento para quem for utilizá-lo. Hoje eu já não crio mais CPT's, Taxonomies, Meta Boxes nos temas, já tenho utilizado o Odin Toolkit como base para os plugins dos projetos.

[mariovalney]

Concordo com o @allysonsouza : sempre crio uma dupla Tema + Plugin [de Core] para os projetos.

[allysonsouza]

Sobre o front-end concordo que deve ter algo em relação a tasks e tudo o mais. O Bootstrap poderia ser preparado para ser instalado (com Composer por ex.), compilado pelo task runner, etc, mas não necessariamente incorporado nos templates do tema. Me corrijam se eu estiver falando alguma besteira.

[Rahmon]

Também acho interessante remover coisas do plugin territory. Porque se alguém quiser colocar o tema que criou no repositório oficial, vai ter que tirar essa parte do core.

[mariovalney]

Não só o bootstrap, mas os próprios task runners podem "atrapalhar" quem não use ou use outro. Então ainda acho que pode ser pelado e ter versões com os task runners.

[allysonsouza]

Pessoal, como estamos? Até gostaria de colaborar mais com o projeto, mas senti que deu uma travada nas discussões entre task runners e frameworks front-end. Estava pensando em, no caso de impasse, segue o que já está, Bootstrap e Grunt, só dar prosseguimento no que poderia ter sido melhorado já há um ano atrás...

[guimontme]

Pessoal, como usuário, senti falta dessa função no tema:

                 /**
		 * Register nav menus.
		 */
		register_nav_menus(
			array(
				'main-menu' => __( 'Main Menu', 'odin' )
			)
		);

Ela é essencial construir um menu dinâmico, sendo que o menu já está localalizado abaixo do banner, porém não foi registrado no /functions.php e aparente mente não estava sendo usado em numa outra classe. Eu acabei acrescentando no inc/theme/functions.php, mas não sei se seria um local indicado para isso. Eu instalei odin v3 beta ontem no meu servidor local, demorei um pouco a me acostumar com a mudança radical de uma versão para outra, porém é uma questão de me acostumar, não sabia do Odin Toolkit, estarei instalando para teste. Eu uso o Odin para fazer meus temas a tempo, tenho um carinho especial por esse projeto.

[rodrigophpweb]

Olá Pessoal tudo bem? Gostaria de dar uma sugestão. Hoje é muito comum utilizarmos SVG nos projetos. Não seria interessante também colocar nas Taks do Gulp a tarefa para comprimir SVG?

https://www.npmjs.com/package/gulp-svgmin

[brunopulis]

Boa noite pessoal, tudo bem? Gostaria de dar uma sugestão. Tenho visto alguns frameworks de Wordpress como o Sage e algo muito interessante que eles utilizam é um template engine para o WP, atualmente eles utilizam o Twig.

Talvez seria interessante incorporar ele, a vantagem é que os arquivos .php trabalharia somente com a lógica e os *.twig com a apresentação.

[rodrigosotto]

Boa tarde! o Odin foi descontinuado?

[brunopulis]

@Jeffersontads estou querendo saber também

[nandomoreirame]

👀

[ligiasalzano]

👀

[rudwolf]

o @allysonsouza me disse no slack que estava afim de retomar isto, Ally meu caro... vamo criar um canal no slack só pra falar do odin 3.0 vamo? Ou já tem? Creio que precisamos retomar isto!

[brunopulis]

o @allysonsouza me disse no slack que estava afim de retomar isto, Ally meu caro... vamo criar um canal no slack só pra falar do odin 3.0 vamo? Ou já tem? Creio que precisamos retomar isto!

Eu apoio, utilizo o Odin em praticamente todos os projetos WP ❤️

[rudwolf]

Inclusive @brunopulis eu acho que o Odin tinha que ser um plugin, aliás, acho que tem um projeto, só não sei como anda, chamado Thor, que é de desmembrar funções que poderiam servir pra QUALQUER tema pra dentro de um plugin, e deixar o Odin como um tema esqueleto pra qualquer site (já adaptado pra uso das funções do Thor claro).

[brunopulis]

Inclusive @brunopulis eu acho que o Odin tinha que ser um plugin, aliás, acho que tem um projeto, só não sei como anda, chamado Thor, que é de desmembrar funções que poderiam servir pra QUALQUER tema pra dentro de um plugin, e deixar o Odin como um tema esqueleto pra qualquer site (já adaptado pra uso das funções do Thor claro).

Eu acho super prático da forma que é hoje, porém, tenho que atualizar diversas coisas dele quando executo download da versão 2.0.

O Bootstrap eu sempre mantenho a versão stable dele, e estou tentando usar outro task runner sem ser o Grunt.