Hiyerarşik özel yazı türü kalıcı bağlantılarının tıpkı sayfalar gibi çalışmasını sağlama

Burada özel soru türü kalıcı bağlantılar hakkında her soru kazdık, ama çoğu ya özel taksonomi yeniden yazma sorunları ya da flush_rewrite_rules () bariz eksik gibi görünüyor. Ama benim durumumda, hiyerarşik olarak ayarlanmış özel bir yazı türü (sınıflandırma yok) kullanıyorum (böylece üst-alt ilişkilerini atayabilirim), metabox, vb. yeniden yazma kurallarını binlerce farklı yoldan sildim. Farklı kalıcı bağlantı yapılarını denedim. Ancak alt URL'ler her zaman 404 ile sonuçlanır!

Başlangıçta "üst" ve "alt" öğeleri (p2p kullanarak) için bağımsız özel yazı türlerim vardı ve muhtemelen "ebeveyn" gruplaması için bir sınıflandırma kullanmakta sorun yaşamazdım - bunların anlamsal olarak daha doğru olacağını biliyorum. Ancak istemci için, yöneticiler de tıpkı sayfalar gibi "gönderiler" görüntülendiğinde hiyerarşiyi görselleştirmek en kolay yoldur: çocukların ebeveynin altında, "-" ön ekinde ve uygun sipariş. Ayrıca sürükle-bırak yöntemiyle sipariş atamak için çeşitli yöntemler kullanılabilir. Taksonomi (veya p2p) yoluyla gruplama, yönetim listelerinde görsel olarak açık olmayan düz bir "gönderiler" listesi ile sonuçlanır.

Sonra ne olduğumu tam anlamıyla çekirdek "sayfaları" ile aynı davranış, ama benim özel yazı türü ile. Ben yazı tipini beklediğim gibi kaydettim ve yönetici mükemmel çalışıyor - Ben her bülten "yazı" için bir üst ve bir menu_order atayabilir, onlar düzenleme listelerinde doğru görünür:

Spring 2012
— First Article
— Second Article

Ve bunların kalıcı bağlantıları düzgün bir şekilde inşa edilmiş gibi görünüyor . Aslında, yapı hakkında bir şey değiştirirsem veya yazı türünü kaydederken yeniden yazma sümüğünü değiştirirsem, otomatik olarak doğru şekilde güncellenir, bu yüzden bir şeyin çalıştığını biliyorum:

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

Ben de hiyerarşik ilişkileri oluşturulan standart çekirdek "sayfaları" var, ve onlar sadece aynı yönetici görünüyor, ama onlar aslında ön uç üzerinde de çalışır (hem üst hem de alt URL iyi çalışır).

Kalıcı bağlantı yapım şu şekilde ayarlanmış:

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

Bunu da denedim (sadece başka birçok yanıtın gerekli olduğunu belirtmiş gibi göründü, ancak benim durumumda anlamlı değildi):

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

Kayıt CPT değişkenlerim şunları içerir:

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

Özel yazı türü çocuklarım ve normal sayfa çocuklarım arasındaki tek görünür fark , CPT'mün kalıcı bağlantı yapısının başında sümüklüğe sahip olması, ardından ebeveyn / çocuk sümüklü böcekleri (sayfaların ebeveyn / çocuk sümüklü böceklerle başladığı, "önek" yok). Bu niye falan oluyor, bilmiyorum. Pek çok makale, böyle hiyerarşik CPT kalıcı bağlantılarının tam olarak böyle davranması gerektiğini gösteriyor - ama benimki iyi biçimlendirilmiş olsa da işe yaramıyor.

Beni de şaşırtan şey, o 404 sayfası için query_vars'ı incelediğimde - WP'nin alt sayfalarımı "bulması" için doğru değerleri içerdikleri görünüyor, ancak bir şey çalışmıyor.

$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
[...]

Ben sadece benim eksik bazı şablon olmadığından emin olmak için, yirmili kurt da dahil olmak üzere çeşitli temalar ile denedim.

Yeniden Yazım Kuralları Denetçisi'ni kullanarak, URL için görünen şey şudur: 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: 

başka bir denetçi sayfasında nasıl görüntülendiğini:

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

Bu yeniden yazma çıktısı, aşağıdaki "hoş olmayan" kalıcı bağlantının işe yarayacağına inanmamı sağlayacaktır:

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

404 değil, üst CPT öğesini "bülten" olarak gösterir, alt öğe değil. İstek şu şekildedir:

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

Bu benim ilk kez Stack Exchange'e katılıyor, ama bunu bir deneyeceğim ve sizi doğru yöne yönlendirmeye yardımcı olup olamayacağımı göreceğim.

Varsayılan olarak, hiyerarşik CPT'ler tam olarak tanımladığınız şekilde davranır. Bu durumda benzersiz slug öneki "bülten", yeniden yazma motoruna farklı yazı türleri için istekleri nasıl anlatacağını bildirmektir.

Bu CPT kayıt argümanları iyi görünüyor, ancak bir CPT istendiğinde, pagenamesorgu var değeri nameolmamalı ve sorgu var newsletterburada olduğu gibi olmalıdır , bu yüzden kurulumunuzda bir çakışma var gibi görünüyor.

Hata ayıklamaya yardımcı olmak için Kuralları Yeniden Yazma Denetçisi Eklentisini yükleyin ve etkinleştirin , ardından " Araçlar -> Kuralları Yeniden Yaz " ekranını ziyaret edin .

1. Listeye bakarken, haber bülteni CPT ile ilgili tüm kurallarınız herhangi bir sayfa yeniden yazma kuralından önce listelenmelidir . " Kaynak " sütununu tarayarak durumun bu olduğunu doğrulayın .
2. Bu kontrol edilirse, " URL'yi Eşleştir " alanına "ilk makale" CPT'nizin URL'sini girin ve hangi kuralın eşleştiğini görmek için "Filtre" düğmesini tıklayın. Bir bülten kuralı ve bir sayfa kuralıyla eşleşmelidir, ancak önce bülten kuralı olmalıdır.

Bu herhangi bir sorun ortaya çıkarmazsa, bir çarpışma olup olmadığını görmek için "ilk makale" sümüklü diğer yayınları bulmak için post_namesütunda arama yapın wp_posts. Emin olmak için "haber bülteni" için de arama yapın.

Sorgu değişkenlerinizi incelemek için aşağıdaki snippet'i, yeniden yazma kuralı eşleşmesi tarafından hangilerinin ayarlandığını kontrol etme ve görme isteğinin başlarında ekleyin (ön uçtaki alt CPT'yi ziyaret edin). Eğer pagenamevar burada görünmüyorsa, o zaman sonradan talebinde şey tarafından belirlenen varlık:

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

Sorgu değişkenlerini değiştiren herhangi bir eklenti / işlev çakışmaya neden olabilir, bu nedenle hala sorun görüyorsanız bunları devre dışı bırakın. Ayrıca, özellikle istek yukarıdaki ikinci adımda yanlış bir kuralla eşleşiyorsa, her adımdan sonra yeniden yazma kurallarınızı yıkayın ("Kalıcı Bağlantılar" ekranını ayrı bir sekmede açık tutun ve sadece yenileyin).

parent/ChildPermalink sette sürece kutunun dışında Works

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

Güncelleme:

Ben sadece tekrar test ve bu test durumda, beklendiği gibi çalışır:

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

ve kalıcı bağlantı /%postname%/bülten / ebeveyn / çocuk düzgün çalışıyor olsun olarak ayarlanmış .

" Tekrar kapatıp açmayı denediniz mi?" Sorusunun yanı sıra, "Etkin herhangi bir eklentiniz var mı ve Temanız kalıcı bağlantılara bir şey yapıyor mu (örneğin: sınıflandırma kaydı, posta türleri ekleme, yeniden yazma kuralları ekleme) , vb.)?

Öyleyse: Bu, tüm eklentileri devre dışı bırakıp TwentyEleven'a geçtikten sonra da oluyor mu?

Daha fazla hata ayıklamak için GitHub'a gidin ve Toschos "Yeniden Yaz" Eklentisini alın . Ardından wp.org adresindeki resmi eklenti deposuna geçin ve MonkeyManRewriteAnalyzer Eklentisi'ni alın . Hatta her ikisini birlikte yapıştırmak için küçük bir uzantı bile yazdım. Bu size kurulumunuzla ilgili birçok ayrıntı verecektir.

Tamamen temiz bir yükleme ve sadece tek bir CPT bildirimi ile beklenen hiyerarşik sayfa davranışını alabileceğimi doğruladıktan sonra, hatanın CPT oluşturma işlemini (çok karmaşık, özel meta kutuları, taksonomileri ele almak için kullandığım) kendi eklentim içinde bir yerde olduğunu biliyordum , vb). Sorun, yeniden yazma veya sorgu sorunlarını kontrol etmek için tüm tavsiyelere rağmen, açıkça yanlış bir şey göremedim oldu. Her filtreyi ve kancayı kontrol ettim, her noktada sorguyu gördüm ve 404'e neden olacak hiçbir şey görmedim.

