Estas en: Home > plugin

Entradas etiquetadas con plugin

Cron Job WordPress

Versión 0.5 del plugin para WordPress Collapsing Category List

0

En esta nueva versión del plugin se ha añadido una nueva página de administración para el plugin, que podéis encontrar en el menú Settings (Ajustes)/Collapsing category list.

Desde ella podréis activar una nueva funcionalidad para poder limitar el número de categorías y subcategorías que se pueden seleccionar en el listado de categorías al crear o modificar un post. Se puede indicar más de un nivel de subcategorías y el número de categorías máxima que se pueden seleccionar. Si lo dejáis a cero no habrá límite; si indicáis una sola categoría o subcategoría el checkbox se convertirá en un radio button para cada categoría de ese nivel. Si se supera el número de categorías que se pueden seleccionar, el usuario verá un mensaje indicando que este límite sea superado, impidiéndole que pueda seleccionar más categorías.

Hasta la próxima versión.

 

Cron Job WordPress

Versión 0.4 del plugin para WordPress Collapsing Category List

0

Poquito a poco se va aumentando el número de características y utilidades que el plugin ofrece. En esta ocasión se ha añadido la posibilidad de mantener colapsadas las categorías cuando se muestra la página de un post al usuario. Además se han corregido varios bugs.

Como novedad para los desarrolladores de WordPress que usen el plugin, se han añadido los archivos de traducción para español e inglés (que ya era hora), y la compatibilidad para poder traducir el plugin a cualquier otro idioma.

Cron Job WordPress

Versión 0.3 del plugin para WordPress Collapsing Category List

4

En esta nueva versión se ha actualizado el plugin para adaptarlo a WordPress 4.4, añadiéndole compatibilidad con versiones anteriores.

Se han sustituido las imágenes que hacían de iconos para expandir y colapsar las categorías por caracteres de texto, que permitirán aumentar su tamaño por css, de tal forma que puedan visualizarse correctamente en dispositivos móviles y responsive web. Por retrocompatibilidad se ha añadido un checkbox que permite cambiar entre las imágenes antiguas y los estilos css que mostrarán los nuevos iconos.

Se ha añadido la opción de ocultar los iconos de expandir y colapsar las categorías para poder mejorar la visualización y usabilidad en los dispositivos móviles.

Cron Job WordPress

Versión 0.2.1 del plugin para WordPress Collapsing Category List

0

Pues sí, este pequeño plugin propio sigue creciendo. Como no suelo publicar post relativos a las actualizaciones de los plugins que he creado (mal por mi parte) os explicaré qué es, para qué sirve y los cambios que se han realizado hasta la fecha.

Collapsing Category List es un plugin para WordPress que, a través de un filtro, modifica el widget de categorías de WordPress para que las subcategorías colapsen y no se muestren directamente. Además de otras características mejoradas.

Subcategoría colapsada

Subcategoría colapsada

Subcategoría expandida

Subcategoría expandida

 

Las mejoras de las que dispone el plugin son las siguientes:

 

  • Colapsar y expandir el listado de subcategorías.
  • Posibilidad de ordenar las categorías por nombre o slug.
  • Posibilidad de ocultar categorías.
  • Posibilidad de eliminar el enlace de todas las categorías.
  • Posibilidad de eliminar el enlace de una o varias categorías.
  • Posibilidad de cambiar las imágenes que indican la acción de colapsar o expandir un listado de subcategorías. Por defecto aparecen los símbolos más (+) y menos (-).

Cualquier sugerencia o idea para mejorar el plugin es bienvenida.

Página de descarga: https://wordpress.org/plugins/collapsing-category-list/

Cron Job WordPress

Collapsing category list: Oculta y despliega las subcategorías de WordPress

1

Durante un tiempo estuve buscando un plugin para ocultar y desplegar las categorías con subcategorías en WordPress, por desgracia los plugins que probé o no funcionaban o estaban abandonados o solo funcionaban para unos themes concretos. Así que me decidí a crear el mío: Collapsing category list, es un pequeño plugin, en realidad un filtro para las categorías por defecto de WordPress que permite colapsar y desplegar las categorías con subcategorías

Categoría colapsada

Categoría colapsada

 

Categoría desplegada

Categoría desplegada

 

Si deseas descargarlo puedes acceder por esta URL: http://wordpress.org/extend/plugins/collapsing-category-list/

Cron Job WordPress

WordPress 3.x para desarrolladores: Plugins, conceptos básicos

0

Un plugin WordPress es un programa, o un conjunto de una o más funciones, escritas en el lenguaje de scripting PHP, que añade un conjunto específico de características o servicios para el weblog WordPress, los cuales pueden ser integrados sin problemas con el weblog usando puntos de acceso y métodos proporcionados por la API.

 

Nombres, archivos y ubicaciones

La primera tarea a la hora de crear un plugin de WordPress es pensar en qué va a hacer el plugin, y crear un (ojalá único) nombre para él. Compruebe en Plugin y en otros repositorios referidos en el enlace, que el nombre no exista ya; se puede hacer, también, una búsqueda en Google. Muchos desarrolladores eligen nombres que describen, de alguna manera, lo que hace el plugin; por ejemplo, un plugin que haga algo relacionado con el tiempo, podría llevar la palabra “tiempo” en su nombre. El nombre puede tener varias palabras.

 

El siguiente paso es crear un archivo PHP con un nombre, derivado del nombre que usted ha elegido para el plugin. Por ejemplo, si su plugin se llamará “funcionalidad maravillosa”, usted podría nombrar al archivo PHP funcimara.php. De nuevo, intente elegir un nombre único. La gente que utilice su plugin, lo pondrá en el directorio de WordPress, en su instalación wp-content/plugins/, de forma que no puede haber dos plugin distintos con el mismo nombre de archivo PHP.

Otra opción es separar el plugin en varios archivos. Su plugin WordPress debe tener al menos un archivo PHP; además puede contener archivos JavaScript, archivos CSS, archivos de imagen, archivos de localización, etc. Si hay varios archivos, elija un nombre único para una carpeta de archivos y para el archivo PHP principal, tales como funcimara y funcimara.php en este ejemplo, coloque todos los archivos del plugin en la carpeta y diga a los usuarios que copien toda la carpeta en wp-content/plugins/.

En el resto de este artículo, nos referiremos al archivo PHP principal como “el archivo PHP del Plugin”, ya esté en wp-content/plugins/ o en un subdirectorio.

 

Información Estándar del Plugin

Las primeras líneas del archivo PHP principal del plugin deben contener la cabecera estándar de información del plugin. Esta cabecera permite a WordPress reconocer que el plugin existe, y ponerlo en la pantalla de gestión para que pueda ser activado, cargado y ejecutar sus funciones. Sin esta cabecera, su plugin no podrá ser activado ni funcionar. Este es el formato de la cabecera:

<?php
/*
Plugin Name: Nombre del plugin
Plugin URI: http://URI_De_La_Página_Que_Describe_el_Plugin_y_Actualizaciones
Description: Una breve descripción del plugin.
Version: El número de versión del plugin e.j.: 1.0
Author: Nombre del autor del plugin
Author URI: http://URI_del_Autor_del_Plugin
License: Un nombre de licencia "pegadizo" e.j. GPL2
*/
?>

El mínimo de información que WordPress necesita para reconocer su plugin es el nombre del mismo. El resto de la información (si está presente) se utilizará para crear la tabla de plugin en la pantalla de gestión de plugins. El orden de las líneas no es importante.

La línea de licencia debería ser un identificador común, corto, para señalar bajo que licencia se distribuye el código y está destinado a ser una forma sencilla de ser explícito acerca de la licencia del mismo.

 

Sugerencias sobre Desarrollo de Plugin

Esta última sección contiene sugerencias aleatorias sobre el desarrollo de plugin.

  • El código de un plugin WordPress debería seguir los Estándar de WordPress Coding. Por favor, también considere los estándarDocumentación en Línea.
  • Todas las funciones en su plugin necesitan tener nombres únicos que sean diferentes de los de funciones del núcleo de WordPress, otros plugins y plantillas. Por esta razón, es una buena idea utilizar un prefijo de nombre de función en todos sus plugins. Otra posibilidad es definir sus funciones de plufin dentro de una clase (que, a su vez, necesita tener un nombre único).
  • No utilice el prefijo de bases de datos (normalmente “wp_”)de WordPress directamente en sus plugins. Asegúrese de que utiliza la variable $wpdb->prefijo en su lugar.
  • Leer la base de datos es barato, pero escribir es caro. Las bases de datos son excepcionalmente buenas recuperando datos y ofreciéndosela a usted y estas operaciones son (normalmente) veloces como el rayo. El hacer cambios en la base de datos, es un proceso más complejo, y más caro desde el punto de vista computacional. Como resultado, intente minimizar la cantidad deescritura que usted hace en la base de datos. Deje todo preparado en su código primero, de forma que usted hace las operaciones de escritura estrictamente necesarias.
  • SELECT solo lo que se necesita. A pesar de que las bases de dato recuperan información realmente rápido, usted debería intentar de reducir la carga sobre la base de datos, seleccionando solo la información sobre la que quiere trabajar. Si usted necesita únicamente contar el número de líneas de una tabla no haga SELECT * FROM, porque se cargarán todos los datos de cada registro, desaprovechando memoria. Así mismo, si solo necesita el post_id y el post_author en el plugin, simplemente SELECTesos campos específicos, para minimizar la carga de la base de datos. Recuerde: cientos de procesos diferentes pueden estar consultando la base de datos al mismo tiempo. La base de datos y el servidor tienen recursos limitados para atender dichos procesos. Aprender como minimizar el impacto de sus plugins en la base de datos asegurará que el suyo no sea el señalado como culpable de abuso de recursos.
  • Elimine errores de PHP en sus plugin. Añada define('WP_DEBUG', true); a su archivo wp-config.php, compruebe toda la funcionabilidad del plugin, y chequee si hay errores y/o avisos. Arregle cualquier incidencia y continue en modo debug hasta que se hayan eliminado todos los errores.
  • Intente no utilizar directamente las etiquetas <script> y <style> – en su lugar utilice las funciones recomendadaswp_enqueue_style() y wp_enqueue_script(). Estas ayudan a eliminar scripts y estilos duplicados y, además, introducen soporte de dependencias. Consulte post de las siguientes personas para más información: Ozh RichardsonArtem Russakovskii, yVladimir Prelovac.
Cron Job WordPress

WordPress 3.x para desarrolladores: Introducción

0

Después de varias semanas buscando información sobre WordPress para un proyecto que tenía pendiente (ya acabado), he observado que hay cierta escasez de información sobre el desarrollo de WordPress, ya que la mayoría de tutoriales o manuales que rondan por internet están limitados a la creación básica de plugins o a lo más básico de la creación de plantillas.

Por ello voy a realizar un tutorial que, basandome en el tema Twenty Eleven de WordPress permita conocer el funcionamiento de los temas y las plantillas. Para desarrollar la parte de los plugins se creará uno de ejemplo.

Muchos ejemplos de código serán de la documentación principal de WordPress y es la que deberías consultar más habitualmente si vas a desarrollar para WordPresshttp://codex.wordpress.org/Main_Page

Durante las próximas semanas publicaré un tema por semana hasta que se complete el tutorial.

Optimización de WordPress

WP-SynHighlight, plugin para insertar código en tus post

4

Llevaba unos días buscando un plugin que me permitiese añadir trozos de código fuente en los post sobre programación, ya que el que tenía debía trabajar en la vista HTML y, la verdad, es un engorro. Así que buscando y buscando encontré este plugin que permite escribir código fuente en el editor visual.

Este plugin, al igual que la mayoría que permiten añadir código fuente a los post, está basado en Geshi, que es el responsable de procesar el código y darle el formato deseado.

Su instalación es igual que la de cualquier otro plugin de WordPress, pero lo interesante de este plugin es que dispone de un editor visual para añadir el código fuente, donde podrás cambiar muchos aspectos de como se visualizará el código.

Además permite añadir código fuente en los comentarios utilizando para ello los QuickTags de la siguiente manera:

Si quisiéramos añadir código PHP a un comentario escribiríamos lo siguiente:

[*codesyntax lang=”php”]

<?php echo “Hello World!”; ?>

[*/codesyntax]

Eso sí, sin los asteriscos. Así quedaría el fragmento de código:

  1. <?php echo "Hello World!"; ?>

 

Geshi permite añadir código de una gran cantidad de lenguajes. Podeis ver un listado en su página principal: http://qbnz.com/highlighter/index.php

Optimización de WordPress

Mi última pesadilla: Optimizar el VPS para WordPress

16

Pesadilla… de tres semanas y pico. Anoche soñé con la lista de procesos del comando top de Linux. Apache consumía cada vez más y más memoría. Por consumir, consumió el Kernel de Linux y se transformó en el Kernel de Windows. Y no se porqué antes de despertarme entre sudores fríos apareció Bill Gates descojonandose a moco tendido. Dios, ¡Qué imagen!, no se me quita de la cabeza.

Durante este tiempo me he didicado a “intentar” optimizar tanto el VPS como WordPress para reducir el consumo de memoría. Aunque he hecho algunas mejoras (pocas por desgracia) sigue cayendose Apache; pero comenzaré por el prinicpio:

¿Porqué un VPS?

  1. Por el precio: Ví un VPS más o menos al mismo precio que un hosting y apliqué el dicho “burro grande ande o no ande”.
  2. Por aprendizaje: Nunca había probado un VPS y quería saber como poder administrarlo, que se puede hacer con él. No jodes tantas cosas como con un dedicado y hasta cierto punto tienes menos responsabilidad y es mucho más barato. Y es el paso lógico antes de administrar un dedicado, en el que ahí estas solo completamente.
  3. Por unificar mis proyectos web: Dispongo de cinco dominios. Para cada uno tengo planes para crear una web con ellos,o en algunos casos ya está creada y online, en otro, estoy esperando a ver que pasa con el VPS y otros solo estan proyectados. Disponer de todas las webs en un solo servidor, ya que no tienen muchas visitas, es muy pero que muy cómodo, además de económico.
  4. Por ahorar costes: Cinco dominios, cinco hostings. Aunque los hay muy baratos (desde un euro) siempre te limitan alguna cosa y no me convencian.
  5. Por libertad: La posibilidad de hacer y deshacer a mi antojo, en definitiva, de tener el control de la máquina (virtual) es una gozada.

Características del VPS

  • Memoría RAM: 256 MB
  • Espacio en disco: 5 GB
  • Transferencia mensual: 150 GB
  • Sistema operativo: CentOS 5
  • Panel de control: Plesk
  • Y obviamente el resto de características habituales: Perl, PHP, MySQL, etc, etc, etc.

El principio

Cuando contraté este VPS, era un puto ignorante, así de claro, desconocía muchas cosas sobre la administración de servidores, su optimización, y sobre todo, las características que había que observar detenidamente antes de contratar nada (en VPS. En hosting, tengo bastante idea). Menos mal que era el más barato xD.

Desde el tercer o cuarto día comenzó a fallar Apache. Los datos que obtenía tanto de Plesk como de Virtuozzo me indicaban que la memoría se saturaba y paraba los servicios. Claro, como un ignorante creé un ticket al proovedor. La respuesta fué rápida (y ahora la más lógica), “actualice su VPS a uno superior”. No comprendía como me podían decir eso. ¡Que sólo es un blog! ¡Que el día que llega a 100 visitas monto la fiesta padre! !Coño, que no es Digg, ni el Mundo! ¿Cómo podía ser que con solo al acceder a la página principal de la administración (el escritorio de WordPress), Apache ya se viniese abajo? ¿Cómo era posible?.

Sólo había una idea en mi cabeza: “Estos del hosting quieren sacarme más pasta” (Viendolo ahora, en cierto sentido, tenía razón). Pero esa idea no soluciona el problema, aunque mi cabezonería la convirtió en  mantra y como con levantar Apache o reiniciar el contenedor volvía todo a funcionar, se quedo así durante meses.

Primeros intentos

No soy una persona que se rinda fácilmente. Yo siempre digo que en informática no hay nada imposible, sino poco presupuesto. Así que comencé a informarme sobre VPS, WordPress, Apache, etc. De esto puede dar fe mi navegador (uso Opera) que ahora mismo tengo abiertas unas 50 pestañas.

Lo primero fue buscar una forma para averiguar cuánta memoría consumía WordPress. Encontré el siguiente código:

$memoria_usada = round(memory_get_usage(1) / 1024,1);
echo ‘Memoria usada: ‘ . round(memory_get_usage() / 1024,1) . ‘ KB de ‘ . $memoria_usada . ‘ KB’;

Este código indica la memoría que había antes de ejcutar el script (que se guarda en la variable $memoria_usada y se pone al inicio del archivo) y la memoría consumida después de ejecutar el script (que se pone al final). Los datos en local que saqué fueron los siguientes:

9 plugins: Memoria usada: 27462 KB de 67.1 KB
Sin plugins: Memoria usada: 20468.8 KB de 67.2 KB
Actualizando el theme: Memoria usada: 21049.1 KB de 67.1 KB (Utilizando el theme que tengo en el blog actualmente, sustituyendo al theme por defecto)

Siento no tener los datos del VPS, pero no varían mucho. Ahora mismo consume 29,5 MB con ocho plugins activos (no son los mismos plugins han variado desde entonces) más el theme.

Las pruebas las realicé con WordPress 3.0.1 con la base de datos tal cual se instala, bajo Windows con la suit de AppServ sin modificaciones.

Yo, cuando ví las cifras, me quedé alucinado: ¡Wordpress consume casi 20,5 MB!. Realicé pruebas con otras versiones de WordPress para verificar que esto era así, es decir, comprobar que con el paso de las versiones el consumo de memoria había aumentado. Que no era cosa mía, sino que es así de chupón. Aunque aquí puede variar el consumo de memoría dependiendo de las reglas de mod_rewrite de Apache, de como esté optimizado PHP y MySQL, etc. El único culpable no es WordPress, pero acojona.

Viendo lo visto, era hora de actuar.

WordPress a dieta

Sabía que existian varios plugins que permitian cachear las páginas del blog y reducir el consumo de memoria y procesador, pero simpre lo había visto en blogs con miles de visitas, no en uno cutre con theme gratuito que no llega a las cien visitas diarias (triste pero cierto).

El primero en activar en el blog, wp-cache, me costó un poco instalarlo, más por mi inexperiencia con cachés que otra cosa (mira que es sencillito el plugin). Al final no se lo que me paso, no lo recuerdo, que lo desactivé. Busqué otro.

WP Super Cache, no mienten los que hablan bien de él, funciona estupendamente, es un poco más complicado de configurar que wp-cache pero el resultado es magnífico. Pero el blog seguía consumiendo casi 30 MB de memoría y Apache se caía. Mejoró la estabilidad del blog un poco, al menos de cara al visitante sí. Pero seguía con el mismo problema: en cuanto entraba en el Escritorio Apache se escoñaba.

Antes de esto probé cada uno de los plugins para ver cual era el que hacía que Apache se cayera nada más entrar en las administración del blog. WordPress.com Stats era el culpable, la establidiad mejoró sustancialmente teniendo este plugin desactivado. Durante unos días pensé que estaba solucionado el problema, nada más lejos de la realidad. Aunque el blog consumia menos memoría, en cuanto hacía algo que requiriese más esfuerzo por parte de la RAM, Apache se venía abajo. Simplemente con entrar varias veces en el escritorio del blog o activar un plugin, Apache caía. Fue frustrante.

Un plugin del que no conocía su existencia es DB Cache Reloaded. Como su nombre indica, permite cachear las consultas a la base de datos, evitando que se conecte a la base de datos cada vez que haya una petición a esta. Reduce el consumo de recursos. Bien. Activado está y funciona de maravilla, aunque de momento no termina de cachear todas las consultas. Tendré que mirar porqué.

Pero el problema continuaba, Apache se caía. Había que entrar en el servidor.

SSH

Tengo que admitir que no me había conectado nunca a otro ordenador a través de SSH, si a través de VNC y VPNs.

Trabajo con Windows XP SP3 principalmente, pero no le hago ascos a las distribuciones linux, todo lo contrarío: en VirtualBox tengo instalados Debian, CentOS, Ubuntu y ChromeOS, y excepto para el tema de configurar la tarjeta gráfica que aun no he conseguido (creo que VirtualBox es el que no la reconoce y por algún motivo envía al SO una tarjeta gráfica compatible con la que tengo, pero me obliga a estar con una resolución de 800×600).

Bien, ¿porqué cuento esto?. Además de por que quería contarselo a alguien xD, por que así comprenderás que después de varios intentos por conectarme al servidor con varios programitas para Windows, arrancase una máquina virtual para conectarme por la consola de linux. ¡Bendita seas!. Hasta que descubrí que lo que me fallaba era el puerto para poder acceder. ¡La ignorancia da la felicidad!.

Una vez conectado al servidor lo primero que hice fue un top de la máquina para conocer el consumo de RAM (la leche no) en tiempo real.

Me indicaba que tenía 512 MB de RAM total y la memoría consumida oscilaba entre los 170 y los 220 MB, aunque en algunos podía llegar a 270 MB. El problema radica en que el VPS no tiene 512 MB de RAM sino 256 MB; los otros 256 es memoría compartida, con lo que no puedo contar con ella para realizar el cálculo.

