:Xtandard

Dos de los sitios que hacen e-commerce -de la empresa en la que trabajo- han estado (desde que surgieron) como un subdominio del dominio principal; sin embargo, a partir de este mes es necesario migrarlos a su propio dominio. Por suerte, lo preví y la base de datos está alojada en cada dominio, sería cuestión de mover los archivos nada más.

Un asunto que no sabía como conseguir apropiadamente, es la redireccion exacta de cada URL indexada en los buscadores (cosa que es primordial sobre todo para sitios haciendo comercio); lo que pensaba era hacer una redirección del subdominio hacia el dominio principal del sitio en su nuevo servidor.

Al ser un sitio que sirve a partir de operaciones con tarjetas de crédito e información de los clientes, necesita pasar por un certificado de seguridad (lo que conocemos por conexión segura https) y el manejo desde un subdominio se me hacía más fácil haciendo redirecciones a partir de un .php; pero, haciéndolo desde la raíz del sitio, núnca lo había hecho.

Para mi fortuna, le comenté a un amigo lo que estaba haciendo -a través del Talk (IM) de Google- y me sugirió resolver el asunto con expresiones regulares desde un .htaccess.

Primero convertir cualquier dirección http a https:
RewriteEngine On
RewriteCond %{HTTPS} !=on
#RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R]
RewriteRule ^(.*) https://nuevo-dominio.com/$1 [R]* Este código va en la raíz del nuevo dominio.

Lo que se entiende a simple vista es que para una condición en la que estamos en una dirección http (sin conexión segura), reescribimos (redirigimos) la url hacia una con conexión segura (https).

Si te fijaste, hay una línea con el símbolo de numero (#) (eso significa que la estamos comentando, no será interpretada) que indica que %{SERVER_NAME} escribirá SIEMPRE la dirección incluyendo “www“. Sin embargo, debido a que el SSL del sitio en cuestión está gestionado para una dirección sin “www“, pues lo escribí a mano: https://nuevo-dominio.com.

Apoyado en la información que me dió mi amigo y datos que encontré en sitios visitados desde Google, solucioné el asunto con un par de líneas dentro del .htaccess para que las URL guardadas en caché o tomadas desde un buscador me llevaran al punto exacto, pero en el nuevo dominio.
RewriteEngine on
RewriteCond %{http_host} ^dominio-indexado\.com [nc]
RewriteRule ^subdominio/(.*)$ https://nuevo-dominio.com/$1 [r=301,nc]
RewriteCond %{http_host} ^www\.dominio-indexado\.com [nc]
RewriteRule ^subdominio/(.*)$ https://nuevo-dominio.com/$1 [r=301,nc]* Este código va en el dominio anterior (en la raíz).

En menos de media hora tenía resuelto mi problema.

Para casos en los que se pasen variables por URL, se puede hacer también, sólo que es preciso utilizar la misma estructura.

Espero que esta información te sirva

Compártelo

4 Comentarios

Hemos tenido que imprimir nuevas facturas en la oficina (aprovechamos para hacer un nuevo diseño) y en la imprenta han pedido el PANTONE de nuestros colores… así que emprendí la búsqueda. Como es obvio, ese dato… no lo tenemos.

De plano, el primer lugar que ausculté fue Google… así que me encontré un par de sitios interesantes, entre ellos uno donde se nos cuenta que los propietarios de la marca PANTONE “solicitaron” dejar de usar y publicar su material (era un buscador de pantone).

Le pregunté a un par de amigos por el GTalk y ambos me dijeron que no conocían una forma directa de saber un PANTONE partiendo de un HEX (colores que usamos en CSS para darle vida a la Web); por tal razón seguí investigando hasta encontrar un método que al menos me resolvió relativamente el problema con aproximados.

Primero convertí los HEX a RGB (esto lo puedes hacer con cualquier programa de manejo de imagenes) desde un sitio que utiliza javascript para generar los valores.

Luego, teniendo los RGB, utilicé una herramienta Web que me deja saber los PANTONE aproximados partiendo de los RGB.

Ya con esto pude obtener varias opciones y tomar la que me parecía mejor o más cercana a la deseada; sin embargo, terminé yendo donde un conocido que aún usa Corel Draw y le pedí verificar en su software y me dió los que utilizará la imprenta:
Rojo: 492C
Negro: 439C
Ambos de la paleta solid coated.

Compártelo

1 Comentario

Pues -hasta donde he visto- Televisa se asegura que cada cosa que hace lleve la clara leyenda de derechos reservados y de derechos de autor; sin embargo a la hora de conceder los créditos al autor de otras obras parece que no responde igual.

Leyendo mis feeds, me di cuenta -en el blog de Aoyama- que el blog de EsMas[punto]com usa WordPress como manejador de contenido; sin embargo, ni siquiera como cortesía (aunque según la licencia con la que se concede WordPress y la mayoría de plantillas o themes, es obligatorio publicar los créditos) dejan el enlace al sitio de Wordpress ni al del autor de su plantilla o theme.

En esta imagen, puedes ver el pie del blog:

Como ves, no están los créditos que todos los que usamos WordPress dejamos (o al menos debemos dejar) por compromiso para que crezca el CMS y por simple ética… ¿cómo me voy a adjudicar algo que yo no escribí o creeé?, NO es ético ni legal.

La segunda imagen, muestra el código en el que claramente el maquetador del sitio comenta las líneas en las que debería estar público el crédito a Wordpress y al autor del theme o pantilla.

Dano, Aoyama, La100rra y demás, han dicho que no vale el dinero que no percibe Wordpress; cierto, no obstante yo quiero pedir que EsMas[punto]com publique unas disculpas a la comunidad opensource y despida a ese fulano que cometió la falta. Repito, pido que cesen de sus funcionen a ese tipo sin ética y escrúpulos. Si es capaz de robar en cosas tan sencillas, será también capaz de robarle a Televisa, que -quisiera creer- no se da cuenta de esas cosas tan simples y básicas del negocio.

No podía quedarme callado ante semejante atropello. No se tú, pero yo creo que necesitan disculparse.

Compártelo

8 Comentarios