Válasz a hozzászólásra

No ez megint amolyan nagy tömegeket érintő szösszenet lesz, de miután fél óra debugolás után jöttem rá, hogy miújság, gondoltam megspórolom magamnak (meg hátha azért másnak is..) egy következő fél órát.

A helyzet a kövi: Search Api által hajtott okos keresőt kell csinálni, amelynek az egyik sorrendezési módja: A legtöbbet kapott szavazat. A szavazáshoz a drupal.hu is látott Vote Up/Down modult használom, ami a votingapira épít.
Feladat: Etessük meg az entitásokra adott szavazatértékeket a search apival.

Igazából baromi egyszerű a dolog: Az Entity API a drupal gyári entitás paramétereit ki tudja egészíteni bizonyos adatokkal, jellemzőkkel (magyarul property), amit aztán különböző modulok okosan felhasználhatnak, mint például a rules, vagy a search api.

Tehát az első része, hogy adjunk hozzá egy ilyen jellemzőt:

/**
 * Implements hook_entity_property_info_alter().
 */
function MODULOM_hook_entity_property_info_alter(&$info) {
  $info['node']['properties']['voting_results'] = array(
    'type' => 'integer',
    'label' => t('Votes for a node'),
    'sanitized' => TRUE,
    'getter callback' => 'MODULOM_get_search_api_votes',
  );
}

A sokatmondó 'getter callback' jelenti azt a függvényt, amellyel az adott értéket elő kell túrni valahonnan. Esetünkben ez egy szimpla lekérdezés a votingapi_cache táblából:

function MODULOM_get_search_api_votes($item) {
  $results = db_query('SELECT value FROM {votingapi_cache} WHERE entity_id = :nid AND function = :function', array(
    ':nid' => $item->nid,
    ':function' => 'sum'
  ));
  $result = $results->fetchField();
  return $result;
}

Ezután egy gyorstárürítés, és már látszik is a search api indexbeállító felületén az új mezőnk, csak bepipáljuk, majd újraépítjük az indexet.

Mondhatnánk, hogy készen vagyunk, de itt jön a bibi, ami miatt az a plusz fél óra becsúszott: Az entity apinak ugyan megmondjuk, hogy helló, itt egy property, itt egy getter callback, viszont az már teljes mértékben az entity apit használó modulra van bízva, hogy hogyan, mikor használja fel ezt az adatot.

Miután nálam baromira nem akart összejönni a szavazatok szerinti sorrendezés, elkezdtem nézegetni, hogy ugyan mikor hajlandó az én kici MODULOM_get_search_api_votes függvényem lefutni. Nos, akárhogyan, akármilyen oldalról rugdostam, csak nem akart megállni az xdebug.

Nosza, elkezdtem visszakövetni, hogy egyáltalán hogyan épül fel a search api lekérdezése. Ehhez a search api dokumentációjában kiszúrtam egy hookot, ami feltételezéseim szerint mindenképpen le kell fusson: ez pedig a hook_search_api_query_alter().

El is csíptem, szépen megállt az xdebug. Itt már látszott, hogy a SearchApiQuery->preExecute metódusa hívta meg az alterünket, ott is van benne: drupal_alter('search_api_query', $this); (nem mintha nem lett volna egyszerűbb rákeresni a 'search_api_query' stringre a modul fáljaiban, na mindegy..)

Ebből adódik, hogy kell lennie egy SearchApiQuery->Executenek is, ott is van benne:

// Execute query.
    $response = $this->index->server()->search($this);

Itt gyakorlatilag szépen ellépegettem egészen a search metódusig, ahol maga a kereső query felépül. Soronként lépegetve a kóddzsumbujban kezdtek összeállni a változók, mígnem megláttam egy $valamilyen_valtozo['base_table']['search_api_db_default_node_index_voting_results'].
Hopppá! Hát itten kérem minden indexelt mezőnek saját táblája van!
Gyorsan belenéztem a táblába, és láttam, hogy ott vannak rossz értékek. Az már sanszos volt, hogy ezek a táblák index épüléskor frissülnek, úgyhogy újraindexeltem a keresést, és el is akadt az xdebug a MODULOM_get_search_api_votes() függvénynél egyből. Miután az egykarakteres typot már korábban kijavítottam, szépen feltöltődött az index - immár a jó értékekkel, és máris működött a szavazatok szerinti sorrendezés.

Tulajdonképpen baromi jók ezek az xdebugos diagnosztikák. Picit legalább sikerült megérteni a search api logikáját, legközelebb már gyorsabban eltalálom, hogy hová kell nyúlni, ha valami nem ok.