पृष्ठों की तरह काम करने के लिए पदानुक्रमित कस्टम पोस्ट प्रकार के पर्मलिंक प्राप्त करना

Question

मैंने यहाँ कस्टम पोस्ट टाइप पर्मलिंक्स पर हर सवाल के माध्यम से खुदाई की है, लेकिन ज्यादातर या तो कस्टम टैक्सोनॉमी रीराइट्स के साथ समस्याएँ लगती हैं, या फ़्लश_ब्राइट_रुल्स () की स्पष्ट अनुपस्थिति। लेकिन मेरे मामले में, मैं केवल कस्टम पोस्ट प्रकार (कोई टैक्सोनॉमी) का उपयोग नहीं कर रहा हूं, पदानुक्रमित होने के लिए सेट किया गया है (इसलिए मैं अभिभावक-बच्चे के रिश्तों को असाइन कर सकता हूं), विशेषताओं मेटाबॉक्स आदि के लिए उचित "समर्थन" के साथ, आदि। एक अलग तरीके से फिर से लिखना नियम फ्लश हो गया है। मैंने विभिन्न पर्मलिंक संरचनाओं की कोशिश की है। लेकिन बाल URL का परिणाम हमेशा 404 होता है!

मेरे पास मूल रूप से "माता-पिता" और "बच्चे" तत्वों (पी 2 पी) का उपयोग करने के लिए स्वतंत्र कस्टम पोस्ट प्रकार थे, और मुझे शायद "माता-पिता" समूह के लिए एक वर्गीकरण का उपयोग करने में कोई परेशानी नहीं हुई होगी - मुझे पता है कि वे शब्दार्थ अधिक सटीक होंगे। लेकिन क्लाइंट के लिए, उनके लिए पदानुक्रम की कल्पना करना सबसे आसान है जब "पोस्ट" को व्यवस्थापक में प्रदर्शित किया जाता है जैसे पृष्ठ हैं: एक साधारण पेड़ जहां बच्चे माता-पिता के नीचे दिखाई देते हैं, "-" के साथ उपसर्ग करते हैं, और उचित ऑर्डर। इसके अलावा, ड्रैग-एन-ड्रॉप के माध्यम से ऑर्डर देने के विभिन्न तरीकों का उपयोग किया जा सकता है। टैक्सोनॉमी (या पी 2 पी) के माध्यम से समूहीकरण करने के लिए व्यवस्थापक सूची में "पदों" की एक फ्लैट सूची होती है, जो कि स्पष्ट रूप से स्पष्ट नहीं है।

तो जो मैं कर रहा हूं, वह वास्तव में कोर "पृष्ठों" के समान सटीक व्यवहार है, लेकिन मेरे कस्टम पोस्ट प्रकार के साथ। मैंने पोस्ट प्रकार को उम्मीद के अनुसार पंजीकृत किया है, और व्यवस्थापक में यह पूरी तरह से काम करता है - मैं प्रत्येक समाचार पत्र "पोस्ट" के लिए एक माता-पिता और एक मेनू_ऑर्डर असाइन कर सकता हूं, वे संपादन लिस्टिंग में सही ढंग से दिखाई देते हैं:

Spring 2012
— First Article
— Second Article

और उनके पर्मलिंक ठीक से बनाए गए प्रतीत होते हैं। वास्तव में, अगर मैं संरचना के बारे में कुछ भी बदलता हूं, या यहां तक ​​कि पोस्ट प्रकार को पंजीकृत करते समय फिर से लिखने वाले स्लग को बदल देता हूं, तो वे स्वचालित रूप से सही ढंग से अपडेट होते हैं, इसलिए मुझे कुछ काम करना पता है:

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 */

मेरे पास पदानुक्रमित संबंधों के साथ मानक कोर "पृष्ठ" भी हैं, और वे केवल व्यवस्थापक में समान दिखते हैं, लेकिन वे वास्तव में फ्रंट-एंड पर भी काम करते हैं (माता-पिता और बच्चे दोनों यूआरएल ठीक काम करते हैं)।

मेरी पर्मलिंक संरचना के लिए सेट है:

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

मैंने भी इसका प्रयास किया है (सिर्फ इसलिए कि कई अन्य उत्तरों से लगता था कि यह इंगित करने की आवश्यकता है, हालांकि यह मेरे मामले में कोई मतलब नहीं था):

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

मेरे रजिस्टर सीपीटी आर्ग में शामिल हैं:

$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 ),

मेरे कस्टम पोस्ट टाइप बच्चों और सामान्य पृष्ठ के बच्चों के बीच एकमात्र अंतर यह है कि मेरे सीपीटी में पर्मलिंक संरचना की शुरुआत में स्लग है, फिर माता-पिता / बच्चे के स्लग के बाद (जहां पेज सिर्फ माता-पिता / बच्चे के स्लग से शुरू होते हैं,) कोई "उपसर्ग" नहीं)। यह क्यों बेईमानी करेगा, मुझे नहीं पता। बहुत सारे लेखों से संकेत मिलता है कि यह वास्तव में इस तरह के पदानुक्रमित सीपीटी पर्मलिंक का व्यवहार करना चाहिए - लेकिन मेरा, हालांकि अच्छी तरह से गठित, काम नहीं करते हैं।

जब मैं उस 404 पृष्ठ के लिए query_vars की जांच करता हूं, तो वह भी मुझे चकित कर देता है - वे मेरे बाल पृष्ठों को "खोजने" के लिए 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
[...]

मैंने इसे विभिन्न विषयों के साथ आज़माया है, जिसमें ट्वेंटीवेट भी शामिल है, बस यह सुनिश्चित करने के लिए कि यह मेरी ओर से कुछ गायब टेम्पलेट नहीं है।

रीराइट नियम निरीक्षक का उपयोग करना, यह वही है जो यूआरएल के लिए दिखाता है: 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

यह फिर से लिखना उत्पादन मुझे विश्वास है कि निम्नलिखित "गैर सुंदर" permalink काम करेगा:

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

यह 404 नहीं है, लेकिन यह माता-पिता सीपीटी आइटम "न्यूज़लेटर" को दर्शाता है, बच्चे को नहीं। अनुरोध इस तरह दिखता है:

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

Answer 1

यह मेरा पहली बार स्टैक एक्सचेंज में भाग लेने का अवसर है, लेकिन मैं इसे एक बार जाऊंगा और देखूंगा कि क्या मैं आपको सही दिशा में इंगित करने में मदद कर सकता हूं।

डिफ़ॉल्ट रूप से, पदानुक्रमित CPT आपके द्वारा बताए गए तरीके से व्यवहार करता है। इस मामले में अद्वितीय स्लग उपसर्ग, "न्यूज़लेटर", फिर से लिखना इंजन को अलग-अलग पोस्ट प्रकारों के लिए अनुरोध बताने का तरीका बताने के लिए है।

वे CPT पंजीकरण ठीक लग रहे हैं, लेकिन जब CPT का अनुरोध किया जाता है, तो pagenameक्वेरी संस्करण का मान नहीं होना चाहिए और nameक्वेरी संस्करण newsletterयहाँ के समान होना चाहिए , इसलिए ऐसा प्रतीत होता है कि आपके सेटअप में कहीं न कहीं कोई विरोध है।

डिबग, रिवर्ट रूल्स इंस्पेक्टर प्लगइन को स्थापित और सक्रिय करने में मदद करने के लिए , फिर स्क्रीन पर " टूल्स -> रिस्ट्रिक्ट रूल्स " पर जाएं।

1. सूची को देखते हुए, समाचार पत्र सीपीटी के लिए आपके सभी नियम किसी भी पृष्ठ को फिर से लिखने से पहले सूचीबद्ध किए जाने चाहिए । सत्यापित करें कि यह " स्रोत " कॉलम को स्कैन करके मामला है ।
2. यदि वह जांच करता है, तो " मैच URL " फ़ील्ड में अपने "प्रथम-लेख" CPT के लिए URL इनपुट करें और "फ़िल्टर" बटन पर क्लिक करें यह देखने के लिए कि कौन सा नियम मिलान किया गया है। यह एक समाचार पत्र नियम और एक पृष्ठ नियम से मेल खाना चाहिए, लेकिन समाचार पत्र का नियम पहले होना चाहिए।

यदि वह किसी भी मुद्दे को प्रकट नहीं करता है, तो "पहले-लेख" स्लग के साथ अन्य पदों को खोजने के लिए post_nameकॉलम wp_postsको खोजें, अगर कोई टक्कर हो सकती है। "न्यूज़लेटर" के लिए भी एक खोज करें, बस सुनिश्चित करने के लिए।

जाँचने के अनुरोध में जल्दी से अपनी क्वेरी वार्स का निरीक्षण करने के लिए निम्नलिखित स्निपेट जोड़ें और देखें कि कौन से फिर से लिखना नियम मैच द्वारा सेट किए जा रहे हैं (सामने के छोर पर बच्चे सीपीटी पर जाएं)। यदि pagenameयह संस्करण यहां दिखाई नहीं देता है, तो यह बाद में अनुरोध द्वारा कुछ सेट किया जा रहा है:

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;
}

क्वेरी प्लग को संशोधित करने वाले कोई भी प्लगइन्स / फ़ंक्शन एक संघर्ष का कारण बन सकते हैं, इसलिए यदि आप अभी भी समस्या देखते हैं तो उन्हें अक्षम करें। प्रत्येक चरण के बाद अपने रीराइट नियमों को भी फ्लश करें, खासकर यदि अनुरोध ऊपर के दूसरे चरण में एक गलत नियम से मेल खा रहा था ("Permalinks" स्क्रीन को एक अलग टैब में खोलें और बस इसे ताज़ा करें)।

Comments

मैंने प्रश्न को फिर से लिखने वाले इंस्पेक्टर से आउटपुट दिखाने के लिए संपादित किया है, क्योंकि ये टिप्पणियां पर्याप्त प्रारूपण की अनुमति नहीं देती हैं। सीपीटी के लिए नियम सूची में सबसे ऊपर दिखाते हैं, इससे पहले कि कुछ भी हो - लेकिन यह सुनिश्चित नहीं है कि नीचे दिए गए कौन से नियम "पृष्ठ" नियम हैं (स्पष्ट नहीं)। इसके अलावा, post_nameकॉलम में कोई टक्कर नहीं ।

— दैहिक

क्या आपके पास उचित पर्मलिंक संरचना पर कोई विचार है? मैं तब से वापस चला गया हूं, /%postname%/जिसमें /%category%/केवल फिर से लिखना निरीक्षक में चीजों को भ्रमित करना शामिल है। मैंने लोगों को यह दावा करते हुए भी देखा है कि /%category%/सीपीटी के लिए "माता-पिता" का अर्थ जादुई है, हालांकि मुझे यह सच नहीं लगता।

— दैहिक

यह आउटपुट एक अलग प्लगइन के लिए आता है, यही कारण है कि आप नियम का "स्रोत" नहीं देखते हैं। किसी भी तरह से, ऐसा लगता है कि आपका नियम ठीक मेल खा रहा है। मैंने अपने उत्तर को एक स्निपेट शामिल करने के लिए संपादित किया है ताकि वे पहले से ही सही ढंग से सेट किए जा रहे हों, यह सुनिश्चित करने के अनुरोध में क्वेरी संस्करण का निरीक्षण करें।

— ब्रैडी वर्चर

पर्मलिंक संरचना के लिए, मैं श्रेणी को शामिल करने का प्रशंसक नहीं हूं। यह सिर्फ एक और गतिशील हिस्सा है जो कुछ भी मदद नहीं करता है, और पोस्ट कई श्रेणियों से संबंधित हो सकते हैं। अगर भविष्य में आपको कोई भी मौका मिलता है, तो आप भविष्य में पर्मलिंक संरचना को बदल सकते हैं या एक और सीपीटी चाहते हैं कि वह बिना किसी स्लग उपसर्ग के लोड हो सके, मैं आपकी संरचना को "नाम बदलने" की सलाह दूंगा जैसे कि कुछ निश्चित और अद्वितीय /blog/%postname%/।

— बजे ब्रैडी वर्चर

यह सही प्लगइन है, लेकिन दो पृष्ठ हैं: "विश्लेषक को फिर से लिखना" और "नियमों को फिर से लिखना", दोनों एक परीक्षण URL प्रदान करते हैं। मैंने दूसरे पृष्ठ की कोशिश की और इसने स्रोत को पहले इंडेंट किए गए समूह के लिए "प्रोग्राम" और दूसरे के लिए "पेज" के रूप में दिखाया।

— दैहिक

Answer 2

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 );
}

और /%postname%/मेरे लिए न्यूज़लैटर / पैरेंट / चाइल्ड ठीक काम कर रहा है।

Comments

ऊपर दिए गए मेरे कोड ने इसे नहीं दिखाया, लेकिन मेरे पास page-attributesसमर्थन में है (जो वास्तव में केवल पेरेंटेज को असाइन करने के लिए मेटाबॉक्स दिखाने के बारे में है, परमलिंक्स को प्रभावित नहीं करना चाहिए) - लेकिन 404 का मिलना। क्या पर्मलिंक संरचना सेट करने की आवश्यकता है? या फर्क पड़ता है?

— दैहिक

@somatic i ने इसे फिर से परीक्षण किया और इसके ठीक काम कर रहा है, जैसा कि पर्मलिंक के लिए मुझे यकीन नहीं है कि अगर यह बात होनी चाहिए, लेकिन किसी भी तरह से मैंने अपना जवाब अपडेट किया।

— बेनेटर्ट

मैं इस बात की पुष्टि कर सकता हूं कि 'लेबल' के लिए एक तर्क सरणी के अलावा (जिसके बिना सीपीटी व्यवस्थापक में प्रकट नहीं होगा), यह मूल उदाहरण WP3.5 के एक वेनिला इंस्टॉलेशन पर ट्वेंटीवेट के साथ काम करता है। लेकिन मैं आपके register_post_type$ args में कुछ प्रमुख अंतरों को देख रहा हूँ : मैंने उपयोग किया 'rewrite' => array( 'slug' => 'newsletter', 'with_front' => false ), जहाँ आपने अभी उपयोग किया है true। तुम भी बस से पारित कर दिया trueके लिए has_archiveहै, जहां मैं स्लग पारित कर दिया। हालाँकि, जब मैंने आपके आर्ग्स से मिलान किया, तब भी मुझे 404 मिले ... फिर भी मैं गलत होने की कोशिश कर रहा था।

— दैहिक

Answer 3

पूछने के अलावा »क्या आपने इसे बंद करने का प्रयास किया है?« , मुझे यह भी पूछना होगा "क्या आपके पास कोई प्लगइन्स सक्रिय है और क्या आपका थीम कुछ भी पर्मलिंक के लिए कर रहा है (उदाहरण के लिए: वर्गीकरण का पंजीकरण करना, पोस्ट प्रकार, पुनर्लेखन नियम जोड़ना , आदि।)?

यदि ऐसा है: क्या यह तब भी होता है, जब आप सभी प्लगइन्स को अक्षम कर लेते हैं और ट्वेंटीलेवेन में बदल जाते हैं?

आगे डिबग करने के लिए, GitHub पर जाएँ और टोस्चोस "रीराइट" प्लगिन को पकड़ें । फिर wp.org पर आधिकारिक प्लगइन रेपो पर स्विच करें और मंकी मैनराइट एनालाइजर प्लग इन को ग्रैप करें । मैं भी थोड़ा विस्तार के लिए एक साथ थोड़ा गोंद दोनों लिखा था। यह आपको आपके सेटअप के बारे में बहुत सारी जानकारी देगा।

Comments

ठीक है, अगर मैं सब कुछ अक्षम करता हूं, तो मेरे पास कस्टम पोस्ट प्रकार नहीं होगा जो इस प्रश्न का बिंदु है ... लेकिन हां, मैंने ट्वेंटीवेटव थीम के साथ भी कोशिश की है। मैं अभी भी कुछ आवश्यक प्लग के माध्यम से खुदाई कर रहा हूं, यह देखने के लिए कि क्वेरी क्या है, जैसा कि मैं देख सकता हूं, इससे पेरालिंक्स स्वयं अच्छी तरह से बनते हैं।

