Balogh Zoltán képe

Ezt a hibát a 6-os Drupalban sajnos nem lehet kijavítani, mivel abban 1 karaktersorozatnak 1 fordítása lehet. Ha ezt átírnánk, akkor az Übercart, Drupal Commence, stb használói írnák, hogy a „Save order” a megrendelést menti el, nem pedig a sorrendet. Tehát ez Drupal 6 alatt a won't fix kategória (A 130 hasonló - view, may, stb - kifejezésekkel együtt).

Drupal 7-ben már van rá megoldás, a kérdéses modul hibajegyei közé fel kell venni egy újat, melyben a kérdéses karaktersorozatokhoz kontextust kell rendelni, valahogy így. Régi:

t('Save order')

Új:

t('Save order', array(), array('context' => 'ubercart'))

A dolog persze nem ennyire egyszerű, mert logikusan meg kell nézni, hogy a kérdéses karaktersorozat hány modulban fordul elő, és azokat kell kontextusba kérni egy-egy hibajeggyel, amelyik értelmezés a leginkább rendhagyó. Tehát a Save order esetében a Sorrend mentése lenne a jó valóban, viszont ahol az order rendelésként szerepel, oda már mehet is a hibajegy, hogy lécci rendelj hozzá kontextust, mert a fordítás miatt ez szükséges. Ezáltal elérhető, hogy a Save order kifejezést annyiszor fordítsuk le különbözőképpen, ahány értelme van.

0
0
Zotya képe

Végül is sikerült megoldanom a pdf törzsét generáló tartalomba firkált php kódokkal. Nem túl elegáns, de működik.

Viszont modullal nem tudom megoldani.

function _webform2pdffiletokenwebform2pdf_list_template_vars($component, $tokens) {
    switch ($component['type']) {
      case 'file':
       $tokens[] = '%' . $component['form_key'];
      break;
    }
}

Ez tulajdonképp elkészíti a fájl mezőhöz tartozó tokent, csak az a baj, hogy mindig felülírja a legutolsót, így a végén csak egy érték marad.
Még inkább probléma, hogy ez az egy érték sem szerepel a többi token között a pdf tartalmát beállító szövegmező alatt.
Ellenben print_r($token) szerint szerepelnie kellene benne.

Hol rontottam el?

0
0
Geva képe

jól látod a megoldás menetét, kezdj csak hozzá,
de a _preprocess_page(&$vars, $hook) maga már egy függvény...

ezen a függvényen belül kellene a $body_classes tartalmához hozzáfűzni az útvonal álnevet pl ahogy szantog írta,

én a body id-ként állítottam össze egy változót az útvonal álnévvel, ehhez a honlaphoz: http://www.worldofyagyas.com/ ahol a body id szerint állítottam be egy div háttérképét, a felső menüpontok oldalaihoz

...  
$vars['body_id'] = ' id="' . $bdid . '"';            // Add a unique page id

a page.tpl.php -ben pedig

<BODY<?php print $body_id; ?> <?php print $body_classes; ?>>

... a $body_classes változóra másutt volt szükségem, nem akartam abba beleírni
0
0
balagan képe

Pont most olvastam a Pro drupal 7 development című könyvben az erre vonatkozó részt. Mondjuk saját példamodult írt a szerző, de talán segít. Itt az ide vonatkozó rész:

Validating User-Submitted Settings
If system_settings_form() is taking care of saving the form values for us, how can we check whether the
value entered in the “Annotations per node” field is actually a number? We just need to add the check to
see whether the value is numeric to a validation function (annotate_admin_settings_
validate($form, $form_state)) in sites/all/modules/custom/annotate/annotate.admin.inc and use it to
set an error if we find anything wrong.
/**
* Validate annotation settings submission.
*/
function annotate_admin_settings_validate($form, &$form_state) {
$limit = $form_state['values']['annotate_limit_per_node'];
if (!is_numeric($limit)) {
form_set_error('annotate_limit_per_node', t('Please enter number.'));
}
}
Now when Drupal processes the form, it will call back to annotate_admin_settings_validate() for
validation. If we determine that a bad value has been entered, we set an error against the field where the
error occurred, and this is reflected on the screen in a warning message and by highlighting the field
containing the error.
How did Drupal know to call our function? We named it in a special way, using the name of the form
definition function (annotate_admin_settings) plus _validate. For a full explanation of how Drupal
determines which form validation function to call, see Chapter 11.

0
0
szantog képe

Belepiszkálni max akkor, ha nagyon tudod mit csinálsz, kényes egy dög ez a media. És nem, jelenleg nem lehet irányítani mappákba a wysiwyg által beszúrt képeket.

A media_browser_plus githubon fejlesztett verziója tudja ezt, neki komplett admin felülete van egy taxonómia alapú könyvtárkezeléshez. Azonban ez is kutya vacsorája, hacsak nem kapcsolódsz be a fejlesztésbe, sok gondod lesz vele.

Összességében a legegyszerűbb módja egy minimális könyvtárkezelésnek jelenleg wysiwyg felületről egy saját célmondul a media_browser_plus githubos verziója alapján:

1. Egy szótár létrehozása a könyvtárstruktúrának, benne a termek a könyvtárstruktúra
2. A könyvtármozgatás lekódolása a term feldolgozó hookok segítségével.
3. _form_alter megvalósítása, hogy a termválasztó form elem kerüljön rá a wysiwyg beszúró formra.
4. A file fizikai mozgatása a form mentésekor, file adatainak frissítése.
+ bónusz ezt az egészet nem taxonómia alapján, hanem saját entitással megcsinálni.

