การรับประเภทโพสต์ที่กำหนดเองแบบลำดับชั้นจะทำให้ลิงก์ทำงานเหมือนหน้าเว็บ

ฉันขุดทุกคำถามที่นี่เกี่ยวกับ Permalinks ประเภทโพสต์ที่กำหนดเอง แต่ส่วนใหญ่ดูเหมือนว่าจะมีปัญหากับการเขียน taxonomy ที่กำหนดเองหรือการขาด flush_rewrite_rules () อย่างชัดเจน แต่ในกรณีของฉันฉันใช้ชนิดโพสต์ที่กำหนดเองเท่านั้น (ไม่มีอนุกรมวิธาน) ตั้งเป็นลำดับขั้น (ดังนั้นฉันจึงสามารถกำหนดความสัมพันธ์ระหว่างผู้ปกครองกับลูก) โดยมี "การสนับสนุน" ที่เหมาะสมสำหรับคุณสมบัติ metabox ฯลฯ เป็นต้น ได้เขียนกฎใหม่อีกหลายพันวิธีแล้ว ฉันลองใช้โครงสร้างลิงก์อื่น แต่ URL ย่อยจะส่งผลให้เกิด 404 เสมอ!

เดิมฉันมีประเภทโพสต์ที่กำหนดเองที่เป็นอิสระสำหรับองค์ประกอบ "หลัก" และ "เด็ก" (ใช้ p2p) และฉันอาจจะไม่มีปัญหาในการใช้อนุกรมวิธานสำหรับการจัดกลุ่ม "ผู้ปกครอง" - ฉันรู้ว่าสิ่งเหล่านั้นจะแม่นยำกว่า แต่สำหรับลูกค้ามันเป็นเรื่องง่ายที่สุดสำหรับพวกเขาที่จะเห็นภาพลำดับชั้นเมื่อ "โพสต์" ถูกแสดงในผู้ดูแลระบบเหมือนกับหน้าคือ: ต้นไม้ที่เรียบง่ายที่เด็ก ๆ จะปรากฏภายใต้ผู้ปกครองนำหน้าด้วย "-" และใน คำสั่งที่เหมาะสม นอกจากนี้ยังสามารถใช้วิธีการต่างๆในการกำหนดคำสั่งผ่าน drag-n-drop ได้ การจัดกลุ่มผ่านอนุกรมวิธาน (หรือ p2p) ให้ผลลัพธ์ในรายการ "โพสต์" แบบแบนในรายการผู้ดูแลระบบซึ่งไม่ชัดเจนเท่าที่เห็น

ดังนั้นสิ่งที่ฉันตามมาก็คือพฤติกรรมเช่นเดียวกันกับ "หน้า" หลัก แต่มีประเภทโพสต์ที่กำหนดเองของฉัน ฉันได้ลงทะเบียนประเภทโพสต์ตามที่คาดไว้และในการดูแลระบบมันทำงานได้อย่างสมบูรณ์แบบ - ฉันสามารถกำหนดผู้ปกครองและ menu_order สำหรับจดหมายข่าว "โพสต์" แต่ละรายการพวกเขาปรากฏอย่างถูกต้องในรายการแก้ไข:

Spring 2012
— First Article
— Second Article

และ Permalink ของพวกเขาดูเหมือนจะถูกสร้าง ในความเป็นจริงถ้าฉันเปลี่ยนอะไรก็ตามเกี่ยวกับโครงสร้างหรือแม้กระทั่งเปลี่ยนกระสุนเขียนเมื่อลงทะเบียนประเภทโพสต์พวกเขาปรับปรุงอย่างถูกต้องโดยอัตโนมัติดังนั้นฉันรู้ว่าสิ่งที่ทำงาน:

http://mysite.com/parent-page/child-page/                  /* works for pages! */
http://mysite.com/post-type/parent-post/child-post/        /* should work? */
http://mysite.com/newsletter/spring-2012/                  /* works! */
http://mysite.com/newsletter/spring-2012/first-article/    /* 404 */
http://mysite.com/newsletter/spring-2012/second-article/   /* 404 */

ฉันยังมี "หน้า" หลักมาตรฐานที่สร้างความสัมพันธ์แบบลำดับชั้นและพวกเขาดูเหมือนกันในผู้ดูแล แต่จริง ๆ แล้วพวกเขาทำงานในส่วนหน้าเช่นกัน (ทั้ง URL หลักและลูกทำงานได้ดี)

