aboros képe

az előfeldolgozó azért van, az a célja és értelme, hogy a számára elérhető változókat módosítsam benne még mielőtt azok a sablonba kerülnének. _semmi_ gányolás nincs benne, ez a rendeltetésszerű használata.

tipikusan ilyen feladat, hogy a node valamilyen paraméterétől függően szeretném változtatni mondjuk a $content változó tartalmát, ami ugye más, a nodeban egyébként is szereplő változókból áll össze gyárilag is. (gyárilag is preprocessor állítja össze). nem feltétlenül csak más szemantikát akarok adni neki, ezer példa van, amit pikk-pakk el lehet úgy intézni egy előfeldolgozóban, hogy közben az admin felület funkciói nem sérülnek, nem töröd el a sminkrendszert, csak módosítod a kimenetet. erre való.
ez persze nem azt jelenti, hogy mondjuk előfeldolgozóban db_query -t futtatok, bár elvi akadályát ennek se látom.

a display:none -al meg az a helyzet, hogy lehet használni helyenként, az viszont lúzer, amikor mondjuk úgy "sminkelek", hogy bevett gyakorlat, hogy ha valamit el akarok tüntetni, rádobok egy display:none -t aztán jóvan. na, _ez_ looser.

a keresés űrlap módosításához egyébként nem kell saját form_alter modul, mert ugye van neki saját előfeldolgozója :) ami _pont arra való_ hogy például kivegyed az űrlapból a labelt, vagy képre változtasd a submit gombot vagy hozzátegyél még amit akarsz.

persze minden tiszteletem a tiéd, én azt írom, ami szerintem. :)

0
0

-
clear: both;

stamina képe

Szia, köszönöm, legalább már világos, hogy mi nem világos :)
Szóval, addig világos hogy adott két tartalom típus. Az oldal lényege, amit szeretnék megvalósítani, hogy vannak felhasználók, akik Eredményeket küldenek be (pl 3DMark05), amit egy adott Konfigurációval csináltak (pl ASUS alaplap, E2200 processzor, stb), amit egy adminisztrátor ellenőriz. Konfigurációt bárki felvihet.
Amikor egy felhasználó Eredményt küld be, választhat egy legördülő listában a saját konfigurációi közül, amit ő vitt fel. Ezt sikerült megoldanom egy olyan Views-al, aminek az a kritériuma hogy "Felhasználó: Current Igen".
A beküldött Eredményt egy adminnak kell Közzétett állapotba tenni, amihez szerkesztenie kell. Így sajnos a szerkesztésnél az admin által felvitt Konfigurációk listázodnak ki, és nem az eredményt beküldő felhasználóé. Hogy tudom elérni, hogy ez ne így legyen?
Vagy hogy tudom azt megcsinalni, hogy csak új Eredmény esetében lehessen a konfigurációk közül választani, szerkesztésnél meg csak kiírja a konfiguráció nevét?

Remélem így világosabb a probléma. Nagyon örülnék ha valaki tudna segíteni nekem ebben, mert a site-nak ez az egyik lényeges pontja az induláshoz.

PP én most voltam a Pentaschool hallgatója (Drupal webmester), és ezt a problémát emailben is megírtam neked a tanfolyam után, persze mondtad hogy sok idő lehet amíg válaszolsz :)

0
0
aboros képe

nekem is van munkám, meg itt mindenki másnak is. :)
előbb már írtam, hogy erre való például a google groups, nem tudom azzal mi a problémád vagy láttad e egyátalán a linket.

van google sites is, pont az olyan esetekre mint a tiéd (nem akarok semmit csinálni csak legyen egy veboldalam varázsütésre). talán azt is érdemes kipróbálni.
van drupal gardens, az is jó lehet.
van wordpress.com, az is jó lehet.
van blogger.com, az is jó lehet.
van háromszázezer amatőröknek szánt szolgáltatás, az mind jó lehet neked, mindnek te vagy pontosan a célcsoportja.

de el kell szomorítsalak, anélkül, hogy bármit elolvasnál, a te jelenlegi tudásszinteden egyiket se fogod tudni kezelni. még egy kenyérpirítóhoz is van használati utasítás jóember, amit illik elolvasni, hogy tudjad működtetni az eszközt. még egy ajtóhoz meg egy kilincshez is van használati utasítás, rá van írva, hogy tolni.

ha nem szánod rá te a te idődet mert olyan baromi drága, akkor más kell, hogy rászánja helyetted, amit meg neked akkor meg kell fizetni. egy ilyen egyszerű oldalt egyébként baromi gyorsan össze lehet legózni zéró programozással, szerintem egy tapasztaltabb drupalosnak egy olyan 10 tiszta munkaóra kb. bár lehet megvan hat alatt is. :)

0
0

