Web

Los mejores hosting de España para tu proyecto

Muchos de vosotros seguramente tengáis vuestro propio proveedor de hosting preferido para alojar vuestras páginas web. Otros en cambio aún no hayáis creado aún nunca un proyecto web pero estáis pensando en hacerlo. Sea cual sea tu caso, analizamos varias de las empresas que ha día de hoy consideramos que son los mejores hosting en Español del momento. En función de cual sea tu objetivo, te compensará más contratar con uno o con otro.

Lo mejor de los hosting españoles es que han ajustado mucho sus precios. Ya no hace falta recurrir a empresas extranjeras como Hostgator por ejemplo para poder alojar tu página web de forma económica. Antiguamente, la única opción para tener un hosting barato era recurrir al extranjero. Esto gracias a Dios a cambiado y hoy en día existen empresas nacionales con precios muy competitivos y servicios muy buenos. Además han aprendido muy bien la forma de hacer marketing que tenían las empresas americanas y es realmente sencillo encontrar comparativas como esta donde tienes descuentos para la mayoría de ellas.

Empresas de hosting en Español que te recomendamos

En función de que tipo de proyecto quieras alojar, te compensará más una u otra empresa, pero a grandes rasgos y para prácticamente cualquier proyecto, te recomendamos estos hosting:

Webempresa: Verás que es uno de los más recomendados en la blogosfera y de los más utilizados. El crecimiento de Webempresa ha sido brutal y en poco tiempo ha superado los 20.000 usuaruios y no para de crecer manteniendo la calidad tanto de su servicio como de su soporte, uno de los aspectos que sin duda más valoramos. A pesar contar sólo con planes de hosting compartido son capaces de aguantar miles de visitas al día sin ningún problema, gracias a que utilizan Nginx, Varnish, Apache, MemCache, OPCache junto a su plugins de Magic Cache. La verdad es que sus planes de alojamiento web rinden más como un VPS que como un compartido.

Factoría Digital: Otra de las empresas destacadas del sector pero con precios más altos. Sus planes de hosting y servidores están enfocados a un sector más profesional, centrándose sobre todo en ofrecer hosting especializado en comercio electrónico. Destacan sus planes optimizados para Prestashop y Magento.
Si tu intención es alojar una tienda online te recomendamos que eches un vistazo a sus servicios.

Raiola Networks: Un player relativamente nuevo que ha sabido hacerse un hueco sobre todo entre algunos de los bloggers nacionales más influyentes, lo que le ha ayudado a crecer rápidamente. Lo cierto es que además de su marketing, el servicio que ofrecen es realmente bueno y al igual que Webempresa cuentan con un equipo de soporte solvente y rápido que te ayuda en todo lo que necesites. A diferencia de Webempresa, también ofrecen VPS y servdores dedicados, por lo que si eres un desarrollador o necesitas contratar un servidor puede ser una muy buena opción.
Cubenode: Otra de las empresas españolas que queremos destacar, sobre todo en el apartado de servidores, es sin duda Cubenode. Quizás no sea tan conocida como las otras mencionadas anteriormente, pero sus planes de precios para servidores virtuales sobre todo son bastante económicos y funcionan muy bien. Las críticas que tienen entre sus usuarios son muy buenas.

Profesional Hosting: Por último, queremos mencionar a Profesional Hosting, un clásico de los proveedores de servicios de alojamiento web y que destacamos por ofrecer alojamiento web optimizado para prácticamente cualquier script que quieras utilizar. Mientras la mayoría de empresas se centran en Wordpress y Prestashop, Profesional Hosting ofrece servicios adaptados para muchísimos más gestores que quizás te puedan interesar en función del que vayas a utilizar.

Como podéis ver, cualquiera de estas empresas españolas mencionadas ofrecen alojamiento web por menos de 100€ al año, es decir, por muy poco dinero puedes tener un hosting de calidad para tu proyecto y no te hace falta recurrir a empresas extranjeras que en caso de necesitar un soporte te las verás y desearás para entenderte con ellos.

