This post was published 14 years ago so it may be outdated.
Saber el navegador con el que se accede a nuestras páginas web es algo muy útil. Lo podemos utilizar para cargar algo de CSS / Javascript específico para un navegador (como por ejemplo, para evitar errores con IE6), también lo podemos usar para cargar una página completamente distinta en navegadores antiguos y, ¿por qué no? para mostrar una página específica para móviles.
Ya he comentado este tema en otras ocasiones, pero esta vez ampliaré el rango de navegadores a detectar, concretamente nos centraremos en Internet Explorer, Firefox, Safari, Opera, Konqueror, Chrome, iPod Touch, iPhone, Android (vale, estos tres no son navegadores, pero en estos casos me refiero a detectar el sistema operativo) o cualquier tipo de navegador para móvil.
En esta ocasión crearemos una función que acepte dos parámetros: el navegador que queremos buscar y la versión específica que buscamos (si es que buscamos alguna versión en especial). Para el primer parámetro, usaremos una serie de identificadores:
Identificador
Navegador
IE
Internet Explorer
FF
Firefox
SF
Safari
OP
Opera
KQ
Konqueror
CH
Chrome
IPD
iPod
IPH
iPhone
IPO
iPod / iPhone
AD
Android
MB
Navegador de móvil
Sobre la versión del navegador, sólo nos centraremos en las versiones de Internet Explorer.
La función seguirá la siguiente estructura:
Cargamos en una variable el agente de usuario del visitante.
Mediante un bucle foreach determinamos en qué navegador buscamos.
Mediante la función strrpos comprobamos si el agente de usuario se corresponde con el del navegador que buscamos.
Sólo si buscamos Internet Explorer: Detectamos si se ha accedido con la versión que hemos establecido (si es que hemos establecido alguna versión).
Sólo si buscamos un navegador móvil: Buscamos alguno de los diversos agentes de usuario que tienen los diferentes navegadores para móviles.
Devolvemos el valor true si se ha detectado el navegador en cuestión y false si no se ha detectado, a través de una variable que tiene por defecto el valor false y sólo cambia a true al detectarse el navegador.
Finalmente todo esto traducido a PHP quedaría así:
[php]
function is_browser($name, $version=”) {
$user_agent = $_SERVER[‘HTTP_USER_AGENT’]; // Cargamos el UserAgent en una variable
$wtr = false; // Esta variable es la que indica si se ha accedido con el navegador que buscamos o no. Por defecto es false, sólo cambia si se accede con el navegador buscado
$wtmb = ”; // Esta variable almacena el navegador del dispositivo móvil (sólo si buscamos un navegador de dispositivo móvil, esto no incluye ni Android ni iPod ni iPhone)
// Primero veamos a quién buscamos y luego comprobemos si es él
switch ($name) {
// Caso Internet Explorer
case ‘IE’:
if (strrpos($user_agent, "MSIE") === false) {} else {
if ($version != ”) {
if (strrpos($user_agent, ‘MSIE ‘.$version) === false) {} else { $wtr = true; }
} else {
$wtr = true;
}
}
break;
// Caso Firefox
case ‘FF’: if (strrpos($user_agent, "Firefox") === false) {} else { $wtr = true; } break;
// Caso Opera
case ‘OP’: if (strrpos($user_agent, "Opera") === false) {} else { $wtr = true; } break;
// Caso Konqueror
case ‘KQ’: if (strrpos($user_agent, "Konqueror") === false) {} else { $wtr = true; } break;
// Caso Chrome
case ‘CH’: if (strrpos($user_agent, "Chrome") === false) {} else { $wtr = true; } break;
// Caso Safari
case ‘SF’: if (strrpos($user_agent, "Safari") === false) {} else { $wtr = true; } break;
// Caso iPod
case ‘IPD’: if (strrpos($user_agent, "iPod") === false) {} else { $wtr = true; } break;
// Caso iPhone
case ‘IPH’: if (strrpos($user_agent, "iPhone") === false) {} else { $wtr = true; } break;
// Caso iPod o iPhone
case ‘IPO’:
if (strrpos($user_agent, "iPod") === false) {} else { $wtr = true; }
if (strrpos($user_agent, "iPhone") === false) {} else { $wtr = true; }
break;
// Caso Android
case ‘AD’: if (strrpos($user_agent, "Android") === false) {} else { $wtr = true; } break;
// Caso navegador móvil
case ‘MB’:
$mua = array(
‘PIE4’ => ‘compatible; MSIE 4.01; Windows CE; PPC; 240×320’,
‘PIE4_Smartphone’ => ‘compatible; MSIE 4.01; Windows CE; Smartphone;’,
‘PIE6’ => ‘compatible; MSIE 6.0; Windows CE;’,
‘Minimo’ => ‘Minimo’,
‘OperaMini’ => ‘Minimo’,
‘AvantGo’ => ‘AvantGo’,
‘Plucker’ => ‘Plucker’,
‘NetFront’ => ‘NetFront’,
‘SonyEricsson’ => ‘SonyEricsson’,
‘Nokia’ => ‘Nokia’,
‘Motorola’ => ‘mot-‘,
‘BlackBerry’ => ‘BlackBerry’,
‘WindowsMobile’ => ‘Windows CE’,
‘PPC’ => ‘PPC’,
‘PDA’ => ‘PDA’,
‘Smartphone’ => ‘Smartphone’,
‘Palm’ => ‘Palm’
);
foreach($mua as $nav => $ua){ if(strstr($user_agent, $ua) != false) { $wtmb = $nav; } }
if ($wtmb != ”) { $wtr = true; }
break;
// Caso genérico
default: $wtr = false; break;
}
return $wtr;
}
[/php]
Finalmente el uso es muy sencillo, basta con verificar el valor que devuelve la función, de modo que si buscamos, por ejemplo, a Opera, usaríamos el siguiente código:
[php]
if (is_browser(‘OP’)) {
/* Código específico para Opera */
} else {
/* Código para el resto de navegadores */
}
[/php]
This post was published 14 years ago so it may be outdated.
Gestor de menús de WordPress 3.0
¿Os acordáis de aquel artículo que escribí en el que recopilaba las novedades que me gustaría que añadiesen en WordPress 3.0? Pues bien, parece que una de ellas sí que estará en la nueva versión de WordPress, que incluirá un nuevo gestor de menús. Estará basado en el sistema de menús que ofrecen los themes de pago de WooThemes, y por lo que parece de momento, funcionará de forma similar a las actuales sidebars: arrastrando un elemento hasta un contenedor y estableciendo a continuación su configuración.
Esto me hace pensar que puede se añada una nueva API para interactuar con el menú y añadir desde plugins nuevos tipos de elementos al menú (como se puede hacer ahora con los widgets: un plugin puede añadir un nuevo tipo de widget a los disponibles en las sidebars).
En otro orden de cosas, el anuncio oficial también comenta brevemente el calendario de WordPress y la integración con WordPress MU. Respecto a las fechas, se ha establecido la fecha límite para añadir nuevas funciones al lunes 1 de marzo (sí, pasado mañana). A partir de ese día se centrarán en acabar las funciones que están a medias y en parchear cualquier error que pueda haber. La fecha de liberación de WordPress 3.0 quedaría a principios de mayo, aunque veremos unas cuantas Betas y Versiones Candidatas antes.
Finalmente, poco se comenta sobre la integración de WordPress MU, tan sólo advierten que los usuarios de WordPress no notarán ninguna diferencia al actualizar a WordPress 3.0, mientras que los de WordPress MU verán que algunas etiquetas tendrán nombres diferentes.
Me alegra que añadan el gestor de menús, aunque me da lástima que eso signifique el final de WP Main Menu, que seguiré actualizando hasta que se libere WordPress 3.0.
This post was published 14 years ago so it may be outdated.
Antes de nada, disculpad que estos últimos días no haya publicado nada, no ha sido por gusto, sino porque he tenido una semanita de lo más completa y me no he tenido tiempo ni para revisar los emails. Afortunadamente ya estoy de vuelta y con tiempo para publicar artículos al ritmo normal (uno al día), aunque primero tendré que ponerme al día.
Pero pasemos ahora a las noveades que he añadido al blog. Tenía en mente actualizar el diseño del blog el fin de semana pasado, pero no he podido acabar de ultimar los cambios hasta hace apenas una hora.
El motivo principal de actualizar el diseño era reducir el ancho de banda que necesita Sumolari.com, ya que este año está superando ligeramente el límite que tengo contratado. Está claro que se puede ampliar dicho límite (previo pago), pero una solución más elegante es reducir el consumo (y por tanto, la factura). Por supuesto, esta reducción no debía acarrear bajo ninguna circunstancia un cambio en la estructura actual del diseño, así que lo he optimizado a través de 3 caminos diferentes:
Reducir el código Javascript necesario y cargarlo desde servidores externos (¿no os recuerda a este artículo?)
Reducir el código del theme y enviarlo comprimido en Gzip
Optimizar las imágenes
Tiempo de carga y tamaño
Entre los tres he conseguido reducir el tamaño de la página a casi una séptima parte de lo que era en principio (de 3.5MB a poco más de 500KB) y el tiempo de carga a la mitad (de 13.7 segundos a 6.6, cargando la página tras haber borrado por completo la caché del navegador).
También he aprovechado para hacer algunos cambios que quería hacer desde hacía tiempo. Para comenzar, el logo cambia al pasar el cursor sobre él, sólo que ahora vuelve a hacerlo con un efecto de aparición / desvanecimiento que tuvo durante una temporada (pero por problemas de Javascript eliminé). Los otros que han vuelto han sido los comentarios anidados, ahora se puede responder a un comentario de forma individual, así que se manejan más cómodamente las conversaciones.
Pero la anidación no es la única novedad de los comentarios, y es que siguiendo la propuesta de JaimePG, he añadido la posibilidad de editar un comentario propio durante la hora siguiente a haber sido publicado, así que cualquiera puede modificar sus comentarios durante ese tiempo y corregir errores o ampliar información. Pasado ese periodo, cualquier modificación tendré que hacerla yo. El formulario para añadir comentarios también ha sido ligeramente modificado, añadiendo un par de iconos en los campos correspondientes al nombre, email y página web, y mostrando las etiquetas XHTML disponibles si has iniciado sesión.
Carrusel
He modificado el carrusel, actualizando WP Carousel a la versión 0.4 (no me había actualizado antes porque tenía que crear un theme para mí y aún no había tenido la ocasión) y he cambiado las imágenes de fondo de los paneles y las flechas por unas ligeramente más oscuras y que al pasar el cursor por encima se iluminan en azul.
Y estas son todas las novedades que hay por ahora, y digo por ahora porque aún tenía más ideas mente, que he dejado para más adelante para poder añadir cuanto antes las que ya estaban acabadas.
Espero que os resulten agradables las novedades :) .
This post was published 14 years ago so it may be outdated.
Vía Genbeta descubro que a partir de la semana que viene, Microsoft publicará una actualización que reemplazará el acceso a Internet Explorer por un acceso a la “Ballot Screen”, una ventana que muestra una lista de alternativas a Internet Explorer, y que permite obtener más información o descargar otros navegadores.
Inicialmente, se implantará en Reino Unido, Bélgica y Francia, y más adelante (en Marzo), en el resto de los paises de la Unión Europea.
¿Y cómo nos afectará esto? Pues la verdad es que no lo tengo demasiado claro.
Los usuarios sin conocimientos sobre navegadores se sorprenderán al ver desaparecer su iconito de “Internet” y que aparezca una lista extraña que no comprenden. Seguramente muchos harán clic en el icono de Google Chrome, porque relacionarán Google con Internet, el resultado sería menos cuota de mercado para IE y más para Chrome, lo cual nos beneficia a los diseñadores, ya que Chrome sigue bastante mejor los estándares que IE (aunque lo cierto es que no es incómodo hacer que un diseño se vea bien en IE, es incómodo hacer que se vea bien en IE6 o anterior).
Los usuarios con algo más de conocimientos seguramente elegirán Internet Explorer, ya que recordarán que el acceso antes tenía ese nombre.
Por último, los usuarios que ya conocían las alternativas a Internet Explorer no notarán ninguna diferencia: si conocían las alternativas y seguían con IE, seguirán con IE y si usaban un navegador diferente, probablemente ni siquiera vean la “Ballot Screen”.
Sobre el resto de navegadores de la lista, tengo la impresión de que no aumentarán mucho su cuota por la “Ballot Screen” (aunque pueden aumentarla por otras cosas). Los 6 primeros navegadores serán los que más aumenten (siendo el primero en ganar, Chrome) y los otros, al estar ocultos al principio (hay que hacer scroll para poder verlos), serán generalmente ignorados.
Aunque, ¿quién sabe? Tal vez me equivoque y el resultado sea muy diferente…
This post was published 14 years ago so it may be outdated.
Anteayer publicaron en SmashingMagazine un recopilatorio de 50 técnicas CSS / JS para mejorar el aspecto de nuestros diseños, que van desde hacer un menú desplegable usando CSS3 hasta crear una réplica de la barra inferior de Facebook, pasando por crear galerías de imágenes al estilo de las de la web de Apple o ajustar el alto de diversas columnas usando jQuery.
Parece que los desarrolladores de WordPress se están tomando muy en serio las aplicaciones para los móviles. Sería interesante ver la cantidad de artículos escritos desde móviles para hacerse una idea de la necesidad de estas aplicaciones, porque, para ser sincero, todo lo que he escrito en Sumolari.com lo he escrito desde un ordenador de sobremesa o portátil (nunca desde un móvil o un iPod).
This post was published 14 years ago so it may be outdated.
WordPress utiliza varios frameworks Javascript para hacer diversos efectos y mejorar a interfaz, además de que algunos themes se aprovechan de esto para añadir mejoras al diseño utilizando funciones que ofrecen estos frameworks. Recurrir a estos métodos ocasiona un aumento del tiempo de carga de la página y del ancho de banda consumido por el servidor al enviar los archivos solicitados al usuario, sin embargo, podemos hacer que WordPress cargue estos archivos desde servidores externos que nos reducen el ancho de banda gastado y que, en algunos casos, son más rápidos que nuestro servidor. Además, usar este método también nos permite cargar automáticamente la versión más actualizada de los diversos frameworks, evitando tener que volver a subir las nuevas versiones a nuestro servidor.
En este artículo me centraré en jQuery, jQuery UI y Prototype, los frameworks que utiliza actualmente Sumolari.com, pero antes de hacer que WordPress cargue los archivos desde servidores externos (usaremos los de Google), veremos primero el método general.
wp_deregister_script, wp_register_script y wp_enqueue_script
WordPress tiene varias funciones para gestionar el código Javascript que se carga en cada página. Esta funciones permiten, a grandes rasgos, añadir un script con un nombre identificatorio (del cual se definen la URL del archivo, las dependencias, la versión o incluso si se puede cargar en el pie de página o no), eliminarlo o cargarlo.
Para el primero de todos los usos, recurriremos a la función wp_register_script. Esta función tiene 5 parámetros: $handle, $src, $deps, $ver e $in_footer.
La primera de todas debe contener el nombre identificatorio del script. Yo recomiendo usar nombres coherentes, así evitamos posibles problemas al usar muchos scripts y no distinguir unos de otros por su nombre.
El segundo parámetro de la función indica la URL del archivo a cargar. Tanto el primer parámetro como éste son obligatorios, los otros tres son opcionales y son, por orden de aparición, la matriz que indica las dependencias (estas dependencias se deben indicar usando el nombre identificatorio del script correspondiente), la versión del archivo a cargar (se utiliza para evitar problemas con la caché y demás, pero en muchos casos basta con dejarlo en blanco) y si el script se puede cargar al final de la página o no.
La función wp_deregister_script es la que elimina un script previamente registrado. Esto nos permitirá eliminar los script registrados por WordPress y añadir los nuestros modificados. El uso sería el siguiente:
[php]wp_deregister_script( $handle );[/php]
La función wp_enqueue_script es la que le indica a WordPress que debe cargar cierto script. Admite los mismos parámetros que wp_register_script, sólo que en la primera, a diferencia de la segunda, el nombre identificatorio le indica a la función qué script debe cargar (ya que esta función no registra ningún script) y sólo usará los demás parámetros en caso de no existir el script solicitado.
Dicho lo cual ya podemos pasar a aplicar lo visto hasta ahora.
Cargando jQuery, jQuery UI y Prototype desde los servidores de Google
Una pequeña aclaración antes de comenzar: podemos cargar cualquier script de WordPress (lista completa) desde cualquier servidor, de hecho veréis como no es nada complicado hacerlo.
Los scripts están alojados en los servidores de Google, que ofrecen una buena velocidad y se actualizan con cada nueva versión. También almacenan versiones antiguas de los frameworks, con lo que podemos optar por cargar una versión actualizada, la última o una más antigua.
El proceso para cargar los scripts es el siguiente:
Registramos de nuevo los tres scripts anteriores, cambiando la URL de los archivos
Cargamos los scripts recién registrados
Esto en código quedaría así:
[php]
// jQuery
wp_deregister_script(‘jquery’); // Des-registramos jQuery
wp_register_script(‘jquery’, ("http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"), false, ”); // Registramos de nuevo jQuery, con la URL de la última versión del framework alojada en el servidor de Google
wp_enqueue_script(‘jquery’); // Cargamos jQuery
// jQuery-UI
wp_deregister_script(‘jquery-ui-core’); // Des-registramos jQuery-UI
wp_register_script(‘jquery-ui-core’, ("http://ajax.googleapis.com/ajax/libs/jqueryui/1/jquery-ui.min.js"), false, ”); // Registramos de nuevo jQuery-UI, con la URL de la última versión del framework alojada en el servidor de Google
wp_enqueue_script(‘jquery-ui-core’); // Cargamos jQuery-UI
// Prototype
wp_deregister_script(‘prototype’); // Des-registramos Prototye
wp_register_script(‘prototype’, ("http://ajax.googleapis.com/ajax/libs/prototype/1/prototype.js"), false, ”); // Registramos de nuevo Prototype, con la URL de la última versión del framework alojada en el servidor de Google
wp_enqueue_script(‘prototype’); // Cargamos Prototype
[/php]
Como veis, no tiene mucho misterio y es muy fácil ampliarlo a otros scripts. Como siempre, cualquier duda o sugerencia la podéis hacer en los comentarios.
Nota: La versión que carga por defecto WordPress de jQuery incluye una llamada a la función jQuery.noConflict, por lo que en el primer script que utilice jQuery deberemos hacer una llamada a esta función para asegurar que todos los scripts funcionen correctamente.
This post was published 14 years ago so it may be outdated.
Ya está disponible WordPress 2.9.2, soluciona un error que permite a los usuarios registrados en el blog ver artículos enviados a la papelera escritos por otros autores. Este es el único error arreglado mencionado en el anuncio oficial de la nueva versión, a la que se puede actualizar descargándola desde WordPress.org o desde el Panel de Administración de nuestros blogs.
This post was published 14 years ago so it may be outdated.
Vía Anieto2k descubro jDigiClock, un plugin para jQuery que te permite añadir un reloj con el aspecto del de un HTC, además de añadir información meteorológica sobre una ciudad a nuestra elección.
This post was published 14 years ago so it may be outdated.
Revisando el código generado por WP Carousel me he dado cuenta de que añadía dos veces el código que iniciaba cada carrusel: una vez junto al propio carrusel y otra vez al final del código HTML generado por WordPress, justo antes del final de la página. La idea era que el carrusel se cargara sólo una vez, y al final de la página, por lo que una de las dos llamadas sobraba.
En esta nueva versión, el único cambio es que el carrusel ya no cargará dos veces el código, tan sólo lo cargará una vez, y al final de la página. La actualización, por tanto, es recomendada, pero opcional, ya que realmente no se arregla ningún fallo que afecte al funcionamiento correcto del carrusel, y la mayoría de los usuarios no van a advertir la diferencia.
