WooCommerce üst kategoride ürünler görünmüyor: gerçek sebepler

WooCommerce ürünleriniz üst kategori sayfalarında görünmüyorsa, her yerde tekrarlanan tavsiyeler — kalıcı bağlantıları yenileyin, önbelleği temizleyin, Storefront’a geçin — büyük olasılıkla öğleden sonranızı harcamaktan başka işe yaramaz. Çoğu durumda arşiv, tam olarak yapılandırıldığı şeyi yapmaktadır. WordPress bir üst kategori arşivine alt kategori ürünlerini varsayılan olarak zaten dahil eder; dolayısıyla “ürünlerin hepsi alt kategorilerde duruyor” tek başına bir açıklama değildir. Ya ürün döngüsünü bastıran ya da ürünleri döngünün dışında bırakan somut bir şey vardır ve gerçekçi aday sayısı yedi civarındadır.

Bu yazı adayları olasılık sırasına göre ele alıyor, bir geliştiricinin gerçekten çalıştıracağı kontrolleri veriyor ve çoğu kişinin aradığı kod parçasıyla bitiyor. O kod parçasının size neye mal olduğunu da dürüstçe anlatıyor.

Kısa cevap#

WordPress bir üst kategori arşivine alt kategori ürünlerini zaten dahil eder; bu yüzden boş bir üst kategorinin sebebi neredeyse her zaman kategorinin Görüntüleme türünün alt kategorilere ayarlanmış olmasıdır ya da ürünlerin katalogda gizli, stok dışı veya yayımlanmamış olmasıdır.

• Önce görüntüleme türüne bakın. “Alt kategorileri göster” olarak ayarlanmış bir kategori kutucukları basar ve döngü toplamını sıfıra çeker, yani ürünleri bilerek atar — önce terimin kendi Görüntüleme türünü, sonra Görünüm → Özelleştir → WooCommerce → Ürün Kataloğu altındaki site geneli varsayılanı kontrol edin.
• İkinci sırada katalog görünürlüğü. Gizli veya Yalnızca arama sonuçları olarak ayarlanan ürünler exclude-from-catalog terimini taşır ve arşivlerden düşer; bir CSV içe aktarımında yanlış eşlenen bir sütun da koca bir kategorinin bir anda boşalmasının alışılmış sebebidir.
• Üçüncü sırada stok dışı ürünleri gizleme. “Stokta olmayan ürünleri katalogdan gizle” seçeneği bu ürünleri hem arşivden hem de terim yeniden sayımlarından çıkarır; bir kategorinin boş olanları gizleyen bileşenlerden ve menülerden tamamen kaybolması da böyle olur.
• Dördüncü sırada ürün durumu. Taslak, incelemeyi bekleyen ve zamanlanmış ürünler kategori atamalarını korur ama ön yüzde hiç görünmez; özel ürünler ise yalnızca yöneticilere ve mağaza yöneticilerine işlenir — bu yüzden arşivi bir gizli pencerede açmak, durum kaynaklı bir sorunu sorgu kaynaklı bir sorundan ayırır.
• Sayılar listeleri açıklar, arşivleri değil. wc_term_counts geçici verisinde önbelleğe alınmış bayat sayılar yalnızca bir kategorinin kenar çubuğundan veya menüden eksik olmasını açıklar; WooCommerce → Durum → Araçlar altındaki Terimleri yeniden say işlemini çalıştırın, ama sayıyı asla boş bir sayfanın sebebi saymayın.

Önce iki belirtiyi birbirinden ayırın#

“Üst kategori hiçbir şey göstermiyor” cümlesi birbiriyle ilgisiz iki arızayı birden kapsıyor. Birincisi, arşiv şablonunun hiç ürün basmamasıdır. İkincisi, kategorinin kendisinin bir menüden, kenar çubuğu bileşeninden veya kategori bloğundan kaybolmasıdır. Sebepleri de çözümleri de farklıdır; forumlardaki bunca konunun kırk yanıt boyunca hiçbir şeyi çözemeden sürüklenmesinin sebebi de bu ikisini birbirine karıştırmaktır.

“Ürünler üst kategoride görünmüyor” bildirimlerinin çoğunun arkasındaki ayar#

WooCommerce’in kategori başına bir Görüntüleme türü ayarı, bir de site geneli varsayılanı vardır. Bunlardan biri alt kategorilere çözümlüyorsa, o arşivdeki ürün döngüsü bilerek boşaltılır.

Site geneli ayar Görünüm → Özelleştir → WooCommerce → Ürün Kataloğu → Kategori görünümü altındadır ve üç seçeneği vardır: Ürünleri göster, Alt kategorileri göster ve Alt kategorileri & ürünleri göster. woocommerce_category_archive_display seçeneği olarak saklanır. Kategori başına geçersiz kılma ise terim düzenleme ekranında, Ürünler → Kategoriler → (bir kategoriyi düzenleyin) → Görüntüleme türü altında durur; Varsayılan, Ürünler, Alt kategoriler ve Her ikisi seçeneklerini sunar ve display_type terim meta verisi olarak saklanır. Terim meta verisi kazanır; seçeneğe yalnızca terim meta verisi boşken bakılır.

Çözümlenen değer subcategories olduğunda woocommerce_maybe_show_product_subcategories() kategori kutucuklarını basar, wc_set_loop_prop( 'total', 0 ) ile döngü toplamını sıfırlar ve ana sorgu söz konusuysa post_count ile max_num_pages değerlerini de $wp_query üzerinde sıfırlar; böylece döngü özelliklerine hiç bakmadan ürün basan temalar da hiçbir şey göstermez. Ürünler çekilmiştir. Sonra bilerek atılmıştır.

İki ayrıntı bunu fark etmeyi zorlaştırır. Birincisi, bastırma yalnızca gerçekten alt kategori varsa devreye girer; terimin alt terimi yoksa woocommerce_get_loop_display_mode() products değerine düşer, yani aynı ayar farklı kategorilerde farklı davranır. İkincisi, alt kategorileri gösterecek şekilde ayarlanmış bir üst kategori görsel olarak makul durur: sayfa kutucuklarla doludur, bariz biçimde bozuk görünmez. İkisini birden istiyorsanız kod yazmak yerine görüntüleme türünü Her ikisi yapın.

Efsane: üst kategoriler alt kategori ürünlerini “dışlamaz”#

İnternette en çok tekrarlanan açıklama, WooCommerce’in yalnızca doğrudan atanmış ürünleri gösterdiği, dolayısıyla tüm stoku alt kategorilerinde duran bir üst kategorinin haklı olarak boş kaldığıdır. İşleyiş böyle değildir ve buna göre hareket etmek, insanları hiç gereği yokken her ürünü üst kategoriye de kopyalamaya iter.

product_cat hiyerarşik bir taksonomi olarak kaydedilir. Bir taksonomi arşivinde WP_Tax_Query, include_children değerini varsayılan olarak true kabul eder; hiyerarşik bir taksonomide bu, üretilen SQL’in sorgulanan terimle ve onun bütün alt terimleriyle eşleşmesi demektir. Üst kategori arşivi, alt kategori ürünlerini hiçbir ayar yapmadan içerir.

Sayılar da aynı kurala uyar. WooCommerce product_cat taksonomisini 'update_count_callback' => '_wc_term_recount' ile kaydeder; hiyerarşik bir taksonomide bu fonksiyon her terimin üst terimlerini işin içine katar ve alt terimleri sayar, yani bir üst kategorinin sayısı yalnızca alt kategorilerinde duran ürünleri de kapsar. Uzun süredir bilinen bir tuhaflığın kaynağı da budur: bir alt kategoriyi bir üst kategoriden başkasına taşıyın, eski üst kategori onun ürünlerini saymayı sürdürebilir; bu durum #25491 numaralı kayıtta bildirilmiştir.

Yani bir üst kategori arşivi boşsa sebep alt kategoriler değildir. Listede aşağı inmeye devam edin.

Geri kalanı, olasılık sırasıyla#

Katalog görünürlüğü gizli ya da yalnızca arama olarak ayarlı#

Her ürünün Yayımla kutusunda bir Katalog görünürlüğü ayarı vardır: Mağaza ve arama sonuçları, Yalnızca mağaza, Yalnızca arama sonuçları, Gizli. Son ikisi ürüne bir exclude-from-catalog terimi iliştirir; bu terim gizli product_visibility taksonomisinden gelir. WC_Query::get_tax_query() de katalog ve arşiv sorgularına bunun için bir NOT IN koşulu ekler. Ürün kategorisini korumaya devam eder. Yönetim panelinde o kategoriye göre filtrelenmiş ürün listesinde de görünür. Ama arşivde asla görünmez.

Yalnızca mağaza seçeneğinin bunun yerine exclude-from-search iliştirdiğini ve bunun bir kategori arşivini etkilemediğini not edin — yani boş bir sayfayı yalnızca son iki seçenek açıklar. Bir içe aktarımdan sonra gerçekten bomboş kalan bir kategorinin en yaygın tek sebebi budur, çünkü birçok CSV içe aktarıcısı ve göç aracı görünürlüğü satır satır belirler ve hatalı bir sütun eşlemesi bunu her ürüne birden uygular.

