Drupal 6
Durante mucho tiempo estuve usando $(document).ready(); para poner mi js en Drupal, y funcionaba la mar de bien. Esto me permitía ejecutar javascript inmediatamente después que el DOM estuviera cargado evitando así errores de referencias a objetos que todavía no existieran al querer manipularlos.
Ahora bien, hay un problema que vamos a encontrar por medio de un ejemplo simple:
Si tuviéramos un listado de nodos y a ese listado hiciéramos que al pinchar sobre sus enlaces hiciera un alert de su atributo “title” usando jQuery:
jQuery(document).ready(function($) {
$("#listado_de_nodos a").click(function(e) {
alert($(this).attr("title"));
});
});
¿Qué pasa si por medio de AJAX se agregaran nuevos nodos? te lo digo, que no reaccionarían al hacer click sobre ellos, y es por que el método .click() de jQuery se ejecuta una sola vez en busca de elementos que macheen con su criterio y una vez finalizado ya está, no hace mas. Es un comportamiento de lo mas entendible ya que imaginemos que estuviera escaneando constantemente por nuevos elementos ese selector mas los otros 50 que estemos usando para hacer mas cosas…. Google Chrome lo soportaría sin apenas darle carga al procesador y RAM, pero piensen en la basura de IE…..
Perdonen que me vaya por las ramas, como les decía, dado el problema que se planteo para el listado de nodos que di como ejemplo, se implemento una solucion (bueno cubre mas problemas pero este es de los mas comunes) la solución fue usar al objeto Drupal.behaviors a modo de controlador. Drupal.behaviors relanza todas las funciones que almacena por cada vez que se lance una petición AJAX, dándonos la oportunidad de re procesar cosas. Así pues en el ejemplo anterior lo podemos poner dentro de un behavior para poder aplicar nuestra funcionalidad incluso a los nuevos elementos provenientes de la petición:
Drupal.behaviors.alertarEnlaces = function(context) {
$("#listado_de_nodos a").click(function(e) {
alert($(this).attr("title"));
});
}
Como ven lo único que hay que reemplazar en nuestros actuales ficheros de javascript es jQuery(document).ready(function($) {}) por Drupal.behaviors.alertarEnlaces = function(context) {} y no se preocupen por el hecho de que su código este ahora asignado dentro de una función(“Drupal.behaviors.alertarEnlace() ”), porque esta se ejecuta solita, y veanlo incluso como una ventaja, pueden invocarla ustedes mismos cuando quieran ademas.
Si instalaste un Apache Solr y lo estas usando por medio de Drupal 6, otro CMS o una propia implementación, seguramente no te interese que dicho servicio se pueda acceder por medio del puerto 8080 (o el puerto asignado en tu servidor para Tomcat).
Bueno, un ejemplo es mucho mas claro que casos hipotéticos, así que les planteo mi necesidad:
Tengo un Ubuntu con un Drupal configurado con el modulo “apachesolr” que se conecta a localhost en el puerto 8080. Hasta ahí todo normal, el problema es que si a alguien se le ocurre tipear la URL de mi pagina montada en Drupal pero por el puerto 8080… va a poder ver Tomcat, y lo que es mas peligroso, Apache Solr y su administrador (Solr carece de mecanismos de seguridad porque los delega a Tomcat).
Bueno en el ejemplo que comente antes tenemos una solución ideal: Capar el puerto 8080 para que solo se pueda acceder por “localhost”.
Para lograr nuestro cometido solamente tenemos que editar un XML: “server.xml“:
sudo gedit /etc/tomcat6/server.xml
Busca la linea:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Comentarla:
<!--
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
Y poner por dejado de la linea anterior lo siguiente:
<Connector port="8080" address="127.0.0.1" maxHttpHeaderSize="8192" maxThreads="15" minSpareThreads="2" maxSpareThreads="7" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" compression="on" compressionMinSize="0" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml" />
Guarda los cambios y reinicia Tomcat:
sudo service tomcat6 restart
Gualá. Comprobemos que haya funcionado:
Primero mira cual es la ip que tiene tu servidor haciéndole ping:
Usa “ifconfig” para ver la ip, que seguramente tenga la pinta “192.168.1.xxx” o “10.0.2.xx”
bien, ahora suponiendo que seguis en Ubuntu (es mi ejemplo y uso Ubuntu
) abri un navegador y proba a acceder a:
http://localhost:8080
y a:
http://192.168.1.xxx:8080 (las xxx reemplazalas por el resto de tu IP).
Como pudiste ver, podes acceder a localhost pero no por medio de la IP, incluso si probas a acceder a esa IP desde otra maquina/ordenador/PC/ipad/ipod/android/o-lo-que-sea XD
Hemos acabado.
NOTA: esta solución es útil para cualquier sistema que almacene las claves de usuarios en MYSQL por medio de MD5 o SHA1.
Hecha la aclaración, comento el caso concreto de Drupal que nos va a servir de idea para el resto:
Si no te acordás la clave de “admin” en Drupal y tenes acceso a phpMyAdmin, lo único que tenes que hacer es abrir la base de datos, localizar al usuario “admin” dentro de la tabla “users” y editarlo. Una vez que lo tengas abierto tenes que poner la clave nueva en el campo “pass”. Por ultimo solo queda decirle a phpMyAdmin que esa clave la guarde en MD5 (ver imagen).
Listo. Guarda los cambios y accede a tu usuario “admin” como de costumbre.
Un curioso bug en Drupal y de facil solucion. Solamente tenes que poner el siguiente snippet en el template.php de tu theme o bien en algún modulo de tu propia factoría
function TU_THEME_preprocess_page(&$vars) {
$matches = array();
preg_match_all('/(]*>)/', $vars['head'], $matches);
if (count($matches) >= 2) {
$vars['head'] = preg_replace('/]*>/', '', $vars['head'], 1); // strip 1 only
}
}