-
clear: both;

nevergone képe

Ha egy probléma merül fel, akkor érdemes rákeresni, hogy más is találkozott-e már vele, és ha igen, akkor milyen lehetséges ötletek merültek fel.
Viszont új témát kell indítani. Ennek az oka az, hogy ez igazából csak technikailag fórum, gyakorlatban egy tudásbázis: Felmerül egy kérdés, a kérdező egy új témában elmondja, amit szeretne elérni, megad minden használható adatot, elmondja, hogy mivel próbálkozott eddig, esetleg milyen hasonló problémákat talált a keresése során. Ezután jobb esetben válaszok születnek, remélhetőleg a helyes megoldás is előkerül, a kérdező boldog, a téma pedig archiválódik, mintegy "magától elalszik szépen", ahogy én is fogok nemsokára.
Az új téma két okból fontos: Bár úgy tűnik, hogy az eredeti témafelvetés és a te kérdésed közel állnak egymáshoz, valójában nem: Más a tárhely, más a PHP verzió, a Drupal verzió, használt modulok, és a többi. Ezért a tiszta lappal, új témában kérdezés több eredményre vihet és könnyebben követhetővé teszi a kérdést.
A másik ok kapcsolódik ehhez: Bár még nem látszik, de mi meg tudunk jelölni egyes hozzászólásokat, hogy "ez egy helyes megoldás", így a tudásbázis teljes értelmet nyer majd: Látszik majd az eredeti kérdés, az arra született köztes hozzászólások, végül a helyes megoldások. Viszont ez csak akkor működhet jól, ha egy fórumtémában csak egy kérdés szerepel.
Nem tudom, mennyire zűrzavaros így éjfél felé, mindenesetre megpróbáltam felvázolni neked. :)

0
0
Balogh Zoltán képe

Az látszik az api.d.o-n, hogy az első paraméter a modul neve, a második a hook neve, a többi paraméter pedig átadásra kerül az így kiválasztott függvénynek, ha az létezik.

$block = module_invoke('similarterms', 'block', 'view', 0);
print $block['content']; 

Ebből tehát a module_invoke olyan hívást csinál, hogy: similarterms_block('view', 0); No, hogyha belenézel a similarterms modul forrásába, akkor látod, hogy annak bizony van similarterms_block függvénye, figyeli azt, hogy ha az első paramétere 'view', akkor vissza kell adni a blokk tartalmát, és még a delta értéket is figyeli, mivel egy modul több blokkot is definiálhat.

0
0
leonidasz képe

Nos, igen... ez egy jó példa arra, ha átvesz valaki egy oldalt további fejlesztésre akkor nézzen át mindent. Mi is kaptunk egy drupal 5-ről updatelt drupal 6-os oldalt, hogy fejezzük be a fejlesztését, mert hát nem úgy megy minden mint az elődjében.
Ez volt az egyik probléma, ami persze a vége felé derült ki. De hát ki tesztel ilyet... már fogok mindig :)

A másik ami megoldódott az volt, hogy az újonan beküldött tartalmakat sem az anonym sem a regisztrált user nem látta. Hozzáférés megtagadva oldal jelent meg.
Ezt a node access táblában kellett javítani, melyet összehasonlítva egy jól működő drupallal, igen furcsa eltérések mutatkoztak.

Ebben ez esetben volt egy már feltett kérdésem is:
http://drupal.hu/forum/tartalom-t%C3%ADpus-m%C3%A1sik-t%C3%ADpusba

Létezett egy kreált termék tart típus, melyet át kellett drupal 6ban vegye az uc node typeja.
Sikerült megcsinálni. Ezt hamarosan közzétesszük, miként sikerült. Még össze kell szedni hozzá a gondolatainkat. :)

Tanulság:
Mindig át kell nézni töviről hegyire egy átadott félkész drupal, vagy nem drupal oldalt. Mert mint a példából látszik érhetnek olyan meglepetések, amire nem is számítunk.

0
0
york képe

