¿Por qué se está agregando ?doing_wp_cron a mis URLs?
¡Gracias! ¿Sabes qué podría hacer para eliminar eso del final de mis URLs?

Elimina la línea de wp-config.php (aunque eso podría hacer que el cron deje de funcionar).

@scribu iThemes sugiere configurar esa línea en el archivo wp-config para que BackupBuddy funcione, por lo que eliminar esa línea nuevamente hace que el plugin deje de funcionar. ¿Hasta donde sabes, existe otra "solución" para esto aparte de deshacerse de BackupBuddy?

@Piet: Es un requisito bastante extraño por parte de iThemes. Una posible solución sería usar trabajos cron de UNIX. Abre una nueva pregunta.

@scribu gracias por tu sugerencia, la nueva pregunta está publicada: http://wordpress.stackexchange.com/questions/28718/alternative-for-wp-cron-with-backupbuddy

He visto muchas publicaciones sobre este problema pero pocas logran encontrar una solución real. Lo que resolvió este problema para mí ha sido manejar la redirección en el archivo .htaccess.
Aquí hay un ejemplo de cómo redirigir la URL agregando estas líneas en el archivo .htaccess:
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron= [NC]
RewriteRule (.*) /$1? [R=301,L]
</IfModule>
¡Espero que esto ayude!
Nota: este consejo proviene de este foro

@toscho : Esto es lo que he entendido (quizás me esté perdiendo algo). El parámetro 'ALTERNATE_WP_CRON' desactiva el cron job desde el punto de vista de WordPress. Así que está desactivado en el "motor" de WordPress. Entonces, el plugin 'All in one Event Calendar', BackWPup y todas las herramientas que necesitan programar trabajos no podrán ejecutar sus tareas. Al jugar con la redirección de Apache, el motor de WordPress no se verá afectado. Eso es lo que entiendo, pero no todo me queda claro. ¿En qué me equivoco?

Desactivar ALTERNATE_WP_CRON no desactiva el sistema interno de cron (programación) de WP. Solo desactiva la forma alternativa de realizar este tipo de tareas en segundo plano. Pero, por defecto, WP siempre realizará sus tareas programadas a menos que uses la directiva DISABLE_WP_CRON en tu wp-config.php.
Consulta aquí una explicación completa de lo que hace ALTERNATE_WP_CRON: https://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282/#post-1163465

@scribu Creo que BackupBuddy utiliza la programación de tareas de WordPress para programar tareas como parte de los procedimientos de copia de seguridad. Si el sitio tiene loopbacks deshabilitados, entonces la única solución (aparte de alguna solución externa personalizada) y la solución alternativa específica que, estoy seguro de que sabes, está integrada en WordPress, es la solución alternativa de cron. Por lo tanto, esto solo es "necesario" si el host tiene loopbacks deshabilitados. Ten en cuenta que si ese es el caso, ninguna tarea programada, ya sean las tareas programadas estándar de WordPress o aquellas asociadas con otros plugins, funcionará. Lo que parece ocurrir es que un usuario no sabrá que su host ha limitado su instalación de WordPress hasta que pruebe BackupBuddy, porque eso hace evidente el problema en lugar de que haya sido invisible hasta ese momento.
Utilizar un enfoque tipo crontab es solo un parche temporal porque, a menos que lo configures para "hacer ping" al procesamiento de cron de WordPress muy frecuentemente, solo funcionará con algunos tipos de tareas programadas.
Por supuesto, si un usuario no quiere o no puede usar la solución alternativa de wp-cron, no quiere cambiarse a un host que permita loopbacks y no tiene el conocimiento suficiente para configurar una capacidad adecuada basada en crontab, entonces BackupBuddy ofrece un modo de copia de seguridad manual que funcionará, pero carece de la flexibilidad y algunas de las capacidades disponibles cuando la programación está habilitada.

Lo que causa este problema es el cron alternativo. Como solución alternativa, si tienes acceso, puedes habilitar un proceso cron real (si tu hosting te lo permite) y desactivar ALTERNATE_WP_CRON en tu archivo wp-config.php.