Bu yüzden 9 büyük sınıfın her birini manuel olarak devre dışı bırakma / etkinleştirme ve daha sonra bunların en az 2 tanesinin 404'e neden olmasını bulma, her bir işlevi tek tek geçme ve devre dışı bırakma / etkinleştirme ve ardından çizgi izleme görevinden ayrıldım. bu fonksiyonlar içinde sıralı olarak - nedenini bilmesem bile 404'e neyin sebep olduğunu tam olarak görmeye çalışır.

İşte o zaman kullanmanın bir sonucu olduğunu gördüm $query->get_queried_object(). Bu sarmalayıcı işlevini kullanarak aslında benim işlev sonunda değişmeden döndüğünü düşündüm $ query kendisi değiştirir gibi görünüyor. 2 sınıflar arasında üç filtreleri sorgu değiştirilmiş olduğu tutulmuştu: parse_query, posts_orderby, posts_join- ve geri arama fonksiyonları tüm sesleniyordun $query->get_queried_object()geçti üzerine $querysorgu (özel sıralama düzeni durumlar için benzeri) vars değiştirmek bazen bazı koşullu testler ve sonra arg. Garip bir şekilde, bu işlevleri kullanmama rağmen , aslında tasarlandıkları şeyde iyi çalıştı . Daha önce dönen $ sorgusu ile yanlış bir şey fark ettim!

Her nasılsa, düzinelerce canlı prodüksiyon sitesinde bir yıldan fazla bir süredir geliştirme ve kullanımdan sonra, bu hatadan hiçbir zaman olumsuz etkiler yaşamamıştım. Sadece hiyerarşik CPT'lere girdiğimde, bu küçük fark aniden bazı şeyleri kırdı. Bu beni bu kadar zor atan bir parçası - en iyi söyleyebileceğim gibi, sorgu filtrelerim güvenilir!

İtiraf ediyorum ki neden hala bu işlevi çağırmanın CPT alt sayfalarının sadece bu küçük bir yönünü bozduğunu tam olarak bilmiyorum - ve yine de başka hiçbir problemle karşılaşmadım! Ancak, bir filtre geri çağrısında kullanmanın, bir $queryşekilde geri döndüğünü açıktı . Bu aramayı kaldırarak 404 hatalarım kayboldu.

Tüm ipuçları için teşekkürler - nihai çözüm biraz ilgisiz olsa bile, her cevaptan içgörü kazandığım için ödülün bölünebilmesini diliyorum. Bu, sizin için uzun süre güvenilir bir şekilde çalışıyor olsa da veya bariz hatalar oluşturmasa bile, kodunuza körü körüne güvenmeme konusunda bir eğitim dersi olmuştur.

Bazen, kaiser grafiği çok düzgün bir şekilde somutlaştığından, ışıklar yanana kadar anahtar atmaya başlamanız gerekir. Benim durumumda, problemi görmeden önce aynı sorun giderme stratejisini bir fonksiyondaki münferit satırlara kadar götürmek zorunda kaldım.

WP'nin en güncel sürümünü mü kullanıyorsunuz? Sanırım ilk soru (teknik desteği aradığınızda ve bilgisayarınızın takılı olup olmadığını sormanız gibi!), Çünkü bu sorunun en güncel sürüm güncellemesinde giderildiğini okudum.

Digwp.com'da bu sorunu ele alan bir yazı var (http://digwp.com/2011/06/dont-use-postname/). Görünüşe göre WP, yazı ve sayfalar arasındaki farkı kolayca söyleyemez ve URL'lerinizi metin tabanlı bir seçenekle başlatırsanız, WP sahip olduğunuz her sayfa / yazı için kural oluşturan bir bayrağı tetikler. Sitenizde çok fazla içeriğiniz varsa, bu çok sayıda isteğe neden olabilir ve sunucunuz zaman aşımına uğrayacaktır, bu da sayfalar olsa bile 404'lük bir grupla sonuçlanacaktır.

Yani. Önce sayı tabanlı bir yapı, sonra metin tabanlı yapı kullanırsanız, 404 sorununun çözüleceğinden emin olurum. Şimdi, SEO sorunları göz önüne alındığında, bir tarih yapısı kullanmazdım, ancak bu kararı vermek sizin için yeterince mantıklı olacaktır.