— दैहिक

@ एसओमैटिक ऑफ डिसएबल यू नॉट डिसेबल :)

— kaiser

@somatic अद्यतन देखें।

— कैसर

Answer 4

इसलिए यह पुष्टि करने के बाद कि मैं पूरी तरह से साफ इंस्टॉल और सिर्फ एक सीपीटी घोषणा के साथ अपेक्षित पदानुक्रमित पृष्ठ व्यवहार प्राप्त कर सकता हूं, मुझे पता था कि गलती मेरे ही प्लगइन के भीतर कहीं है जो मैं सीपीटी निर्माण (बहुत जटिल, हैंडल करने के लिए उपयोग करता हूं, कस्टम मेटाबेलेज़, टैक्सोनॉमीज़ को संभालता हूं) , आदि)। समस्या फिर से लिखने या क्वेरी समस्याओं के लिए जाँच करने की सभी सलाह के बावजूद, मैं स्पष्ट रूप से गलत कुछ भी नहीं देख सकता था। मैंने प्रत्येक फ़िल्टर और हुक की जाँच की, प्रत्येक बिंदु पर क्वेरी को देखा और ऐसा कुछ भी नहीं देखा जिससे 404 हो।

इसलिए मुझे 9 बड़ी कक्षाओं में से प्रत्येक को मैन्युअल रूप से अक्षम / सक्षम करने के कार्य के साथ छोड़ दिया गया था, और फिर, उनमें से कम से कम 2 को खोजने के लिए 404 का कारण बना, प्रत्येक फ़ंक्शन को एक-एक करके गुजरना और उन्हें सक्षम / सक्षम करना और फिर अनुरेखण रेखा। उन कार्यों के भीतर लाइन द्वारा - एक क्रूर बल प्रयास यह देखने का प्रयास करता है कि 404 क्या कारण था, भले ही मुझे पता नहीं था कि क्यों।

जब मैंने पाया कि उपयोग करने का एक परिणाम है $query->get_queried_object()। ऐसा लगता है कि यह आवरण समारोह वास्तव में $ क्वेरी को संशोधित करता है, जो मुझे लगा कि मैं अपने फ़ंक्शन के अंत में अपरिवर्तित लौट रहा था। 2 वर्गों में तीन फिल्टर शामिल थे कि क्वेरी संशोधित: parse_query, posts_orderby, posts_join- और कॉलबैक कार्यों के सभी बुला रहे थे $query->get_queried_object()पारित कर दिया पर $queryफिर आर्ग कुछ सशर्त परीक्षण चलाने के लिए और कभी कभी संशोधित क्वेरी (जैसे विशेष सॉर्ट क्रम मामलों के लिए) वार्स। अजीब पर्याप्त, इन कार्यों वास्तव में ठीक है कि वे क्या करने के लिए डिजाइन किए गए थे पर, काम के बावजूद फ़ंक्शन के उपयोग के । मैंने पहले कभी नहीं लौटा $ क्वेरी के साथ कुछ भी गलत नहीं देखा!

किसी तरह, दर्जनों लाइव उत्पादन साइटों पर विकास और उपयोग के एक वर्ष से अधिक के बाद, मुझे इस गलती से किसी भी प्रतिकूल प्रभाव का अनुभव नहीं हुआ। केवल जब मैंने पदानुक्रमित सीपीटी में भाग लिया, तो इस एक छोटे से अंतर ने अचानक चीजों को तोड़ दिया। यह इस बात का हिस्सा है कि मुझे इसके साथ कितना मुश्किल था - सबसे अच्छा मैं बता सकता था, मेरे क्वेरी फ़िल्टर भरोसेमंद थे!

मैं स्वीकार करता हूं कि मुझे अभी भी ठीक से पता नहीं है कि इस फ़ंक्शन को कॉल करने से सीपीटी चाइल्ड पेजों का सिर्फ एक छोटा पहलू टूट जाता है - और फिर भी कभी भी कोई अन्य समस्या सामने नहीं आई है! लेकिन यह स्पष्ट था कि एक फ़िल्टर कॉलबैक के भीतर इसका उपयोग करके लौटाया गया मंगा हुआ$query किसी तरह । इस कॉल को हटाने से, मेरी 404 त्रुटियां गायब हो गईं।

