Saltar al contenido →

Categoría: programación

Trabajando con SVN (y WordPress)

Esto es un reblog de trabajo para no perder el archivo. Cómo usar SVN para tus traducciones de WordPress, en inglés. Lo guardo por histórico, porque en próximas versiones esta forma de trabajar dejará de funcionar.


Using SVN in your translation flow is not as hard as it seems. If you know some of the basics, you can update a repository (for themes, plugins, or core) in an easy way. Let’s begin :).

We are going to work with the example of the Spanish (Spain) translation. What do we need to begin with?

Permissions

First of all, we need to have permissions granted to write to our Subversion repository. We can ask for this access in the make/polyglots site.

make-polyglots

Don’t forget to:

  • Ask for access politely
  • Indicate your wp.org user
  • Indicate the repository you want access to (you need to be a validator for your language to be granted commit access)
  • Tag your post with request. Locale tags are not needed, as they are automatically associated with validators, but they will be appreciated by others translators and validators.

Creating your own local copy

Now that you have access to the repository, you need to make your own local copy to work with it.

First, you need to locate your locale’s repository. You can look for it in https://i18n.svn.wordpress.org. Once you have located it, copy the URL. For the Spanish example, the URL is https://i18n.svn.wordpress.org/es_ES/

The next step is to make the copy. If you are a Mac or Linux user, you only need to go to a terminal. If you are a Windows, user, you can install Win32SVN to work with a terminal with SVN.

We are going to use SVN. SVN is an abbreviation for Subversion, a software versioning and revision control by Apache. SVN (and other revision control software, like git) allow the programmers to work in a collaborative way and allow to all the people involved to look at and review the code, modify it, and revert it if there is any problem.

Once you have your terminal ready, you need to write this with your own locale:

svn-co

Now you’ll see a lot of archives being copied, and you will have all your locale repository copied in your local directory.

archive

copied

SVN basics

Note that you are right now in a SVN repository. You can see what others have done in the repository by using the command svn log. When you submit your changes, others will see your activity in the logs.

SVN is a little wayward. When you are in a SVN repository, you need to remember to alway use the command svn to do things.

  • if you want to copy something, you need to use svn copy or svn cp
  • if you want to move something, you need to use svn move or svn mv
  • if you want to delete something, you need to use svn delete or svn del
  • if you add a new file to a directory and want it to be in the SVN repository, you need to use svn add <file> to add it to the next commit

You have a list of all the available commands writing svn help in your local repository.

blame

Creating a new tag and/or branch

Now that we have our local repository, we need to create our new branches and tags. We are going to work with the example of WP 4.0-alpha.

As we see before, when you create a new file or archive you need to add it to the repository. If you do not add it, you will not be able to commit your files to the repository.

To make things easier, we are going to svn copy a prior directory and modify the files.

First step, we go into the tags directory. We will have a list of all prior tags.

Now, we copy the last directory created to a new one with our version:

svn-cp

Done! Now we can navigate with our browser to make things easier.

Understanding the repository

In our new directory we will see two directories: dist and messages.

The dist directory has this content:

  • license.txt – the license archive
  • licencia.txt – name may vary. This is the license in your language.
  • readme.html – the readme file in your language.
  • wp-admin/setup-config.php – a translated version of the setup in your language
  • wp-config-sample.php – a translated version of the config sample in your language

The messages directory has this content:

  • admin-xx_XX.mo – the translation archive for the administration ( link )
  • admin-xx_XX.po – .po version
  • admin-network-xx_XX.mo – the translation archive for the network administration ( link )
  • admin-network-xx_XX.po – .po version
  • continent-cities-xx_XX.mo – all the translated Continents and Cities to your language ( link )
  • continent-cities-xx_XX.po – .po version
  • xx_XX.mo – the main WordPress translation ( link )
  • xx_XX.po – .po version
  • twentyxxxxx – the translation of each official theme (various directories)
    • xx_XX.po
    • xx_XX.po

Updating your files

At this point, we need to update the files of our new directory to commit the new version. To do this, we need to know how are we going to build the new package.

packagesIf you are going to use the translate.wordpress.org option,

  • All the installation and setup archives will be read from our new /dist directory (and we will tell the system where they are)
  • The translations will be read from the translate.wordpress.org site

If you choose the Subversion option,

  • All the installation and setup archives will be read from our new /dist directory (and we will tell the system where they are)
  • All the translations will be read from our translations svn directory (and we will tell the system where they are)

You should always try to use the first version. If you need to use the second version, then you will need to:

  • go to each one of the translation sites in translate.wordpress.org (you have the links here)
  • export the translations in .po and .mo versions
  • change the names of the archives to match the list before
  • put them in the svn directory in their correct place

Regardless the option we want to use, we need to update the archives in the dist directory. Usually, you will only need to update the version number in the readme.html file. If you need to do something else, it will be mentioned in the make/polyglots site.

readme

After finishing with the archives and changes, we can use the command svn status in our parent directory to see the changes that are going to be committed.

svn-status

Committing changes

  • If we are committing a minor version (3.9.1 for example), we will need to commit a tag with the new version
  • If we are committing a major version (4.0 for example), we will copy this new tag to a branch to upload the tag and branch

svn-branch

If we are using the Subversion option we will see the list of all .po and .mo archives; it’s a good idea to update the .mo and .po archives in the /trunk directory as well.

If we are using the translate.wordpress.org option, we are ready to commit our changes.

The command to commit our changes is svn commit or svn ci. We will add a message using the -m subcommand, containing:

  • the version we are uploading
  • the language we are uploading
  • please use english to make understanding easier

svn-commitAnd done! We are ready to go to our local WordPress.org site and build the new version of WordPress.

Building a localized WordPress  version

If you have just committed the files to the repository, you will need to wait a bit to see it appear in your local WordPress.org site.

Once it’s working, you need to select:

  • the translate.wordpress.org option
  • the /dist/ directory
  • the development (trunk) project

The WordPress version will change and you will see the last version in development. The revision number will be ignored, it only works in the Subversion option.

version-2

If you want to build an official release version, you will need to look in the project list and select the one that you are looking. You will get the last minor version released. Again, the version will be automatic and the revision number will be ignored.

version-prior

You can build and distribute as many beta and release candidate versions as you want. They will automatically go to the beta and release candidates place.

rc-versions

Deja un comentario

Entorno de desarrollo continuo con github y deployHQ

Una de las cosas que me está tocando hacer en mi nueva empresa es el staging. Buscar formas para que podamos tener un desarrollo continuo de todos nuestros productos y servicios, a la vez que tengamos todo controlado perfectamente.

Uno podría pensar que con github puede ser suficiente para montar un entorno como el descrito. Y lo es. Aunque soy más fan de crear releases y desplegarlas, podemos utilizar los commits como puntos de anclaje y así poder ir hacia adelante y hacia atrás en sus cambios.

Pero claro, a nosotros no nos importa entrar en el servidor y hacernos nuestro git push. Y no todo el mundo es como nosotros.

Además, cuestión comprensible, mi jefe me pide poder hacer él los commits de forma autónoma después de haberlos comprobado en el servidor de desarrollo. Y un método igual de sencillo para poder revertirlo. ¿Qué solución le damos?

Git como herramienta de versionado

Está claro que GitHub (git, en realidad) es la herramienta básica que todos utilizamos para llevar el control de nuestras versiones de código y para poder trabajar de forma colaborativa. Algunos todavía utilizamos en algunos entornos SVN (sobre todo los que hacemos cosas para WordPress, que en este aspecto sigue un poco en el pasado), y otros han pasado de GitHub a GitLab o Bitbucket.

En mi caso, yo me quedo con GitHub para todo lo que sea software libre (todos los repositorios públicos son gratuitos), y con Bitbucket para todo lo que sea privado (hasta 6 usuarios es gratuito). De esta forma, tengo todos los proyectos libres en GitHub, y todo lo relacionado con clientes en mi repositorio de Bitbucket. De esta forma puedo tener una copia completa de su sistema, configuración incluida, y siempre puedo ir hacia adelante y hacia atrás en el sistema.

Copias de seguridad con Bitbucket

Además del trabajo normal y rutinario, donde actualizamos cosas o programamos cosas y las añadimos a nuestro git, una de las cosas que tengo automatizadas para todos los clientes son las copias de seguridad. ¿Cómo las hago?

Aprovechando que Bitbucket no me pone límites a la hora de subir repositorios (aunque me ponga un bonito mensaje grande y amarillo si me paso del giga), lo subo todo ahí.

Cada 6 horas hago que el sistema ejecute un script con cron job.

Y hago que se haga una copia de seguridad en Bitbucket… (git add –all borrará también los archivos que se hayan borrado, y esto es importante para después).

… y otra de la base de datos, aunque ésta la guardo en local.

Dando un paso atrás con las bases de datos

Imaginaos que un cliente nos llama porque se ha cargado un artículo que estaba haciendo ayer. No sabe cómo ha pasado, pero el artículo se ha ido a la papelera, y la papelera se ha borrado sola. Sí, pasa mucho. Más de lo que os imagináis. ¿Cómo solucionamos esto?

Pues tiramos de copia de seguridad. Lanzamos este comando y…

¡Restaurado!

Pero atención. Esta copia de la base de datos es una copia completa de la base de datos. Si tenéis algo más que un blog conectado con Jetpack, esto machacará datos de métricas que para vosotros pueden ser muy valiosos. ¿Qué hacemos en ese caso? Pues modificar la copia de seguridad de la base de datos que hacíamos inicialmente, para ajustarla a nuestras necesidades. En el ejemplo tenéis cómo hacer un dump de la base de datos ignorando tablas, o añadiendo sólo las tablas que queramos.

Lo bueno que tiene este sistema es que nos podemos hacer una copia por cada tabla, o agruparlas de la forma que queramos, para que cualquier restauración del sistema sea muy sencilla y rápida de hacer. Si lo tenemos todo correctamente automatizado, podremos incluso hacerlo desde el móvil.

¿Esto sustituye a la copia de seguridad tradicional?

Podría, pero la respuesta es NO. Hago hasta tres copias de seguridad de todo, y en alguna ocasión he tenido que tirar de la tercera. Para no hacer una cuarta, organicé este sistema que me ayuda en el día a día. Pero estamos confiando en un sistema externo, por lo que debe ser una copia más.

Staging con DeployHQ

DeployHQ es un servicio que nos permite conectar un servicio de versionado como GitHub o Bitbucket a una cuenta.

dep1

Una vez conectado, nos mostrará el listado de nuestros repositorios, y podremos elegir cualquiera de ellos.

dep2Y una vez elegido, nos conectará con el servicio creando una nueva clave pública en Github de forma automática.

dep3

Tras este paso, DeployHQ nos cacheará el repositorio. De esta forma, podemos hacer cualquier despliegue en segundos.

Después añadiremos nuestro servidor (que puede ser una conexión por FTP, si estamos trabajando para un cliente externo).

ftp

Y a partir de este momento, ya estaremos preparados para enviar cosas al servidor. Todo lo que esté giteado lo podremos mover hacia adelante y hacia atrás, y el sistema de DeployHQ nos añadirá o borrará la información necesaria correspondiente a nuestro git. Y si ha pasado algo raro, incluso podemos volcar el repositorio completo.

repository

Y la ejecución es tal que así:

deployment

Así que tenemos:

  • Copias de seguridad que podemos llevar hacia adelante y hacia atrás siempre que necesitemos
  • Una forma de poner en producción cambios, y de revertirlos en seguida en caso de que vayan mal

Si estamos desarrollando en local, en un servidor de desarrollo, o en un directorio del mismo servidor, de esta forma podemos montarnos un sistema de control muy cómodo e interesante que nos puede ahorrar muchas horas y quebraderos de cabeza.