Y tu, ¿qué empresa de hosting utilizas?

PHP error

Aumentar memoria en WordPress para evitar Fatal error: Allowed memory size of N bytes exhausted

Si manejáis WordPress a diario seguro que alguna vez habréis sufrido un error de falta de memoria RAM, que se traduce en un mensaje de este tipo:

Fatal error: Allowed memory size of N bytes exhausted

Como sabréis, PHP es un lenguaje del lado del servidor, que se interpreta (no se compila) y que en cada ejecución necesita una no despreciable cantidad de memoria para poder ejecutarse. Si usamos un sistema gestor de contenidos como WordPress y encima usamos cantidad de plugins y un theme que sea algo pesado, es muy posible que una ejecución necesite del orden de 64MB de RAM hacia arriba (he visto necesidades de más de 128 MB de RAM para ciertas operaciones).

Desde el punto de vista del rendimiento, esto podemos solucionarlo usando cachés (a varios niveles: Varnish o WP Super Caché son dos ejemplos) pero las cachés en una primera ejecución, tienen que llamar al sistema por lo que siempre tendremos este problema aunque estemos usando una caché.

La solución varía en el entorno en el que estemos trabajando, servidor propio o compartido, pero voy a daros una solución que debería funcionar en la mayoría de los casos (siempre y cuando el proveedor de servicios no os quite la posibilidad de aumentar la cantidad de RAM disponible vía .htaccess).

La solución consta de dos pasos.

Aumentar memoria disponible en .htaccess

En el fichero .htaccess que ha creado WordPress en el raíz de la instalación, incluimos lo siguiente:

<IfModulemod_php5.c>
php_value memory_limit 128M
</IfModule>

Si con 128MB de RAM no es suficiente, lo subimos.

Definir el límite de memoria en el fichero de configuración de WordPress

Haremos algo análogo pero en el fichero wp-config.php, incluyendo esta línea:

define( 'WP_MEMORY_LIMIT', '128M' );

¿Te sigue ocurriendo? Cuéntanoslo que te ayudemos.

Logo PHP

Manejo básico del búfer en PHP

Logo PHPSiempre que manejamos PHP, existe la problemática de mezclar la vista y funcionalidad. Este problema se da a varios niveles y es más complejo y da más quebraderos de cabeza cuanto más se enrevesan código y funcionalidad, el caso típico es cuando guardamos parte de la vista en una cadena y la devolvemos o la imprimimos. Al meter la vista dentro de la cadena, el código se vuelve poco legible y además hay ocasiones en las que este métodos llega a ser inoperable.

Veamos un ejemplo:

$cadena = "Voy a preparar una cadena con parte de la vista";
$cadena .= "Para devolverla";
$cadena .= "Aquí podríamos meter código HTML";
return $cadena;

Ese caso llevado al extremo sería mucho más grande, con variedad de código HTML y JavaScript en su interior y con un enrevesamiento tal que haría muy complejo su manejo y mantenimiento.

Gracias a que PHP nos ofrece multitud de soluciones, la solución es bien sencilla. Usar las funciones de búfer. Un apunte rápido:

  • ob_start(): abre el búfer
  • ob_get_contents(): obtiene los elementos que hay en ese momento en el búfer
  • ob_end_clean(): cierra el búfer y lo limpia

Con estas tres funciones, el código equivalente al de arriba, sería tan simple como el que sigue:

ob_start();
?>
Voy a preparar una cadena con parte de la vista
Para devolverla
Aquí podríamos meter código HTML
<?php
$cadena = ob_get_contents();
ob_end_clean();

return $cadena;

Podremos jugar tanto como queramos con el código HTML, en lugar de hacer una salida a pantalla, se acumulará en el búfer y podremos manejarlo en forma de variable. Además de ese tipo de salida, podremos manejar salidas con echos también para acumular datos en el búfer.

