Categorías
hoy aprendí ...

… a decirle a git que deje de darle bola al cambio de modo de los archivos

git config core.fileMode false

Encontrado en https://stackoverflow.com/a/1580644

Con una explicación muy buena:

Try:

git config core.fileMode false

From git-config(1):

core.fileMode
    Tells Git if the executable bit of files in the working tree
    is to be honored.

    Some filesystems lose the executable bit when a file that is
    marked as executable is checked out, or checks out a
    non-executable file with executable bit on. git-clone(1)
    or git-init(1) probe the filesystem to see if it handles the 
    executable bit correctly and this variable is automatically
    set as necessary.

    A repository, however, may be on a filesystem that handles
    the filemode correctly, and this variable is set to true when
    created, but later may be made accessible from another
    environment that loses the filemode (e.g. exporting ext4
    via CIFS mount, visiting a Cygwin created repository with Git
    for Windows or Eclipse). In such a case it may be necessary
    to set this variable to false. See git-update-index(1).

    The default is true (when core.filemode is not specified
    in the config file).

The -c flag can be used to set this option for one-off commands:

git -c core.fileMode=false diff

Typing the -c core.fileMode=false can be bothersome and so you can set this flag for all git repos or just for one git repo:

# this will set your the flag for your user for all git repos (modifies `$HOME/.gitconfig`)
git config --global core.fileMode false

# this will set the flag for one git repo (modifies `$current_git_repo/.git/config`)
git config core.fileMode false

Additionally, git clone and git init explicitly set core.fileMode to true in the repo config as discussed in Git global core.fileMode false overridden locally on clone

Warning

core.fileMode is not the best practice and should be used carefully. This setting only covers the executable bit of mode and never the read/write bits. In many cases you think you need this setting because you did something like chmod -R 777, making all your files executable. But in most projects most files don’t need and should not be executable for security reasons.

The proper way to solve this kind of situation is to handle folder and file permission separately, with something like:

find . -type d -exec chmod a+rwx {} \; # Make folders traversable and read/write
find . -type f -exec chmod a+rw {} \;  # Make files read/write

If you do that, you’ll never need to use core.fileMode, except in very rare environment.

Categorías
hoy aprendí ...

… a como arreglar un problema de login en WordPress

Una instalación de WordPress vieja (4.0) que tenía un cliente dejó de funcionar al login cuando el proveedor de hosting hizo la actualización del servidor de PHP 5.6 a PHP7.

Lo primero fue activar los mensajes de error para saber qué estaba pasando.

Luego de obtener el mensaje realizar la búsqueda en la internet a ver si esto ya alguien lo había solucionado.

Y gracias a este sitio en alemán encontré la solución.

Hay que reemplazar una sola línea de código. Y luego de hacer el login, ingresar al panel y hacer la actualización de WP.

Y chau

Categorías
hoy aprendí ...

…apuntar por IP entre dnsExit y Wix

El sitio del que comentaba ayer al momento de publicarlo lo teníamos que asociar al dominio.

Como la idea era tener un subdominio alojado en otro servidor diferente de Wix para poder acceder vía SFTP la solución fue:

En el sitio de Wix asociar al dominio por apuntamiento IP (cosa que Wix no recomienda, pero somo así de aventureros) con lo cual en DNS Exit hay que agregar la IP que proporciona Wix y apuntar un registro.

Registros de apuntamiento

Haz clic aquí para saber cómo conectar tu dominio por apuntamiento.

Categorías
hoy aprendí ...

…que Wix es super atractivo (pero no todo lo que brilla es oro)

Tengo que trabajar con un colega en la construcción de un sitio web. Él usa Wix y yo tiro más para el lado de WordPress.

Pero como siempre me interesa aprender cosas nuevas, y ya tenía ganas de meterle mano al Wix, decidí que armaríamos en esa plataforma.

Lo primero es que es super atractiva, con colores, animaciones, una interfaz muy cuidad, con guías paso a paso, ayudas. Todo como para que el que tenga ganas le resulte fácil empezar a armar una página o sitio web. Casi parece un juego de Lego.

Pero algunas cosas se nota que están todavía las están incorporando, cosas que en WordPress ya las doy por echo (está bien, son casi 16 años y una comunidad gigante de desarrolo y soporte), pero las principales que necesitaba son:

  • Capacidad idioma
  • Que varios usuarios puedan editar (al mismo tiempo en diferentes partes)

Pero logramos resolver varias cosas y salimos adelante.

El principal problema fue el blog de entradas que el feed no cambiaba con el cambio de idioma. Hay una solución alternativa que propone la gente de Wix que es tagear las entradas por idioma y luego armar una página para cada feed de idioma y filtrar por el tag.

Otro problema que tuvimos, pero esto le puede pasar a cualquiera, es que en el home teníamos un ligthbox de video que reproducía automático al entrar, pero generaba problema con la animación de entrada de la cabecera y menú. Al cerrar el video desaparecía el menú y la cabecera.

La solución fue desactivas las animaciones de entrada (perdimos un poco de brillo en pos de la funcionalidad)

Sin embargo resulta interesante.

Categorías
hoy aprendí ...

… que a veces resolver algunas cosas de WordPress son más simples de lo que parece.

Un cliente me contactó porque su sitio web en WordPress se había «desarmado un poco»: en el home algunas cosas se desejustaron de la maquetación (apenas) y lo más importante, en una sección ya no le aparecían las imágenes.

La sección en cuestión usa un armado con solapas para separar los contenidos ligados a días específicos de la semana. Cada día tenía cargada una serie de imágenes, a modo de flyers, para cada actividad. Había dejado «funcionar», o por lo menos eso parecía porque no aparecía cuando se visualizaba la página desde la parte pública.

Cuestión que me pongo a relevar qué plugins tenía instalados. Un montón, y algunos con funciones similares como los site builders.

Dado que no tenía forma de hacer un backup completo de la base de datos, quería tocar lo menos posible y no actualizar ningún plugin ni nada.

Mientras trataba de ofrecerle una maquetación alternativa con el builder que sí funcionaba (o al menos eso pensaba yo), que le permitiera cargar las imágenes y separarlas por día de la semana (y que no sea un choclazo, vamos, que quede amigable), me encuentro que al querer aplicarle la misma plantilla de página ¡el contenido dejó de aparecer!

El problema era que la página había estado usando una plantilla que no le correspondía: específicamente la de archives. Cuando hago el cambio en la página original que no funcionaba, ¡empezó a funcionar de nuevo!

Por cierto, también aprendí que los builders pueden ser atractivos al principio, pero tienen demasiados pasos para hacer cosas sencilla. Igualmente me resultó interesante la forma en que se manejaban: