Cuando la función on_sent_ok os de el error de ajuste obsoleto (o is Deprecated), habrá que cambiar la función que tenemos por código JavaScript.
En nuestro caso, el cliente tenía una redirección a una URL, con lo que cambiamos el código a
|
1 2 3 |
if ($('.wpcf7-form.sent').length) { $(location).attr('href', 'https://www.midominio.com/otra_url') } |
En este artículo veremos qué componentes tiene Docker.
Básicamente, Docker es una aplicación cliente-servidor, y pueden trabajar ambos en la misma máquina, o en distintos servidores. Además, también existe una API REST para comunicarse con la parte servidor de Docker, aparte de la aplicación cliente, con lo que no tendremos problema alguno para trabajar con Docker.
Las imágenes de Docker es el código fuente de nuestros contenedores, es una colección ordenada de comandos y parámetros para ejecutarlos en el momento de arrancar el contenedor, para, por ejemplo, abrir con puerto, o ejecutar un comando.
Las imágenes que se crean, se guardan en registros, y existen dos tipos: públicos y privados, como podeis ver en la misma web de Docker.
Es el proceso o conjunto de procesos que se lanzan desde una imagen. Un contenedor puede ser creado, inicializado, parado, vuelto a ejecutar y destruido, a diferencia del resto de componentes de Docker.
Los contenedores reciben este nombre porque recuerdan a los contenedores que se utilizan en el transporte (todos hemos visto los contenedores de transporte marítimo, ¿verdad?). Así, podemos hacer un contenedor con una base de datos, una web, o cualquier otro servicio que pensemos, y podemos llevarlo de un sitio (servidor) a otro, sin problemas. De esta manera, el desarrollador enviará su imagen al departamento de testeo, o de puesta en producción desde su máquina local, sin que se pierda nada por el camino, a la par que todos los actores implicados en un desarrollo se aseguran de tener el mismo entorno en cada momento.
A veces sucede que cuando se instala un plugin en MAgento, o lo desinstalamos, o actualizamos la plataforma de alguna forma, la parte del front se ve perfectamente y funciona todo, pero al intentar entrar en el backend, no podemos acceder al mismo.
Nos ponemos un poco nerviosos, porque aunque no es la pantalla de mantenimiento, no podemos acceder al backend de nuestro comercio electrónico. Si después de hacer lo que te recomiendan en foros y webs, que suele ser “borrar el contenido del directorio de var/cache de Magento”, “borrar el contenido del directorio var/sessions de Magento” y ver que sigue igual, y después de poner el código correspondiente al modo desarrollador:
[crayon-5ae23a5cb95a6618198878/]
y comprobar que seguimos sin ver nada, ni en los archivos de log propios de Apache ni en los de var/log y var/reports de Magento, y tampoco has conseguido ver qué ocurre al desactivar la compilación, es que ha llegado el momento de utilizar este código, que devolverá qué clase es la que da el error, y por lo tanto, nos dará pistas de qué está ocurriendo (por ejemplo, que no se ha instalado / desintalado el plugin correctamente, o que la instalación ha encontrado algún problema a la hora de volcar todos los archivos de la actualización, y alguno no lo ha hecho, o se ha corrompido algún archivo, etc).
[crayon-5ae23a5cb95b1411029165/]
En desarrollo, estamos acostumbrados a que el despliegue de una aplicación en producción sea un dolor de muelas, y no nos gusta llegar al momento “paso a producción”, por la de posibles errores de última hora que nos encontramos. ¿Cuántas veces nos hemos encontrado que el desarrollo realizado en un servidor y entorno determinado, no funciona en otro? ¿Cuántas veces hemos dicho la temida frase “en mi local (o servidor) funciona”?. Solucionar este tipo de problemas siempre ha sido un añadido en todo proyecto que nunca se sabe calcular, hasta ahora, ya que gracias a herramientas como Docker, podemos realizar despliegues de desarrollos independientemente del entorno en el que se despliegan. ¿Cómo logramos hacerlo? ¿Realmente interesa trabajar con una herramienta como Docker? Para explicarlo, vamos a publicar unas entradas, en las que iremos viendo qué es y para qué sirve, y cómo funciona Docker. ¡Esperamos que os gusten!
Cuando realizamos una web, es conveniente no tener las imágenes en servidores de terceros, sino en nuestros propios servidores, o en un CDN. ¿Cómo descargamos las imágenes de otro servidor?
Podemos hacerlo de varias formas:
[crayon-5ae23a5cb97cc851804701/]O:
[crayon-5ae23a5cb97d2015583970/]Y la más eficiente de todas, si tenemos que descargar muchas imágenes, es hacerlo con cURL:
[crayon-5ae23a5cb97d5476966350/]
En Moodle, cambiar el tamaño máximo del archivo subido en el sitio o en los cursos no es complicado, pues la propia plataforma nos indica los ajustes que hay que modificar en el php.ini y en Apache.
Pero a veces ocurre que, a pesar de haberse propagado el cambio por toda la plataforma Moodle, el tamaño máximo del archivo subido en las tareas sigue siendo el antiguo (1 MB, 2 MB, etc.). Esto se debe a que en el caso de las tareas este ajuste hay que realizarlo a ese nivel, y para ello hay que acceder a otra parte de Moodle. El menú desplegable tiene un aspecto similar, pero se encuentra en Administración del sitio > Extensiones > Extensiones de tarea > Extensiones de entrega > Archivos enviados. Una vez allí, modificaremos el valor del tamaño máximo de las entregas en el menú desplegable pertinente.
Seguro que más de una vez habeis tenido una web con su certificado SSL, y os ha dado el error de que hay elementos no seguros en ella.
Este error es muy sencillo de corregir y se da cuando en una página que va sobre HTTPS, tiene referencias a elementos HTTP.
Para no tener que revisar cada una de las líneas de nuestro código buscando las referencias erróneas, podemos ir a la web http://www.whynopadlock.com y darle la URL de la página que nos devuelve ese error de elementos no seguros, y nos dará un informe de cada elemento no seguro, incluidas imágenes de la hoja de estilo, enlaces no seguros, etc.
Probablemente muchos de vosotros habréis tenido dificultades para acceder a los enlaces del footer de Magento. Esto se debe, una vez más, a la particular distribución/dispersión de los archivos en esta plataforma. A grandes rasgos, los enlaces del pie de Magento pueden estar en dos lugares bien diferentes: en un bloque estático del back-end, o repartidos por una serie de archivos XML.
Bloque estático Footer links
Para acceder al contenido de este bloque estático, ingresamos en el back-end de Magento y nos vamos a CMS > Bloques estáticos.
Dentro de la lista de bloques aparecerá uno llamado Footer links. Hacemos doble clic sobre su fila para acceder al código HTML que contiene.
Esto nos llevará a una pantalla que en su parte inferior tiene un editor WYSIWYG que nos permitirá editar el código de los enlaces a nuestro gusto.
Pero no todos los enlaces se encuentran aquí. Probablemente también tengamos que acceder a otros enlaces que se encuentran repartidos en varios archivos XML.
Archivos XML
El número de los archivos implicados puede variar según la versión de Magento, aunque en general suelen ser casi siempre los mismos, y deberemos acceder a ellos por FTP. Su ruta de acceso es app/design/frontend/default/default/layout.
En nuestro caso (nosotros estamos trabajando con la 1.7.0.2), los archivos que hemos tocado son los siguientes:
Si lo que queremos es eliminar los enlaces del pie (bien porque queremos prescindir de alguno, bien porque vamos a crearlos manualmente en el editor del back-end que vimos en el punto anterior), deberemos localizar la etiqueta <reference name=”footer_links”> y marcarla (desde su apertura hasta su cierre) como comentario, para desactivarla. Procederemos del mismo modo con todas las etiquetas con el mismo atributo name de estos archivos.
Como comentamos, los archivos a editar pueden variar según el caso, por lo que puede que también aparezcan etiquetas similares en los archivos rss.xml, page.xml, cms.xml y customer.xml.
if ((!$this->visible or !$this->available) and
!has_capability('moodle/course:viewhiddenactivities', $modcontext, $userid)) {
$this->uservisible = false;
y sustituirlo por
if ($modcontext != "") {
if ((!$this->visible or !$this->available) and !has_capability('moodle/course:viewhiddenactivities', $modcontext, $userid))
{ $this->uservisible = false; }
}
else
{ $this->uservisible = false; }
Primero explicamos brevemente qué es wget. Según la definición de la Wikipedia:
GNU Wget es una herramienta libre que permite la descarga de contenidos desde servidores web de una forma simple.
Una vez lo tenemos claro, vamos a ver cómo instalamos esta herramienta en nuestro Mountain Lion. Lo primero que tenemos que tener instalado en nuestro sistema operativo es el Command Line Tools for Xcode. Para ello necesitamos tener una cuenta de desarrollador (developer) en Apple. Para ello nos damos de alta en Apple’s developer page y descargamos la herramienta. La instalamos como cualquier otro paquete de aplicaciones y comprobamos que funciona. Para comprobarlo, abrimos una ventana de Terminal y escribimos
gcc -v
Si os sale algo parecido a
Using built-in specs.
Target: i686-apple-darwin11
Configured with: {ignore long text…}
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
quiere decir que está todo el paquete de herramientas de Apple instalado correctamente.
Bien, a partir de aquí, seguimos en la ventana de Terminal y escribimos los siguientes comandos:
Primero nos vamos a la carpeta de Descargas, para bajarnos el archivo de instalación de wget:
cd ~/Downloads
Descargamos el paquete
curl -O http://ftp.gnu.org/gnu/wget/wget-1.14.tar.gz
Lo descomprimimos
tar -zxvf wget-1.14.tar.gz
Vamos a la carpeta
cd wget-1.14/
Lo configuramos
./configure --with-ssl=openssl
Hacemos la instalación
make
sudo make install
Y borramos el directorio de instalación
rm -rf ~/Downloads/wget*
Y listo, ya podemos hacer un wget del archivo que necesitemos.