Sin lugar  dudas, una funcionalidad estupenda de PHP para hacer más legible el código y ampliar más aún su potencia. Yo lo uso prácticamente a diario desarrollando con WordPress.

Akismet no conecta. Configurar Akismet detrás de un proxy

Si Akismet, el archiconocido plugin de WordPress para evitar SPAM, no es capaz de conectar con sus servidores puede ser por dos motivos, o porque sus servidores están caído (esto no suele pasar), o porque la red donde nos encontramos está bajo un firewall. ¿Qué hacemos en este caso? posiblemente los administradores de esa red provean un salida opcional mediante proxy.

proxy_akismet_linux_hispano

Este fue nuestro caso en uno de nuestro últimos proyecto con Codection. No citaré el nombre de la organización, pero si diré que tiene un volumen bastante grande, y la opción de abrirnos puertos o pasarelas para un servicio determinado no suele ser una opción que se ofrezca. ¿Entonces? Lo que os adelantaba arriba, la instalación de WordPress saldrá por un proxy.

¿Qué problema tiene Akismet con un proxy? Básicamente que no está debidamente preparado. Pero tras unos pocos cambios veréis cómo funciona a la perfección. Os explico cómo hacerlo.

Lo primero es definir en nuestro wp-config las siguientes líneas, especificando lo correspondiente a cada caso.

[code]define('WP_PROXY_HOST', 'url.del.proxy');
define('WP_PROXY_PORT', '8100');
define('WP_PROXY_USERNAME', 'usuario'); // no todos los proxies necesitan autenticación
define('WP_PROXY_PASSWORD', 'contraseña');[/code]

Ahora hemos de modificar el plugin, para ello, editamos el archivo akismet.php que encontramos dentro del directorio del plugin (por defecto: /wp-content/plugins/akismet). Buscamos la función akismet_http_post y la reemplazamos por la siguiente. Y eso es todo.

[code]

function akismet_http_post($request, $host, $path, $port = 80, $ip=null){
global $wp_version;
$akismet_version = constant('AKISMET_VERSION');
$args = array(
'method'=>'POST',
'user-agent'=>"User-Agent: WordPress/$wp_version | Akismet/$akismet_version",
'body'=>$request
);
$url = "http://".$host.$path;

if( !class_exists( 'WP_Http' ) )
include_once( ABSPATH . WPINC. '/class-http.php' );
$http_request = new WP_Http;
$http_response = $http_request->request($url,$args);
if( is_wp_error( $http_response ) )
return;
$response[0] = $http_response['headers'];
$response[1] = $http_response['body'];
return $response;
}

[/code]

qTranslate

Saber qué lenguaje está siendo visualizado con qTranslate en WordPress

El tema del multilenguaje en WordPress es uno de los grandes problemas que todavía no ha resuelto este popular sistema gestor de contenidos. Ahora en WordPress 3.8 se espera que los Language Packs sean la solución, sin embargo, hasta que no sea oficial y no tengamos una versión funcional, debemos buscar soluciones de terceros.

Básicamente hay dos soluciones populares en forma de plugins para este problemas (otras soluciones pasan por tener por ejemplo, una instalación en cada lenguaje). Son dos, una premium WPML y otra gratuita qTranslate. Manejo los dos habitualmente cuando trabajo como experto WordPress, así que dedicaré unas pocas entradas a este tema porque me parece interesante para todos.

qTranslate

¿Cómo sé que lenguaje está activo en un momento determinado con qTranslate?

Podéis usar esta variable:

$GLOBALS['q_config']['language']

Esta variable contendrá una cadena del tipo: es, de, en... con esto tendréis resulto ya este problema. Otro día hablaremos de cómo hacerlo con WPML.

WordPress AJAX

Diferencia entre wp_ajax y wp_ajax_nopriv

