Şimdi bu konunun üzerinde günler olmuştur. Başlangıçta, bir kullanıcının takipçi verilerini veritabanında nasıl saklayacağımı, burada WordPress Cevaplarında birkaç güzel öneri aldım. Sonra önerileri izleyerek buna benzer yeni bir tablo ekledim:

id  leader_id   follower_id
1   2           4
2   3           10
3   2           10

Yukarıdaki tabloda, ilk satırda 4 kimliği olan bir kullanıcı tarafından takip edilen 2 kimliği olan bir kullanıcı var. İkinci satırda kimliği 3 olan bir kullanıcı takip eden kimliği olan bir kullanıcı tarafından takip ediliyor. 10. Aynı mantık üçüncü satır için de geçerlidir.

Şimdi, aslında WP_Query'yi genişletmek istiyorum, böylece yalnızca bir kullanıcının liderleri tarafından alınan gönderileri sınırlayabilirim. Bu nedenle, yukarıdaki tabloyu dikkate alarak, eğer kullanıcı kimliğimi 10 WP_Query'ye geçireceksem, sonuçlar sadece kullanıcı kimliği 2 ve kullanıcı kimliği 3 tarafından gönderilen mesajları içermelidir.

Bir cevap bulmaya çalışırken çok şey aradım. Ayrıca WP_Query sınıfını nasıl genişleteceğimi anlamama yardımcı olacak herhangi bir eğitim görmedim. Mike Schinkel'in cevaplarını (WP_Query'yi) benzer sorulara uzatarak gördüm, ancak bunu ihtiyaçlarıma nasıl uygulayacağımı gerçekten anlamadım. Biri bu konuda bana yardımcı olsaydı çok iyi olurdu.

Mike'ın cevabına istenen bağlantı : Bağlantı 1 , Bağlantı 2

Önemli feragatname: Bunu yapmanın doğru yolu tablonuzun yapısını değiştirmemek, wp_usermeta kullanmaktır. Daha sonra, yazılarınızı sorgulamak için herhangi bir özel SQL oluşturmanız gerekmez (yine de, örneğin Yönetici bölümünde, belirli bir amirine rapor veren herkesin listesini almak için bazı özel SQL'lere ihtiyacınız olacaktır). Bununla birlikte, OP özel SQL yazma hakkında sorular sorduğundan, özel SQL'i mevcut bir WordPress Sorgusu'na enjekte etmek için en iyi yöntem budur.

Karmaşık birleştirme yapıyorsanız, posts_where filtresini kullanamazsınız, çünkü birleşim, seçim ve muhtemelen grubu sorgunun bölümlerine göre veya sırayla değiştirmeniz gerekir.

En iyisi 'posts_clauses' filtresini kullanmak. Bu, WordPress çekirdeğindeki birçok kod satırı tarafından otomatik olarak oluşturulan SQL'in çeşitli bölümlerini eklemenize / değiştirmenize izin veren (kötüye kullanılmamalıdır!) Oldukça kullanışlı bir filtredir. Filtre geri arama imzası şudur: function posts_clauses_filter_cb( $clauses, $query_object ){ }ve geri dönmenizi bekler $clauses.

Cümleler

$clausesaşağıdaki anahtarları içeren bir dizidir; her anahtar doğrudan veritabanına gönderilen son SQL deyiminde kullanılacak olan bir SQL dizesidir:

• nerede
• GroupBy
• katılmak
• tarafından sipariş
• farklı
• alanlar
• sınırları

Veritabanına bir tablo ekliyorsanız (yalnızca post_meta, user_meta veya taksonomilerden kesinlikle yararlanamıyorsanız bunu yapın), muhtemelen, bu maddelerden daha fazlasına, örneğin, fields"SELECT" seçeneğine dokunmanız gerekir. SQL deyiminin bir kısmı), join("FROM" yan tümcesinde olanlar dışındaki tüm tablolarınız) ve belki de orderby.

Cümleleri Değiştirme

Bunu yapmanın en iyi yolu, ilgili anahtarı $clausesfiltreden aldığınız diziden almanızdır :

$join = &$clauses['join'];

Şimdi, değiştirirseniz $join, aslında doğrudan değiştireceksiniz, $clauses['join']böylece değişiklikler $clausesgeri döndüğünde de olacak.

Orijinal Maddelerin Korunması

Şanslar (hayır, cidden, dinle), WordPress'in sizin için oluşturduğu mevcut SQL'i korumak isteyeceksiniz. Değilse, muhtemelen bakmak gerekirposts_request filtreye - bu veritabanına gönderilmeden hemen önce tam mySQL sorgusu, bu yüzden tamamen kendiniz ile clobber edebilirsiniz. Bunu neden yapmak istiyorsun? Muhtemelen bilmiyorsun.

Yani, bentlerinde varolan SQL korumak amacıyla, (onlara atamak, yani maddeleri değil eklemeyi unutmayın: kullanım $join .= ' {NEW SQL STUFF}';değil $join = '{CLOBBER SQL STUFF}';. Not olduğu her eleman, çünkü $clausesdizinin bir dizidir buna eklemek istiyorsanız, Muhtemelen başka herhangi bir karakter belirteçlerinden önce boşluk eklemek isteyeceksiniz, aksi halde muhtemelen bazı SQL sözdizimi hatası oluşturabilirsiniz.

Her bir maddede her zaman bir şeyler olacağını varsayabilir ve bu nedenle her yeni dizgiye bir boşlukla başladığınızı unutmayın:, $join .= ' my_tableveya, istediğiniz zaman, sadece bir boşluk ekleyen her zaman küçük bir satır ekleyebilirsiniz:

$join = &$clauses['join'];
if (! empty( $join ) ) $join .= ' ';
$join .= "JOIN my_table... "; // <-- note the space at the end
$join .= "JOIN my_other_table... ";


return $clauses;

Bu her şeyden çok stilistik bir şey. Hatırlanması gereken önemli nokta şudur: Zaten içinde bazı SQL olan bir cümle ekliyorsanız, dizginizden ÖNCE daima bir boşluk bırakın!

Bir araya koyarak

WordPress geliştirmenin ilk kuralı, kullanabildiğiniz kadar temel işlevsellik kullanmaya çalışmaktır. Gelecekte işinizi kanıtlamanın en iyi yolu budur. Çekirdek ekibin WordPress'in şimdi SQLite veya Oracle veya başka bir veritabanı dili kullanacağına karar verdiğini varsayalım. Elle yazılmış herhangi bir mySQL geçersiz olabilir ve eklentinizi veya temanızı bozabilir! WP'nin kendi başına mümkün olduğu kadar SQL üretmesine izin vermek ve ihtiyaç duyduğunuz bitleri eklemek daha iyidir.

Bu yüzden, ilk iş emri, WP_Querytemel sorgunuzdan mümkün olduğunca fazlasını elde etmenize yardımcı oluyor. Bunu yapmak için kullandığımız yöntem, büyük ölçüde bu yazı listesinin nerede görünmesi gerektiği ile ilgilidir. Sayfanın bir alt bölümü ise (ana sorgunuz değil) kullanırsınız get_posts(); ana sorguysa, kullanabileceğinizi query_posts()ve bununla yapılabileceğinizi varsayalım , ancak bunu yapmanın doğru yolu, ana sorguyu veritabanına çarpmadan önce (ve sunucu döngülerini tüketir) requestfiltrelemektir.

Tamam, sorgunuzu oluşturdunuz ve SQL oluşturulmak üzere. Aslında, yaratıldı, veritabanına gönderilmedi. posts_clausesFiltreyi kullanarak, çalışan ilişkileri tablosunuzu karışıma ekleyeceksiniz. Bu tabloya {$ wpdb-> prefix} diyelim. 'user_relationship' ve bu bir kesişim tablosu. (Bu arada, bu tablo yapısını genelleştirmenizi ve aşağıdaki alanlarla uygun bir kesişim tablosuna dönüştürmenizi öneririm: 'relationship_id', 'user_id', 'related_user_id', 'relationship_type'; bu çok daha esnek ve güçlüdür. .. ama dalıyorum).

Ne yapmak istediğinizi anlarsam, bir Liderin Kimliğini geçmek ve sadece o Liderin Takipçilerinin gönderilerini görmek istersiniz. Umarım doğru anlamışımdır. Doğru değilse, söylediklerimi almak ve ihtiyaçlarınıza göre uyarlamak zorunda kalacaksınız. Masa yapınıza bağlı kalacağım: a leader_idve a follower_id. Dolayısıyla, JOIN, {$wpdb->posts}.post_author'user_relationship' tablonuzdaki 'follower_id' için yabancı bir anahtar olarak kullanılacaktır.

add_filter( 'posts_clauses', 'filter_by_leader_id', 10, 2 ); // we need the 2 because we want to get all the arguments

function filter_by_leader_id( $clauses, $query_object ){
  // I don't know how you intend to pass the leader_id, so let's just assume it's a global
  global $leader_id;

  // In this example I only want to affect a query on the home page.
  // This is where the $query_object is used, to help us avoid affecting
  // ALL queries (since ALL queries pass through this filter)
  if ( $query_object->is_home() ){
    // Now, let's add your table into the SQL
    $join = &$clauses['join'];
    if (! empty( $join ) ) $join .= ' '; // add a space only if we have to (for bonus marks!)
    $join .= "JOIN {$wpdb->prefix}employee_relationship EMP_R ON EMP_R.follower_id = {$wpdb->posts}.author_id";

    // And make sure we add it to our selection criteria
    $where = &$clauses['where'];
    // Regardless, you always start with AND, because there's always a '1=1' statement as the first statement of the WHERE clause that's added in by WP/
    // Just don't forget the leading space!
    $where .= " AND EMP_R.leader_id={$leader_id}"; // assuming $leader_id is always (int)

    // And I assume you'll want the posts "grouped" by user id, so let's modify the groupby clause
    $groupby = &$clauses['groupby'];
    // We need to prepend, so...
    if (! empty( $groupby ) ) $groupby = ' ' . $groupby; // For the show-offs
    $groupby = "{$wpdb->posts}.post_author" . $groupby;
  }

  // Regardless, we need to return our clauses...
  return $clauses;
}

Bu soruyu oldukça geç cevaplıyorum ve bunun için özür dilerim. Buna katılmak için son teslim tarihleriyle çok meşguldüm.

Uygulamamda genişletebileceğim ve uygulayabileceğim temel çözümleri sağladığı için @ m0r7if3r ve @kaiser'e teşekkür ederiz. Bu cevap @ m0r7if3r ve @kaiser tarafından sunulan çözümlere adaptasyonum hakkında detaylar sağlar.

Öncelikle, neden bu soruyu ilk başta sorduğumu açıklayayım. Soru ve yorumlarından biri, WP_Query'i belirli bir kullanıcının (takipçisinin) takip ettiği tüm kullanıcılar (liderler) tarafından yazılan mesajlar almaya çekmeye çalıştığımı toplayabilir. Takipçi ve lider arasındaki ilişki özel bir tabloda depolanır follow. Bu sorunun en yaygın çözümü, takipçinin tüm liderlerinin kullanıcı kimliklerini takip tablosundan çekip bir diziye yerleştirmektir. Aşağıya bakınız:

global $wpdb;
$results = $wpdb->get_results($wpdb->prepare('SELECT leader_id FROM cs_follow WHERE follower_id = %s', $user_id));

foreach($results as $result)
    $leaders[] = $result->leader_id;

Liderler dizisine sahip olduğunuzda WP_Query'ye bir argüman olarak iletebilirsiniz. Aşağıya bakınız:

if (isset($leaders)) $authors = implode(',', $leaders); // Necessary as authors argument of WP_Query only accepts string containing post author ID's seperated by commas

$args = array(
    'post_type'         => 'post',
    'posts_per_page'    => 10,
    'author'            => $authors
);

$wp_query = new WP_Query( $args );

// Normal WordPress loop continues

Yukarıdaki çözüm, istenen sonuçlarıma ulaşmanın en basit yoludur. Ancak, ölçeklenemez. Onlarca ve binlerce lideri takip eden bir takipçiniz olduğu zaman, sonuçta lider lider kimlikleri dizisi çok büyük olacak ve WordPress sitenizi her sayfa yüklemesinde 100 MB - 250 MB bellek kullanmaya zorlayacak ve sonunda siteyi çökertecektir. Sorunun çözümü, SQL sorgusunu doğrudan veritabanında çalıştırmak ve ilgili gönderileri almaktır. @ M0r7if3r'nin çözümü o zaman kurtarılmaya başladı. @ Kaiser önerisini takiben her iki uygulamayı da test etmek için yola çıktım. Bunları yaklaşık 47.000 kullanıcıyı, yeni bir WordPress test kurulumuna kaydetmek için CSV dosyasından içe aktardım. Kurulum Yirmi Eleven temasını kullanıyordu. Bunu takiben yaklaşık 50 kullanıcının diğer kullanıcıları takip etmesini sağlamak için bir döngü çalıştırdım. Hem @kaiser hem de @ m0r7if3r çözümü için sorgu süresindeki fark şaşırtıcıydı. @ kaiser'in çözümü normalde her bir sorgu için yaklaşık 2 ila 5 saniye sürmüştür. Tahmin ettiğim varyasyon, WordPress daha sonra kullanmak üzere sorguları önbelleğe alırken olur. Öte yandan, @ m0r7if3r'nin çözümü ortalama olarak 0.02 ms'lik sorgu süresini göstermiştir. Her iki çözümü de test etmek için leader_id sütunu için AÇMA dizinini oluşturdum. Dizin oluşturmadan, sorgu süresinde önemli bir artış oldu.

Dizi tabanlı bir çözüm kullanırken bellek kullanımı yaklaşık 100-150 MB arasında durdu ve doğrudan bir SQL çalıştırırken 20 MB'ye düştü.

Takipçi kimliğini posts_where filtre işlevine geçirmem gerektiğinde @ m0r7if3r'nin çözümüyle çarptım. En azından, benim bilgime göre, WordPress, değişkenleri doldurma işlevlerine geçirmenin hiçbir yolu yoktur. Ancak Global değişkenleri kullanabilirsiniz, ancak küresellerden kaçınmak istedim. Sonunda sorunu çözmek için WP_Query'yi genişletmeye başladım. Öyleyse işte uyguladığım son çözüm (@ m0r7if3r çözümüne dayanarak).

class WP_Query_Posts_by_Leader extends WP_Query {
    var $follower_id;

    function __construct($args=array()) {
        if(!empty($args['follower_id'])) {
            $this->follower_id = $args['follower_id'];
            add_filter('posts_where', array($this, 'posts_where'));
        }

        parent::query($args);
    }

    function posts_where($where) {
        global $wpdb;
        $table_name = $wpdb->prefix . 'follow';
        $where .= $wpdb->prepare(" AND post_author IN (SELECT leader_id FROM " . $table_name . " WHERE follower_id = %d )", $this->follower_id);
        return $where;
    }
}


$args = array(
    'post_type'         => 'post',
    'posts_per_page'    => 10,
    'follower_id'       => $follower_id
);

$wp_query = new WP_Query_Posts_by_Leader( $args );

Not: Sonunda yukarıdaki çözümü 1,2 milyon giriş ile takip tablosunda denedim. Ortalama sorgu süresi 0.060 ms civarındadır.

Bunu, posts_wherefiltreyi kullanarak tamamen SQL çözümü ile yapabilirsiniz . İşte buna bir örnek:

if( some condition ) 
    add_filter( 'posts_where', 'wpse50305_leader_where' );
    // lol, question id is the same forward and backward

function wpse50305_leader_where( $where ) {
    $where .= $GLOBALS['wpdb']->prepare( ' AND post_author '.
        'IN ( '.
            'SELECT leader_id '.
            'FROM custom_table_name '.
            'WHERE follower_id = %s'.
        ' ) ', $follower_id );
    return $where;
}

Bunu da yapmanın bir yolu olabileceğini düşünüyorum JOIN, ancak bunu yapamam. Oynamaya devam edeceğim ve elde edersem cevabı güncelleyeceğim.

Alternatif olarak, @kaiser'in önerdiği gibi, iki bölüme ayırabilirsiniz: liderleri almak ve sorguyu yapmak. Bunun daha az etkili olabileceğini hissediyorum, ama kesinlikle daha anlaşılır bir yoldur. Yuvalanmış SQL sorguları oldukça yavaşlayabileceğinden, hangi yöntemin daha iyi olduğunu belirlemek için verimliliği kendiniz için test etmeniz gerekir.

YORUMLARDAN:

İşlevin içine koymanız ve yöntemi çağrılmadan önce doğru functions.phpyapmanız gerekir . Bundan hemen sonra , diğer sorguları etkilemeyecek şekilde yapmalısınız.add_filter()query()WP_Queryremove_filter()

Şablon Etiketi

Sadece iki işlevi de functions.phpdosyanıza yerleştirin. Ardından 1. işlevi ayarlayın ve özel tablo adınızı ekleyin. Daha sonra ortaya çıkan dizideki mevcut kullanıcı kimliğinden kurtulmak için bir deneme / hata yapmanız gerekir (yoruma bakınız).

/**
 * Get "Leaders" of the current user
 * @param int $user_id The current users ID
 * @return array $query The leaders
 */
function wpse50305_get_leaders( $user_id )
{
    global $wpdb;

    return $wpdb->query( $wpdb->prepare(
        "
            SELECT `leader_id`, `follower_id`
            FROM %s
                WHERE `follower_id` = %s
            ORDERBY `leader_id` ASC
        ",
        // Edit the table name
        "{$wpdb->prefix}custom_table_name"
        $user_id
    ) );
}

/**
 * Get posts array that contain posts by 
 * "Leaders" the current user is following
 * @return array $posts Posts that are by the current "Leader
 */
function wpse50305_list_posts_by_leader()
{
    get_currentuserinfo();
    global $current_user;

    $user_id = $current_user->ID;

    $leaders = wpse5035_get_leaders( $user_id );
    // could be that you need to loop over the $leaders
    // and get rid of the follower ids

    return get_posts( array(
        'author' => implode( ",", $leaders )
    ) );
}

Şablonun içinde

Burada sonuçlarınızla ne istersen yapabilirsiniz.

foreach ( wpse50305_list_posts_by_leader() as $post )
{
    // do something with $post
}

NOT Biz Sakın yukarıda bir tahmin oyunu biraz bu yüzden, vb testdata var. Emin olun size daha sonra okuyucuları için bir tatmin sonucu alabilmek için, sizin için çalıştı ne bu yanıtı değiştirebilir. Temsilciniz çok düşük olursa, düzenlemeyi onaylayacağım. Daha sonra bu notu da silebilirsiniz. Teşekkürler.

_{Not: Buradaki cevap, yorumlardaki geniş tartışmalardan kaçınmak içindir.}

1. İşte ilk test kullanıcısı grubunu eklemek için yapılan yorumlardan OPS Kodu. Gerçek bir dünya örneğine değiştirilmem gerekiyor.

   for ( $j = 2; $j <= 52; $j++ ) 
   {
       for ( $i = ($j + 1); $i <= 47000; $i++ )
       {
           $rows_affected = $wpdb->insert( $table_name, array( 'leader_id' => $i, 'follower_id' => $j ) );
       }
   }

   OP Testi Hakkında Bunun için bir csv dosyasından yaklaşık 47K kullanıcı ekledim. Daha sonra, ilk 45 kullanıcının diğer tüm kullanıcıları takip etmesi için bir for döngüsü yürüttü.

   • Bu, özel masama kaydedilen 3.704.951 kayıtla sonuçlandı.
   • Başlangıçta, @ m0r7if3r'ın çözümü bana 95 sn'lik sorgu süresini verdi, bu da leader_id sütununda AÇIK endekslemesini açtıktan sonra 0.020 ms'ye düştü. Tüketilen toplam PHP belleği 20 MB civarındaydı.
   • Öte yandan, çözümünüz endeksleme AÇIK olan sorgu için yaklaşık 2 - 5 saniye sürmüştür. Tüketilen toplam PHP belleği 117 MB civarındaydı.

2. Bu teste cevabım:

   daha "gerçek hayat" testi: Her kullanıcının bir a izlemesine izin verin $leader_amount = rand( 0, 5 );ve sonra her kullanıcıya bir numara ekleyin $leader_amount x $random_ids = rand( 0, 47000 );. Şu ana kadar bildiğimiz şey şudur: Bir kullanıcı birbirini takip ederse çözümüm aşırı derecede kötü olacaktır. Ayrıca: Testi nasıl yaptığınızı ve zamanlayıcıları tam olarak nereye eklediğinizi göstereceksiniz.

   Ayrıca, zamanın yukarısındaki izlemenin gerçekten de ölçülemeyeceğini belirtmek zorundayım, aynı zamanda döngüyü birlikte hesaplamak da zaman alacaktır. Daha iyi bir sonuç elde edilen ID setinde ikinci bir döngüde dolaşmak olacaktır.

burada daha fazla işlem