No puedo explicar el comportamiento, pero puedo sugerir cómo investigaría más a fondo. Obtener un 404 «suave» como se ve significa que la consulta para la página solicitada no ha podido encontrar nada. Examinar la consulta SQL real debería revelar por qué no puede encontrar nada. Lo que eso es de alguna manera necesita ser corregido.
Para ver el SQL real, agregue el siguiente código PHP a la plantilla 404.php de su tema (dentro de Etiquetas, copie la plantilla del tema principal si aún no lo ha hecho):
global $wp_query;
echo '
',$wp_query->request;Como referencia, el SQL predeterminado para una solicitud de página 2 no registrada debería ser algo como esto:SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND ((wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish'))) ORDER BY wp_posts.post_date DESC LIMIT 10, 10
¡Muchas gracias por este consejo! Hice lo que dijiste y obtuve la siguiente consulta:
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND ((wp_posts.post_type="post" AND (wp_posts.post_status="publish"))) ORDER BY wp_posts.post_date DESC LIMIT 4, 4
Parece que el límite se toma de la lectura de WordPress-Settings, donde se establecen 4 publicaciones. ¡En mi plantilla he establecido 30 publicaciones y otro pedido!
Cuando cambio las publicaciones de WordPress a 30 publicaciones, la página aún no está disponible. Esta es la consulta mostrada:
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND ((wp_posts.post_type="post" AND (wp_posts.post_status="publish"))) ORDER BY wp_posts.post_date DESC LIMIT 30, 30
Entonces, ¿cómo puedo obligar a WordPress a usar mi propia configuración de la plantilla? Como dije, obtengo los datos de otra base de datos de WordPress. Este es mi código en el archivo en la plantilla-Parts-Directory:
$variable = get_query_var( 'variable' );
$wpdb = new wpdb('user','PW','database','localhost:3306');
$paged = get_query_var( 'paged' ) ? get_query_var( 'paged' ) : 1;
$post_per_page = 30;
$offset = ($paged - 1)*$post_per_page;
$result = $wpdb->get_results ( "
SELECT SQL_CALC_FOUND_ROWS *, ...my custom sql query...
WHERE post_type="persons"
AND pm3.meta_value != '0000-00-00'
AND pm3.meta_value LIKE '$variable-%'
ORDER BY pm3.meta_value DESC LIMIT $offset, $post_per_page");
$sql_posts_total = $wpdb->get_var( "SELECT FOUND_ROWS();" );
$max_num_pages = ceil($sql_posts_total / $post_per_page);
foreach ( $result as $page )
{
...my template content...
}
$big = 999999999;
echo paginate_links( array(
'base' => str_replace( $big, '%#%', esc_url( get_pagenum_link( $big ) ) ),
'format' => '?paged=%#%',
'current' => max( 1, get_query_var('paged') ),
'total' => number_format($max_num_pages,0),
) );
¡Ah! No me di cuenta de que estaba usando una consulta personalizada para obtener contenido. Eso cambia las cosas por completo. Para usar paginate_links (), no puede usar «Paged» como la consulta de paginación var. Pertenece a la consulta principal. No hay una segunda página para la consulta principal, por lo que va 404. Deberá usar un VAR de consulta de paginación personalizado, un var que no conoce WP u otro código. WhitList Your Consuly Var a través del filtro «Query_vars».
He agregado una nueva consulta var ‘seite’ en lugar de ‘paginado’ a través del filtro Query_vars. Luego cambié la regla de reescritura a:
add_rewrite_rule('died-persons/([0-9]{4})[/]page/([0-9]+)/?$', 'index.php?variable=$matches[1]&seite=$matches[2]', 'top'); En la plantilla cambié el código de paginación a:
$paged = get_query_var( 'seite' ) ? get_query_var( 'seite' ) : 1;
//$post_per_page = intval(get_query_var('posts_per_page'));
$post_per_page = 30;
$offset = ($paged - 1)*$post_per_page; $big = 999999999;
echo paginate_links( array(
'base' => str_replace( $big, '%#%', esc_url( get_pagenum_link( $big ) ) ),
'format' => '?seite=%#%',
'current' => max( 1, get_query_var('seite') ),
'total' => number_format($max_num_pages,0),
) );
Luego he refrescado los enlaces permanentes. Pero desafortunadamente no resolvió el problema. En la página 1 no hay paginación visible en absoluto, y sigue siendo un error 404 para la página 2.
Intenté probar su código en mi sitio, pero tuve que hacer algunos cambios significativos para ser compatibles. Con tales cambios, todo funciona, en particular Paginate_Links ().
Naturalmente, tuve que crear mi propia consulta personalizada ya que no tengo su tipo de publicación. Pero la consulta real no es el problema de todos modos.
Estar seguro get_query_var('seite') está devolviendo el valor correcto. Durante bastante tiempo no funcionó bien para mí. Hice todo tipo de intentos de depuración al tratar de determinar por qué estaba fallando. Entonces, de repente, comenzó a funcionar sin que yo cambiara a sabiendas nada relacionado. Sospecho que algún tipo de problema de almacenamiento en caché. Lo mismo ocurre con get_query_var('variable')aunque no se usa en mi consulta.
Aquí está todo lo que cambié para adaptarme:
Creé una consulta completamente diferente, pero aún utilicé la consulta VAR «Seite».
Reduje las publicaciones por parámetro de página para asegurar que tuviera varias páginas de publicaciones.
Agregué un parámetro «PageName» a la cadena de consulta index.php en la regla de reescritura para llegar a la plantilla correcta.
Pedí una redirección canónica al valor solicitado de PageName. Si su solicitud de página 2 va 404, me pregunto si está obteniendo algún tipo de redirección no deseada. De alguna manera, la página/ 2/ elemento en su URL todavía se aplica a la consulta principal a pesar de que su regla de reescritura la aplica de manera diferente. ¿Quizás intente cambiar el elemento / página / URL a / seite / en las solicitudes? Asegúrese de cambiar la regla de reescritura relacionada y las reglas de reescritura de descarga. ¿Estás seguro de que tienes suficientes publicaciones de «personas» con el meta valor «variable» solicitado (personas muertas) para llenar más de una página?
En breve, get_query_var('seite') Debe funcionar correctamente y/página/2/El elemento URL no debe aplicarse a la consulta principal. Y Flush Reescribe reglas y cualquier cachés.
¡Muchas gracias por su ayuda y su paciencia! ¡Las páginas paginadas funcionan ahora con var ‘seite’! Lo único, que está mal ahora, son los enlaces de paginación. Supongamos que hay tres páginas para el año 2024 y la URL actual se ve así -> mydomain.com/died-persers/2024/seite/3
Cuando intento usar los enlaces de paginación ahora para ver la página 2 y quiero hacer clic en la página 2 del menú de navegación, la URL se vería así-> mydomain.com/died-persers/2024/seite/3/page/2 en lugar de mydomain.com/died-persers/2024/seite/2.
Entonces, en los enlaces de paginación todavía hay una ‘página’ existente junto con el número de página actual. ¿De dónde viene? ¿Cómo puedo personalizar paginate_links para deshabilitar los valores innecesarios? Mi código actual se ve así:
$big = 999999999;
echo paginate_links( array(
'base' => str_replace( $big, '%#%', esc_url( get_pagenum_link( $big ) ) ),
'format' => '?seite=%#%',
'current' => max( 1, get_query_var('seite') ),
'total' => number_format($max_num_pages,0),
) );
Se debe a get_pagenum_link(). Obtiene el enlace actual y se agrega/página/%#%/si aún no está allí. Como no se encontró ningún elemento «/Page/», se confundió 🙂 Tendrá que construir la URL base a través de otros medios. Si está seguro de que la URL nunca cambiará, simplemente podría codificar la mayor parte (excepto el número de «variable»). O obtenga la ruta actual de $ _server (‘request_uri’), agregue a la url de inicio (nombre de dominio) y reemplace (si corresponde) el número de página solicitado con $ big. Deberíamos evitar las URL codificantes, pero es una solución fácil. Construir la URL dinámicamente es preferible.
No vi este comportamiento en mis pruebas porque mantener / página / en la URL funcionó para mí. Sin embargo, usé Seite en cualquier otro lugar. Por alguna razón/página/2/no se aplicó a mi consulta principal como lo hizo por usted. Probablemente algo sobre cómo suprimí las redirecciones.
¡Lo tengo para trabajar! Hice lo que dijiste y generé URL estáticas con la ayuda de str_replace. Todo es perfecto ahora. ¡Gracias de nuevo por tu gran ayuda!
¡De nada! Fue un rompecabezas interesante para mí. Siempre me ha gustado resolver rompecabezas.