Cuando trabajas con AJAX en WordPress, si quieres hacerlo bien, debes hacer llamadas a admin-ajax.php y desde ahí gestionar las peticiones y sus salidas. Si conocéis esta técnica, conoceréis las funciones: wp_ajax_(acción) y wp_ajax_nopriv_(acción) (de la que no encuentro una referencia directa en el Codex, es raro).

WordPress AJAX

La diferencia entre ambas no se suele conocer y lo malo es que si no lo sabes, recibirás todo el rato un cero (0) como salida de la petición del admin-ajax.php si no estás usándolo correctamente. La diferencia es la siguiente:

  • wp_ajax: se usa cuando el usuario tiene que haber iniciado sesión
  • wp_ajax_nopriv: cuando el usuario no tiene que haber iniciado sesión

La llamada sería así en cada caso:

add_action( 'wp_ajax_<acción>',  );
add_action( 'wp_ajax_nopriv_<acción>',  );

Un ejemplo práctico que acabo de hacer:

add_action( 'wp_ajax_actualizar_formulario', 'actualizar_formulario' );
add_action( 'wp_ajax_nopriv_envio_contacto', 'enviar_formulario_contacto' );

¿Manejáis AJAX con WordPress? ¿Tenéis dudas?

Datepicker jQuery UI

Localizar calendario datepicker de jQuery UI: formato de fecha y nombres de los meses

Cuando hacemos desarrollos web para proyectos con algún apartado de gestión basado en formularios, lo más normal, es que terminemos teniendo que introducir fechas. Las fechas son un tanto problemáticas, tanto por su posterior manejo, como por su introducción por parte del usuario. ¿Por qué? Por dos razones:

  • Hay que introducirlas en un determinado formato, en español es primero el día, luego el mes y luego el año, todo separado por barras "tipo Unix". Podemos hablar de diferentes formatos, depende del país y la cultura y podemos hablar también de fechas incluyendo el día de la semana o incluso el nombre del mes con letras.
  • Es más fácil y más gráfico hacer clic sobre un día en un calendario que escribir la secuencia a mano.

Una buena solución suele ser manejar un calendario que salga directamente sobre el campo de texto como este que os muestro a continuación:

Datepicker jQuery UI

El que siempre uso en estos casos es jQuery UI Datepicker. Lo más normales que dependiendo de dónde sea tu cliente, que tengas que traducir el nombre de los meses, de los días de la semana y el formato de las fechas adaptarlo a tu estándar.

¿Cómo? Puedes hacerlo todo de una vez siguiendo las posibilidades de localización de la API, para traducir todos los calendarios a español por defecto tendríamos:

$.datepicker.setDefaults( $.datepicker.regional[ "es" ] );

O si queremos hacer lo mismo pero para un elemento en concreto al crearlo:

jQuery( ".datepickerui" ).datepicker( $.datepicker.regional[ "es" ] );

Cambiar directorio por defecto de Apache

Si trabajáis con Apache, quizás os interese conocer cómo cambiar el directorio por defecto del mismo para poder cambiar la ruta de acceso a los datos del mismo a vuestro antojo. Tened en cuenta que por defecto suele ser: /var/www. Por partes.

Lo primero que hacemos es copiar la plantilla de sitios disponibles para crear una nueva:

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/misitio

Ahora debemos editar dicho fichero (recordad que debéis ser superusuarios para editarlo, con algo como gksudo gedit fichero no tendréis problemas para editarlo). En una de las primeras líneas aparece:

DocumentRoot /var/www

Debemos cambiar la parte derecha a lo que más os guste, por ejemplo:

DocumentRoot /home/carazo/miweb

Lo siguiente que tenéis que hacer es buscar la siguiente directiva:

<Directory /var/www/>

Y también cambiarla de forma análoga. Ya estamos en disposición de guardar el fichero y proceder a comunicarle a Apache que el sitio por defecto ha cambiado, para ello:

  • Deshabilitamos primero el anterior: sudo a2dissite default
  • Activamos el actual: sudo a2ensite misitio

Sólo queda reiniciar el servicio para que ponga en práctica los cambios:

sudo service apache2 restart

Eliminar enlaces de una cadena en PHP

En alguna ocasión, mostrando un extracto o por cualquier otra razón, a lo mejor necesitáis eliminar los enlaces de una cadena que manejáis en PHP. Para esta labor, podemos usar el siguiente código, que se basa en el uso de una expresión regular:

$cadena = preg_replace('/\b(https?|ftp|file):\/\/[-A-Z0-9+&@#\/%?=~_|$!:,.;]*[A-Z0-9+&@#\/%=~_|$]/i', '', $cadena);

Con esto tendríamos la  cadena sin enlaces: HTTP, HTTPS, FTP o FILE, si queréis podéis ampliar la primera parte de la expresión regular para incluir más posibilidades.

Imitar target=”_blank” en JavaScript

Cuando trabajamos con JavaScript, en ocasiones imitamos el comportamiento de la etiqueta <a href=""> de anchor, de HTML, con un location.href = url. Sin embargo, cuando queremos que el enlace destino se abra en una pantalla aparte, haciendo uso de la expresión:

<a href="URL" target="_blank">el texto del enlace</a>

No podemos usar ese método, sino este que muestro a continuación:

<script type='text/javascript'>
window.open(url);
</script>

Uso de CDN: ventajas e inconvenientes

El hecho de tener una CDN (Content Delivery Network o Red de Entrega de Contenidos), tiene puntos positivos y negativos. Antes de comentarlos, tenemos que comprender qué es exactamente.

Una CDN nos proporciona la posibilidad de descargar contenido estático: imágenes, audio, librerías en JavaScript, estilos CSS, etc. desde una fuente diferente a nuestro servidor principal donde tenemos alojado nuestra aplicación web, por ejemplo nuestro WordPress o cualquier otro.

¿Pero por qué usarlos?

Ventajas

  • Actualización: te puedes asegurar de que siempre tienes la última versión de cierta librería (por ejemplo jQuery)
  • Rapidez: mientras tu servidor dialoga con el cliente atendiendo una a una las peticiones HTTP, con un CDN son dos servidores, por lo que la transferencia es más veloz
  • Posibilidad de descargar a un servidor de proceso de entrega de contenido estático (por ejemplo, podemos tener Apache sirviendo contenido dinámico y a Nginx limitándose a ofrecer contenido estático)

Inconvenientes

  • Si usamos un CDN externo puede haber un coste extra 
  • Los CDN suelen tener un uptime mayor que el nuestro, sin embargo, no deja de ser un riesgo que el CDN caiga

Sabidos ya los convenientes e inconvenientes, en la próxima entrada hablaré de cómo usar librerías populares de JavaScript usando los CDN de Google.

Monitorizar servidor web para ver si está caído o no de forma automática

Probablemente, tengáis más de una vez problemas con los servidores que mantenéis. Un problema típico es que un servidor web deja de dar servicio por cualquier razón. Cuando esto pasa depende de la gravedad, podemos tomar muchas acciones. A veces con reiniciar el servidor web, un proxy caché que tengas o cualquier otro, puede ser suficiente.

Para no tener que estar pendientes, lo ideal es que tengas este proceso automatizado y se ejecute cada cierto tiempo. ¿Cómo? Veamos.

Crear el script

Este es el primer paso, deberemos crear un fichero chequeo.sh o como queráis llamarlo con permisos de escritura e incluir dentro de él las siguientes líneas:

#!/bin/bash
url="aquí_tu_url";
response=$(curl -s -I -L $url | grep HTTP); 