सभी युक्तियों के लिए धन्यवाद - काश मैं इनाम को विभाजित कर सकता, जैसा कि मैंने प्रत्येक उत्तर से अंतर्दृष्टि प्राप्त की, भले ही अंतिम समाधान कुछ हद तक संबंधित था। यह आपके कोड पर आंख मूंदकर भरोसा न करने का एक शैक्षिक पाठ रहा है, भले ही यह लंबे समय से आपके लिए मज़बूती से काम कर रहा हो, या यह कोई स्पष्ट त्रुटि उत्पन्न नहीं कर रहा है।

कभी-कभी, केसर के चार्ट के रूप में इतने करीने से अवतार लेते हैं, आपको बस स्विच को फेंकना शुरू करना होगा जब तक कि रोशनी वापस नहीं आती। मेरे मामले में, मुझे समस्या निवारण रणनीति को एक समारोह में व्यक्तिगत लाइनों के नीचे सभी तरह से लेना पड़ा, इससे पहले कि मैं समस्या देख सकूं।

Comments

आप ऑब्जेक्ट get_queried_object()को इंटरसेप्ट किए बिना रैपर फ़ंक्शन का भी उपयोग कर सकते हैं $wpdb।

— केसर

लेकिन जो $queryहड़प लेता है? मैं इसके लिए एक फिल्टर के भीतर का उपयोग कर रहा हूं parse_query, और विशेष रूप से एक विशिष्ट के क्वेरिड ऑब्जेक्ट को प्राप्त करने की आवश्यकता है $queryजो कि फिल्टर से पारित किया गया है ...

— दैहिक

मैं सिर्फ अपने फिल्टर के अंदर आवरण का उपयोग करने की कोशिश की parse_query। इसने फिर से वही 404 त्रुटियां पैदा कीं। मुझे लगता है कि get_queried_object()इन फिल्टरों को हटाने के बिना क्या करना है, इसे दोहराने का कोई तरीका मिल गया है ...

— दैहिक

Answer 5

क्या आप WP का सबसे वर्तमान संस्करण चला रहे हैं? मुझे लगता है कि यह पहला सवाल है (जैसे जब आप तकनीकी सहायता कहते हैं और वे आपसे पूछते हैं कि क्या आपका कंप्यूटर प्लग इन है?), क्योंकि मैंने पढ़ा है कि इस मुद्दे को सबसे वर्तमान संस्करण अद्यतन में संबोधित किया गया था।

Digwp.com पर एक पोस्ट है जो इस मुद्दे को संबोधित करता है (http://digwp.com/2011/06/dont-use-postname/)। जाहिरा तौर पर WP आसानी से पोस्ट और पेज के बीच अंतर नहीं बता सकता है, और यदि आप अपने यूआरएल को टेक्स्ट-आधारित विकल्प के साथ शुरू करते हैं, तो WP एक ध्वज को चलाता है जो आपके द्वारा बनाए गए प्रत्येक पेज / पोस्ट के लिए एक नियम बनाता है। यदि आपके पास अपनी साइट पर बहुत अधिक सामग्री है, तो इसके परिणामस्वरूप भारी संख्या में अनुरोध हो सकते हैं और आपका सर्वर संभवतः समय समाप्त कर देगा, जिसके परिणामस्वरूप 404 का एक गुच्छा होगा, भले ही पृष्ठ वहां हों।

इसलिए। यदि आप पहले नंबर आधारित संरचना का उपयोग करते हैं, तो आपका पाठ आधारित संरचना, मैं चाहूंगा कि आपका 404 मुद्दा हल हो जाए। अब, एसईओ मुद्दों पर विचार करते हुए, मैं एक तारीख संरचना का उपयोग नहीं करूंगा, लेकिन यह निर्णय लेना आपके लिए काफी तार्किक होगा।

Comments

मैं 3.5 पर हूं। WP3.3.1 के रूप में digiwp पर यह मुद्दा तय हो गया है।

— दैहिक