Back-end drupalozas nelkul szerintem nemfog menni.
A kovetkezo lepeseket kell megtenni:

  1. Letrehozol egy rejtett mezot az alapertelemzett erteke: %get[q]
    Igy az urlap ertekei koze bekerul az az utvonal ahonnan bekuldtek a webformot.
  2. Itt tobb lehetoseged is van, talan a legegyszerubb az, ha letrehozol egy olyan email cimzetet amit technikai jellegu es a level kikuldesekor kicsereled a szallashoz tartozo cimre.
  3. Szukseged lesz egy sajat modulra, ahol implementalod a hook_mail_alter (modulneve_mail_alter) hookot (http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hoo...).
  4. Itt a $messages valtozoban megkapod a kikuldendo levelet es a $message['params'] tombben a webform altal atadott parametereket, neked a $message['params']['submission'] tombben levo rejtett mezo ertekere lesz szukseged ami 'node/szam' formaban tartalmazza az utvonalat.
  5. A szovegbol kihamozod a szamot, majd node_load() (http://api.drupal.org/api/drupal/modules--node--node.module/function/nod...) segitsegevel betoltod szallashely node-jat.
  6. A node-bol kiolvasod a szallashely email cimet. Atirod a level cimzetjet szallashely mail cimere.

Ha valahol elakadsz irj ide batran segitek.

0
0
eager képe

A gyári core Image fieldnél, ami a gyári article tartalomtípushoz is jár, annyit módosítottam, hogy 1 feltölthető képről Korlátlanra állítottam a mennyiséget.

A $base_url-nél beállítottam a domainnév www-s verzióját. Aztán töltöttem fel ezt-azt.

Utána a $base_url-hez a www nélküli domaint tettem, és töltöttem ezt-azt.

Aztán ehhez a fieldhez beállítottam a Colorboxot megjelenítőnek, és töltöttem mindent mindenhova :).

Eközben újra meg újra néztem a forráskód nézetet (nem Firebuggal (ki tudja mi mindent formál az át kicsit (pár dolgot tuti)), hanem a rendes forráskódot)

A tanulság az, hogy minden képnél mind az img src, mind a colorbox link a $base_url aktuális állapotában jelenik meg, függetlenül attól, hogy éppen mi volt az ukáz a feltöltésükkor.

Szóval a $base_url arra nagyon jól működik, amire kitalálták: minden lekéréskor meg van vizsgálva, és az kerül felhasználásra a linkek kovácsolásánál.

De úgy néz ki, hogy csak erre lehet használni, a domain eltűntetésére nem.

(<off>: a www-s/www nélküli alapállást a kísérlet végeztével visszaállítottam a saját preferenciámra a .htaccessben (nehogymár mind a kettőn bejöjjön az oldal </off>)

0
0
eMeLA képe

Nem tudom, hogy saját minimodul is számításba jöhet-e, mert az autocomplete igen egy jószág:

Ha belenézel ebbe:
http://api.drupal.org/api/drupal/modules!taxonomy!taxonomy.pages.inc/fun...

Akkor látod, hogy az adatbázisban így keres a taxonomy autocomplete: ->condition('t.name', '%' . db_like($tag_last) . '%', 'LIKE')

Neked pedig ez kell: ->condition('t.name', db_like($tag_last) . '%', 'LIKE')

Ezt úgy tudod megcsinálni saját minimodulban, hogy bemásolod a modulodba a taxonomy_autocomplete()-et és átnevezed SAJÁTMODUL_autocomplete()-re.
Benne átírod a fent említett sort.

Kell még egy hook_menu() az alábbi menüvel:

$items['AKÁRMI/autocomplete'] = array(
'title' => 'Saját autocomplete taxonomy',
'page callback' => 'SAJÁTMODUL_autocomplete',
'access arguments' => array('access content'),
'type' => MENU_CALLBACK,
'file' => 'taxonomy.pages.inc',
);

Ezután kell egy hook_form_alter()

Amiben az adott form-nál a taxonomy fieldednél az #autocomplete_path értékét átállítod AKÁRMI/autocomplete -re.

Ezután már a te autocomplete keresésed fog működni.

(Az autocomplet használati igen egyszerű, és akármilyen textfield pár soros saját modullal könnyen átalakítható)

1
0

...mit tudok: http://web.termuves.hu

eager képe

Első látásra ez a szál tele van örülő emberekkel:
http://drupal.org/node/1545610

Ezek kifejezetten lényegesnek tűnnek:
https://drupal.org/node/1545610#comment-5952370
http://drupal.org/node/1545610#comment-5953606

  1. Elvileg olyan is lehet, hogy valamiért az update.php "nem eléggé fut le"?
  2. azt mondja: [az update.php] "its say : 5 updapts is waiting" <- ez miez?
    ( https://drupal.org/node/1545610#comment-5965026 )
  3. Mit rontott el az, akinél ilyesmi fordul elő?
  4. Mit csinál a drush updb? Hogy lehet hasonló eredményt elérni ott, ahol nincs drush?

És persze:

MINDIG (mindig) legyen mentésed mielőtt bármi komolyba fogsz.

Edit:
Úgy látom az előző hibaüzit sikerült meggooglizni a tied helyett... Mindenesetre a "B" terv az lenne, hogy sorban kikapcsolod a modulokat, és megnézed, hogy hol múlik el a baj. (gondolom cache-t kell közben ürítgetni (ha egy klónozott példányon kísérleteznék a gyógyítással, még a cront is futtatnám az egyes modulkikapcsolások között)).

1
0