Setup Nuevo Proyecto

Setup General

Creo carpeta del proyecto (si el dominio del proyecto es ejemplo.com) lo ideal es que la carpeta se llame ejemplo: mkdir ejemplo
Configuro el IDE o editor de texto necesario en esa carpeta.
Inicio git: git init
Clono Trellis en la raiz y borro el repo correspondiente:

git clone git@github.com:roots/trellis.git
cd trellis && rm -rf .git
cd ..

Clone Bedrock sobre la carpeta site y borro el repo correspondiente:

git clone git@github.com:roots/bedrock.git site
cd site && rm -rf .git
cd ..

Voy a la carpeta de themes e instalo Sage con el nombre que quiero darle al theme

cd site/web/app/themes
git clone git@github.com:roots/sage.git nombre-theme
cd nombre-theme && rm -rf .git

Edito las opciones del theme en resources/style.css (Opcional)
Hago el commit inicial. Si el repo no está creado aún ejecuto primero, sobre la raiz del proyecto: git init.

cd ../hasta/raiz/del/sitio
git add .
git commit -m "Initial commit"
git push -u origin master

Configuración Trellis

Sobre la carpeta group_vars

En la carpeta all/users.yml agrego las keys de los usuarios que van a participar del proyecto. Para cuestiones de admin del server está el grupo admin, para deploys está el grupo web

# Documentation: https://roots.io/trellis/docs/ssh-keys/
admin_user: admin

# Also define 'vault_users' (`group_vars/staging/vault.yml`, `group_vars/production/vault.yml`)
users:
  - name: "{{ web_user }}"
    groups:
      - "{{ web_group }}"
    keys:
      - https://github.com/jdebuchy.keys
  - name: "{{ admin_user }}"
    groups:
      - sudo
    keys:
      - https://github.com/jdebuchy.keys

Agrego API KEYS comunes a cada entorno en all/vault.yml:

vault_wpmigratepro_user: '######################'
vault_wpmigratepro_pass: '######################'

vault_wordpress_env_defaults:
    acf_pro_key: '######################'
    wpmdb_licence: '######################'

En principio no se necesita agregar más info sobre la carpeta all

En el archivo development/wordpress_sites.yml edito example.com y los canonical y redirects por las direcciones locales.
En el archivo development/vault.yml el nombre example.com tiene que coincidir con lo que se escribió en wordpress_sites.yml.
Repito 3 y 4 sobre las carpetas staging y production con la diferencia que hay que incluir el link al repositorio en repo y en los archivos vault hay que cambiar los passwords y salts, para que sean diferentes en cada entorno.
Encripto los archivos con información (opcional). Para ello, primero tengo que crear, en la carpeta trellis un archivo llamado .vault_pass y escribir una contraseña dentro y guardar. También tengo que cambiar los permisos a 600.

touch .vault_pass
echo "custom_password" >> .vault_pass
chmod 600 .vault_pass

Nota: este archivo está dentro de .gitignore, por lo que deberá ser compartido por fuera del repositorio con el resto del equipo para poder desencriptar. En ansible.cfg agrego la siguiente línea

 # ansible.cfg
  [defaults]
  roles_path = vendor/roles
  force_handlers = True
  inventory = hosts
+ vault_password_file = .vault_pass

Luego, con el siguiente comando encripto los archivos. ansible-vault encrypt group_vars/all/vault.yml group_vars/development/vault.yml group_vars/staging/vault.yml group_vars/production/vault.yml

Sobre la carpeta hosts y el archivo vagrant.default.yml

Edito las IPs correspondientes. En development por default es 192.168.50.5, pero hay que tener cuidado que no se pise con otros proyectos que puedan tener su propia máquina virtual con esa IP. Sugerimos cambiarla. Las IPs de staging y production serán provistas por Digital Ocean o el proveedor del VPS.
En el archivo vagrant.default.yml la dirección IP de vagrant_ip debe coincidir con la que escribimos en development en 1.

Sobre la carpeta deploy-hooks

Edito build-before.yml Quito los comentarios para que quede así y reemplazo en cada chdir, src y dest el nombre de sage por el nombre del theme que hayamos elegido.

- name: Install npm dependencies
  command: yarn
  delegate_to: localhost
  args:
    chdir: "{{ project_local_path }}/web/app/themes/sage"

- name: Install Composer dependencies
  command: composer install --no-ansi --no-dev --no-interaction --no-progress --optimize-autoloader --no-scripts
  args:
    chdir: "{{ deploy_helper.new_release_path }}/web/app/themes/sage"

- name: Compile assets for production
  command: yarn build:production
  delegate_to: localhost
  args:
    chdir: "{{ project_local_path }}/web/app/themes/sage"

- name: Copy production assets
  synchronize:
    src: "{{ project_local_path }}/web/app/themes/sage/dist"
    dest: "{{ deploy_helper.new_release_path }}/web/app/themes/sage"
    group: no
    owner: no
    rsync_opts: --chmod=Du=rwx,--chmod=Dg=rx,--chmod=Do=rx,--chmod=Fu=rw,--chmod=Fg=r,--chmod=Fo=r

Creo que el archivo auth.json.j2 y escribo lo siguiente:

{
  "http-basic": {
    "composer.deliciousbrains.com": {
      "username": "{{ vault_wpmigratepro_user }}",
      "password": "{{ vault_wpmigratepro_pass }}"
    }
  }
}

Por último, nuevamente sobre el archivo build-before.yml agrego la siguiente línea al final

- name: Create compose auth.json for wp migrate pro
  template:
    src: "{{ playbook_dir }}/deploy-hooks/auth.json.j2"
    dest: "/home/{{ ansible_user }}/.composer/auth.json"
    mode: "0600"

Servidor Local

Opción A: Máquina virtual Una vez realizada toda la configuración vamos a crear la máquina virtual con la ayuda de Vagrant y Ansible. Esta opción crea todo el setup en forma automática y al terminar uno debería poder ir a http://dominio.test y ver el sitio de WordPress arriba. Como contrapartida el uso de la máquina virtual quita un montón de recursos, a veces hace muy lenta la operación y cada MV arranca pesando 2GB.

vagrant up

Opción B: Valet Esta opción es una alternativa mucho más liviana y veloz, pero por otro lado, se pierde una de las grandes virtudes de Trellis, que es la paridad entre servidores locales y de staging/producción. Por otro lado, el proceso es un tanto más manual en la medida que hay que crear la base de datos de WordPress y crear el usuario correspondiente. Para generar los archivos .env file (que en la opción A se crean mediante Ansible) utilizamos la librería enveigle.

# trellis
enveigle

Luego tenemos que crear, mediante SequelPro, la base de datos y usuario correspondiente con sus correspondientes privilegios de esquema para que pueda acceder a la base de datos. Si utilizamos esta opción también vamos a tener que ejecutar los comandos de Bedrock antes de poder ver el sitio funcionando localmente.

Por último, tenemos que pararnos sobre la la raíz del proyecto y correr: valet link

Servidor Remoto

Si no está configurado aún el servidor y se eligió la opción de instalación local mediante Valet, hay que ejecutar los siguientes comandos.

ansible-galaxy install -r requirements.yml // Instala las dependencias necesarias de ansible. No hace falta si utilizamos Vagrant localmente.
ansible-playbook server.yml -e env=<entorno> // Setup del servidor remoto

Configuración Bedrock

Archivo composer

El archivo composer.json tendrá todos los plugins y la instalación de WordPress como dependencias. Desde el repositorio wpackagist tendremos acceso a todos los plugins gratuitos del repositorio de WordPress, mientras que para plugins pagos tendremos que utilizar otras opciones.

Dentro de la opción require volcaremos los distintos plugins, mientras que en repositories tendremos algunas de las fuentes para plugins privados.

El archivo aplication.php define la mayoría de las constantes que se cargarán en WordPress. Allí podremos agregar algunas constantes adicionales, como las keys de WP Migrate Pro y otros servicios, como Sendgrid y Google Maps. Debajo de Custom Settings:

// Add WP Migrate License
Config::define('WPMDB_LICENCE', env('WPMDB_LICENCE') ?: false);

// Sendgrid
Config::define('SENDGRID_API_KEY', env('SENDGRID_API_KEY') ?: false);

// Google Maps
Config::define('GOOGLE_MAPS_API_KEY', env('GOOGLE_MAPS_API_KEY') ?: false);

