- iPhone topik
- Yettel topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Xiaomi 15 - kicsi telefon nagy energiával
- Magyarországon is kapható a Moto G85 5G
- Redmi Watch 5 - formás, de egyszerű
- Heteken belül ár/érték bajnokot avat a Poco
- VoLTE/VoWiFi
- Xiaomi 14T - nem baj, hogy nem Pro
-
Mobilarena
Ajánlott szakirodalmak a teljesség igénye nélkül (a lista még bővülhet):
Új hozzászólás Aktív témák
-
drup
junior tag
Azert akarok csomagkezelot telepiteni, hogy ne kelljen egyesevel telepitgetni a programokat, ezert kezdeztem, lamp vagy mas eseteben mi a megoldas.
A drush bejelentkezo weboldala mar menekulesre kesztetett, nem hiszem, hogy akiknek ilyen idiota weboldaluk van, jatekprogramokon kivul masra is kepesek. -
Sk8erPeter
nagyúr
Na, most addig nyújtottam az alapos válaszadást, mint a rétestésztát, hogy most meg Te előztél meg.
Egyébként ja, a szakirodalmakat érdemes olvasni."Szerintem kezd azzal" - hoppá, most nálad találtam helyesírási hibát, hát ezt nyilvánvalóan nem hagyhatom szó nélkül
Szóval akkor azt akartad írni, hogy "kezdd azzal", ugye?
(#580) :
"Egyébként a kutya szótővel rendelkező szavakat kéretik máskor vastagon kiemelni"
Hogy micsoda?Mirű' teccccik beszélni?
(Igen, cével!)
-
Sk8erPeter
nagyúr
Nem nagyon értem, miért nem frissítették még mindig a drupal.hu-n a 7.19 verzió óta a fordítási linket 7.22-re, pedig már egy ideje megvannak a fordítások...
http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.22.hu.po
ez lenne a jó cím.
Szóval tényleg a localize.drupal.org-ról érdemes letölteni.Igazából jelezni kéne nekik a hibát a fórumon, de most lusta vagyok.
Amúgy jeleztem már pár hibát, és akkor általában gyorsan intézkedtek, szóval odafigyelnek a visszajelzésekre. Gondolom ez vmiért elfelejtődött, ők is emberek. (és hozzánk hasonlóan kockák)
(#553) Ablakos :
A topic-összefoglalóban lévő szakirodalmakat érdemes lenne megnézned, a Nagy Gusztáv-féle jegyzetek pl. jól összefoglalnak rengeteg dolgot, tök érthetően. Haladóbb témakörökhöz is találhatsz hasznos infókat az ottani linkek között (legalábbis én ezeket tetettem be az összefoglalóba, biztos még számtalan hasznos szakirodalom van Drupalhoz, érdemes is lenne bővíteni a listát (csak mostanság nem Drupalozom aktívan)).
-
Sk8erPeter
nagyúr
A drupal.hu-t később frissítik.
Attól még a 7.22-es verzióhoz NEM a 7.19-es fordítás a jó, teljesen logikusan...Az a HIVATALOS legkésőbbi, ami a drupal.org-on szerepel!
Tehát innen kell letölteni, nem a drupal.hu-ról: -
Sk8erPeter
nagyúr
Ja tényleg, erről meg is feledkeztem, hogy van ilyen lehetőség, azért nem választottam ezt, mert szeretem, ha pontosan tudom, mi történik, tényleg a hivatalos változat kerül-e fel, végigkövetem rendesen a szokásos Drupal-telepítési folyamatot, és így tovább, ráadásul erről az automatizált backupról és update-ről nem is tudtam, szóval ez nekem új volt, jó, hogy megosztottad, lehet, hogy majd adok neki egy esélyt.
Viszont miközben leírtam, rájöttem, hogy ezzel már megint csak az a gáz, hogy a frissítésnél van pár modul, ami kiakad, hibákat dobál, és ezeket jobb' szeretem akkor már localhoston tesztelni, az éles változatot békénhagyva, Drush-sal update-elve, hogy legyen lehetőségem ezeket rendesen utánanézve kijavítani, szóval szerintem maradok mégis csak a hagyományos módszernél. -
Sk8erPeter
nagyúr
Ezt így még nem próbáltam, de miért nem határozod meg eleve a command line-ban a kívánt jelszót?
user-create
Create a user account with the specified name.Examples:
drush user-create newuser Create a new user account with the name newuser, the email address person@example.com, and the password letmein
--mail="person@example.com"
--password="letmein"Arguments:
name The name of the account to addOptions:
--mail The email address for the new account
--password The password for the new accountAliases: ucrt
szóval pl.:
drush user-create newuser --mail="person@example.com" --password="letmein"
==
(#521) Siriusb
jaja, ez a Tárhelyparkos dolog kicsit szívás, ha először nem jut eszébe az embernek, de szerencsére nem akkora para."Még jó, hogy egy okos ember javasolta a drush-t"
Kire gondolsz? -
Sk8erPeter
nagyúr
Ja, hogy ezt poénnak szántad? Nem hiszem, hogy velem van a baj, hogy ezt nem vettem jó "viccnek".
Nem voltam harapós kedvemben, de a blődségek terjedését időben meg kell akadályozni.
Egyébként pont igen rossz példa, ezek szerint Te vetted magadra a dolgot- én más topicokban sem vettem magamra semmit mostanság, még ha volt is szakmai vita; ez a baj az emberekkel, hogy ha egy vita megindul egy topicban, akkor azt már eleve összekötik valamiféle sértődöttséggel, és csípőből negatívan kezelik a dolgot, és úgy is reagálnak; pedig abszolúte nem erről van szó.
Vitázni szokás a topicokban hevesen és lájtosan is, nincs azzal semmi baj, ha valahova végül kilyukadunk. Hidd el, engem is oltottak eleget fórumokban, és összességében mindig jó néven vettem, ha valaki korrigált, mert akkor abból én is tanultam, meg más számára sem a hülyeségek maradtak meg. Ezeket az általánosító véleményeidet pedig inkább lehetőleg privátban írd meg nekem, mert abszolúte nem tartozik a topicba, másokat valszeg nem érdekel, majd priviben megbeszéljük.
Igen, tapasztalat. Plusz vannak általános szabályok, amikhez tartani kell magunkat fejlesztés közben, ez is azok közé tartozik, és én sem most találtam ki, hogy téged bosszantsalak.
Azzal kell megoldani a feladatot, amivel a lehető legjobban lehet, a megadott keretek között. Az ember ne legyen lusta és túl büszke utánaolvasni a dolgoknak, mások tapasztalataira hallgatni, folyamatosan fejlődni.
Ha pedig korrigálnak, akkor azon nem kell megsértődni, hanem mérlegelni, aztán ha kell, értelmesen vitázni!
Főleg nem kell cserébe ráhúzni a másikra, hogy csak ő nem érti a "viccet", bár valóban egyszerűbb megoldás.
"Ha elkészítesz egy weboldalt, utána teljes arculatváltás szerintem nem szokott havonta lenni, tehát a modul előnye ebből a szempontból nem feltétlenül van jelen. "
És amíg az arculat ki nem alakul, és váltogatsz sminkeket, akkor addig egyik template.php-ból pakolgatod mindig a másikba az alapvetően modulba tartozó kódot?
Mindegy, a lényeg, hogy template.php-ba pakolni kényelemből lustaság. -
Sk8erPeter
nagyúr
"nem szeretem azt a gyakorlatot, hogy minden apróságra telepítsek / készítsek egy modult.
Az _én_ szemszögemből túlzás egy egyszerű számításra egy modult létrehozni. "
Ez egy nagyon rossz megközelítés. Ha egy feladat megvalósításához modult kell írni, akkor modult kell írni, és kész. Ha sminkelős, megjelenítéssel kapcsolatos feladatról van szó, akkor pedig buzerálhatod a template.php-t, vagy berakhatod a templates könyvtárba a megfelelő template-fájlt, hogy átvariáld azt.Egyébként szerintem alaposan félreérted a modulok szerepét, legalábbis az alapján, amiket írsz róla. Nem arról van szó, hogy minden egyes apró feladatra külön-külön modult kell létrehozni. Az oldal fejlesztésekor előbb-utóbb akár apróbb egyedi módosításhoz is úgyis szükséged lesz egy minimodulra, ami aztán a további kisebb-nagyobb feladatokkal elkezd szépen duzzadni. De még mindig csak egy modulról beszélünk. Ha valami specifikus, más oldal fejlesztésekor is előforduló feladatról van szó, akkor akár érdemes lehet külön modulba pakolni a kódokat, főleg, ha esetleg publikálni is szeretnéd azt drupal.org-on. De a saját, egyedi kisebb módosításaidra lehet egy darab modulod is.
"Persze csinálja mindenki úgy, ahogy az az ő gondolkodásába beleillik."
Úgy csinálja mindenki, ahogy érdemes, ahogy beleillik a Drupal-koncepcióba, különben hajlamos lehet valaki elmenni a gányolás irányába. Ha mindenki a saját kicsavart gondolkodása szerint kezdené el okádni a kódokat, és nem kellene semmi szabályhoz igazodni, akkor még rég elfelejthettük volna a Drupalt."Aki lusta, az írjon modult.
"
Ezt jobb lenne nem is kommentálni, mert akkora f@szság (bocsi, de tényleg az). Az a lusta, aki inkább elkezd tákolgatni, kényszermegoldásokat keresni, ahelyett, hogy rávenné magát, hogy úgy csinálja, ahogy kell, és nem lenne rest (!!) megírni azt a pár sort, hogy legyen egy modulja (ahhoz, hogy a modulod engedélyezhető legyen admin-felületen, a Drupal tudjon róla, és lefussanak az abban található kódok, 1-2 percet kell maximum eltölteni (alapeset: *.info fájl megírása, *.module fájl)), amit aztán rengeteg célra fel tud használni az oldal továbbfejlesztéséhez. Ráadásul egyes feladatok logikailag is megkövetelik a külön-külön modulokat.
Egy csomó feladat megvalósítása eleve gány sminkben, mivel van olyan feladat, ami csak modulban valósítható meg, plusz a kódok lefutásának, implementált hookok meghívódásának van egy adott sorrendje is (így pl. korábban kellene bekapcsolódni az egész folyamatba, ami modullal könnyen megtehető). -
Ablakos
őstag
-
Sk8erPeter
nagyúr
"Szerintem az exit() nagyon jó megoldás a huncut manók ellen, akik valami csúnyaságon törik fejüket. Hirtelenjében nem találtam, mi a drupal mód a minden művelet megszakítására. Ismersz ilyet?"
Hát az exit() (vagy die()) tényleg kevés esetben indokolt, a hibákat kezelni kell, nem pedig kalapáccsal szétverni a scriptet.Teljesen változó lehet a kezelési mód, nincs erre általános recept. Attól függ.
Igen, a linkelt kódban nem az volt a lényeg, hogy a 6-ost egy az egyben át lehet ültetni 7-esre, a szemléltetést akartam megmutatni az adatbázisból való közvetlen lekérésre.
Az is_numeric() függvénynél egyébként érdekes, hogy az is_numeric(' 123') is átmegy a teszten, szóközzel az elején. Erre mondják, hogy a PHP tákolmány.
Amúgy jobb lett a scripted.
-
Sk8erPeter
nagyúr
Hát van különbség, mert jóval több függvényhívás, ami jóval több overheadet jelent, de azért nem katasztrófa, meg jogos az a szempont, amit írsz, hogy 8-asnál is működjön; ettől függetlenül 8-asnál tudtommal alapból a többi mezővel egyszintű mező lesz a node title (nem úgy, mint most, a 7-esnél még mindig, hogy csak kerülő módszerrel lehet fieldszintűvé tenni, az említett Title modullal), tehát azt most még nem tudom (utána kellene nézni), konkrétan $node->title-lel lehet-e majd elérni, vagy mondjuk node->field_title-lel... esetleg lesz-e/van-e valami értelmes módszer az API felhasználásával az entitás címének lekérésére.
-
Sk8erPeter
nagyúr
Kezdjük azzal, hogy így a minta is helytelen, és nem is fog működni a dolog.
Így lenne jó:
$pattern = '/[0-9]/';
Aztán ez nem is helyes reguláris kifejezés, mivel ez illeszkedik arra a query stringre is, hogy ?ta=123abc.
Szerintem ide nem feltétlenül indokolt a reguláris kifejezés használata, egyszerűbb egy is_numeric() függvényhívás. Ezenkívül nagyon ocsmány megoldás exit()-tel az egész script futását leállítani Drupalban egy általad tetszőlegesen kiszemelt helyen...exit()-et vagy die()-t (a kettő ekvivalens) csak NAGYON indokolt esetben használj. A template.php-kbe helyezett exittel vagy die-jal azt éred el, hogy a Drupalnak "megtörik" a megjelenése valahol "félúton", vagy még meg sem jelenik semmi, csak azt az üzenetet írja ki, amit megadtál paraméterként a die()-ban. De a hiba kijelzésére drupal_set_message() való:
drupal_set_message(t('An error occurred and processing did not complete.'), 'error');
a form használhatatlanná tétele pedig valami form_alterben elintézendő, de leginkább egy #after_build callbackben, ha erre szükség van, például $form tömb módosításával, aztán az elküldést meg lehet akadályozni validáló függvényben form_set_error()-ral.
A node_load() hívása helyett kevésbé erőforrás-igényes a közvetlen adatbázisból való címlekérés, mondjuk ez abban az esetben nem lesz jó, ha Title modult használsz, mert akkor a Title is egy "rendes" field.Te kérted, hogy vesézzem ki.
-
Sk8erPeter
nagyúr
Tényleg nem értem. A hook_form_alter() sem hívódik meg?
Legalább akkor egy watchdogot próbálj meg a hook_form_alteren belül:
watchdog('test', 'blabla');
vagy ilyesmi. Aztán nézd meg a naplóban, hogy bekerült-e az üzenet az előbbi szöveggel.
Nem ártana megtudni, hogy egyáltalán meghívódik-e a függvény, de kicsit nehéz belőled kihúzni... -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
Ehhez totálisan felesleges volt definiálnod hook_theme-ben egy template-et, az ilyeneket nem is illik template-fájlban elintézni, a template-fájlba NEM kerülhet ilyen jellegű logika, ott az ember legfeljebb elrejthet dolgokat hide()-dal, vagy csak kinyomja a kimenetre, a megfelelő formában, és kész.
Szóval ezt most vagy egy form_alterben, vagy egy preprocess-ben módosítod. De az ilyen "nem működik"-jellegű hibaleírásokkal nehéz mit kezdeni, gondolom azt te is belátod...Először is Devel modult engedélyezed, majd a sminkedben implementálod a hook_form_altert, debuggolás erejéig kiíratsz minden szart, aztán majd kikommenteled, ha kiderítetted, ami neked kell, és persze nem felejtesz el cache-t törölni (drush cc theme-registry):
/**
* Implements hook_form_alter()
*/
function SMINKEDVAGYMODULODNEVE_form_alter(&$form, &$form_state, $form_id){
dsm($form_id, '$form_id in '.__FUNCTION__.'()');
dsm($form, '$form in '.__FUNCTION__.'()');
dsm($form_state, '$form_state in '.__FUNCTION__.'()');
}rájössz, hogy jé, a contact formnak az id-ja "contact_site_form", így implementálod az ennek megfelelő hook_form_FORM_ID_alter()-t:
function SMINKEDVAGYMODULODNEVE_form_contact_site_form_alter(&$form, &$form_state, $form_id){
dsm($form_id, '$form_id in '.__FUNCTION__.'()');
dsm($form, '$form in '.__FUNCTION__.'()');
dsm($form_state, '$form_state in '.__FUNCTION__.'()');
}megint törölsz cache-t, jé, ez is működik, csak most már kizárólag a contact form dolgait buzerálod.
Kideríted, mit akarsz módosítani, szépen a dsm() kimenetét kotorászva, kétszer klikkelve arra a kulcsra, ami neked kell, hogy ki tudd másolni a pontos nevét, aztán kikommenteled a dsm()-eket, majd letiltod a develt (drush dis -y devel).[ Módosította: Eagle16 ]
-
adam_
senior tag
Szóval a struktúrák/menübe hozzak létre kategóriát, és azon belül menüpontokat, amit majd a hírdetés részbe illesszek be kategória választó gyanánt? Taxonomy egyáltalán nem kell hozzá?[link]
Melyik modulba néztem volna bele? A google mapsesbe belenéztem, és a kategóriással is foglalkoztam, html-t is néztem, igaz én a taxonomiával szórakoztam, a videó alapján arra gondoltam, hogy az lehet a "katerógira választó" kialakításának a kulcsa.
Kb. 1 hete ismerkedem Drupallal, sok dolog még nem tiszta a számomra, szerencsére az alapismeret könyv elolvasása után már kezdenek világosak lenni a dolgok.
-
Sk8erPeter
nagyúr
Erre a beállításra gondolok konkrétan:
http://drupal.stackexchange.com/questions/48465/drupal-7-views-contextual-filter-content-nid-content-id-from-url/48535#48535aztán itt pár dolog bekattintásával úgy emlékszem, ki lehet nyerni a node title-t a node id argumentumból. Most nincs előttem, úgyhogy konkretizálni nem tudom, de érdemes adni neki egy próbát.
Ha a Webform lesz, akkor az is egy rendes node lesz, mezőzhetővé válik, van hozzá mindenféle validáció, még azt is lehet, hogy ennek a node id-jéhez csapsz hozzá még egy másikat, mondjuk így:
node/123/related-content/432
most ez persze csak példa, szóval érted. Aztán ezt az argumentumot nagyon egyszerűen ki lehet nyerni arg() függvénnyel:
http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/arg/7
konkrétan arg(2) == "related-content" és arg(3) == 432 lenne.
Ezt egy form_alter-ben lehetne kinyerni, és ez alapján kinyerni a node title-t egy node_load()-dal vagy SELECT title FROM {node} WHERE nid = 432 query-vel, aztán a subject mezőnek egyből átadni ezeket az infókat.Persze lehet teljes node title-t passzolgatni URL-ben, de szerintem nem "biztonságos" (nem biztos, hogy minden böngészőben jól fog működni), meg nem túl szép megoldás.
-
Sk8erPeter
nagyúr
De az jó neked, ha ékezet és egyéb speciális karakterek levágásával érkezik meg a tárgy?
"Nem lenne jó egyáltalán"
Indoklást nem igazán láttam a leírásodban...
Én arról beszéltem, hogy contextual filter lenne a node id, ez az argumentum pedig a beépített eszközök segítségével le lenne cserélve a node title-re, magyarul ez bekerülhetne akár a tárgymeződbe is. Mondjuk azt sem írtad, hogyan kerül be a contact formod tárgyába a title.De egyébként erre a feladatra miért nem a Webformot használod? Többek közt felmérésekre, testreszabottabb kapcsolat-felvételi űrlapok készítésére használható, a beépített contact form ehhez képest csak egy buta kis jószág, egyszerű feladatra, sima kapcsolatfelvételre.
-
Sk8erPeter
nagyúr
"Egy tartalomtípusban van egy email mezőm, ami rejtett, mert contact form segítségével automatikusan generálom a linket Views-ban."
Igaából mi a cél? Biztos, hogy ez a jó megoldás?"Ez azt jelenti, hogy az adott kategóriájú contact form töltődik be és a tárgy a node-title-lel töltődik fel.
Az a kérdésem, hogy nem okoz az problémát, ha a node-title, ezáltal a hivatkozás kis- és nagybetűket, ékezeteket, speciális karaktereket, pl . (pont) tartalmaz?"
Kérdés, a hivatkozás minden böngészőben jól fog-e működni, nem lenne-e jobb, ha inkább node id-t raknál az URL-be, és Views-ban pedig contextual filterrel szűrnél node id-re, majd alakítanád át ebből értelmes címmé.===================
(#395) sh4d0w : hajrá!
===================
(#394) Jeno.L : hát miért, majd valami kulturált, csöcsmentes képet választok, nem?
Mindenesetre írhatnál a magyar drupal.hu fórumra is, hátha tudnak hotlink protectionre kész Drupalos megoldást is, vagy Drupal Answers-re.
Kíváncsi vagyok, hogy alakul, érdekes téma. -
Jeno.L
tag
Sziasztok!
"Köszönhetően" az új, csoda google kép keresőnek csak 50%-t esett vissza az oldalam forgalma mivel most már a user az oldal látogatás nélkül, egyből letöltheti a képet kvázi a googleből. Ok, a kép rankja megmarad, ez nem is baj, csak mivel a forgalom esik vissza az adsense és a hírdetők is kevesebbet fizetnek...
Nah már most egy fórumon linkeltek egy érdekességet ami kb. olyan mint a hotlink protection.
Érdeklődnék, hogy van-e ehhez hasonló is a drupalhoz vagy békéljek meg a tudattal mint az a többi pár millió (ha nem millárd) üzemeltető, hogy a kép keresésből érdemleges látogató többet nem lesz
Mondjuk a keywordökkel is szórakoztak valamit, kb forrong az összes fórum most emiatt a neten -
Sk8erPeter
nagyúr
"Sőt, még új drupal telepítést is csináltam a standarddal"
Na, akkor ebben már előrébb vagy, mint én"Ha csak annyit tudna a drush, hogy nem kell modult letölteni, kicsomagolni, bemásolni, engedélyezni, függőséget letölteni stb, már akkor is megérné használni."
Na igen, a Drupal beépített felületén az admin/modules/install oldalon csak a félkövérrel kiemelt részeket lehet megtenni, az összes többi pöcsölős rabszolga-kattintgatás.Szerk.: amúgy vicces, hogy így ketten elvezetgetünk egy topicot az eszmecserénkkel.
-
Sk8erPeter
nagyúr
Na látod, először még azt mondtad, a Drush olyan melós.
Pedig nagyon durván lerövidíti a szükséges időt az admin-felület buzerálása helyett.
Legutóbb új telepítésnél a Colorbox library-t így töltöttem le a modul engedélyezése után:
drush colorbox-plugin
automatikusan bepakolja a sites/all/libraries-be, kicsomagolva a zipet.
Ezzel kapcsolatban fontos megjegyeznem, hogy érdemes upgrade-elni a legfrissebb Drush-ra, nekem 7.x-5.4 volt fent, de ott rossz volt a MIME-type detektálása, és gzippel akarta kitömöríteni a zippelt fájlt:
http://superuser.com/questions/544153/when-using-gzip-decompress-the-result-is-gzip-myfile-zip-unknown-suffixAmit még ki akarok próbálni, a Drush-ból telepítés friss Drupalnál megadott profilból (itt pl. a standard profilból):
drush site-install standard --site-name="D7test" --site-mail=xyz@example.com --account-name=d7admin --account-pass=1234 --db-url=mysql://d7admin:1234@localhost/db_d7_test
Aztán amit szintén ki szeretnék próbálni, ha lesz időm, hogy saját modulomból implementáljak olyan hookokat, ami Drush-ból elérhető:
Hogyan készítsünk Drush kompatibilis modult, vagyis CLI-ből elérhető Drupal funkciókat
http://www.kalman-hosszu.com/hogyan-keszitsunk-drush-kompatibilis-modult-vagyis-cli-bol-elerheto-drupal-funkciokatAmit épp most csinálok, az a saját testreszabott telepítési profil létrehozása:
Drupal 7 telepítési profil írása
http://www.kalman-hosszu.com/drupal-7-telepitesi-profil-irasa
amire ez jó, az az, hogy egyből települnek a saját moduljaim, amiket berakok a dependency-be, nem kell még egy csomó mindent külön engedélyeznem a telepítést követően; sőt, egyből a telepítés után létrehozhatom a saját CKEditor-profiljaimat, meg egyéb beállításokat is eszközölhetek, külön macera nélkül, csak egyszer meg kell írni a kódot hozzá.Amit az imént olvastam el, az egy cikk azzal kapcsolatban, hogy a moduljainkhoz tartozó JavaScript-kódokban hookszerűségeket biztosítsunk, a jQuery event triggerelésével, ami egyszerűvé teszi más modulokkal a beavatkozást a kódba:
Your Javascript should expose APIs, too!
http://www.lullabot.com/articles/your-javascript-should-expose-apis-tooHa már így kérted, hogy ha van érdekesség, akkor közöljem...
-
Sk8erPeter
nagyúr
Szívesen, majd jelezz vissza, hogy sikerült.
De egyébként ha gyorsan ki akarod próbálni az épp látogatott oldalon, arra van egy nagyon egyszerű lehetőség, egyszerűen megnyitod az épp használt böngésződ fejlesztőpanelét (nyilván FF-nál legyen telepítve a Firebug, Chrome és Opera esetén ez beépített; Ctrl+Shift+I vagy F12), majd a Console fülön egyszerűen másold be ezt a kódrészletet:for(var ckeditorInstanceId in CKEDITOR.instances){
console.log('ckeditorInstanceId');
console.log(ckeditorInstanceId);
console.log('ckEditorInstance:');
console.log(ckEditorInstance);
var ckEditorInstance = CKEDITOR.instances[ckeditorInstanceId];
ckEditorInstance.resize(1000, 900);
}Így on-the-fly tudod egyből átméretezni, hogy ki tudd próbálni, melyik méret a legmegfelelőbb.
Szerk.: nyilván az első 4 sor csak debuggolás céljára hasznos, hogy meg tudd nézegetni, mi van ezekben az objektumokban, én mindig a konzolra szoktam kiíratni, ha gyorsan meg akarok vizsgálgatni valamit JS-ben.
-
Sk8erPeter
nagyúr
No, sorry, kicsit több lett, mint negyed óra, társaságom lett, aztán végül már nem volt energiám ezzel foglalkozni.
Ami működőképes az átméretezésre, most modulból méretezek át, de ugyanezt meg lehetne tenni sminkből is (végül is sminkelési feladat inkább, mivel adott helyen szeretnéd átszabni, a megjelenésnek megfelelően, de a lényeg ugyanaz):
/**
* Implements hook_form_alter().
*/
function testmodule_form_alter(&$form, &$form_state, $form_id) {
// az after_build függvényben már megvannak az egyes elemek HTML id-jai (itt még nem)
$form['#after_build'][] = 'testmodule_form_alter_after_build';
}
/**
* Form after build function
*/
function testmodule_form_alter_after_build($form, &$form_state) {
$form_id = $form['#form_id'];
switch ($form_id) {
// most a példa kedvéért az Article content type formjánál fogom átszabni a CKEditor szélességét, magasságát
case 'article_node_form':
drupal_add_js(drupal_get_path('module', 'testmodule') . '/js/ckEditorResizing.behaviors.js', array('type' => 'file', 'scope' => 'footer', 'weight' => 100));
// itt az Article content type body-jánál a summary-hez és a fő törzsszöveghez tartozó CKEditort fogom átméretezni!
// a HTML id azért kell, mert a CKEDITOR.instances tömböt fogjuk felhasználni a JS-kódban, és ebben HTML id-k kulcsai szerint vannak meg az objektumok, a rá vonatkozó attribútumok és metódusok
drupal_add_js(array(
'testmodule' => array(
'ckEditorResizing' => array(
array(
'id' => $form['body']['und'][0]['summary']['#id'],
'width' => 400,
'height' => 200
),
array(
'id' => $form['body']['und'][0]['value']['#id'],
'width' => 300,
// 'width' => '50%',
'height' => 600
)
)
)
), 'setting');
break;
}
return $form;
}Aztán a testmodule/js könyvtárban van egy
ckEditorResizing.behaviors.js
fájl, aminek a tartalma a következő:(function ($, Drupal) {
Drupal.behaviors.ckEditorResizing = {
attach: function (context, settings) {
var self = this;
// némi késleltetéssel kell átméretezni, miután inicializálódott
window.setTimeout(function(){
self.resizeCKEditor(context, settings);
}, 600);
},
resizeCKEditor : function (context, settings) {
if(settings['testmodule']['ckEditorResizing']){
var ckEditorResizingData = settings['testmodule']['ckEditorResizing'];
for(var i = 0; i < ckEditorResizingData.length; i++){
var ckEditorInstance = CKEDITOR.instances[ckEditorResizingData[i].id];
ckEditorInstance.resize(ckEditorResizingData[i].width, ckEditorResizingData[i].height);
}
}
}
};
})(jQuery, Drupal);Ez csak szemléltetés, biztos lehetne ezen szépíteni (például elég ronda az a multidimenziós tömb valami rendes osztály helyett, de sajnos ezt a multidimenziós tömb szemléletet a 7-es Drupalban (valszeg még 8-asban is) elég sokszor alkalmazzák).
A lényeg tehát, hogy a .resize() metódust hívjuk meg:
http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.editor.html#resizeVonatkozó cikk még:
How Do I Change the Size of the Editor on the Fly?
http://docs.cksource.com/CKEditor_3.x/Howto/Editor_Size_On_The_FlyHa nem érthető, kérdezz.
-
Sk8erPeter
nagyúr
Felejtsd el, amit az előbb írtam, a form_alteres megoldás nem lesz jó, értelemszerűen JavaScripttel kell megoldani, mindjárt le is írom, hogyan.
Nem kell emiatt eldobnod a CKEditort, nagyon egyszerű megoldani, konzolból (Ctrl+Shift+I vagy F12) már megcsináltam, mindjárt írok valami tisztességes Drupal-megoldást, csak most egy negyed órára nem leszek gépnél, úgyhogy az tragédia.
Na, szóval nemsokára megírom. -
Sk8erPeter
nagyúr
Itt egy hook_form_alter-es megoldást javasol valaki (még nem próbáltam, ez így ér-e valamit):
http://ckeditor.com/comment/39228#comment-39228function MODULODNEVE_form_alter(&$form, &$form_state, $form_id) {
switch ($form_id) {
case 'taxonomy_form_term': // vagy más form_id
$form['MEZONEVE']['description']['#rows'] = 4;
break;
}
}(Szerk.: vagy akár MODULODNEVE helyett sminked neve is szerepelhet.)
-
Sk8erPeter
nagyúr
"Valahogy kezd az az érzésem lenni, hogy két irányba változott a drupal 7. Bizonyos téren sokkal jobban kezelhető, azonban vannak olyan területek (modulok), ahol bonyolultabb lett. Tudom, modul != core. De akkor is.
"
Hát ha tudod, akkor meg minek jelentesz ki ilyet?
Hogy egy 7-esre elkészített modul nehézkesebb lett, az lehet annak a hibája, aki fejlesztette, meg azé is, aki használja.
Viccet félretéve a Drupal 7 elég sok mindenben más lett, rengeteg dologban más a koncepció, mint a 6-osnál, de hosszabb használat után rá fogsz jönni, hogy előnyére változott, sok mindennek a megvalósítása hatékonyabb.
Hogy konkrétan a User alert modulban mit műveltek, az már teljesen más lapra tartozik, köze nincs ahhoz, hogy a 7-es core miben lett más, mint a 6-os. -
Siriusb
veterán
Felraktam még a search_page_api modult, így már sikerült összekalapálni. Elvileg a fuzzy telepítésekor létre kellett volna jönnie szervernek és indexnek, nálam csak index volt, azt is be kellett állítani egy szerver hozzáadása után.
Viszont most a user_alert modullal kínlódok, drupal 6-ban pikk-pakk működött, 7-esben meg nem jeleníti meg a tartalmat. Valahogy kezd az az érzésem lenni, hogy két irányba változott a drupal 7. Bizonyos téren sokkal jobban kezelhető, azonban vannak olyan területek (modulok), ahol bonyolultabb lett. Tudom, modul != core. De akkor is.
Szóval a a user alerttel kapcsolatban van ötlet, hallgatom. -
Sk8erPeter
nagyúr
Még nem próbáltam, de pont a Fuzzy Search nem jó? Finderrel meg lehet autocomplete-ezni.
=========
(#362) execute93 :
nekem nincs tapasztalatom a sminkkel, szóval ezt az utat egyedül kell végigjárnod.Hacsak nem találsz neten olyan forrást, ahol leírják, hogy lesz olyan, mint a belinkelt cuccos. Vagy megkérdezheted drupal.hu fórumán is, ha nem jutsz előrébb. Mindenesetre elvileg a kis fülecskékkel ki tudod kapcsolni a gridek meg régiók jelzését, de gondolom arra már rájöttél.
-
Sk8erPeter
nagyúr
Nekem komplett site upgrade-del, mármint major verzióváltással nincs tapasztalatom, van egy 6-os oldalam, amit elképesztő nagy szopás lenne átültetni. Te simán Drush-sal ezt is megcsináltad hibátlanul? Az elég fasza, gratula!
Speciel a Zen subtheme átültetését én kisebb szívásnak tartottam volna elsőre, mint magának a site-nak a 6-ról 7-re upgrade-elését, de ezek szerint neked szerencséd volt, hogy nem volt agyonkomplikálva az oldalad ilyen-olyan contrib modulokkal.Mindenesetre a legújabb Zen theme-ek már HTML5-ös markupot használnak, érdemes tehát ehhez igazodni.
Amúgy a sminknél sok minden másképp van a 7-esnél. A theme_ kezdetű függvények nagy részénél sok argumentum volt még a Drupal 6-osnál, D7-nél már többnyire egyetlen $variables tömbbe gyűjtögetik az adatokat különbözö tömbindexek szerint.
Nagyon komplikált dolgok vannak a sminkedben? Sok theme function override van, vagy egyedi sminkmegoldás a 6-os kódodban? -
Siriusb
veterán
A jó öreg módon egy helyi másolaton megcsináltam a 6-ról 7-re frissítést. Eljátszottam vele egy darabig, pedig elég egyszerű, kevés modullal. Egyelőre működni látszik, bár nem igazán tesztelgettem. Nem mertem még belevágni a zen subtheme átültetésébe, remélem nem nagy szivató...
Örülnék, ha valaki itt azt mondaná, neki pikkpakk ment. -
Sk8erPeter
nagyúr
Hidd el, nem gyökerek írták a Drush-t, úgyhogy pontosan tudják, mit csinálnak, és sokan használják éles környezetben is. És mint említettem vala, ez jóval biztonságosabb, mint a manuális tákolgatások.
Főleg frissítésnél jön ki eléggé a különbség, csak stimmeljenek a jogosultságok.
De így is-úgy is igaz, hogy backupolni minden komolyabb művelet előtt inkább többször is érdemes, MINDENRŐL. -
Sk8erPeter
nagyúr
Hát ez elég rossz hozzáállás a Drush esetén.
Paranoia. Miért, gondolod, hogy elküldi a szupertitkos adataidat valakinek?
Egyébként Drush-sal jóval kevesebb az esély az update-elb@szásra, mint manuálisan, úgyhogy már csak ezért is érdemes azzal elvégezni ezt a műveletet. Még ha nem is szereted az automatizálást.
De ha nem szereted, hogy "túl automatikusan" megy valami, akkor nem kéne használnod a Drupalt, hanem mondjuk egy keretrendszerben meg kéne írnod az egészet. -
Sk8erPeter
nagyúr
Ettől függetlenül remélem, azért frissítgeted néha a Drupalt, még ha 6-os is, mivel ahhoz is jelentek meg bőven biztonsági foltozások...
Ha nem, akkor ideje kipróbálnod a Drush-t!
De nem csak azért, mert ezt is sokkal egyszerűbbé teszi, hanem rengeteg pöcsölős folyamatot.
-
Sk8erPeter
nagyúr
Van rá példa, lásd a Views core-ba való bekerülését:
Views in Drupal 8
http://buytaert.net/views-in-drupal-8Hát nem hiszem, hogy várni kéne 2013 szeptemberéig...
Mondjuk nem csodálom, hogy nehezen veszed rá magad, hogy belevágj, mert az biztos nem két perc. Nagyon összetett, vagy csak cikkek vannak lényegében? Van benne valami egyedi, amit nehéz áttenni 7-esre? Csak azért kérdezem, mert nekem van egy 6-osban készült oldalam, amit nem lenne például egyszerű átrakni.
-
Sk8erPeter
nagyúr
Én most kipróbáltam localhoston, mert úgy emlékeztem, hogy kitörlődik, ha egyből nem is, legalább a következő cron lefutásakor. Ez a hsz. meg is erősíti ezt.
Sima Article típusnál feltöltöttem az Image fieldhez egy 12 MB-os képet, elmentettem a node-ot, majd utána rámentem a szerkesztésre, és ott a Remove gombbal eltávolítottam a képet, majd megint elmentettem a node-ot. Egyből törölte a fájlt a sites/default/files/field/image könyvtárból is! -
Sk8erPeter
nagyúr
Háde így mondják.
Nézd:"Warning
Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why."
===============
(#222) SecMan : fura, nálam ugyanezek vannak fent a tesztcélú Drupalnál, ahol most kipróbáltam.
Még megpróbálhatnál valahol egy másik, szintén AJAX-ot igénylő dolgot végrehajtani, hogy az működik-e.Milyen modulok vannak fent nálad?
Jöjjünk rá a hiba okára.===============
(#223) Siriusb : szerintem már korábban gondja lett volna, ha nincs engedélyezve a PDO MySQL-hez tartozó része, mert elvileg requirement:
"Drupal 7 will only support MySQL 5.0.15 or higher, and requires the PDO database extension for PHP (see What is PDO?)." -
Sk8erPeter
nagyúr
Igen, mert nem mindig lesz objektum a menu_get_object(); eredménye, van, amikor NULL lesz. Igazából amikor írtam a kódot, gyorsan kiollóztam a Te kódodból innen ezt a részt, mert őszintén szólva hirtelen nem tűnt fel ez a hibalehetőség, tehát MEGINT A TE HIBÁD!!
A megoldás az isset() használata:$node = menu_get_object();
if (isset($node->nid)) {
....
}"Kihagytad a leírásból a function zenTest_links($variables) -t, ami azért a pastebin-es kódban benne van."
Persze, hogy kihagytam, mert rohadt sok helyet foglal.===================
(#214) SecMan : nálam is jól működik!
Két dolgot megpróbálhatnál: átmenetileg Devel és Theme Developer modul kikapcsolása (ha egyáltalán engedélyezve van), vagy a Comment Abuse modul letiltása, uninstall, majd reinstall.
Melyik változatot raktad fel? -
Sk8erPeter
nagyúr
"Universally Unique IDentifier"-t generál Drupal-objektumokhoz, pl. entitásokhoz, ez van a leírásban is.
Már f×ngom sincs, melyik modul(ok)nak kellett. Ez egyébként csak a test site-on van fent, de ott sok más szarság is fent van.
A Drush-hoz Windows-os telepítő is van.
Amúgy a var_dump-nál még rövidebb is a dsm vagy dvm meg a többi.
Na, most egész rövidre sikerült a hsz.
-
Sk8erPeter
nagyúr
Hát az még várat magára egy darabig.
Csak jó dolgokra beszélem rá erőszakosan az embereket.
Egyébként nagyon örülök neki, hogy ezek nálad is beváltak."Ha jól emlékszem drupal 6-nál a dpm-et használtam, viszont a 7-esben hibával elszállt."
Az hogy lehet? Pedig még a 8-as változatnál is működnie kell a dpm-nek: dpm().Én azért használom a dsm()-et, mert elég beszédes a neve, a drupal_set_message-ből van összerakva.
Ez így pont leírja, amit csinál. A státuszüzenetekhez fogja kiírni szétnyitható változatban a változókat, mármint kibontható, ha nem egy stringről, hanem mondjuk egy tömbről van szó.
A dvm() pedig var_export-ot használ, stb..."Néha meg bekandikál a var_dump(), ha rá kell keresni valamire"
Ez nem biztos, hogy jó ötlet. Mármint pont a var_dump alkalmazása. Nem biztos, hogy ott fogod kiprintelni a változó eredményét, ahol nem töri szét mondjuk a megjelenítést. Viszont ezt áthidalják a Devel modul által elérhető függvények, mert hívnak egy drupal_set_message-et, és akkor a státuszüzenetek közé fog kerülni a változók tartalma.
(Akkor már var_export($valtozo, TRUE), a TRUE-val visszaadja az értéket, ezt meg kiírathatod a megfelelő helyen... áhh, melós, inkább használd a Devel modul sajátjait.
Mondjuk én annak idején, amikor nem ismertem eléggé a Devel modult, felfedeztem a spanyolviaszt, mert egy ilyen függvényt írtam (igaz, ez sem rossz, a célnak megfelel):function var_export_drupal_set_message($var, $text = ' __ ', $output_type = TRUE, $type = 'status') {
// $type: e.g. 'status'
if (is_string($var)) {
$var = htmlentities($var);
}
$msg_to_output =
'
<p>' . $text . ($output_type ? ' (type: ' . gettype($var) . ')' : '') . ':
</p>
<pre>' . var_export($var, TRUE) . '</pre>
<hr />
';
drupal_set_message($msg_to_output, $type);
}Ezt is meghívhatod így:
var_export_drupal_set_message($valtozo, 'ez az én változóm');
Ez kb. ugyanazt csinálja, mint a dvm();.
Szerk.: na, már megint sikerült egy óriási hsz.-t kreálnom...
-
Sk8erPeter
nagyúr
"Akkor jobban érteném, mikor milyen hook-ot célszerű alkalmazni."
Csak kérdezz, abban van a kihívás.
Több fontos hook van ezzel kapcsolatban:hook_node_load
hook_node_view
stb.Amit mindenképp érdemes használni, az a Devel modul fejlesztéshez használható függvénye, dsm(), dvm(), stb., példa:
function myModule_node_view($node, $view_mode, $langcode) {
dsm($node, '$node variable in '.__FUNCTION__.'()');
dsm($view_mode, '$view_mode variable in '.__FUNCTION__.'()');
// ........................
}Ezt mindenképp próbáld ki, persze template.php-ben vagymáshol is tudod használni ezt a függvényt, iszonyú hasznos, ha átlátható módon szeretnéd "kinyomtatni" a változók tartalmát. Egy csomó időt spórolhatsz meg magadnak ezzel.
Hát ez hihetetlen, hogy minden egyes hozzászólásomnál annyit elkezdek pofázni, hogy le kell magam lőni, hogy végre abbahagyjam, mindenről eszembe jut valami.
Biztos az az oka, hogy öröm, hogy végre valakivel tudok dumálni érdemben a Drupalról.
Mondjuk a drupal.hu-n is meg lehet ezt tenni, de az a fórum annyira nem áll közel a szívemhez. -
Sk8erPeter
nagyúr
Szívesen! Most már tényleg megérdemeltem, hogy valaki dobjon egy csontot...Na, vissza a Drupalhoz.
"Értem én, hogy csak a kimenet számít, de majdnem mindenhol azzal találkoztam, hogy ott van paraméterként a &$variables, szóval furcsa volt."
Biza, de ha jól megnézed, a $variables előtt ott van a referenciát jelző karakter (&):
Passing by Reference
Tehát a változót referencia szerint adjuk át a függvénynek, ezt a függvény fejlécében jelezni kell; ez azt jelenti, hogy akármit is változtatsz ezen a változón, az a hívás helyén is változni fog.
Erre pont jó egy tök egyszerű példa a php.net-en:
function foo(&$var)
{
$var++;
}
$a=5;
foo($a);
// $a is 6 hereTehát nem visszatérési értéket vizsgálnak, hanem az adott függvény kap egy referenciát, az adott függvényben hozzácsapod a változóhoz a dolgaidat, vagy épp törölsz belőlük, stb., tehát a tömböket nem kell állandóan lemásolgatni, aminek mondjuk elég nagy jelentősége van memóriaspórolási célból.
Gondolj bele, milyen erőforrás-igénye lenne az amúgy is erőforrás-igényes Drupalnak, ha minden egyes brutális nagy tömböt le kellene másolni.Rövid példával:
function blabla(&$variables){
$variables['asdasd'] = 'bla';
unset($variables['nem']);
}
$myVariables = array();
$myVariables['igen'] = 'NEM!';
$myVariables['nem'] = 'IGEN!'; // :D
blabla($myVariables);Az eredménye ennek:
$myVariables = array(
'igen' => 'NEM!',
'asdasd' => 'bla'
);Tehát a függvényben hozzácsaptam egy adott kulcson lévő értéket ('asdasd' kulcs), meg elvettem egyet (a 'nem' kulcsban lévő értéket), aztán ez lett belőle.
Remélem érthető.A hook_form_alter és ehhez hasonló jellegű függvények (amikben változtathatsz a beállított értékeken) is referenciákat kapnak.
Ez a konvenció elég könnyen megszokható, ha már megérted a miérteket.A hook_theme és egyéb függvények nem ilyen jellegű változtatásokra valók, ott visszatérési értéket vár a Drupal, nem ad át referenciaként semmit.
-
Sk8erPeter
nagyúr
"Egyébként én mindent cache-t ki szoktam kapcsolni, amíg turkálok, így is néha kell egy plusz ctrl+f5, hogy frissüljön a böngésző."
A Drupal attól még bizonyos dolgokat cache-elhet, bár ha Zennél úgy állítottad be, hogy minden oldalfrissítésnél frissítse a theme registry-t, akkor okés, bár eléggé lassítja az oldalbetöltést, tehát nem biztos, hogy mindig érdemes ezt bekapcsolva hagyni, csak legfeljebb akkor, ha tényleg folyamatosan olyan dolgokat pakolsz a template.php-be vagy hasonló helyre, aminél a módosítások után amúgy is üríteni kéne a cache-t.
Bár ha SSD-n van a webszervered, akkor nagy eséllyel majdnem "mindegy", hogy be van-e kapcsolva, vagy sem."Ezt a függvényt nem teljesen értem. Igazából azt furcsállom, hogy nincs bemenet."
Igen, a bemeneteket lustaságból hagytam le, mert jelen esetben úgysincs szükségem a hook_theme() leírásában látható ($existing, $type, $theme, $path) változókra, egyébként ennek a függvénynek úgyis csak a KIMENETE számít: visszaadsz egy tömböt a modulod/theme-ed által deklarált theme implementation(ök)ről.
Tehát a bemenet csak segítségül szolgálhat, hasznos lehet bizonyos esetekben, de egyébként nincs rá feltétlenül szükség. A bizonyos eseteknél arra gondolok, hogy mondjuk a már meglévő implementációkból szeretnél kiszedni valami adatot ($existing tömb), esetleg az elérési utat fel akarod használni template fájlhoz ($path string), vagy hasonló. (pl. ha egy template-fájlnak adod át a theme bizonyos változóit [ilyenekre kell gondolni template fájloknál, mint a block.tpl.php és hasonlók]).Ha már block, csak hogy megértsd, ehhez hasonló jellegű végül is a hook_block_info() is, ott sincs elvárt BEMENET, csupán elvárt KIMENET! Itt előre szólsz a Drupalnak, hogy a modulod milyen blokkokat fog definiálni. Aztán a hook_block_view() megfelelő implementációját is elő fogja venni a Drupal, és szintén elvár egy kimenetet, de itt viszont már fontos a bemenet is, vagyis a $delta változó, ami megmondja, hogy épp melyik blokkot is szeretné renderelni az általad megadottak alapján a Drupal.
=========================================
Abból, hogy "a megfelelő helyre megy", számomra nem sok derül ki.
Ettől függetlenül értem, mire gondolsz.
Tulajdonképpen abból a szempontból jogos, amit mondasz, hogy bár magában az AKTÍV theme-ben definiálod a theme megfelelő implementációját, és ott is implementálod (ez elég kemény magyar mondat volt...), végül is az engedélyezett modulok még úgy emlékszem (most, hogy mondod), végezhetnek rajta módosítást egy megfelelő preprocess függvénnyel.Jelen esetben én csak magára a theme-re koncentráltam, az ott végzett módosításokra, mert nagyon ragaszkodtál hozzá, hogy mindent a template.php-ből végezz el.
TEHÁT A TE HIBÁD AZ EGÉSZ!!!Na jó, akkor most megmutatom a legjobb változatot, ahol MODULBAN implementálom a hook_theme-et, ott hozom létre a megfelelő theme_ kezdetű fájlt is, majd ezt abban a theme-ben bírálod felül, amelyikben csak akarod:
/**
* Implements hook_theme()
*/
function myModule_theme($existing, $type, $theme, $path) {
return array(
'links__locale_block' => array(
'variables' => array('links' => NULL, 'attributes' => array('class' => array('links')), 'heading' => array()),
),
);
}
/**
* @see theme_links()
*
* @param array $variables
* @return string
*/
function theme_links__locale_block($variables) {
$node = menu_get_object();
if ($node->nid) {
if ($node->type == 'test_multilingual_type') {
$myTestFieldValue = $node->field_title_for_test['und'][0]['value'];
foreach ($variables['links'] as $langcode => $langLinksArray) {
$variables['links'][$langcode]['attributes']['title'] = t('!myTestFieldValue (original: !originalTitle)', array(
'!myTestFieldValue' => $myTestFieldValue,
'!originalTitle' => $langLinksArray['attributes']['title'],
)
);
}
}
}
return theme('links', $variables);
}Így már biztos, hogy a Drupal-konvenciók szerint fog működni a dolog.
Persze ha nagyon akarod, mindezt a template.php fájlban is megcsinálhatod, de ideje leszakadni kicsit a template.php-ről, és modult fejleszteni.Ha a fentit szeretnéd felülbírálni egy theme-ben, akkor a theme_ előtagot helyettesítsd a sajátThemeNeve_ előtaggal, pl. ha a subtheme-ed neve zenTest, akkor:
function zenTest_links__locale_block($variables){
// ... a fentit kimásolod, aztán a megfelelő módosításokat elvégzed!!
} -
Sk8erPeter
nagyúr
Ja tényleg, azt nem vettem észre, hogy csak 6-osig van elkészítve.
"És azt derítettem ki még, hogy theme() függvényt illik inkább használni"
Mi? Ezt kifejtenéd bővebben?Tudom, mire való a theme függvény, de ebben a kontextusban nem igazán értem ("inkább" - mi helyett?).
Egyébként a candidate functions-nél sokáig nem jöttem rá, hogy kell használni, de aztán próbálkoztam, kiderült, hogy csak a modulban/theme-ben deklarálni kell a felajánlott nevet a hook_theme implementálásával, ahogy mutattam, majd definiálni a függvényt.
-
Sk8erPeter
nagyúr
Hmm, már értem. Most hirtelen nem jut eszembe ellenérv.
Viszont kipróbálhatnál erre is egy modult, ezt: Node Title.
Ezt még nem próbáltam, de elvileg ez is csak megjelenítéskor változtat a címen:
"The difference with this module is mainly in functionality. Automatic Nodetitles hides the actual title field from the node creation form and let you configure a default title that will be stored as the actual node title in the database. This module does not change the actual title of the node, it just lets you modify the display of a node title when you view it."Szerk.:
Egyébként azt el tudod esetleg mondani, mi az alkalmazási terület, ami miatt ez szükséges, amit csinálsz? Csak hogy jobban értsem.
Elmondok egy saját példát, ahol szükségem volt az Automatic Nodetitles-re: júzerek feltölthetik Youtube-videók linkjeit, én pedig nem akarom, hogy a címet manuálisan adják meg, hanem egy PHP pattern segítségével (igen, sajnos itt még használom a PHP filtert, itt még nem alkalmaztam hookot) kiszedem Youtube-ról a videó ott tárolt címét, majd ezt adom meg a node címének. Tehát a cím automatikusan generálódik a Youtube-os cím alapján.
Nálad mi az alkalmazás módja?
Csakis egyszer adható meg a node-nak cím? Utána azt már nem is lehet változtatni többé?
Ha jól értem, egyszer megvan a node title, ezt a felhasználó nem látja, az csak belső használatra kell, ők egy mező tartalmát látják csak. De a mező tartalmát ők adják meg? Azt tudják módosítani?
Azért kérdezem megint, mert a kerülő megoldást keresem: tehát pl. hogy nem elég-e, ha épp az általad látott cím tárolódik mezőértékként, csak az admin-oldalakon kell kiszedni a megfelelő címet, és akkor kisebb szívás, tehát a felhasználók a "rendes" node title-t látják. -
Sk8erPeter
nagyúr
"A node title úgymond belső használatra (azonosításra van), viszont nem kéne publikus legyen, mert nem értelmezhető a látogatók számára."
Nem értem. Miért lenne publikus? Az Automatic Nodetitles segítségével a content type szerkesztésénél beállíthatsz egy mintát, ami alapján generálódik a cím, amihez fieldeket is felhasználhatsz, lásd ezt: [link].
Akár teljesen elrejtheted a "Title" mezőt, és beállíthatod, hogy az milyen minta alapján generálódjon (pl. épp a másik mezőből!).
Ennek a szerkesztéséhez meg csak annak van joga, akinek a content type-ot is van joga szerkeszteni, tehát mezei júzer ezt egyáltalán nem látja!
A cím tehát így is automatikusan generálódik, ebből a felhasználó ebből semmit nem lát.
Ez miért nem jó?"Ha változik a tartalom, amiből a dinamikusan előállított title keletkezik, az úgy helyes, hiszen a node - ban található mezőből állítom elő (kivéve egy helyen, ahol konstans), azaz nem borul az egész, hanem úgy működik, ahogy szeretném."
Igen, és pont ezt, amit most leírtál, meg lehet csinálni a már említett Automatic Nodetitles modul segítségével.Mindenesetre találtam egy megoldást a language switcher block title mezőjének megváltoztatására, gányolás nélkül, mindjárt leírom azt is, csak előbb készítek screenshotokat, hogy érthetőbb legyen.
-
Sk8erPeter
nagyúr
Most megint megnéztem a kódodat, és hát azt kell, hogy mondjam, hogy a "nem szép" kifejezés elég finom volt ennek jellemzésére....
Mi történik, ha változtatsz a címeken, tartalmakon, akkor borul az egész?
Basszus, most értettem meg, mire gondolsz a language switchernél... tehát a lényeg, hogy a title-be kerül bele a tartalom, mind a blokknál, mind pedig a node aljánál lévő nyelvváltoztató linkeknél. Akkor ezt mondd!
Na mindjárt utánanézek, hogy lehet ezt szépen megoldani.
De azért közben gyorsan megkérdezem: miért akarsz ezzel feltétlenül szívni, miért nem jó neked a linkelt modul, amivel patternek segítségével éred el ugyanezt?Page title megváltoztatására hátha hasznát veszed: [link]. Bár erre is vannak modulok, felesleges vele szopni.
"Valami olyat olvastam a fejlesztőjétől, hogy írják meg rendesen a többiek a moduljukat, ő nem foglalkozik vele. Ilyesmire emlékszem."
De utálom az ilyen fejlesztőket...biztos rendkívül nehéz lenne írni egy ellenőrző függvényt, hogy minden kulcs a helyén van-e.
"Le vagyok nyűgözve, a tarhelypark.hu-n van script a drupal 7.14 (!) telepítésére. Fél perc az egész, létrehoz adatbázist, usert."
Jaja, a Tárhelypark CPanelje tényleg faszán működik, ez engem is meglepett, hogy tele van funkciókkal, ami szép és jó, de ugye úgy álltam hozzá, hogy tuti a fele nem működik, és pedig de... ami link ott van, az tényleg működik!Legalább így kéne hozzáállnia a dolgokhoz minden szolgáltatónak.
-
Sk8erPeter
nagyúr
$last_pos = strpos($variables['content'],'"',$first_pos+8);
Te most itt miket művelsz?Őszintén szólva nem volt nagyon kedvem megérteni a kódot, mert számomra eléggé homály. Mi az a +8?
Miért pont 8?
Egyébként nálad hogy van benne a node title a language switcher block-ban?
Nálam sem annál, sem a Language switcher dropdown blokkjában nincs benne: [link].(#185) Siriusb : ja, ehhez még annyit, hogy ezek szerint a Pathauto elég érdekes dolgokat művelhet, ha egy másik modul csak úgy tönkrevághatja... bár elvileg a Pathauto is biztosít hookokat ahhoz, hogy URL aliast létre tudjon hozni a modult, amennyiben a Pathauto modul megvan, lehet, hogy az vágja tönkre ilyenkor a dolgot, hogy valamelyik modul fosul implementálja az adott hookot. Bár akkor az meg a Pathauto modul hibája, ha ezt az esetet nem kezeli le.
Egyébként nem tudom, mi a véleményetek erről, de én azt tapasztaltam, hogy Drupalnál már a core-ban is sok esetben a hibakezelés eléggé csapnivaló (a modulok fejlesztői meg sokszor átveszik ezt a mentalitást). Miért kell nekem PHP-s warningokon keresztül értesülnöm róla, hogy valami modul hülyeséget csinált?
Van egy olyan érzésem, hogy a Drupal core-ban is esetleges teljesítménybeli okokból nem akartak mindenféle hibát lekezelni, de néha indokolatlannak érzem, hogy megspórolták - szerintem az sem normális, hogy nagyobb hiba elkövetésénél fehér képernyőt észlelsz, aztán debuggoljál, vazze...(#184) SecMan : várom.
-
Sk8erPeter
nagyúr
phpMyAdmin + BLOB:
Configuring phpmyadmin to show Drupal 7 BLOB data# Show 1000 rows instead of 30 by default
$cfg['MaxRows'] = 1000;
# Show BLOB data as a string not hex.
$cfg['DisplayBinaryAsHex'] = FALSE;
# Show BLOB data in row detail pages.
$cfg['ProtectBinary'] = FALSE;
# Show BLOB data on table browse pages. Hack to hardcode all requests.
$_REQUEST['display_blob'] = TRUE; -
Siriusb
veterán
Meguntam és favágó módon oldottam meg:
function MY_THEME_preprocess_block(&$variables, $hook) {
if ($variables['block_html_id'] == 'block-locale-language'){
//removing node title value from language switcher url title
$first_pos = 0;
for ($i=0;$i<2;$i++){
$first_pos = strpos($variables['content'],'class="language-link',$first_pos);
$first_pos = strpos($variables['content'],'title',$first_pos);
$last_pos = strpos($variables['content'],'"',$first_pos+8);
$variables['content'] = substr_replace($variables['content'],'',$first_pos,$last_pos-$first_pos+1);
}
}
}
Nem szép, de hatékony -
Sk8erPeter
nagyúr
Milyen típusú, amit változtatni akarsz?
Én most létrehoztam egy List (integer) mezőt (Select list widgettel), és tudtam változtatni utólag is a kulcsokat is meg az értékeket is.
Tudsz mellékelni screenshotot?"A Variables 2.1 verziójával újra láthatóak a Patterns fülön lévő tartalom típusok, mármint az azokra vonatkozó beállítási lehetőségek."
Én nem értem nálad ezeket a parákat, nálam Variable 7.x-1.1 van fent, és minden szükséges pattern látszik: http://i.imgur.com/GYEdB.png
Nem jöttél még rá, mitől tűnnek el úgy hirtelen ezek a mezők, meg fordulnak elő ilyen furcsa problémák?Ja, még nem is gratuláltam, hogy már egyedi avatarod van, szóval grat.
-
Sk8erPeter
nagyúr
Nem lesz "baj" belőle.
Más érték fog tartozni hozzá, az már más kérdés, hogy nem engedi, mert vannak már feltöltött értékek.
(#175) Siriusb: ezt most nem vágom, hogy tűnt el neked minden?
(#176) Siriusb : mármint mit oldott meg, visszakerültek a mezők, vagy mi?==========
(#177) SecMan : na, micsoda megkönnyebbülés, hogy azért mást is érdekel a Drupal!
Nem kicsit hajtépős hibát én is tudok neked mutatni, ezt nem tudom, láttad-e még korábban, mondjuk ez NEM user error, hanem valami érthetetlen baromság:
[link]
Azóta sem jöttem rá az okára. A kódot kénytelen voltam helyettesíteni az Ubercart core modulban, a Conditional Actions-nél úgy, hogy működjön. -
Sk8erPeter
nagyúr
ja, hát ez már lehet conditional stylesheet, csak az nem, amit az imént "idéztél" a kódból.
Szóval arra gondoltál, de mást mutattál?Amúgy azért nem rossz, hogy ketten viszünk egy topicot.
A cél a topic kiemeltté nyilváníttatása azáltal, hogy elképesztő aktív munkát folytatunk itt.
-
Sk8erPeter
nagyúr
"A linked az conditional stylesheet."
Ebben nincs semmi stylesheet, szóval csak az első fele igaz, hogy conditional.Ettől még ehhez a modulhoz nincs köze.
-
Sk8erPeter
nagyúr
Hogy néz ki nálad konkrétan az erre vonatkozó kód?
Ilyen, mint itt? Lásd View source. -
Sk8erPeter
nagyúr
Jaja, jól sejted.
Amúgy megtévesztő az lt-ie9 class, mert azt sejteti, hogy az összes IE-re vonatkozik, ami IE9-nél kisebb verziószámú, pedig csak IE8-ra vonatkozik.
Ennek tehát inkább valahogy így lenne értelme:
<!--[if lt IE 9]>
<html class="lt-ie9" lang="en" dir="ltr">
<![endif]-->Ha extra dolgokat akarsz detektálni (pl. CSS3-as, HTML5-ös dolgok támogatása, stb.), és megfelel, hogy JavaScript-támogatás kell hozzá, akkor tudom ajánlani a Modernizr-t, ellátja mindenféle class-okkal a <html> taget, attól függően, mit támogat a böngésző, és természetesen van modul is hozzá. Én ezt többek közt a CSS3-as transition támogatottságának detektálására használtam, a CSS-fájlba az ennek megfelelő class-okat raktam, példa:
.csstransitions
#navigation ul.links li a:hover
{
...
} -
Sk8erPeter
nagyúr
Szerintem ne szívj vele, használd ezt a modult:
Automatic NodetitlesHasználhatsz vele tokeneket a meglévő fieldekre, példa: [link].
Elég jól működik.De szólj, ha valamiért ez nem felel meg, és akkor tovább dumálunk az ügyről.
Ajánlott függvény: drupal_set_title(). -
Sk8erPeter
nagyúr
"<front>, ez az, amit php filterrel sem tudsz használni egy blokkban, szerintem."
De szerintemek helyett miért nem próbálod ki végre?
Nem csak a levegőbe beszélek, kipróbáltam, mielőtt leírtam. Meg még a megfelelő függvényt is belinkeltem, a dokumentációból idézett résszel együtt, nem tudom, hogy győzzelek még meg- pl. úgy, hogy kipróbálod magad is.
Jaja, nem baj az, pörgesd csak a topicot, legalább jár az agyunk.
-
Sk8erPeter
nagyúr
Jaja, a variable_get() a core része, ez mindenhol elérhető, a includes/bootstrap.inc fájlban található függvény. Kukkants bele phpMyAdminnal az adatbázisba, és nézd meg a `variable` táblát, na ez a függvény onnan szedi ki az adatokat. A második paraméterrel default értéket lehet megadni neki, ezt fogja visszaadni a függvény, amennyiben nincs beállítva érték a variable táblában (pl. nézd meg a site_frontpage nevű értéket, ehhez tartozik egy bizonyos érték, ha beállítottad a /admin/config/system/site-information oldalon. Példa: variable_get('site_frontpage', 'node') - megnézi, van-e a variable táblában site_frontpage nevű változóhoz beállítva valami (itt serialized értékek találhatóak, ami unserialized lesz), ha még nincs, akkor visszaadja a 'node' stringet. (Itt egy globális $conf változóban tárolódnak a beállított értékek, korábban állítja be a Drupal.)
Még egy, amit érdemes ismerni, ha nagyon egyszerűen akarsz tárolni (pl. modullal) adatot, és ugyanilyen egyszerűen akarod kiszedni:
variable_set($name, $value);
Egyszerűen megadsz egy nevet és a hozzá tartozó értéket. De vigyázz, ezzel a core modulok által beállított értékeket is felül lehet bírálni.
Törlés pedig a variable_del($name) függvénnyel történik.
Tényleg egyszerű használni, ha modult fejlesztesz, akkor pl. ez beállítások tárolására a legegyszerűbb mód lehet. (Komplexebbhez már nyilván saját táblák kellenek.)"echo l(t('Home'), variable_get('site_frontpage', 'node'));
Csalsz, idáig <front>-ról beszéltünk."
Igen, de ezt csak alternatívaként említettem meg.Inkább használd a <front>-ot, én azt mondanám, az szerintem beszédesebb. Ez csak azért volt érdekes, hogy mutassak ms módszert is, mert ilyen módon más változókat is ki tudsz kotorászni, ha kell.
===
Más: a PHP filter használatát meg kerüld. Eleinte, amikor időre kellett csinálnom dolgokat, és f*ngom nem volt még a hookok megfelelő használatáról, saját modulfejlesztésről, stb., akkor én is használtam kényszerből, de senkinek nem kívánom azt a szopást, amikor átnézi a régi tákolmányait, amit PHP filterrel kódolt, és aztán ültetheti át normálisan. Adatbázisban tárolni PHP-kódot? Fúj. Nekem nem nagyon mondták el ezeket (bár persze olykor kérdezgettem azért drupal.hu-n, drupal.stackexchange.com-on), csak szorgos utánaolvasás, kódkotorászás, beletanulás után jöttem rá, hogyan is kell normálisan használni a Drupalt, pedig mennyire más lett volna, ha van egy pörgős Drupal topic PH!-n akkor is...Brühühühühühűűűűűű, most felszakadtak a régi sebek, brühühühüűűűű!!
Új hozzászólás Aktív témák
Hirdetés
- Dell,14"FullHd IPS,core i5 6440HQ(Fizikai 4x3,5Ghz)8-16GB,Vil.bill,256-512GB SSD,Jó akku
- 14" ACER SWIFT 5 (970 gramm!)Érintős 14,1"FullHD IPS,8.gen.core i5,Vil.bill,16GBRAM,512GB SSD
- Xiaomi Redmi Note 11 64Gb Kártyafüggetlen 1Év Garanciával
- Apple iPhone 14 128Gb Kártyafüggetlen, 1Év Garanciával
- Acer 15,6",core i3,IntelHD+GT 940MX VGA,8-16GB RAM,SSD,szép állapot,W11
- HP ProBook 430 G4 Pentium 4415U (bios jelszavas)
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- LG OLED Televíziók: FRISS SZÁLLÍTMÁNY -30%
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest