Esta mañana deseé instalar un par de paquetes de PECL y PEAR desde los repositorios de PHP (en mi laptop recién instalado con ArchLinux+XFCE), pero vaya sorpresa que me llevé cuando al ejecutar:

sudo pear upgrade

y

sudo pecl upgrade

Y aunque subí el valor de memory_limit a 4092M no tuve suerte, pues siempre obtuve el mismo mensaje.
Después de “googlear” un poco y probar múltiples opciones decidí lanzarme a la aventura y con base de diferentes comentarios de múltiples foros encontré la solución, bastante sencilla, por cierto; actualizando el propio PEAR:

sudo pear upgrade PEAR

Problema resuelto. Espero que no sólo a mí me resuelva el problema sino a muchos de ustedes también.

Hace algún tiempo trabajando para alguna empresa, necesité instalar la extensión php_solr en mi laptop con Chakra (basado en ArchLinux) y luego de investigar un poco acá está el método que utilicé.

Instalamos los paquetes autoconf y php-pear (si ya están instalados se ignoran)

sudo pacman -S autoconf php-pear

Luego bajamos el archivo de la extensión desde http://pecl.php.net/package/solr y lo descomprimimos:

tar -zxvf solr.1.0.1.tgz

Entramos al directorio y ejecutamos “phpize” en el directorio:

cd solr.1.0.1
phpize

Configuramos el paquete antes de instalarlo:

./configure

Lo instalamos:

make && make install

Activamos la extensión en el archivo php.ini o /etc/php/conf.d/solr.ini

extension=solr.so

Y reiniciamos el servidor (normalmente Apache, en mi caso es nginx).

Espero que haya sido útil.

Actualización:

Desde que solr dejó de ser beta, ahora es posible instalar la extensión usando el comando:

sudo pecl install -f solr

He encontrado un post bastante interesante acerca de la distancia de Levenshtein que aplicado a la programación web, sirve para cuando nos hacen un vínculo a nuestro sitio web y la dirección contiene “typos” o errores de digitación y el servidor reinterpreta y corrige la dirección evitando así un error 404. ¿Interesante verdad?

Wikipedia nos dice lo siguiente:

En Teoría de la información y Ciencias de la Computación se llama Distancia de Levenshtein, distancia de edición, o distancia entre palabras, al número mínimo de operaciones requeridas para transformar una cadena de caracteres en otra. Se entiende por operación, bien una inserción, eliminación o la sustitución de un carácter. Esta distancia recibe ese nombre en honor al científico ruso Vladimir Levenshtein, quien se ocupara de esta distancia en 1965. Es útil en programas que determinan cuán similares son dos cadenas de caracteres, como es el caso de los correctores de ortografía.
Por ejemplo, la distancia de Levenshtein entre “casa” y “calle” es de 3 porque se necesitan al menos tres ediciones elementales para cambiar uno en el otro.
casa → cala (sustitución de ‘s’ por ‘l’)
cala → calla (inserción de ‘l’ entre ‘l’ y ‘a’)
calla → calle (sustitución de ‘a’ por ‘e’)

Podríamos decir entonces que si tuviésemos una URL que fuese: http://miservidor.com/mipaigna se podría reescribir a http://miservidor.com/mipagina evitando así el error 404.

He aquí algunos vínculos con el código fuente para WordPress, Drupal y el código genérico.

WordPress Plugin: http://pro.virante.com/404/predictive404.txt
Drupal Module: http://www.socialseo.com/
Generic PHP Code : http://pastebin.com/P35zHGDW

Creo que próximamente estaré desarrollando una extensión para mi framework

Quienes me hayan seguido o me conozcan habrán notado mi preferencia hacia Yii como framework de desarrollo, pues bien, un buen colega mío y desarrollador del framework,llamado Alexander Makarov  ha redactado este espectacular libro “Yii 1.1 Application Development Cookbook” o en español (o castellano como más gusten) se llamaría algo como: Libro de Cocina del Desarrollo de Aplicaciones en Yii 1.1.

El libro puede ser adquirido a través del sitio de Packt Publishing desde donde podremos adquirir el libro (con interesantes descuentos sea dicho de paso) que también puede ser adquirido en versión PDF.