Stok dışı ürünleri gizleme#

WooCommerce → Ayarlar → Ürünler → Envanter → Stok dışı görünürlüğü, “Stokta olmayan ürünleri katalogdan gizle” etiketli onay kutusudur ve woocommerce_hide_out_of_stock_items olarak saklanır. Kutu işaretliyken outofstock görünürlük terimi de aynı NOT IN dışlama listesine katılır; kimse tek bir ürüne dokunmadan sezonluk bir kategori kendi kendini tamamen boşaltır.

Ayar terim sayımını da besler: seçenek açıkken _wc_term_recount() stok dışı ürünleri hesabın dışında bırakır. Bir kategorinin kenar çubuğu bileşeninden tümüyle yok olması da böyle olur — sayı sıfıra düşer ve boş olanları gizleyen her şey o kategoriyi listelemeyi bırakır. Bu ürünleri gizlemek yerine arşivin sonuna itmek genelde daha iyi bir denge kurar; stok dışı ürünleri en sona almak hem kategoriyi dolu tutar hem de sayıyı dürüst tutar.

Ürün durumu#

Taslak, incelemeyi bekleyen ve zamanlanmış ürünler kategori atamalarını korur ve yönetim listesinde görünür, ama ön yüzde asla görünmez. Özel ürünler bunun daha sinsi biçimidir: yalnızca read_private_products yetkisi olanlara, yani yöneticilere ve mağaza yöneticilerine işlenir, başka kimseye işlenmez. “Bende çalışıyor, müşteride boş” bildirimlerinin kaynağı budur. Başka bir şeyi teşhis etmeden önce her zaman gizli pencerede doğrulayın.

Bayat terim sayıları#

Bu yalnızca listeleri ve sayıları etkiler, arşivin kendisini asla etkilemez — ama bir üst kategorinin sayfası hâlâ çalışırken gezinme menüsünden kaybolmasının sebebi budur.

Ön yüzde WooCommerce, wc_change_term_counts() aracılığıyla kendi sayılarını devreye sokar. Bu fonksiyon yönetim panelinde ve AJAX istekleri sırasında erkenden geri döner, product_count_product_cat terim meta verisini okur ve sonucu wc_term_counts adında bir geçici veride MONTH_IN_SECONDS boyunca önbelleğe alır. Geçici veri _wc_term_recount() fonksiyonunun sonunda silinir. Ürünler yeniden sayımı hiç tetiklemeyen bir yoldan değiştirilirse — doğrudan SQL, kötü yazılmış bir içe aktarıcı ya da sadece bir görünürlük ayarını açıp kapatmak — hem meta veri hem de geçici veri eski cevabı tutmaya devam eder. WooCommerce’in kendi araçlar sayfası bu konuda açık sözlüdür: WooCommerce → Durum → Araçlar altındaki Terimleri yeniden say işlemi, ayarları ürünleri katalogdan gizleyecek şekilde değiştirdiğinizde faydalı olarak tarif edilir.

Bu davranış yıllar içinde defalarca bildirildi; örneğin önbelleğe alınmış sayıların hiç tazelenmeden süresiz sunulduğu #5204 numaralı kayıt ve bir kategori bir ürüne atandıktan sonra kategori sayısının güncellenmediği #13191 numaralı kayıt. Yönetim panelindeki Sayı sütununun aslında ne anlama geldiğini bilmekte de fayda var: “bu kategorideki ürünler” değil, “bu kategorideki veya altındaki yayımlanmış, katalogda görünür ürünler”.

product_cat taksonomisini paylaşan başka bir yazı türü#

Bazı eklentiler ve bir hayli özel yazılmış kod, taksonomiyi yeniden kullanmak için product_cat üzerine fazladan bir yazı türü kaydeder. Bu durumda sayılar artık kataloğunuzu tarif etmez: #27268 numaralı kayıt, yönetim panelindeki kategori sayılarının bambaşka bir türdeki gönderilerle şişttiğini bildiriyor. Siteyi devraldıysanız, herhangi bir sayıya güvenmeden önce taksonomiye neyin bağlı olduğunu get_taxonomy( 'product_cat' )->object_type ile kontrol edin.

Toplu düzenleme kayması#

Toplu Düzenle yalnızca kategori ekler; işaret listesinde bir kategoriyi kaldırmanın yolu yoktur. Hızlı Düzenle kaldırabilir ama tek seferde tek ürün için. Birkaç yeniden düzenlemenin ardından elinizde kimsenin istemediği kategorilerde duran, taşınmaları gereken kategorilerde ise bulunmayan ürünler kalır. Durumunuz buysa çözüm teknik değil yöntemseldir — tekrarlanabilir bir yaklaşım için ürünleri kategorilere toplu atama yazısına bakın.

Teşhis sırası#

Bunları sırasıyla çalıştırın. Her adım tek bir ayarı değil, bir grup sebebi birden eler.

1. Arşivi gizli bir pencerede açın. Ürünler görünüyorsa elinizde sorgu sorunu değil, durum ya da görünürlük sorunu var.
2. Terimdeki Görüntüleme türünü kontrol edin. Açıkça Ürünler olarak ayarlayıp sayfayı yenileyin. Ürünler görünüyorsa iş bitmiştir — Ürünler ile Her ikisi arasında karar verin ve Özelleştirici varsayılanını da buna göre ayarlayın.
3. Kategoride gerçekte ne olduğunu veritabanına sorun; görünürlüğü tamamen yok sayarak.

wp post list --post_type=product --product_cat=outerwear 
  --post_status=any --fields=ID,post_title,post_status

product_cat, taksonominin kayıtlı sorgu değişkenidir ve taksonomi hiyerarşik olduğu için sonuç alt kategori ürünlerini de içerir. Boş bir sonuç, atamaların yanlış olduğu anlamına gelir; ne kadar şablon uğraşırsanız uğraşın bir şey değişmez. Her satırında draft yazan uzun bir sonuç ise soruyu kendi başına yanıtlar.

4. Bunu saklanan sayılarla karşılaştırın. Buradaki bir uyuşmazlık arşivi değil, yeniden sayımı işaret eder.

wp term list product_cat --fields=term_id,name,slug,parent,count
wp transient delete wc_term_counts

Ardından WooCommerce → Durum → Araçlar altından Terimleri yeniden say işlemini çalıştırın; bu işlem product_count_product_cat terim meta verisini yeniden kurar ve geçici veriyi düzgünce temizler. Alttaki meta veri yanlışsa geçici veriyi elle silmek size yalnızca tek bir sayfa yüklemesi kazandırır.

5. Hâlâ boşsa SQL’i okuyun. Bu, gerçek terim listesini ve görünürlük dışlamalarını tek satırda gösterir; hangi eklentinin neyi filtrelediğini tahmin etmeye çalışmaktan iyidir.

add_filter( 'posts_clauses', function ( $clauses, $query ) {
	if ( ! is_admin() && $query->is_main_query() && is_product_category() ) {
		error_log( 'WHERE: ' . $clauses['where'] );
	}
	return $clauses;
}, 999, 2 );

Sağlıklı bir üst kategori arşivinde WHERE koşulu, term_taxonomy_id değerlerinden oluşan bir IN listesi — üst terim ve bütün alt terimleri — ve görünürlük terimlerini tutan bir NOT IN listesi içerir. IN listesinde tek bir terim kimliği varsa, bir şey include_children değerini false yapmıştır. Şüpheli ölçüde uzun bir NOT IN listesi ise haberiniz olmayan bir görünürlük filtresi demektir. Üstüne bir yama daha eklemek yerine sorumlu eklentiyi bulun.

Tersini istiyorsanız: üst kategori yalnızca kendi ürünlerini göstersin#

Alt kategorilerin varsayılan olarak dahil edildiğini öğrendikten sonra talep genellikle tersine döner. Derin bir ağacı olan mağazalar çoğu zaman üst kategorinin yalnızca doğrudan atanmış ürünleri göstermesini ister; böylece “Dış Giyim” sitedeki her montun listesi değil, seçilmiş bir derleme olur. Ayrıştırılmış taksonomi sorgusunu değiştirin:

add_action( 'parse_tax_query', function ( $query ) {
	if ( is_admin() || ! $query->is_main_query() ) {
		return;
	}
	if ( empty( $query->tax_query->queries ) ) {
		return;
	}
	foreach ( $query->tax_query->queries as $i => $clause ) {
		if ( isset( $clause['taxonomy'] ) && 'product_cat' === $clause['taxonomy'] ) {
			$query->tax_query->queries[ $i ]['include_children'] = false;
		}
	}
} );

Kanca, WP_Query kendi WP_Tax_Query nesnesini kurduktan sonra ama SQL üretilmeden önce çalışır; queries dizisini yerinde düzenlemenin işe yaramasının sebebi budur. Yine de bedeli konusunda net olun. _wc_term_recount() alt terimleri saymayı sürdürür, yani menülerde, bileşenlerde ve yönetim listesinde kategorinin yanındaki sayı artık sayfadaki ürün sayısıyla uyuşmayacaktır. Katmanlı gezinme sayıları da aynı şekilde kayar, çünkü sizin değiştirdiğiniz sorgudan değil aynı terim verisinden türetilirler. Sayımı yalnızca doğrudan atananlarla sınırlayan desteklenen bir filtre yok; yeniden sayımı baştan yazmanız gerekir ki bu gerçek bir bakım yüküdür.

Eskiden yüzlerce ürün gösteren bir üst kategorinin artık bir avuç ürün göstermesi yalnızca bir düzen değişikliği değil, gerçek bir sıralama değişikliğidir. Üst kategorinin organik trafiği varsa, buna da diğer kategori yapısı değişiklikleri gibi yaklaşın ve sonrasında sayfaları izleyin — içerik bakımından zayıf kategori arşivleri, dizine eklenmeyen kategori sayfaları ile sonuçlanmanın en kestirme yollarından biridir.

Asıl sorun kaymanın kendisi olduğunda#

Yukarıdaki listeyi baştan sona işleyince bir şey açığa çıkar. Görüntüleme türü sizin seçtiğiniz bir ayardır. Katalog görünürlüğü ürünün üzerindeki bir değerdir. Bayat sayılar bir önbellektir. Ama toplu düzenleme kayması, eski bir kategoride mahsur kalmış ürünler, geçen çeyrek dolu görünürken şimdi cılız duran bir üst kategori — bunların hepsi aynı arızadır: kategori üyeliği elle bakılan bir durumdur ve elle bakılan durum, tarif etmesi gereken katalogdan zamanla uzaklaşır.

Kayma ara sıra oluyorsa, yukarıdaki WP-CLI komutlarıyla üç ayda bir yapılan bir denetim fazlasıyla yeterlidir ve bir eklenti daha kurmaktan ucuzdur. Öngörülebilir bir kaymaysa — £20 altındaki her şey, bu ay yayımlanan her şey — kendi kurallarınızdan wp_set_object_terms() çağıran küçük ve zamanlanmış bir betik işi görür ve sürüm kontrolünde kalır. Ancak kurallar, o betiği sürdürmek başlı başına bir projeye dönüşecek kadar karmaşıklaştığında bir eklenti daha iyi bir tercih olur.

Bizim Smart Categories for WooCommerce eklentimiz bu son yolu izliyor. Mevcut bir product_cat terimine bir kural kümesi bağlıyorsunuz — 35 eşleşme alanı üzerinde iç içe AND/OR/NOT grupları, kaydetmeden önce eşleşen ürünlerin ve sayılarının canlı önizlemesiyle birlikte — ve eşleşen ürünlere gerçek terim arka planda Action Scheduler üzerinden atanıyor. Gerçek terim olduğu için sayılar, breadcrumb bağlantıları ve menüler tam olarak bu yazıda anlatıldığı gibi davranıyor. Eklenti; ürün oluşturulduğunda veya güncellendiğinde, fiyat ya da stok değiştiğinde ve günlük bir taramada yeniden değerlendirme yapıyor ve yalnızca kendi oluşturduğu üyelikleri kaldırıyor, yani elle yapılan atamalar yerinde kalıyor. Aynı mantık, kendiniz yazsanız da hazır kursanız da genel olarak kural tabanlı kategori atama için geçerli.

Bu sayfadaki diğer sebepleri çözmez ve bunu açıkça söylemekte fayda var. Görüntüleme türünü değiştirmez, WooCommerce’in sayma mantığını değiştirmez, katalog görünürlüğüne dokunmaz ve bir ağacı yeniden yapılandırdığınızda yönlendirme oluşturmaz. Bunlar WooCommerce ayarı olarak kalır; yönlendirmeler ve meta etiketleri de SEO eklentinizin işi olarak kalır.

Kısa özet#

Üst kategori arşivi alt kategori ürünlerini zaten içerir ve sayısı da alt terimleri zaten kapsar. Bu yüzden sayfa boşsa önce görüntüleme türünü, ikinci olarak katalog görünürlüğünü, üçüncü olarak stok dışı ürünleri gizleme ayarını, dördüncü olarak ürün durumunu ve en son terim sayısını kontrol edin — çünkü sayı yalnızca bir kategorinin listede eksik olmasını açıklar, boş bir arşivi asla. Bunların her biri, birinin bir kez ayarlayıp kimsenin bir daha dönüp bakmadığı bir durum parçasıdır. Asıl hata budur ve etrafında tasarım yapmaya değen de budur.