status=${response#* };
status=${status:0:3};

if [ "$status" != "200" ] 
then
    // acciones a efectuar
fi

Sólo necesitaréis tener instalado curl. Dentro de URL ponéis la URL que queráis vigilar, propia o externa y en acciones a efectuar pues ya veis qué os interesa más: enviaros un correo con la alarma, forzar un reinicio del servicio (service apache2 restart o service varnish restart) o llamar a otro script para cualquier otra acción.

Programar la ejecución

Todo esto está interesante, pero mucho más si lo metemos en el cron. Para ello nos vamos al fichero /etc/crontab como superusuarios e insertamos una línea más:

0-59 * * * * root sh /ruta-a-fichero/chequeo.sh

Guardamos y listo.

Agrupar misma regla CSS para varios elementos

Cuando estás creando reglas CSS, es muy frecuente que diseñes reglas para cada elemento o grupo de elemento definiendo clases. Es correcto agrupar elementos en grupos mediante las clases, sin embargo, también es correcto definir una sola regla CSS para varios identificadores y clases o partes de reglas que son comunes a varias.

Esto es correcto pero es menos usado y conocido y de ahí la entrada de hoy.

¿Por qué conviene hacerlo?

Básicamente por simplidad y velocidad. Velocidad en dos aspectos, por un lado, por tiempo de transmisión (menos tamaño del fichero CSS resultante), por otro lado, por tiempo de interpretación (menos reglas que interpretar y menos reglas sobre las que buscar al renderizar).

¿Cómo se hace?

Probablemente ya lo sepáis pero merece la pena volver a comentar la sintaxis. Tened en cuenta que ciertos framework como jQuery también hacen uso de la misma sintaxis y puede seros útil.

Veamos un ejemplo esclarecedor:

body {font-size: 12px; }
body {font-family: arial, helvetica, sans-serif;}
th {font-size: 12px; font-family: arial, helvetica, sans-serif;}
td {font-size: 12px; font-family: arial, helvetica, sans-serif;}

Podemos reducirlo a esto:

body, th, td {font-size: 12px; font-family: arial, helvetica, sans-serif;}

Simple, ¿no?

Seguridad en formularios WordPress: usando nonce

Cuando usamos WordPress como un CMS o incluso como una API y desarrollamos para él, no serán pocas las veces que tengamos que hacer operaciones de inserción y edición de datos mediante formularios.

Tener un formulario en una aplicación web, es un punto de entrada a nuestro sistema y un sitio complicado en lo que a seguridad se refiere. Si no cuidamos este aspecto también en WordPress, lo que es un CMS seguro, puede convertirse en un problema.

Para resolver este tema, la API de WordPress nos proporciona un mecanismo muy sencillo llamado nonce, que viene del inglés: número usado sólo una vez,  number used once.

Se usan en todo tipo de peticiones: salvando opciones en el administrador, haciendo peticiones AJAX o llevando a cabo cualquier acción susceptible de un problema de seguridad intercambiando información.

La idea se basa en crear una clave secreta, que se comprobará en cada paso en el que el código se va a ejecutar.

Nonces en WordPress

¿Cómo funcionan? El funcionamiento lo podemos resumir en pocos pasos:

  • Generamos un nonce con un identificador único
  • Pasamos el nonce a través de la petición de datos (enlace o formulario) al script en cuestión que va a recibirlo
  • En el script, verificamos el nonce antes de hacer cualquier otra cosa

Este es el funcionamiento con palabras, con código es el siguiente, primero creamos el nonce (ten en cuenta que la frase que uses al crearlo, va a ser la que uses siempre en tu código):

$nonce= wp_create_nonce ('mi-nonce');

Lo siguiente será pasar el valor al script que va a hacer la manipulación de datos:

<a href="miscript.php?_wpnonce=<?php echo $nonce ?>">

Dentro de dicho script, verificamos que es correcto y en caso de que no lo sea, cortamos la ejecución:

$nonce=$_REQUEST['_wpnonce'];
if (! wp_verify_nonce($nonce, 'mi-nonce') ) 
   die("Alerta de seguridad");

Y con esto tenemos asegurada nuestra manipulación de datos en WordPress.


1 2 6 7