Próximamente estaremos haciendo una evaluación del libro, pero para quienes deseen darle un vistazo a uno de los capítulos, acá está el capítulo 8.

Espero sus comentarios del libro y del framework.

En múltiples ocasiones había tenido la oportunidad de implementar sitios web con formularios de contacto en GoDaddy sin inconvenientes, pero en uno de los últimos sitios que he desarrollado se presentó un problema que me iba dando bastante trabajo para averiguar el porqué no enviaba un email desde el formulario de contacto, algo que en condiciones normales haría.

Todo empezó, como comento arriba, con un formulario de contacto que no enviaba los respectivos mensajes y con el sistema gestor de contenidos Joomla (bastante conocido por todos); cabe aclarar que no acostumbro usar el sistema de formularios de contacto que Joomla trae por defecto, pero nunca había tenido problemas con él, así que ahí empezó la odisea.

Al principio, pensé que el servicio de email de GoDaddy estaba caído o algo así, así que esperé un poco y nada sucedió, por lo tanto, decidí escribir al servicio de soporte de GoDaddy y la respuesta que dieron fue algo plana y sin mayor explicación: todo está funcionando bien. Así que pensé que tal vez había tenido errores a la hora de subir el gestor de contenidos (porque como indiqué, nunca había tenido problemas con los formularios en GoDaddy). Y volví a hacer las pruebas y: Nada. Revisé la información de la función phpinfo() de PHP y vi que todo estaba bien excepto por una cosa: Se me había pasado por alto ver el sistema operativo del plan que mi cliente había adquirido: Microsoft Windows Server.

No es que considere a Windows un mal sistema operativo, sino que es bastante problemático a la hora de hacer las veces de servidor (y creo que en el escritorio pasa algo parecido), así que asumí que la función mail de PHP no estaba habilitada en el paquete, así que decidí probar con otra opción: Sendmail, y para ello para de una vez por todas terminar con el problema escribí a GoDaddy para que me indicaran la ruta de Sendmail para ejecutarlo desde el script y poder enviar los correos (la ruta por defecto en Linux es /usr/sbin/sendmail y por obvias razones esa ruta no funciona en Windows); la respuesta por parte del servicio al cliente fue bastante odiosa: Utilice los formularios prediseñados de GoDaddy!!! Cómo? cómo es posible que un proveedor como GoDaddy esté dando respuestas de ese estilo? en fin, respiré profundo y ponerme manos a la obra, ya que nunca un formlario de contacto me había tomado tanto tiempo.

Seguí investigando, y encontré en la configuración de phpinfo que GoDaddy usaba en Windows el sistema SMTP con una URL bastante particular y decidí probar suerte con la configuración por SMTP:

Mailer: SMTP Server
Mail from: miemail@miservidor.com (Acá va un email DEBE existir en GoDaddy)
From Name: VCS (Nombre de la compañía, a decir verdad, cualquier cosa está bien)
Sendmail Path: /usr/sbin/sendmail (Este dato es totalmente irrelevante)
SMTP Authentication: No
SMTP Security: None
SMTP Port: 25
SMTP Username: email@miservidor.com (lo mismo que arriba)
SMTP Password: (Vacío, no se debe escribir nada)
SMTP Host: relay-hosting.secureserver.net

Y voilà, ha funcionado. No es por nada pero definitivamente esta odisea hubiese sido evitable si el equipo de GoDaddy me hubiese indicado desde un principio que en los planes con Windows solo funciona SMTP y me hubieran dado la URL (que por cierto, tuve que averiguarla manualmente).

En conclusión, GoDaddy puede ser un proveedor de hosting muy popular pero tiene múltiples restricciones de un tipo u otro que sea por seguridad o sea por negligencia hacen difícil la labor de desarrollo web. Por ahora he recomendado a mis cliente un servicio que he probado y ha sido excelente, y que he direccionado a: http://virtual-consulting.duoservers.com/ pruébenlo y me cuentan.

Espero haberles ahorrado trabajo, y por último agrego que lo anterior también aplica para las implementaciones en el lenguaje ASP y ASP.Net.