Antes de empezar cualquier desarrollo bajo WordPress, me gusta tener configurado mi entorno local, ya que después el flujo de trabajo es más rápido y sobre todo, me siento más cómodo. Aquí hago un repaso a lo que suelo hacer antes de empezar manos a la obra.
Crear site con Local By Flywheel
Particularmente, siempre he usado XAMPP, porque era fácil y no tenía que preocuparme de instalar servicios de PHP y Apache.
Sin embargo, en la WordCamp de Zaragoza 2019, descubrí Local By Flywheel y desde entonces no uso otra cosa.
Local By Flywheel es una herramienta fantástica para crear en segundos entornos locales de WordPress. Se puede descargar directamente desde su web. Tiene diversos planes de pago, pero existe una versión muy completa que no lo es. Hay versiones para Windows y Mac.
Una vez instalada, tiene una interfaz muy intuitiva que te facilita mucho la labor. También tiene accesos a un cliente de bases de datos muy parecido a PHPMyAdmin.
Sólo tienes que preocuparte de introducir los datos que te requieren y no tienes que pensar en instalar módulos de Apache ni PHP ni MySQL. Ni siquiera te tienes que preocupar por configurar los virtual host, así como editar el fichero hosts del sistema.
Crear site en producción con SiteGround
Yo tengo mis webs alojadas en SiteGround. Este proveedor proporciona herramientas para hacer despliegues en segundos de entornos WordPress.
Tiene un CPanel bastante amable que te brinda varios autoinstaladores. En mi caso, me centraré en el de WordPress y más adelante, en el SG-Git para desplegar un repositorio remoto sobre la instalación que haga.
Una vez completada la instalación de WordPress, y antes de crear el repositorio remoto, voy a subir por FTP mi archivo .gitignore. El gitignore que yo uso sólo versiona la carpeta wp-content. Sírvete de copiarlo si deseas versionar lo mismo que yo.
*~
.DS_Store
.idea
.svn
.cvs
*.bak
*.swp
Thumbs.db
.htaccess
# Gulp modules
node_modules
# wordpress specific
wp-config.php
wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/*
wp-content/backup-db/*
wp-content/advanced-cache.php
wp-content/wp-cache-config.php
wp-content/cache/*
wp-content/cache/supercache/*
wp-content/ai1wm-backups
# wpengine specific
.smushit-status
.gitattributes
_wpeprivate
wp-content/object-cache.php
wp-content/mu-plugins/mu-plugin.php
wp-content/mu-plugins/slt-force-strong-passwords.php
wp-content/mu-plugins/limit-login-attempts
wp-content/mu-plugins/wpengine-common
wp-content/mysql.sql
# wp core (as of 3.4.1)
/db-config.php
/index.php
/license.txt
/readme.html
/wp-activate.php
/wp-app.php
/wp-atom.php
/wp-blog-header.php
/wp-comments-post.php
/wp-commentsrss2.php
/wp-config-sample.php
/wp-cron.php
/wp-feed.php
/wp-links-opml.php
/wp-load.php
/wp-login.php
/wp-mail.php
/wp-rdf.php
/wp-rss.php
/wp-rss2.php
/wp-pass.php
/wp-register.php
/wp-settings.php
/wp-signup.php
/wp-trackback.php
/xmlrpc.php
/wp-admin
/wp-includes
/wp-content/index.php
/wp-content/themes/twentyten
/wp-content/themes/index.php
/wp-content/plugins/index.php
# large/disallowed file types
# a CDN should be used for these
*.hqx
*.bin
*.exe
*.dll
*.deb
*.dmg
*.iso
*.img
*.msi
*.msp
*.msm
*.mid
*.midi
*.kar
*.mp3
*.ogg
*.m4a
*.ra
*.3gpp
*.3gp
*.mp4
*.mpeg
*.mpg
*.mov
*.webm
*.flv
*.m4v
*.mng
*.asx
*.asf
*.wmv
*.aviCrear repositorio en producción con SiteGround
A mi me gusta siempre desarrollar bajo un repositorio. Prefiero hacerlo así y no trabajar con FTP si puedo evitarlo. Aunque sean proyectos sencillos en los que vaya a estar yo solo. Nunca se sabe qué puede pasar en ese proyecto y en caso de necesitar realmente un repositorio, ya lo tendría configurado.
Creamos repositorio remoto
En primer lugar, haciendo uso de las herramientas del CPanel de SiteGround, pulsamos la aplicación de SG-Git y luego seleccionamos del listado de webs creadas en producción, la que queremos que tenga el código versionado.
Clonamos el repositorio en local
Ahora navegamos por nuestro sistema de ficheros hasta donde hayamos instalado con FlyWheel nuestro proyecto en local. Comprobamos que hay dos carpetas: app y logs. Entraremos en la carpeta app. Dentro de ésta, tenemos otra carpeta, llamado public, que es la que contiene todos los ficheros del WordPress que hemos instalado localmente.
Bien, estando dentro de app/ hacemos un git clone del repositorio remoto, de esta manera creará una carpeta nueva al mismo nivel que public/ con los ficheros de la carpeta wp-content únicamente.
Haciendo la “ñapa”
Ahora renombramos la carpeta public/ por publicOLD/, por ejemplo, y la carpeta con el nombre del repositorio la renombramos a public/.
Copiamos las carpetas wp-admin y wp-includes de publicOLD, así como todos los ficheros raíz a la nueva carpeta public. De esta manera, tendremos toda la configuración hecha con FlyWheel y la carpeta wp-content versionada con Git.
Esta ñapa la hacemos para poder tener los beneficios de una instalación rápida con FlyWheel, por si lo hiciéramos todo manualmente en local, bastaría con clonar el repositorio remoto y listo.
Y con esto ya estaría terminada la parte de configuración del repositorio.
Instalación de Gulp y Sass
Forma parte de mi flujo de trabajo. Gulp para ejecutar las tareas automáticamente de compilar los ficheros Sass y para hacer la minificación del CSS que irá en producción.
De momento, la versión 4 de Gulp tiene algunos fallos en la compilación de los ficheros SASS, así que por mi parte, prefiero optar por instalar la última versión de Gulp que funcionaba a mi gusto.
Nos vamos a la carpeta del theme donde vayamos a empezar el desarrollo y vamos instalando ahí los módulos de Node necesarios. Primero instalamos Gulp (la versión 3.9.1):
npm install gulp@3.9.1 --save-dev
Después, instalamos el compilador de SASS con:
npm install gulp-sass --save-dev
En principio ya estaría en cuanto a módulos, ya que el propio módulo de Sass incluye un modificador para devolver el código compilado de forma comprimida. No nos hace falta instalar ningún módulo minificador o de compresión del CSS.
Creando el fichero de tareas
Nos faltaría crear el fichero para crear las tareas a ejecutar del Gulp. Creamos un fichero vacío llamado gulpfile.js con el siguiente contenido:
// Gulp: gestor de tareas
const gulp = require('gulp');
// Sass: compilador de CSS
const sass = require('gulp-sass');
gulp.task('default', ['compile_css']);
gulp.task('compile_css', function () {
return gulp.src('./assets/styles/*.scss')
.pipe(sass({outputStyle: 'compressed'})
.on('error', sass.logError)
)
.pipe(gulp.dest('./'));
});
gulp.task('watch', function () {
gulp.watch('./assets/styles/**/*.scss', ['compile_css'] );
});Alguna explicación interesante
gulp.src('./assets/styles/*.scss')
Esta línea busca en la ruta indicada cualquier fichero acabado en .scss. En mi caso, sólo tengo el style.scss aposta, porque es el fichero inicial que aglutina el resto. Está hecho así para que cuando lo procese el compilador, genere un único fichero cuyo nombre será style.css porque el nombre del archivo origen (el único que hay en esa ruta) también es style (style.scss)
gulp.watch('./assets/styles/**/*.scss',['compile_css'] );
Esta línea es ligeramente diferente, porque aquí examina en esa ruta cualquier fichero SCSS incluyendo subdirectorios. El segundo parámetro es la tarea a ejecutar, definida más arriba.
Ejecutamos la tarea
Abrimos un terminal y ejecutamos, bajo la carpeta del theme:
gulp watch
Si todo va bien, debería mostrar la tarea “watch” en ejecución y sin devolver el control al prompt del sistema, ya que es una tarea que está en ejecución constante y “observando” cualquier cambio en los ficheros SCSS.
Conclusiones
Puede resultar un poco tedioso todas estas tareas, pero si las tenemos apuntadas, el proceso será más rápido. En mi caso, lo dejo todo aquí indicado en el post, y si en el futuro tengo que cambiar algo, modifico el post y listo.
Sin embargo, a la hora de trabajar, este entorno configurado me facilita mucho las cosas para empezar mis desarrollos.
Espero que a alguien le sirva de ayuda. ¡Os leo!
Imagen principal por Jesus Kiteque de Unsplash
Leave a Reply