Mindezt media 1.x-hez összehozni file_entity nélkül erősen húzós, a media 2.x devje ugyan már eléggé használható, de itt is fel kell készülni nem várt hibákra, és kezelni kell azokat. Az 1.x branchhez file_entity modul nélkül ráadásul igen pazarlóan lehet kivitelezni, több felesleges file_load/file_save párosítással, egészen egyszerűen nincs olyan érdemi hook, amivel a file előkészítésébe bele lehet nyúlni.

Most ezt így leírva + lassan kéthónapi meló a media modullal megértem, amit pp írt, hogy imcere váltottak, elég elvetemült mutatvány megszelidíteni a mediat, hogy tényleg azt csinálja, amit akarunk.

Nálunk most a könyvtárkezelés jelenleg abban a fázisban van, hogy használtuk a media_browser_plus, amivel tökéletesen működőre sikerült csiszolni, viszont ez a mostani hatalmas media 2.x branch ráncfelvarrás után már nem megy. Szóval egyelőre megvannak a megfelelő könyvtárakhoz a termek, csak nincsenek összekapcsolva filemozgatási műveletekkel. Ez annyiban nem gáz, hogy most jelenleg nem érdekel, hogy hol van a filerendszerben fizikailag a file, meg vannak jelölve, hogy hol _kéne_ lennie, és bármikor később alá tudjuk pakolni a működési logikát, és tömegesen frissíteni.

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.

aruna képe

szinte mindenhez lehet field-eket kapcsolni így a term-ekhez is, ha belenézel a betöltött term objektumba (http://i.imgur.com/PbukT.png):

$term = taxonomy_term_load($tid);
dpm($term); // dpm() függvény a devel modulban

és egy mező értékét így írhatod ki:

echo $term->mezod_neve['und']['0']['value'];

Kb. így hozzáférsz a kapcsolt mezők értékeihez. De itt több esetet is le kellene kezelni, pl.: ha egy mezőnek több értéke van vagy ha egy sincs.

----------

> Az Api-n kivül milyen tutorialt javasolsz a
> hasonló kérdések megoldásához?

Alapvetően a google-el jutok el az api-hoz és tutoriálokhoz is.
Ha sikerül jól eltalálni a kulcsszavakat, akkor jó. :)

Itt a taxonomiához tartozó függvénysereg:
http://api.drupal.org/api/drupal/modules!taxonomy!taxonomy.module/7

0
0
hszilard képe

A hook_webform_submission_presave függvénnyel kapcsolatban még az a kérdésem lenne, hogy a $node paraméter segítségével hogyan lehetne szűkíteni ennek a lefutását, hogy ne minden űrlapnál fusson le (ezen a honlapon több webform tartalom is van), hanem csak annál az egynél, ahol erre szükség van?
Gondolom, valahogy így kellene kezdeni:

  1. function sajatmodul_webform_submission_presave($node, &$submission) {
  2. if (isset($node->???)) {
  3. ...
  4. ...
  5. }
0
0
burney képe

A menu_get_object('test_event') -el szépen visszakapom a %test_event -et. :)
Megnézegettem a node.pages.inc -et és a node.module -t is, viszont sajnos még nem világos, hogy milyen műveletet (vagy ellenőrzést) kellene végrehajtanom a test_event_load fv-ben.

Most így működik:

  1. function test_event_load($test_event_id) {
  2. return is_numeric($test_event_id) ? $test_event_id : FALSE;
  3. }

Ezt követően a form default értékeinek visszaadására egy külön fv-t írtam, melynek paramétere: menu_get_object('test_event')
és ez a fv. visszaadja a db-ből a megfelelő default értéket a form adott mezőjének.

Ezzel kapcsolatban kérdésem, hogy a test_event_load fv. művelete megfelelő, elegendő?
Valamint az egész leírt megvalósítás elfogadható megoldásnak tűnik?
Továbbá, hogy megtehetem-e azt, hogy azonos form-ot alkalmazok a new-ra és az edit-re?

Hálás köszönet! :)

0
0
dyra képe

Nekem egy Drupal 6-ról 7-re updatnél jött elő ugyanez a hiba. Méghozzá akkor mikor kommentárt akar beküldeni egy névtelen felhasználó, de bizonyos esetekben számomra logika nélkül akkor is ha reggelt felhasználó szól hozzá. Sajnos én gyakorlatilag nem vagyok olyan szinten, hogy egyáltalán csak sejtsem mi okozhatja ezt a gondot. Nem sok hasonló problémát találtam a Google segítségével és nem jutottam előrébb a megoldásban (az összes modult kikapcsoltam csak a comment meg ami annak függvénye volt bekapcsolva akkor is produkálta a jelenséget). Jelen pillanat kikapcsoltam az oldal ezen funkcióját.

EntityMalformedException: Missing bundle property on entity of type comment. in entity_extract_ids() (line 7697 of /xxxx/xxxx/xxxx/includes/common.inc).

EntityMalformedException: comment típusú entitáson hiányzik a mezőcsoport tulajdonság. entity_extract_ids() függvényben (/xxxx/xxxx/xxxx/includes/common.inc 7697 sor).

0
0

honlapom http://dyra.eu/

makgab képe

A path_set_alias() D7-ben már nincs, ha jól olvasom, akkor a path_save fv kellene nekem(?).

Save a path alias to the database.
 
Parameters
$path: An associative array containing the following keys:
 
    source: The internal system path.
    alias: The URL alias.
    pid: (optional) Unique path alias identifier.
    language: (optional) The language of the alias.

A path_delete az alias törlése.

Delete a URL alias.
 
Parameters
$criteria: A number representing the pid or an array of criteria.

Ez a $criteria paraméter nem egészen világos. Ez lenne az 'url alias', amit törölni szeretnék?

0
0