โครงสร้างลิงก์ถาวรของฉันถูกตั้งค่าเป็น:

http://mysite.com/%postname%/

ฉันได้ลองทำเช่นนี้แล้ว (เพราะคำตอบอื่น ๆ อีกมากมายดูเหมือนจะบ่งบอกว่ามันจำเป็น แต่ก็ไม่สมเหตุสมผลในกรณีของฉัน):

http://mysite.com/%category%/%postname%/

CPT ของฉันที่ลงทะเบียนรวมถึง:

$args = array(
    'public'                => true,
    'publicly_queryable'    => true,
    'show_ui'               => true,
    'has_archive'           => 'newsletter',
    'hierarchical'          => true,
    'query_var'             => true,
    'supports'              => array( 'title', 'editor', 'thumbnail', 'page-attributes' ),
    'rewrite'               => array( 'slug' => 'newsletter', 'with_front' => false ),

ความแตกต่างที่มองเห็นได้ระหว่างเด็กประเภทโพสต์ที่กำหนดเองของฉันและเด็ก ๆหน้าปกติคือ CPT ของฉันมีกระสุนที่จุดเริ่มต้นของโครงสร้าง Permalink แล้วตามด้วยทากผู้ปกครอง / เด็ก (ที่หน้าเริ่มต้นด้วยทากผู้ปกครอง / เด็ก ไม่มี "คำนำหน้า") ทำไมสิ่งนี้จะเหม็นขึ้นฉันไม่รู้ บทความจำนวนมากดูเหมือนจะบ่งบอกว่านี่เป็นสิ่งที่วิธีการเรียงลำดับ CPT แบบลำดับขั้นควรทำ - แต่ของฉันแม้ว่าจะเกิดขึ้นแล้ว แต่ก็ใช้ไม่ได้

สิ่งที่ทำให้ฉันยุ่งเหยิงคือเมื่อฉันตรวจสอบ query_vars สำหรับหน้า 404 - พวกเขาดูเหมือนจะมีค่าที่ถูกต้องสำหรับ WP เพื่อ "ค้นหา" หน้าย่อยของฉัน แต่มีบางอย่างไม่ทำงาน

$wp_query object WP_Query {46}
public query_vars -> array (58)
'page' => integer 0
'newsletter' => string(25) "spring-2012/first-article"
'post_type' => string(10) "newsletter"
'name' => string(13) "first-article"
'error' => string(0) ""
'm' => integer 0
'p' => integer 0
'post_parent' => string(0) ""
'subpost' => string(0) ""
'subpost_id' => string(0) ""
'attachment' => string(0) ""
'attachment_id' => integer 0
'static' => string(0) ""
'pagename' => string(13) "first-article"
'page_id' => integer 0
[...]

ฉันลองสิ่งนี้ด้วยธีมที่หลากหลายรวมถึงยี่สิบสองเพื่อให้แน่ใจว่าไม่ใช่เทมเพลตที่ขาดหายไปในส่วนของฉัน

การใช้ตัวตรวจสอบกฎการเขียนซ้ำนี่คือสิ่งที่ปรากฏสำหรับ URL: http://mysite.com/newsletter/spring-2012/first-article/

newsletter/(.+?)(/[0-9]+)?/?$   
       newsletter: spring-2012/first-article
           page: 
(.?.+?)(/[0-9]+)?/?$    
       pagename: newsletter/spring-2012/first-article
           page: 

วิธีแสดงบนหน้าตรวจสอบอื่น:

RULE:
newsletter/(.+?)(/[0-9]+)?/?$
REWRITE:
index.php?newsletter=$matches[1]&page=$matches[2]
SOURCE:
newsletter

ผลลัพธ์ที่เขียนใหม่นี้จะทำให้ฉันเชื่อว่าลิงก์ถาวร "ไม่สวย" ต่อไปนี้จะใช้งานได้:

http://mysite.com/?newsletter=spring-2012&page=first-article

ไม่ใช่ 404 แต่แสดงรายการ "จดหมายข่าว" หลักของรายการ CPT ไม่ใช่รายการย่อย คำขอมีลักษณะดังนี้:

Array
(
    [page] => first-article
    [newsletter] => spring-2012
    [post_type] => newsletter
    [name] => spring-2012
)

นี่เป็นครั้งแรกของฉันที่เข้าร่วมที่นี่ในการแลกเปลี่ยนกอง แต่ฉันจะให้ไปและดูว่าฉันสามารถช่วยชี้คุณในทิศทางที่ถูกต้อง

ตามค่าเริ่มต้น CPT แบบลำดับขั้นจะทำงานในลักษณะที่คุณอธิบายไว้อย่างชัดเจน คำนำหน้ากระสุนที่ไม่ซ้ำกัน "จดหมายข่าว" ในกรณีนี้คือเพื่อให้เอ็นจิ้นเขียนใหม่รู้วิธีบอกคำขอสำหรับโพสต์ประเภทต่างๆ

การลงทะเบียน CPT เหล่านั้นดูดี แต่เมื่อมีการร้องขอ CPT pagenameคำสั่ง var ไม่ควรมีค่าและnamevar ของแบบสอบถามควรเหมือนกันnewsletterที่นี่ดังนั้นปรากฏว่ามีข้อขัดแย้งในการตั้งค่าของคุณ

ในการช่วยแก้ปัญหาให้ติดตั้งและเปิดใช้งานปลั๊กอินตัวตรวจสอบกฎการเขียนซ้ำจากนั้นไปที่หน้าจอที่ " เครื่องมือ -> กฎการเขียนซ้ำ"

1. ในขณะที่ดูรายการกฎของคุณทั้งหมดสำหรับจดหมายข่าว CPT ควรถูกแสดงรายการก่อนที่จะเขียนกฎหน้าใด ๆ ตรวจสอบว่าเป็นกรณีนี้โดยการสแกนคอลัมน์ " แหล่งที่มา "
2. หากตรวจสอบแล้วให้ป้อน URL สำหรับ "บทความแรก" CPT ของคุณในฟิลด์" จับคู่ URL " และคลิกปุ่ม "ตัวกรอง" เพื่อดูกฎที่ตรงกัน ควรตรงกับกฎจดหมายข่าวและกฎของหน้า แต่กฎของจดหมายข่าวควรเป็นอันดับแรก

หากไม่พบปัญหาใด ๆ ให้ค้นหาpost_nameคอลัมน์ในwp_postsเพื่อค้นหาโพสต์อื่นที่มีกระสุน "บทความแรก" เพื่อดูว่าอาจมีการชนกันหรือไม่ ค้นหา "จดหมายข่าว" เช่นกันเพื่อให้แน่ใจ

เพิ่มตัวอย่างต่อไปนี้เพื่อตรวจสอบ vars แบบสอบถามของคุณก่อนกำหนดเพื่อตรวจสอบและดูว่าอันไหนถูกตั้งค่าโดยกฎการเขียนซ้ำที่ตรงกัน (เยี่ยมชม CPT ลูกที่ส่วนหน้า) หากpagenamevar ไม่ปรากฏที่นี่แสดงว่ามีบางอย่างถูกตั้งค่าไว้ในคำขอ:

add_filter( 'request', 'se77513_display_query_vars', 1 );

function se77513_display_query_vars( $query_vars ) {
    echo '<pre>' . print_r( $query_vars, true ) . '</pre>';

    return $query_vars;
}

ปลั๊กอิน / ฟังก์ชั่นใด ๆ ที่แก้ไข vars แบบสอบถามอาจทำให้เกิดข้อขัดแย้งดังนั้นปิดใช้งานหากคุณยังคงเห็นปัญหา นอกจากนี้ให้ล้างกฎการเขียนซ้ำของคุณหลังจากแต่ละขั้นตอนโดยเฉพาะอย่างยิ่งหากคำขอตรงกับกฎที่ไม่ถูกต้องในขั้นตอนที่สองข้างต้น (เปิดหน้าจอ "Permalinks" ในแท็บแยกต่างหากและเพิ่งรีเฟรช)

parent/Childความคิดเห็นการทำงานออกจากกล่องตราบใดที่คุณชุด

'hierarchical'=> true,
'supports' => array('page-attributes' ....

ปรับปรุง:

ฉันเพิ่งทดสอบอีกครั้งและใช้งานได้ตามที่คาดไว้กับกรณีทดสอบนี้:

add_action('init','test_post_type_wpa77513');
function test_post_type_wpa77513(){
    $args = array(
        'public' => true,
        'publicly_queryable' => true,
        'show_ui' => true, 
        'show_in_menu' => true, 
        'query_var' => true,
        'rewrite' => true,
        'capability_type' => 'post',
        'has_archive' => true, 
        'hierarchical' => true,
        'supports' => array( 'title', 'editor', 'thumbnail', 'page-attributes' )
    ); 

    register_post_type( 'newsletter', $args );
}

และตั้งค่า Permalink ให้/%postname%/ฉันรับจดหมายข่าว / ผู้ปกครอง / เด็กทำงานได้ดี

นอกเหนือจากการถาม»คุณได้ลองปิดและเปิดใหม่อีกครั้งหรือไม่«ฉันต้องถามว่า "คุณมีปลั๊กอินใด ๆ ที่ใช้งานอยู่และธีมของคุณกำลังทำอะไรกับ Permalinks (เช่นการลงทะเบียนอนุกรมวิธานประเภทโพสต์เพิ่มกฎการเขียนใหม่ เป็นต้น)

หากเป็นเช่นนั้นจะยังคงเกิดขึ้นหลังจากคุณปิดใช้งานปลั๊กอินทั้งหมดและเปลี่ยนเป็น TwentyEleven หรือไม่

การแก้ปัญหาต่อไปมุ่งหน้าไป GitHub และคว้าToschos "Rewrite" ปลั๊กอิน แล้วสลับไป repo ปลั๊กอินอย่างเป็นทางการใน wp.org และ grap ปลั๊กอิน ฉันยังเขียนส่วนขยายเล็กน้อยเพื่อกาวทั้งคู่เข้าด้วยกัน นี่จะให้รายละเอียดมากมายเกี่ยวกับการตั้งค่าของคุณ

ดังนั้นหลังจากยืนยันว่าฉันจะได้รับพฤติกรรมของเพจแบบลำดับชั้นที่คาดหวังด้วยการติดตั้งที่สมบูรณ์แบบและเพียงแค่การประกาศ CPT เดียวฉันรู้ว่ามีความผิดพลาดเกิดขึ้นภายในปลั๊กอินของตัวเองที่ฉันใช้จัดการการสร้าง CPT (ซับซ้อนมาก ฯลฯ ) ปัญหาคือแม้จะมีคำแนะนำทั้งหมดในการตรวจสอบปัญหาการเขียนซ้ำหรือการสืบค้น แต่ฉันไม่เห็นอะไรผิดปกติอย่างชัดเจน ฉันตรวจสอบทุกตัวกรองและขอดูการค้นหาในแต่ละจุดและไม่เห็นสิ่งใดที่จะทำให้ 404

ดังนั้นฉันจึงเหลือหน้าที่ในการปิดใช้งาน / เปิดใช้งานด้วยตนเอง 9 คลาสขนาดใหญ่จากนั้นค้นหาอย่างน้อย 2 ในจำนวนที่เป็นสาเหตุของ 404 ผ่านแต่ละฟังก์ชั่นทีละตัวและปิดใช้งาน / เปิดใช้งานพวกเขาแล้วติดตามสาย โดยสายในฟังก์ชั่นเหล่านั้น - แรงเดรัจฉานพยายามที่จะดูว่าอะไรคือสาเหตุของ 404 แม้ว่าฉันไม่รู้ว่าทำไม

$query->get_queried_object()นั่นคือเมื่อผมพบว่ามีผลมาจากการใช้ ดูเหมือนว่าจะใช้ฟังก์ชั่น wrapper นี้แก้ไข $ query เองซึ่งฉันคิดว่าฉันกลับมาไม่เปลี่ยนแปลงในตอนท้ายของฟังก์ชั่น สามฟิลเตอร์ข้าม 2 ชั้นเรียนมีส่วนร่วมที่มีการปรับเปลี่ยนการสอบถาม: parse_query, posts_orderby, posts_join- และทุกฟังก์ชั่นการเรียกกลับถูกเรียก$query->get_queried_object()ในที่ผ่านมา$queryหาเรื่องแล้วเรียกใช้การทดสอบเงื่อนไขบางส่วนและบางครั้งปรับเปลี่ยนแบบสอบถาม vars (เช่นกรณีการเรียงลำดับพิเศษ) น่าแปลกที่ฟังก์ชั่นเหล่านี้ใช้งานได้ดีกับสิ่งที่พวกเขาถูกออกแบบมาให้ทำแม้ว่าฉันจะใช้ฟังก์ชั่นนี้ก็ตาม ฉันไม่เคยสังเกตเห็นอะไรผิดปกติกับการสอบถาม $ ส่งคืนมาก่อน!

ยังไงก็ตามหลังจากผ่านไปกว่าหนึ่งปีของการพัฒนาและการใช้งานในหลายสิบไซต์การผลิตสดฉันไม่เคยได้รับผลกระทบใด ๆ จากความผิดพลาดนี้ เฉพาะเมื่อฉันเข้าสู่การทำ CPT แบบลำดับชั้นความแตกต่างเล็ก ๆ น้อย ๆ ก็เกิดขึ้นอย่างกระทันหัน นั่นเป็นส่วนหนึ่งของสิ่งที่ทำให้ฉันหนักใจกับสิ่งนี้ - อย่างที่ฉันบอกได้อย่างดีที่สุดตัวกรองข้อความค้นหาของฉันเชื่อถือได้!

ฉันยอมรับว่าฉันยังไม่ทราบแน่ชัดว่าทำไมการเรียกฟังก์ชั่นนี้จึงเป็นการแบ่งหน้าเล็ก ๆ ของ CPT เพจย่อย - และยังไม่เคยมีปัญหาอื่นใดเลย! แต่เห็นได้ชัดว่าการใช้งานภายในตัวกรองการเรียกกลับทำให้เกิดการส่งคืน$queryอย่างใด การลบสายนี้ทำให้ข้อผิดพลาด 404 ของฉันหายไป

ขอบคุณสำหรับเคล็ดลับทั้งหมด - หวังว่าฉันจะสามารถแบ่งเงินรางวัลได้เนื่องจากฉันได้รับข้อมูลเชิงลึกจากคำตอบแต่ละข้อแม้ว่าวิธีแก้ปัญหาขั้นสุดท้ายนั้นไม่เกี่ยวข้องกันเลย นี่เป็นบทเรียนที่ให้ความรู้ในการไม่เชื่อถือรหัสของคุณอย่างสุ่มสี่สุ่มห้าแม้ว่ามันจะใช้ได้ผลกับคุณอย่างน่าเชื่อถือมาเป็นเวลานานหรือไม่เกิดข้อผิดพลาดที่ชัดเจน

บางครั้งในขณะที่แผนภูมิของไกเซอร์มีการรวบรวมอย่างประณีตคุณเพียงแค่เริ่มขว้างสวิตช์จนกระทั่งไฟสว่างขึ้น ในกรณีของฉันฉันต้องใช้กลยุทธ์การแก้ไขปัญหาแบบเดียวกันไปจนถึงแต่ละบรรทัดในฟังก์ชั่นก่อนที่ฉันจะเห็นปัญหา

คุณใช้ WP เวอร์ชันล่าสุดหรือไม่? ฉันเดาว่าเป็นคำถามแรก (เช่นเมื่อคุณโทรหาฝ่ายสนับสนุนด้านเทคนิคและพวกเขาถามคุณว่าคอมพิวเตอร์ของคุณเสียบอยู่หรือไม่!) เนื่องจากฉันได้อ่านว่าปัญหานี้ได้รับการแก้ไขในการอัปเดตเวอร์ชันล่าสุด

มีโพสต์ใน digwp.com ที่แก้ไขปัญหานี้ (http://digwp.com/2011/06/dont-use-postname/) เห็นได้ชัดว่า WP ไม่สามารถบอกความแตกต่างระหว่างโพสต์และหน้าได้อย่างง่ายดายและถ้าคุณเริ่มต้น URL ด้วยตัวเลือกแบบข้อความ WP จะกระตุ้นการตั้งค่าสถานะที่สร้างกฎสำหรับทุกหน้า / โพสต์ที่คุณมี หากคุณมีเนื้อหาจำนวนมากในไซต์ของคุณนั่นอาจส่งผลให้มีคำขอจำนวนมากและเซิร์ฟเวอร์ของคุณอาจหมดเวลาซึ่งจะส่งผลให้มีจำนวน 404 รายการแม้ว่าจะมีหน้าเว็บอยู่ก็ตาม

ดังนั้น. หากคุณใช้โครงสร้างแบบตัวเลขก่อนจากนั้นโครงสร้างข้อความของคุณฉันขอเดิมพันว่าปัญหา 404 ของคุณจะได้รับการแก้ไข ตอนนี้เมื่อพิจารณาเรื่อง SEO ฉันจะไม่ใช้โครงสร้างวันที่ แต่การตัดสินใจนั้นจะสมเหตุสมผลสำหรับคุณ