Configuración Sage

n. Incluyo en filters.php dentro del filtro body_class el siguiente código, que permitirá agregar en la body class los nombres de cada bloque de ACF GB llamado en esa página:

// Add GB Block class name
if (isset($post->post_content) && has_blocks($post->post_content)) {
    $block_names = array_filter(array_column(parse_blocks($post->post_content), 'blockName'));
    foreach ($block_names as $block_name) {
        $classes[] = preg_replace(['/^acf\//'], '', $block_name);
    }
}

n. Incluyo en setup.php las siguientes líneas de código que me permitirán tener mayor flexibilidad sobre bloques nativos en GB.

/**
  * Add theme support for Wide Alignment
  * @link https://wordpress.org/gutenberg/handbook/designers-developers/developers/themes/theme-support/#wide-alignment
  */
add_theme_support('align-wide');

/**
  * Add editor styles
  * @link https://wordpress.org/gutenberg/handbook/designers-developers/developers/themes/theme-support/#editor-styles
  */
add_theme_support('editor-styles');
// add_theme_support( 'dark-editor-styles');
// add_editor_style( 'style-editor.css' );

/**
  * Enable responsive embeds
  * @link https://wordpress.org/gutenberg/handbook/designers-developers/developers/themes/theme-support/#responsive-embedded-content
  */
add_theme_support('responsive-embeds');

/**
  * Enable Editor color palette support
  * @link https://wordpress.org/gutenberg/handbook/designers-developers/developers/themes/theme-support/#block-color-palettes
  */
add_theme_support('editor-color-palette', [
    [
        'name' => __('strong magenta', 'sage'),
        'slug' => 'strong-magenta',
        'color' => '#a156b4',
    ],
    [
        'name' => __('light grayish magenta', 'sage'),
        'slug' => 'light-grayish-magenta',
        'color' => '#d0a5db',
    ],
    [
        'name' => __('very light gray', 'sage'),
        'slug' => 'very-light-gray',
        'color' => '#eee',
    ],
    [
        'name' => __('very dark gray', 'sage'),
        'slug' => 'very-dark-gray',
        'color' => '#444',
    ],
]);

/**
  * Enable Editor font size support
  * @link https://wordpress.org/gutenberg/handbook/designers-developers/developers/themes/theme-support/#block-color-palettes
  */
add_theme_support('editor-font-sizes', [
    [
        'name' => __('Small', 'sage'),
        'size' => 12,
        'slug' => 'small'
    ],
    [
        'name' => __('Normal', 'sage'),
        'size' => 16,
        'slug' => 'normal'
    ],
    [
        'name' => __('Large', 'sage'),
        'size' => 36,
        'slug' => 'large'
    ],
    [
        'name' => __('Huge', 'sage'),
        'size' => 50,
        'slug' => 'huge'
    ]
]);

n. Para agregar los campos globales de ACF tengo que tener instalado el paquete de ACF Builder en composer. "stoutlogic/acf-builder": "~1.6.1",

Dentro de setup.php incluyo las siguientes líneas para agregar los campos globales de ACF.

/**
 * ACF Global Settings
 */
$fields['global_settings'] = new FieldsBuilder('global_settings');
$fields['global_settings']
    ->addTab('header', ['placement' => 'left'])
        ->addImage('logo', [
            'preview_size' => 'medium'
        ])
    ->addTab('footer', ['placement' => 'left'])
        ->addImage('footer_logo', [
            'preview_size' => 'medium'
        ])

    ->setLocation('options_page', '==', 'global-options');

/**
 * Initiate
 */
add_action('acf/init', function () use ($fields) {
    foreach ($fields as $field) {
        acf_add_local_field_group($field->build());
    }
});

no olvidar llamar al namespace correspondiente, por lo que arriba de todo incluir

use StoutLogic\AcfBuilder\FieldsBuilder;

# Setup Nuevo Proyecto

# Setup General

# Configuración Trellis

# Sobre la carpeta group_vars

# Sobre la carpeta hosts y el archivo vagrant.default.yml

# Sobre la carpeta deploy-hooks

# Servidor Local

# Servidor Remoto

# Configuración Bedrock

# Archivo composer

# Configuración Sage