DeployHQ es gratis para un proyecto. También para proyectos Open Source si hablas con ellos. Y para repositorios privados, £6 al mes por 10 repositorios. Un precio más que razonable para tener totalmente atados los proyectos en los que estás trabajando.

Ejecutando comandos con DeployHQ

Después de probar distintos softwares para integración continua, me decanté por DeployHQ por estas razones:

  • Enlaza a tus cuentas existentes en GitHub, GitLab y Bitbucket. No tienes que contar con sus repositorios para funcionar.
  • Su web es totalmente responsive, lo que me permite utilizarla desde el móvil sin sufrimiento.
  • Permite conexión con servidores FTP, que es lo más común que vas a tener cuando trabajas con clientes externos que tienen servidores reguleros. La mayoría de otros servicios de integración continua funcionan únicamente a través de git pull/push.
  • Si lo conectamos a través de SSH, permite la ejecución de comandos.

Sí. Podemos decirle que ejecute comandos. Antes o después del despliegue, e incluso en qué despliegues queremos que ocurra.

before

Y podemos crear comandos tan peregrinos como éste:

after

Básicamente, nos permite jugar con todo lo que queramos. Si le ponemos un servidor dummy, que no haga ningún deploy, también podemos utilizarlo para:

  • lanzar copias de seguridad concretas
  • copias a FTP
  • copias a otro servidor
  • sincronización de servidores de desarrollo y producción con rsync o scp

Las posibilidades son muy grandes, y es lo que me gusta de haber montado un sistema así. Sí, £6 al mes. Merecen la pena.

4 Comments

Nuevo formato de menús para WP 3.6

menus-36

Deja un comentario

Adiós, post-formats, adiós

Con mucha pena nos toca decir en esta semana adiós con la manita a los post-formats en WordPress 3.6. Muchos comentaron en la Meetup de WP Marbella que el nuevo formato de tumblrización de WordPress no les gustaba, y en el chat de este miércoles se tomó la decisión de apartarlos del core.

Post-formats

Aparte de que esto pueda quedar muy chulo, si hubiera aparecido por el año 2008 o 2009 casi todos los desarrolladores habrían dicho al unísono esto es territorio plugin. Se nota que la fiebre del diseño y del UI/UX ha calado hondo, y en algunas cosas somos ahora más flexibles ;).

Aunque se pierda esta barra, como comentaba antes, pasará a ser un plugin tal y como comenta Mark Jaquith en este artículo. Lo que se saca del sistema es la UI (Interfaz de Usuario) que veis arriba, quedando en el sistema parte de la codificación. ¿Por qué se hace esto? Porque los formatos de entrada, como la imagen destacada por ejemplo, ya son utilizados por casi todos los temas disponibles. Por tanto, se ha decidido mantenerlos tal y como estaban antes de 3.6, y los temas podrán mostrar los distintos formatos de otra forma.

post-formats-2 Decimos adiós a la interfaz “bonita” de los formatos de entrada, pero no decimos adiós a los formatos, que seguirán dependiendo de los temas tal y como lo han hecho hasta ahora.

Qué es un formato de entrada

Es una forma de mostrar una entrada. Teniendo el mismo contenido, podemos mostrar la información de distintas formas. No es lo mismo que un Custom Post Type (CPT, tipo de datos), donde definimos un nuevo tipo de datos adaptado a nuestras necesidades, con nuevos campos, relaciones taxonómicas…

Por qué creo que esta decisión es buena

No ya tanto porque sea territorio plugin, sino porque se va viendo un espíritu colectivo de hacer que WordPress.org sea y siga siendo algo independiente de WordPress.com, donde este modelo de publicación posiblemente será un estándar.

Por otro lado, si se convierte en estándar en WP.com, me gustaría ver esta interfaz de publicación como módulo en la próxima versión de Jetpack.

Deja un comentario

Herramientas para trabajar con Responsive

Si estás profundizando en Resposive Design, estas herramientas te pueden ser útiles.

Deja un comentario

Creando un widget the right way

Lo vi en postat.us

Deja un comentario
A %d blogueros les gusta esto: