1. Tudásbázis
  2. Egyéb
  3. field_info_field_types() a core típusait nem jeleníti meg

field_info_field_types() a core típusait nem jeleníti meg

Beküldte balagan - 2013. január 9. 18.36
balagan képe

A dpm(field_info_field_types()) futtatására csak a date modul által deklarált mezőtípusokat kapom válaszul. A drush field-info ugyanígy.
Itt látszik, hogy a drush listázza a core mezőtípusait is, ahogy az API szerint a field_info_field_types()-nak is kéne. A drupalt tegnap raktam fel, még nagyon szét sem túrtam. Vajon miért nem jelennek meg a core által deklarált mezőtípusok?

Drupal verzió: 
7.x
Fórum: 
Egyéb
balagan képe

Beküldte balagan - 2013. január 9. 18.38

Persze elszúrtam a címet, pont a core mezőtípusai nem jelennek meg.

0
0
nevergone képe

Beküldte nevergone - 2013. január 9. 18.46

Javítottam. :)

1
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

Sk8erPeter képe

Beküldte Sk8erPeter - 2013. január 9. 22.13

A dpm(field_info_field_types()) futtatására csak a date modul által deklarált mezőtípusokat kapom válaszul.

Ez furcsa. Milyen hookban próbálod mindezt?

Én most egy sima hook_form_alter()-ben próbáltam (de teljesen mindegy, hook_init()-ben is lehetne, úgy is ugyanezt adja), és listázza a core-típusokat:

  1. /**
  2.  * Implements hook_form_alter().
  3.  */
  4. function testmodule_form_alter(&$form, &$form_state, $form_id) {
  5.   dsm(field_info_field_types(), 'field_info_field_types() in ' . __FUNCTION__ . '()');
  6.   // ...
  7. }

field_info_field_types() result

még nagyon szét sem túrtam

Hogy érted, csak felraktál egy pár modult, és annyi?
Másik tesztcélú Drupallal mi a helyzet?

0
0
balagan képe

Beküldte balagan - 2013. január 9. 23.25

Semmilyen hook-ot nem használtam, egy modulba az egyetlen dpm-es sort írtam be, és engedélyeztem. A drush field-info sem ment. Igen, tegnap telepítettem egy drupalt, hogy kipróbáljak néhány dolgot, geocoder, geofield és date modulokat engedélyeztem. A devel-t is most raktam fel a dpm-hez. Mindjárt kipróbálom másik drupallal.

0
0
balagan képe

Beküldte balagan - 2013. január 9. 23.43

Felraktam egy másik mappába ugyanazt a drupal változatot, és ott már működik a drush field-info, ahogy kell. A nem működő webhelyen panels, ctools, advanced_help van még engedélyezve, illetve a plugin_tools. Mindjárt letiltok mindent, és úgy is megpróbálom. Bár meg tudom már jeleníteni a field típusokat, de azért még továbbra is tudni szeretném, hogy ez az egész miért fordult elő.
Lol, a saját, egyetlen dpm(field_info_field_types()) sort tartalmazó modulom tartotta vissza a drush-t. Ahogy azt letiltom, a drush field-info rendesen működik. Nem értek semmit.

0
0
Sk8erPeter képe

Beküldte Sk8erPeter - 2013. január 10. 00.27

Lol, a saját, egyetlen dpm(field_info_field_types()) sort tartalmazó modulom tartotta vissza a drush-t. Ahogy azt letiltom, a drush field-info rendesen működik.

Keresem az összefüggést az általad korábban írtakkal is:

Semmilyen hook-ot nem használtam, egy modulba az egyetlen dpm-es sort írtam be, és engedélyeztem.
[...]
A devel-t is most raktam fel a dpm-hez.

Ha elsőként a saját modulodat engedélyezted, majd ezt követően a Develt, akkor a module_load_all_includes() meghívásakor a saját modulod fájljai előbb include-olódhatnak, mint a Develé, a fájlodba csak úgy minden körítés nélkül berakott dpm() hívás pedig le is akarhat futni - de ebben a kontextusban a dpm() függvény még nem létezik, mivel a Devel modul fájljai nem lettek még include-olva a későbbi engedélyezés miatt (később került be a táblába), ezért nem is hívható. De ekkor fatal errort kéne kapnod, ilyenről viszont nem számoltál be, úgyhogy valószínűleg valahol máshol kell keresni a hiba okát. Mindenesetre be kellene nézni a hibanaplóba, hogy ott látsz-e a korábbiakról valami hibajelzést. Localhoston amúgy tesztelés erejéig érdemes a hibajelzéseket a legmagasabb szintűre állítani (PHP-ben egyébként debuggolás erejéig az E_ALL|E_STRICT jelzés a legjobb szerintem; még ötlet).

Mindenesetre ami tény: ha ilyen szabálytalan módon írsz kódot, hogy akár csak debuggolás erejéig behányod a modul fájljába valahova a dpm() sort, akkor nagy eséllyel kiszámíthatatlan lesz a kapott eredmény. Pont azért, mert eleve szabálytalanul használod a Drupalt, ami pedig alapvetően - nem véletlenül - a hookokra épít, így ad egy követhető keretet az egyéni kódoknak.
Saját tapasztalat is, én is elkövettem hasonlót régen, aztán elég gyorsan leszoktam róla.

Tanulság: nem tesztelünk úgy Drupalban, hogy csak behányjuk a modul kellős közepébe a debuggolás céljából készült kódot, hanem szépen szabályosan, a megfelelő hookokat implementálva, a függvény törzsébe szúrjuk be ugyanazt. Lehet az például a hook_init() (nem cache-elt oldalak esetén) vagy valami egyéb is.

2
0
balagan képe

Beküldte balagan - 2013. január 10. 09.31

Köszönöm a választ! A develt azért azt hiszem előbb engedélyeztem, mint a saját modulom.

0
0
szantog képe

Beküldte szantog - 2013. január 10. 13.23

A kövi van: A modulok weight majd name szerint rendezve töltődnek be.

Tehát ha a module neve mondjuk cica.module, akkor call to undefined function errort fogsz kapni a dsm-re, de ha didi.module, akkor működni fog a dsm. Épp ezért a hook overridera használt modulenak mindenképp érdemes 100-as weightet adni hook_installban.

A dsmet esetedben azért kell most neked egy megfelelő hookba tenni, mert hook eredményét debugolod, és a hook rendszer még nem épül fel akkor, amikor a module fáljod először includolva van, amúgy meg a feladata válogatja, hogy hová kerüljön. Egy ctools pluginnél vagy egy gyors kveri csekkhez nem muszáj (ctoolsnál nem is lehet) hookba rakni.

Na és hogy miért veri szét a drusht:

A drush ugyanazt a bootstrap folyamatot használja, mint egy rendes page build. Szóval eljő itt is a pillanat, amikor includolódik a fáljod, és egyből szalad a dsm. Igen ám, de a többi module fálj még nincs includeolva, szóval a module_implements itt is csak a te moduledig fog szaladni, mivel per pill ebben a fázisban a php még nem tud a többi modulról.

Ja, és a lényeg: drupal_staticba kerül a module_implements eredménye, szóval mivel először olyan fázisban kerül meghívásra a függvény, amikor csak a date moduleig léteznek a modulek, ezért amikor a drush akarja az eredményt kiírni, ő már csak ebből a rosszul összerakott drupal_staticból dolgozik.

2
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Sk8erPeter képe

Beküldte Sk8erPeter - 2013. január 10. 13.21

Ő, itt lényegében ugyanezt írtam korábban. :)) De legalább így kétféleképp írtuk le, kétféle magyarázat. :)

0
0
szantog képe

Beküldte szantog - 2013. január 10. 13.46

Nem, egyáltalán nem ugyanazt írtad, és szándékosan nem neked válaszolva írtam, hogy ne legyen az, hogy téged javítalak.

A hozzászólásod egyik fele szabálytalan kódolásról szól, a másik felében a module_load_all_includes()-t magyarázod félre.
Maga a kódolás (hogy dsm()-et használ függvény nélkül) nem szabálytalan, csak itt épp nem működik, a module_load_all_includes pedig egyáltalán nem úgy muzsikál, ahogy írtad.
/me kiszáll a threadből.

0
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Sk8erPeter képe

Beküldte Sk8erPeter - 2013. január 10. 14.06

szándékosan nem neked válaszolva írtam, hogy ne legyen az, hogy téged javítalak

Miért nem? Ha valamit rosszul írtam, akkor örömmel veszem, ha korrigálsz, én nem sértődöm meg, sőt!

a másik felében a module_load_all_includes()-t magyarázod félre

Ha így gondolod, akkor nyugodtan leírhattad volna, hogy melyik rész nem stimmelt, tök hasznos lett volna! Végre valami szakmai dologról is beszélünk, ami érdekes lehet, és nem csak arról van szó, hogy használd XY modult, és klattyogj ide meg oda.
Szóval ne szállj ki a threadből, ha kérhetem, és ne sértődj meg, mert kicsit sem szántam sértőnek, amit írtam, nem célom pont belédkötni.
Egyébként Te valóban többet írtál, alaposabban, úgyhogy bocs, ha bántó volt, hogy azt írtam, hogy ugyanazt írtad másképp - de Te is a module weightek szerepét fejtegetted, lényegében én is; aztán mondjuk Te még hozzátetted a fájlok elnevezésének szerepét, ami például a module_list() függvényben szerepet játszhat:

  1.   if (empty($list) || $refresh || $fixed_list) {
  2.     $list = array();
  3.     $sorted_list = NULL;
  4.     if ($fixed_list) {
  5.       foreach ($fixed_list as $name => $module) {
  6.         drupal_get_filename('module', $name, $module['filename']);
  7.         $list[$name] = $name;
  8.       }
  9.     }
  10. ........
  11. }

ezt tegnap is néztem, de ennél ott van a "ha", és tegnap úgy gondoltam, a weight itt most fontosabb szerepet játszik.
Nem így van?

Melyik részt írtam tévesen? Tényleg érdekel.

0
0
szantog képe

Beküldte szantog - 2013. január 10. 14.52

Ha elsőként a saját modulodat engedélyezted, majd ezt követően a Develt, akkor a module_load_all_includes() meghívásakor a saját modulod fájljai előbb include-olódhatnak

ami nem így van.

function module_list($refresh = FALSE, $bootstrap_refresh = FALSE, $sort = FALSE, $fixed_list = NULL) {}

Amit beidéztél, hogy 

  1.     if ($fixed_list) {
  2.       foreach ($fixed_list as $name => $module) {

látható, hogy ez egy nem kötelező paraméter, a module_load_all_includes() pedig enélkül a paraméter nélkül hívja meg a module_list()-et. Ergo tovább kell nézni, melyik if ágből fog felépülni a $list, amivel visszatér a module_list.

Esetünkben ezzel:

  1.       else {
  2.         // Not using drupal_map_assoc() here as that requires common.inc.
  3.         $list = array_keys(system_list('module_enabled'));
  4.         $list = (!empty($list) ? array_combine($list, $list) : array());
  5.       }

Szócal ami a module listát előállítja, az valójában a system_list().

Benne a kveri:
      $result = db_query("SELECT * FROM {system} WHERE type = 'theme' OR (type = 'module' AND status = 1) ORDER BY weight ASC, name ASC");

Ezért kezdtem így: „A modulok weight majd name szerint rendezve töltődnek be.”

a későbbi engedélyezés miatt (később került be a táblába)

A system táblába pedig nem module engedélyezése alapján bele dolgok, hanem fáljrendszer alapján. Kb itt lehet megfogni az egészet: http://api.drupal.org/api/drupal/modules%21system%21system.module/functi...

Vagyis amint egy module bekerül a fáljrendszerbe, és valamikor a system_rebuild_module_data() meghívódik, onnantől van a system táblában. Ez történik pl a admin/modules oldal betöltésekor.

1
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Sk8erPeter képe

Beküldte Sk8erPeter - 2013. január 10. 15.25

Köszi, hogy reagáltál!

látható, hogy ez egy nem kötelező paraméter, a module_load_all_includes() pedig enélkül a paraméter nélkül hívja meg a module_list()-et. Ergo tovább kell nézni, melyik if ágből fog felépülni a $list, amivel visszatér a module_list.

Jaja, ezt vágom, csak ezek szerint felületesen néztem meg a doksit, azt feltételeztem, hogy lényegében a táblába bekerülés sorrendje is döntő, ami pedig engedélyezés sorrendje alapján is dőlhet el, de tök igazad van, a system_rebuild_module_data() meghívja a system_update_files_database()-t is (Updates the records in the system table based on the files array.), ami aztán rendezi a dolgot.
Kösz, ma is tanultam valamit. Legközelebb jobban átnézem előbb a Drupal API-t.

Mindenesetre gondolom abban közös nevezőn vagyunk, hogy azért debuggolni a megfelelő helyen érdemes (legtöbbször kínálkozik rá egy megfelelő hook; főleg a kérdés tárgyát képező esetben!), nem pedig a fájlba behányva, legalábbis az esetek 90%-ában, ahogy írod is:

A dsmet esetedben azért kell most neked egy megfelelő hookba tenni, mert hook eredményét debugolod, és a hook rendszer még nem épül fel akkor, amikor a module fáljod először includolva van, amúgy meg a feladata válogatja, hogy hová kerüljön.

viszont utána:

Egy ctools pluginnél vagy egy gyors kveri csekkhez nem muszáj (ctoolsnál nem is lehet) hookba rakni.

Ctools-nál milyen esetre gondolsz? Ezzel kapcsolatban még nincs tapasztalatom.

Szerk.: ja, még annyi jutott eszembe, hogy ha látod, hogy valahol nem teljesen helytálló magyarázatot adtam ilyen mélyvíz-témával kapcsolatban (vagy akármiről), akkor légyszi javíts ki nyugodtan! Tök jó, ha van korrekció, mert akkor én sem a hülyeséget jegyzem meg, hogy aztán később jöjjek rá, hogy az nem is úgy van ám, ráadásul jó ezeket olvasni, elég jókat szoktál írni.

0
0
szantog képe

Beküldte szantog - 2013. január 10. 15.35

Mindenesetre gondolom abban közös nevezőn vagyunk, hogy azért debuggolni a megfelelő helyen érdemes

naná, ctoolson és civicrmen kívül én sem nagyon emlékszem, hogy ne függvényben használtam volna, de nem hiba függvényen kívül használni, illetve pont annyira hiba, mintha egy rossz hookba kerülne bele (szar lesz az eredmény)
Amúgy az ilyen egyfüggvényes gyorscsekkre nekem a kedvencem a devel modul php blokkja, az tuti nem fog csalni.

Ctools plugin, eleve függvényen kívül kell deklarálni: http://drupalcode.org/project/ctools.git/blob/refs/heads/7.x-1.x:/plugin...

0
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Sk8erPeter képe

Beküldte Sk8erPeter - 2013. január 10. 16.12

Köszi, így már értem.
Fuh, de ronda ez a "globális" változó :D Nem akarok nagyon OFF-olni, csak gyorskérdés ezzel kapcsolatban: ezt hogyan használja fel egyáltalán a ctools? Melyik függvénnyel? Csak simán include-olja ezt a fájlt, meg a hozzá hasonlókat, ha a moduljaid implementálnak Ctools-plugint, aztán átadja a benne található $plugin tömböt valami függvénynek? Csak mert furcsa, hogy miért nem hív inkább valami tisztességes hook-implementációt, mint például a hook_ctools_plugin_type(), amitől egy tömböt kap. Mondjuk sosem fejlesztettem még Ctools-hoz, szóval nem tudom, mi lehetett az oka, hogy így alakították ki, miért jobb ez így.

0
0