También hice un free -m para comprobar la memoria, pero top me ofrece más datos.

Observé que cuando se pide al servidor una página apache ejecuta cuatro procesos de sí mismo llegando en varios casos a consumir un 12 por ciento de memoría RAM. Lo normales un 10 por ciento.

A por Apache

Optimizar Apache. Me costó un huevo y medio encontrar la ubicación de los archivos de configuración, pero cuando me enpeño… (/etc/httpd/conf en CentOS). Bien, leí que si realizaba ciertas modificaciónes en el archivo httpd.conf de Apache podría reducir el consumo de memoría. Por defecto la configuración de Apache era la siguiente:

<IfModule prefork.c>
StartServers                     8
MinSpareServers              5
MaxSpareServers            20
ServerLimit                   256
MaxClients                   256
MaxRequestsPerChild   4000
</IfModule>

Se quedo así:

<IfModule prefork.c>
StartServers                      5
MinSpareServers               5
MaxSpareServers             10
ServerLimit                     30
MaxClients                     30
MaxRequestsPerChild 40000
</IfModule>

No solucionó mucho, o por lo menos yo no lo noté. Reduje también varios parámetros más, como el tiempo que espera Apache para cerrar una conexión permanente, etc.

Esto seguía sin mejorar. Probemos con la base de datos

MySQL

Poca optimización realicé aquí, la verdad. Me limite a añadir la configuración para habilitar la caché de la BD, pero no ha hecho mucho. También puede deberse a que el plugin de WordPress que cachea las consultas ya lo está haciendo. No sé. La configuración quedo del siguiente modo:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 8M

PHP

Para optimizar PHP necesitaba instalar en el VPS Eaccelerator y el Zend Optimizer, mis pocos intentos me han llevado a pensar que no puedo instalar nada que no sea a través de Plesk o que necesite el comando yum. Por tanto, a día de hoy, PHP está sin optimizar, habrá que enviar un ticket a ver si ellos me lo isntalan…

VPS

CentOS consume memoría, como todos los SO, las veces que he podido ver el consumo de memoría sin Apache, está rondaba entre 60 y 80 MB. Pero no sólo es el sistema operativo el que consume RAM, Plesk también consume lo suyo (unos 50 MB), he deshabilitado el antivirus que me consumía 70 MB cada vez que se iniciaba. Pero aunque el VPS se ha estabilizado hay momentos en los que Apache tiene cuatro procesos abiertos de 50-60 MB cada uno (según el comando top). Excesivo.

Intenté crear un archivo SWAP pero el comando swapon no lo tengo permitido, al menos por SSH.

CONCLUSIONES

  • Sigo valorando distintas opciones respecto a la optimización del VPS, ahora mismo mi mejor baza es Eaccelerator y que me lo instalen en el VPS para reducir la memoría.
  • Seguiré probando con algunnos plugin de WordPress a ver que tal.
  • Si estas interesado en la contratación de un VPS andate con ojo con la RAM.
  • Me he planteado incluso cambiar de VPS o ampliarlo con la misma empresa o marcharme a otra, ya se verá en septiembre.
  • Lo mejor de todo esto: lo aprendido por el camino. No solo conozco un poco mejor los sistemas Linux, sino también Apache, PHP, MySQL y Plesk, y su administración.
  • Bueno, ¿Y vosotros?¿Qué experiencia habeis tenido con los VPS?¿Qué consejos podeis darme? o simplemente ¿Qué opinais? Los comentarios son vuestros… mientras Apache lo permita xD.

LINKS

Os dejo unos links y así libero al navegador de carga, pobre.

Optimización del VPS

Optimización de WordPress

Optimización de PHP

Optimización de Apache

    Google sitemap y PHP

    0

    Acabo de terminar de programar, testear y poner en servicio un pequeño script en php, que me permitire generar un archivo xml para que el robot de google lo procese, y así, indexar las páginas de una web mucho más rápido.

    No lo utilizo en el blog, por la sencilla razón de que tengo un plugin que lo realiza automáticamente:http://wordpress.org/extend/plugins/google-sitemap-generator/. Este script sirve para webs o bien hechas desde cero sin cms de ningún tipo, o bien para cms modificados que requieran un sitemap especial.

    Continue reading “Google sitemap y PHP” »

    Ir arriba