1. Instalar normalmente bbPress en un subdirectorio usando el mismo admin que en WordPress.
2. Una vez instalado (no antes), abrir config.php y añadir estas líneas justo antes de /* Stop editing */:

   // ---START WORDPRESS INTEGRATION---

   define('CUSTOM_USER_TABLE', 'wp_users');
define('CUSTOM_USER_META_TABLE', 'wp_usermeta');

   $myhash = md5($bb->domain); // No trailing slash. This should be WP's 'siteurl', which can be easily found by browsing to wp-admin/options.php.
$bb->usercookie = 'wordpressuser_' . $myhash;
$bb->passcookie = 'wordpresspass_' . $myhash;
$bb->cookiepath = '/';

   // ---END WORDPRESS INTEGRATION---

Ahora todos los usuarios preexistentes de WordPress lo son también de bbPress, al igual que los de nueva creación; el admin tiene por contraseña la que tenía en WordPress y todos pueden entrar y salir por cualquiera de los dos extremos. Y aquí podría terminar la cosa. Peeeero… el admin ya no puede administrar bbPress porque en la tabla wp_usermeta aparece como un simple miembro. Esta es la parte más delicada del asunto:

3. Dirigirse a la base de datos con phpMyAdmin y examinar la tabla wp_usermeta, ordenando las filas, si no lo están, según la clave umeta_id ascendente. Anotar el valor más alto de esta clave (última fila, primera columna).
4. Ordenar las filas según la clave user_id y buscar las que bbPress ha creado para el usuario admin (es decir, user_id 1), meta_key con prefijo de bbPress (bb_).
5. Borrar estas filas.
6. Examinar la tabla bb_usermeta y exportar los datos.
7. Abrir el archivo de exportación en un editor de texto y cambiar:
   • bb_usermeta por wp_usermeta
   • los valores correspondientes a la clave umeta_id por números consecutivos a partir del anotado en el paso 3.
8. Volver a phpMyAdmin e insertar el resultado en la tabla wp_usermeta.

Yastá. Eso sí, los usuarios que se matriculen a través de bbPress no tendrán ninguna función asignada en el blog, habrá que dársela manualmente o desactivar el enlace de registro en bbPress.

css Hen Garden: The Beauty of Chicken Farming

Digno de verse también el sitio del autor.

Encontré este método:

function get_current_url () {
if (isset($_SERVER['REQUEST_URI'])) {
$current_url = $_SERVER['REQUEST_URI'];
} else {
$current_url = $_SERVER['SCRIPT_NAME'];
$current_url .= (!empty($_SERVER['QUERY_STRING'])) ? '?' . $_SERVER['QUERY_STRING'] : '';
}
return $current_url;
}

Añadí esta función en el functions.php de mi tema y luego la llamé desde mi menu:

$current_url = get_current_url();

Pero luego encontré que era más fácil, sin tener que añadir la función, hacer la siguiente consulta desde el propio menu:

$current_url = $_SERVER['REQUEST_URI'];

Ya sólo me quedaba añadir esto antes del enlace de mi página:

if ($current_url == '/?a=page') { echo "class=\""current_page_item\""; }

Donde '/?a=page' es todo lo que aparece tras la URL (home) de mi WordPress cuando visitas esa página.

Pero ahora, cada vez que estaba en la susodicha página, la pestaña de ‘home’ también cambiaba de color, por lo que tuve que cambiar en el menú esto:

if ((is_home()) && !(is_paged()) ) { echo "class=\""current_page_item\""; }

por esto:

if ((is_home()) && !(is_paged()) && ($current_url !== '/?a=page') ) { echo "class=\"current_page_item\""; }

Prueba superada. Aunque no acabo de entender la diferencia entre el primer método (pedir cada cacho por separado) y el segundo (pedirlo todo de golpe). Supongo que, en según qué configuraciones, será imprescindible el primero, pero soy aún demasiado ignorante para distinguir.

Me lo traduje al español y les ofrecí la traducción pero supongo que, como tienen visión comercial, debieron sospechar de una oferta gratuita, así que no me han contestado. Si alguien lo usa y quiere la traducción, que levante la mano.

Ummm, interesante, aunque no sé si me gusta la idea de tener aún más opciones… Eso de andar todo el día eligiendo o decidiendo no elegir ya me va cansando.

Ahora todo es Ajax.