- Samsung Galaxy S21 FE 5G - utóirat
- Fotók, videók mobillal
- Samsung Galaxy S23 Ultra - non plus ultra
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
- Milyen okostelefont vegyek?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Honor 200 - kétszázért pont jó lenne
-
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
-
#613
Sk8erPeter
nagyúr
Lacika25
#612
-
#611
Sk8erPeter
nagyúr
Ablakos
#610
Sk8erPeter
nagyúr
Szívesen! Amúgy itt is van rövid leírás róla: [link]. Esetedben az "Edit own value" jogosultság szükséges az adott szerepkörnek. Itt egyébként azt írja, hogy "Note: You cannot control the access of file or media fields; they are always accessible.", de ha jól tudom, ez csak arra vonatkozik, hogy önmagában egy kép elérését vagy letölthetőségét nem korlátozza (ha jól vettem le, ez nem is gond, itt csak a szerkesztéshez való jog az érdekes), ettől függetlenül szerkeszteni csak az fogja tudni, akinek beállítottad a jogosultságot (remélem, így is van).
Szerk.: amúgy majd megírhatnád, sikerült-e.
-
#609
Sk8erPeter
nagyúr
Ablakos
#608
Sk8erPeter
nagyúr
Szerintem a Field Permissions pont ilyenre való, de ne tagokhoz kösd (mert azt ezzel nem is lehet), hanem szerepkörökhöz (szerepkör-alapon könnyebben is kezelhető a rendszer).
-
#607
Sk8erPeter
nagyúr
tom_tol
#605
Sk8erPeter
nagyúr
Ha a galériák adott content type-ba tartoznak, vagy van más paraméter, ami alapján szűrhetőek ezek a galériák, akkor a Views modullal egy ilyen listázás simán összekattintható, ami tartalmazni fogja a linket, meg akár egy kisképet is, stb., anélkül, hogy minden újabb képgalériát hozzá kellene adnod manuálisan.
Egyébként ha manuálisan szeretnéd összeállítani azt az oldalt, és van telepítve valami WYSIWYG-szerkesztőd, akkor érdemes lehet ahhoz keresni olyan modult, amivel az ilyen linkelés megoldható, nem neked kell kiszedned a linkeket. Például a CKEditor modulhoz ott van a CKEditor Link modul, aminek segítségével egy mezőbe bepötyögheted az adott cikk/egyéb típus címét, az meg automatikusan kiegészíti, meg a linket is beilleszti helyetted.
-
#600
Sk8erPeter
nagyúr
adam_
#599
Sk8erPeter
nagyúr
Ez a probléma azóta megoldódott?
Egyáltalán be vagy már lépve adminként? Miután beléptél, azután is még ezt az üzenetet kapod? Ez nem derült ki a leírásodból, hogy tényleg be is vagy-e lépve megfelelő jogosultságokkal.(#598) Siriusb:
Azt az embert én nem nevezném "kollégának".![;]](//cdn.rios.hu/dl/s/v1.gif)
Sose legyen olyan kollégám, másnak sem kívánom. 
-
#596
Sk8erPeter
nagyúr
szundybence
#595
Sk8erPeter
nagyúr
válasz
szundybence
#595
üzenetére
Lassan inkább az lesz a kérdés, mennyire kiforrott már a 8-as... Persze ez azért még nem téma, mivel egyelőre még a stabil sem jött ki a 8-asból (a béta viszont már igen!), csak gondoltam érzékeltetem a helyzetet.
A 7-es már igen régóta kiforrott, sőt, a 6-os támogatása lassan teljesen meg fog szűnni, amint kijött a 8-as stabil változata, úgyhogy még csak ne is gondolkozz azon, hogy 7-esnél régebbit raksz fel.Amúgy a 8-as sok tekintetben kapásból jobb lesz, mint a 7-es (persze ez így a normális az újabb változatoknál
), a HTML5-ös megoldások kihasználása, reszponzív admin-felület (értsd: mindenféle eszközről tudod majd babrálni) miatt, a fordítási támogatás még erősebb lesz, sok (szinte) kötelező modul a core-ba kerül (pl. Views, fordításhoz kapcsolódó kiegészítő modulok, CKEditor, utóbbinak ráadásul a helyben történő (inline) szerkesztést lehetővé tévő része is, és így tovább). -
#589
Sk8erPeter
nagyúr
gege64
#588
Sk8erPeter
nagyúr
Azt hogy csináltad, hogy csak 14-et találtál drupal.org-on?
A 7.x változathoz 112-t találtam így gyorsan rákeresve:
https://drupal.org/search/site/?f%5B0%5D=&f%5B1%5D=&f%5B2%5D=drupal_core%3A103&f%5B3%5D=sm_field_project_type%3A%5B*+TO+*%5D&f%5B4%5D=ss_meta_type%3Atheme&solrsort=iss_project_release_usage+desc -
#585
Sk8erPeter
nagyúr
Siriusb
#583
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!) -
#584
Sk8erPeter
nagyúr
gege64
#582
Sk8erPeter
nagyúr
A használt adatbázisban (pl. MySQL) létre kell hozni a Drupal-telepítés ELŐTT egy adatbázist a Drupal számára, amibe majd beillesztgetheti az adatokat, és amiből aztán olvasgatni fogja ezeket. Ennek az adatbázisnak a nevét Te választod meg, ezt kell ebben a lépésben megadnod. Ezt az adatbázist egy megfelelő adatbázis-kezelővel tudod létrehozni (ilyen például a phpMyAdmin, ami a XAMPP-pal szintén települni szokott). Ezzel együtt az adatbázis-kezelőben létre kell (legalábbis mindenképpen érdemes; semmiképp sem szabad a főadminisztrátori felhasználónevet (általában root) és jelszót megadni az adatbázishoz való csatlakozásra) hozni egy külön adatbázis-felhasználót, aminek aztán jogokat biztosítasz az adott adatbázis elérésére ÉS módosítására (angolul privileges; minden jogot adj meg ennek a felhasználónak EHHEZ az adatbázishoz, de MÁSIKHOZ NE; nem szabad elfelejteni ezt a lépést, különben csatlakozási problémák lesznek).
Amúgy nagyon jól teszed, hogy nem élesben próbálkozol először, bölcs döntés.
Egyéb:
A privátbeli kérdésedre, hogy nagyjából mekkora szervert érdemes bérelni, csak annak függvényében lehetne válaszolni, ha ismernénk az igényeidet; attól függ, mire fogod használni a weboldalt. Van, ahol például akár 100 MB is elég (tipikusan egy nagyon egyszerű céges bemutatkozó oldal), van, ahol 10 GB is kevés. (Utóbbin például rengeteg kép lehet.) Azért általában a 100 MB nagyon alacsony korlát, én többet javasolnék, amennyiben például ezen keresztül fog történni az e-mailezés is (és nyilván egy igényes cégnek saját domainhez kötődő e-mail-címe legyen már Igaz, át is lehet irányítani ezeket a maileket másik szerverre).
500 MB vagy 1 GB már a legtöbb általános igénynek megfelel (persze nincs általános recept, mert mint említettem, igényfüggő). Normális tárhelyszolgáltató cégeknél azt is egyszerűen meg lehet csinálni, hogy veszel egy olcsóbb tárhelyet, aztán ha időközben úgy néz ki, többre van szükséged, akkor lazán feljebb lépsz egy eggyel drágább, nagyobb tárhelyet kínáló csomagba, aztán következő hónaptól vagy az átlépés napjától kezdve többet fizetsz (ez a tárhelyszolgáltató érdeke is nyilván).Ami nekem Drupalozásra bevált, az a Tárhelypark, én őket tudom ajánlani. Semmi közöm hozzájuk, szóval az ajánlásból nem származik semmi érdekem, de már annyi szívásnál voltak velem nagyon segítőkészek és gyorsak, hogy nyugodt szívvel javaslom őket. Lehet velük csetelni is amúgy munkaidőben.
Ha őket választod, van egy fontos dolog, amit módosítani kell a .htaccess-fájlban (egy szigorítás miatt), hogy működjön az oldalad:
http://blog.tarhelypark.hu/szerver-beallitas-followsymlink/
Lényeg röviden: az összes .htaccess-fájlban (ez sok FTP-kliensben rejtve van alapból) módosítani kell ezt a sort:
Options FollowSymLinks
erre:
Options +SymLinksIfOwnerMatch
Amúgy még annyi velük kapcsolatban, hogy a cPanel-felületen a Softaculouson keresztül pár kattintásra telepíteni tudod a Drupalt (kicsit gyorsabban, mint az alapmódszer).Kezdésnek mindenképpen ajánlott ez a könyv:
Nagy Gusztáv: Drupal 7 alapismeretek
http://nagygusztav.hu/drupal-7-alapismeretek
Ez az egyik legigényesebb magyar nyelvű, Drupallal kapcsolatos bevezető kezdőknek, képekkel illusztrálva. -
#579
Sk8erPeter
nagyúr
(Bundás)
#578
Sk8erPeter
nagyúr
válasz
(Bundás)
#578
üzenetére
"egy adatbázison tudnak osztozkodni"
Csak abban az esetben, ha táblaprefixeket (előtagokat) használsz! Ezt még az installálás során kell megadni.
Ez azt fogja jelenteni, hogy például lehet egy Drupal 6-osból származó block nevű táblád, és egy Drupal 7-esből származó akarmiprefix_block nevű táblád. Így tehát minden olyan tábla neve, ami a Drupal 7-eshez tartozik, el lesz látva egy "akarmiprefix_" előtaggal. Ezt megadhatod a telepítés során, ha lenyitod a haladó beállításokat (ha jól emlékszem, le kell nyitni egy fieldsetet, aminek vmi ilyesmi neve van).
DE ez a módszer általában kerülendő, amennyiben van jogosultságod létrehozni külön adatbázist is! Ez csak olyan esetben lehet érdekes, ha egy osztott tárhelyen mondjuk valamilyen oknál fogva (pl. ingyenes vagy nagyon kedvezményes csomag) csak egyetlen adatbázist kapsz, és másik oknál fogva pedig valóban szükséged van arra, hogy azonos oldalon két külön webalkalmazásod legyen.
Szóval megfontolandó, hogy valóban kell-e ez neked, csak az előbbi esetek valamelyikében lehet indokolt.
Arra pedig figyelj, hogy lehetőleg teljesen szeparált könyvtárakban legyenek, de legalábbis mindenképp valami alkönyvtárba kerüljön, ne legyen teljesen kutyulva a kettő (nem is működne).Készítettem neked egy screenshotot a telepítőből, itt láthatod azt a fieldsetet, amit le kell nyitni, bekarikáztam a lényeget, ahol meg kell adni az akarmiprefix_ előtagot, ez nyilván legyen valami értelmesebb nevű, például drupal7_ vagy ilyesmi, a név rád van bízva:
-
#576
Sk8erPeter
nagyúr
PiXeL90
#574
Sk8erPeter
nagyúr
Amit Siriusb említett, az a "User login" blokk, aztán még akármelyik menühöz hozzáadhatod a user/register útvonalat (ami amúgy user_menu()-ben van definiálva, ott még láthatók a működő, felhasználókkal kapcsolatos címek), neked tetsző címmel. Nem tudom, ez így megfelel-e neked, vagy valami különlegesebb kinézetű blokkot szeretnél, de úgy tűnt, csak a link kirakása a célod.
=======
(#575) Siriusb :
affene, azt hittem, beindul a topic, de már megint hullaszag lett.
Nálam most épp ez az aktuális megoldandó feladat, kíváncsi vagyok, milyen beépített megoldások léteznek rá:
http://drupal.hu/forum/kepmezo-vegtelen-szamossaggal-az-egyik-kep-megjelolese-checkbox-szal-boritokepnek/18485 -
#570
Sk8erPeter
nagyúr
PiXeL90
#568
Sk8erPeter
nagyúr
Jééé, azt hittem, ez a topic már meghalt
Pont napokban eszembe jutott, megkérdezem, mi ez a hullaszag itt."menüpont alá modult"
Azt hogyan kell elképzelni?"ha rákattintok be jöjjön a modul"
Mit jelent az, hogy "bejön" egy modul?
Megmozdul a link, és egyszercsak besétál egy modul az ajtón, és mindennek szem- és fültanúja lehetsz?
Fogalmazd meg úgy a kérdést, mintha neked intéznék, nulla információ birtokában Te vajon értenéd-e, mit akar az illető? (De nem, inkább fogalmazd meg úgy, mintha mindenkihez szólnál, hogy érthető legyen, és ne kelljen fejvakargatva törni a fejünket rajta, mit is akarhattál.) -
#564
Sk8erPeter
nagyúr
Ablakos
#563
Sk8erPeter
nagyúr
Milyen fielddel állítod be, hogy ki melyik csapathoz tartozik?
Így első nekifutásnak az Entity Reference ugrott be, hogy annak tuti, hogy hasznát tudnád venni a kapcsolat kezelésénél, majd listázás során a Views modulnál is:
Entity reference
http://drupal.org/project/entityreference
ezzel hivatkozhatnál a másik tartalomtípusra.
Sőt, a kölcsönös (oda-vissza) kapcsolat listázásához ennek is nagy hasznát veheted:
Corresponding Entity References
http://drupal.org/project/cer
Utóbbit is használtam már, teszi a dolgát, szinkronizálja mindkét irányba a kapcsolatot, csak mindkét irányban legyen hivatkozó field (Entity reference segítségével). Aztán admin-felületen be kell pipálni a köztük lévő kapcsolatot, hogy kezelje a CER modul.Persze a csapat-játékos kapcsolatra nyilván létezik még ötezer másik megoldás is. Én most annak megfelelően adtam javaslatot, ami az általad használt megoldásba illeszkedik bele legkezelhetőbben (legalábbis szerintem, első megközelítésként).
-
#562
Sk8erPeter
nagyúr
Ablakos
#561
Sk8erPeter
nagyúr
Most konkrétan milyen nézettel szórakozol? Mármint mi a célod?
"Tényleg furcsa, hogy az a javallat Drupálban, inkább fájlba kerüljön a kód. Oracle-nél hozzászoktam, hogy minden bitet táblákban tárol."
Mi van? Hogy lehet a kettőt egyáltalán összehasonlítani?
Nagyjából annyi közük van egymáshoz, mint a Balaton szeletnek a hullámzáshoz. -
#560
Sk8erPeter
nagyúr
Ablakos
#559
Sk8erPeter
nagyúr
Ugye tudod, hogy 7-es Drupalnál már nincs db_fetch_array()? 7-es a PDO-t használja, illetve az aköré írt wrappert.
Itt láthatsz példát a helyes használatra:
Result sets
http://drupal.org/node/1251174tehát a lekérdezésed átalakítva:
$result = db_query("SELECT * FROM {node} AS n WHERE n.status = 1");
$nodesArray = array();
foreach ($result as $record) {
// Do something with each $record
$nodesArray[] = $record;
}Ekkor a $nodesArray[]-ben lesznek a node-jaid, minden fieldjükkel együtt, pl. így érhetők el a tulajdonságok:
$nodesArray[0]->title
de nyilván ilyesmit egy ciklusban értelmesebb elintézni (nem számmal indexelve), nem is biztos, hogy van értelme külön tömbbe gyűjtened, hanem kapásból a foreach ciklusban kellene elintézned, amit szeretnél, a $record változón, ami az aktuális elem a $result bejárásakor.Amúgy ne szokj rá erre a textarea-ba bedobálunk PHP-kódot módszerre, ez csak átmeneti tesztelésre jöhet jól bizonyos esetekben, a Devel blokkjával, de egyébként abszolúte kerülendő, hogy adatbázisba legyenek beerőltetve a PHP-kódjaid, ami aztán eval()-lal kerül kiértékelésre.
Korábban itt megmutattam, hogyan lehet blokkot tisztességesen, modulból létrehozni, szerintem elég érthető:
http://prohardver.hu/tema/drupal_portal_fejlesztes/hsz_144-144.html
Kérdezz, ha valami nem tiszta. -
#555
Sk8erPeter
nagyúr
Siriusb
#554
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)).
-
#551
Sk8erPeter
nagyúr
Ablakos
#550
Sk8erPeter
nagyúr
Hidd el, aki ilyesmi dolgokat megértett, az szintén szopott vele eleget (én is elképesztő sok időt elkúrtam, mire kezdtem átlátni a működését, és csomó dologról még mindig f×ngom sincs). Szóval nem kell amiatt feladni, mert másnak egy tök más jellegű dolog összejött (pl. mert van hozzá jó leírás).
De írd le, min akadtál el, és akkor talán tudunk segíteni a megértésében (vagy nem, de egy próbát megér
).(#549) birozoli7800 :
ennek örülök, szívesen! -
#548
Sk8erPeter
nagyúr
Siriusb
#547
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: -
#546
Sk8erPeter
nagyúr
birozoli7800
#540
Sk8erPeter
nagyúr
válasz
birozoli7800
#540
üzenetére
Többnyelvűség:
amilyen modulokat én nagyon hasznosnak találok a többnyelvűsítéssel kapcsolatban, azokat itt a kérdésben felsoroltam:
http://drupal.hu/forum/t%C3%B6bbnyelv%C5%B1s%C3%A9g-vissza-kezdetekhez/17510Én viszont azt javasolnám, hogy eleve magyarul telepítsd a Drupalt, ha alapvetően magyar honlapról van szó, mégpedig az l10n_install lokalizált disztribúcióval:
http://drupal.org/project/l10n_installWebshop:
Korábban felvetettem a témát drupal.hu-n, hogy melyiket érdemes manapság használni, az Ubercartot vagy a Commerce-t, és egyértelműen azt a választ kaptam, hogy manapság a Commerce a megfelelő választás:
http://drupal.hu/comment/68912#comment-68912
http://drupal.hu/forum/ubercart-vs-commerce-m%C3%BAzeumi-darab-vs-j%C3%B6v%C5%91-vagy-ink%C3%A1bb-csak-el%C5%91%C3%ADt%C3%A9letek-%C3%B6r%C3%B6ks%C3%A9g-vs-%C3%BAjItt van az alaplépésekről leírás:
http://drupal.uzletkotobank.hu/content/drupal-commerce-telep%C3%ADt%C3%A9se-%C3%A9s-be%C3%BCzemel%C3%A9seHa mégis az Ubercart marad, akkor itt van egy szakdolgozat az Ubercartról magyarul, biztos le van írva benne minden alaplépés, ami egy egyszerű webshop kialakításához kell:
-
#538
Sk8erPeter
nagyúr
Ablakos
#537
Sk8erPeter
nagyúr
-
#536
Sk8erPeter
nagyúr
Ablakos
#535
Sk8erPeter
nagyúr
Simán teszteléshez a Devel modul megjeleníthető (lenyitandó) PHP-blokkja is jó lehet. Kapsz egy textarea-t, amibe bedobálhatod a PHP-kódot, ha azt elküldöd, kiértékelődik a kód (eval()).
De Drupallal (vagy bármilyen CMS-sel, frameworkkel, bármi komolyabbal) megtanulni PHP-zni nem jó ötlet.
Visszafelé is igaz természetesen, PHP-ismeretek hiányában megérteni a Drupal működését lehetetlen. Így nem biztos, hogy a tesztelendő kódod úgy és ott fog lefutni, ahol akarod. -
#534
Sk8erPeter
nagyúr
Ablakos
#533
Sk8erPeter
nagyúr
Nem igazán értem a kérdést, hogy érted, hogyan szokták készíteni a kódot? Szövegszerkesztővel (pl. Notepad++) vagy - inkább - egy kissé kényelmesebb és komolyabb tudású - de nagyobb erőforrás-igényű - fejlesztőeszközzel (pl. NetBeans, Eclipse).
Ehhez nagyon hasznos:
http://www.kalman-hosszu.com/netbeans-beallitasa-drupal-fejleszteshez
http://www.kalman-hosszu.com/drupal-template-ek-netbeans-hez-fejlesztoknek-es-sminkeseknek============
(#532) Siriusb :
jaja, ez a jó módszer, hogy először localhoston teszteled, és ha minden rendben ment, vagy már tisztában vagy a szükséges plusz lépésekkel, akkor megcsinálod élesben is, a Softacolous-szal. -
#531
Sk8erPeter
nagyúr
Siriusb
#530
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. -
#529
Sk8erPeter
nagyúr
Ablakos
#527
Sk8erPeter
nagyúr
Nincs véletlenül engedélyezve a Theme developer modul? Ha igen, tiltsd le (ezt csak theme-fejlesztés és egyebek tesztelése erejéig szabad bekapcsolva tartani, aztán szigorúan ki kell kapcsolni, erre fel is hívják a figyelmet a modul oldalán).
Ha nincs, próbálj meg cache-t törölni, olykor csodákra képes...Ha ez sem jött össze, nézd meg az adatbázisnaplót, nincs-e naplózva valami nagy hiba. Aztán nézd meg a státuszjelentést is, hogy ott nem látszik-e pirossal valami.
-
#523
Sk8erPeter
nagyúr
Siriusb
#522
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? 
-
#519
Sk8erPeter
nagyúr
Siriusb
#518
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. -
#517
Sk8erPeter
nagyúr
Siriusb
#516
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ő). -
#515
Sk8erPeter
nagyúr
Ablakos
#512
Sk8erPeter
nagyúr
Pont ilyen problémám volt régebben, kérdezősködtem is drupal.hu-n, aztán végül megírtam magamnak a végső megoldást (egy időben igen aktív voltam drupal.hu-n
), de én a Display Suite modult, meg annak valamelyik almodulját telepítve működő megoldást kreáltam, és az adott content type-ra engedélyezni is kellett valamelyik Display Suite layoutot (esetemben elég volt a One Column layout):
http://drupal.hu/forum/egy-field-%C3%A9rt%C3%A9k%C3%A9b%C5%91l-egy-m%C3%A1sik-field-kre%C3%A1l%C3%A1sa-de-hogyan-kell-ezt-tisztess%C3%A9gesen-csin%C3%A1lni/17092#comment-68484ha meg szeretnél ismerkedni kicsit jobban a Display Suite-tal, akkor ezek közül a videók közül érdemes párat megnézegetni, akár még ha csak belepörgetsz is, hogy értsd a lényegét, mire jó a modul:
http://www.youtube.com/playlist?list=PLwyQygmkPsjgddT0sgK5RFXXin2ZY285XMindenesetre ez a megoldás, amit végül teszteltem, azért nagyon kényelmes, mert nagyon egyszerű (igaz, ahhoz már picit értened kell, hogy egyáltalán mi az a modul, meg hogyan tudsz egy egyszerűt kreálni, bár az alaplépések kb. ugyanazok, mint az itt belinkelt blokkos cuccnál, csak nyilván a blokkra vonatkozó hookok nem kellenek...), meg admin-felületen át tudod húzogatni a többi fieldhez hasonlóan ezt a saját, új fieldet oda, ahova csak szeretnéd (persze csak ha jól csináltad), és szépen, fájlban tartod a kódjaidat, nem adatbázisba beokádva, ahogy a Computed Field esetében lenne.
Szerk.:
ja, és azért NEM érdemes ezt a kódot template.php-ben megírni, mert ez NEM sminkhez kötődő feladat. Ilyesmikre modulban kell megírni a kódot. A template.php-be azok a kódok kerüljenek, amik kifejezetten az adott sminkhez ÉS alapvetően megjelenítési feladatokhoz kötődnek.
Jelen esetben például könnyen elképzelhető, hogy létrehozod ezt a fieldet, de idővel rájössz, hogy az adott smink nem is tetszik, le szeretnéd cserélni valami másikra, mert találtál egy tök jót - na, most az egész kódodat cipelheted át az új smink új template.php-jába. Nem jó, nagyon nem. Már az elején érdemes a jó praktikák szerint csinálni, és jól végiggondolni, minek hol van a helye, hogy ne szívj vele, és ne utólag kelljen rájönnöd számtalan hibádra (mint nekem). Bár nyilván az ilyen elkerülhetetlen, de okos ember más kárán tanul. -
#509
Sk8erPeter
nagyúr
Ablakos
#503
Sk8erPeter
nagyúr
"Cikk(szerű) tartalmat szeretnék alkotni és azokat különféle menüpontokban látni, de úgy, ahogy a <front> oldalra küldve látszódik"
Ezt egy kicsit jobban körülírhatnád, mert attól függ a megvalósítás.
Lényegében Jeno.L és Siriusb megoldása is megfelelő lehet, tehát mindkét javaslat helytálló, de feladatfüggő, melyiket érdemes választani, vagy esetleg mindkettőt...
Taxonomy elsősorban pl. a cikkek kategorizálására való.
A különböző content type-ok (tartalomtípusok) meg arra jók, hogy különböző fieldeket, nyelvi beállításokat, egyebeket is rendelhetsz hozzájuk, tehát két különböző content type mezői és megjelenítése is totál más lehet.
DE ha alapvetően az általad emlegetett cikkek minden tulajdonságukban egyeznek (ugyanolyan mezők tartoznak hozzájuk, a mezőkhöz tartozó leírások is egyeznek, és így tovább), és pusztán valamilyen különböző kategóriákba szeretnéd őket besorolni, amit mondjuk az admin-felületen választanál ki, akkor NEM érdemes különböző content type-ot létrehozni hozzájuk, SŐT, kifejezetten rossz megoldás lenne ez esetben.
A Views-zal viszont rengeteg szempont szerint listázhatsz tartalmakat, nagyon összetett megjelenítésre alkalmas: például tudsz content type szerint is szűrni, tudsz megjelölt taxonomy-kategória szerint szűrni, nyelvi és egyéb beállítások alapján, stb. Tehát a Views bármelyik választott megoldás esetén segítség lehet.
A lényeg, hogy elkészíted a tartalmat, és a különböző menüpontokban aztán Views-zal úgy listázod, ahogy akarod. Példáull ha taxonomy-t használsz, akkor készítesz egy olyan menüpontot, ami az egyik kategóriába tartozó tartalmakat listázza, és egy másikat, ami pedig a másikat listázza.Ha gondolod, írj le még több szempontot (pl. milyen cikkek lennének ezek, és miben térnének el, pl. mezők szempontjából eltérnének-e, stb.), és megpróbálunk segíteni a leginkább megfelelőnek tűnő megoldás kiválasztásában.
-
#506
Sk8erPeter
nagyúr
Jeno.L
#502
Sk8erPeter
nagyúr
Annak idején itt írtam le, hogyan lehet egyszerű blokkot definiálni Drupal 7-ben, saját modulból:
http://drupal.hu/comment/69116#comment-69116Nálad a hook_block_info()-ban persze az if-feltételre nincs szükség, és itt, meg hook_block_view()-ban is cseréld le a "drupalchat_smileys" kulcsot a sajátodra. Utóbbiban a subject a blokk címe, a content kulcs magát a tartalmat adja meg.
Innen remélem, nagyjából egyértelmű, hogy mit cserélj le a sajátodra. Ha mégsem, kérdezz. -
#501
Sk8erPeter
nagyúr
Ablakos
#500
Sk8erPeter
nagyúr
Abban az esetben, ha úgy törlöd, hogy előtte nem uninstallálod, pedig lett volna rá lehetőség (a modul implementálta a hook_uninstallt), akkor maradhat szutyok az adatbázisban.
Tehát mindig úgy kell fájlrendszerszinten is eltávolítani, hogy előtte az ember uninstallal eltávolítja a modul dolgait, amennyiben van rá lehetőség. Szabályos uninstall után viszont abból nincs probléma, ha a fájlrendszerből nem törlöd, erőforrást nem emészt az, hogy ott van a modul könyvtára, legfeljebb csak a modulok listázásakor fog picit tovább szöszölni, amikor beolvassa a könyvtárakat és fájlokat, de egyébként irreleváns, legfeljebb tárhely-foglalás szempontjából érdekes. Persze amiatt érdemes törölni, hogy aztán később, ha mégis szükség van a modulra, mindig az aktuális legfrissebbet telepítsd. -
#498
Sk8erPeter
nagyúr
Ablakos
#497
Sk8erPeter
nagyúr
Nem mindegyik modul implementálja a hook_uninstall-t, ezért nem mindegyik jelenik meg az Uninstall opciónál. Nem is feltétlenül szükséges, ha nem ír pl. adatot az adatbázisba, nincs mit eltávolítani.
Ja igen, és ha a fájlrendszerben még ott van, akkor megjelenik az engedélyezhető modulok listájában, de ezzel nincs is gond.
-
#494
Sk8erPeter
nagyúr
Jeno.L
#491
Sk8erPeter
nagyúr
Státuszjelentésben nincs hiba, hibanaplóban nem szerepel kapcsolódó bejegyzés?
Ha megnyitod a konzolt F12-vel, majd a Console fülre kattintasz, akkor JavaScript-kóddal kapcsolatos hibát nem jelez ki pirossal?Szerk.: most látom a (#493)-at... "Am nem csak az én oldalom, pl a Raiffeisen bank direct net oldala sem megy most vele...mármint Chrome-l" - hát basszus, akkor ennek mi köze a Drupalhoz?
Töröld a szokásos dolgokat a Chrome-ban, ezt írd a címsorba:
chrome://settings/clearBrowserData
aztán "Böngészési adatok törlése"
de akkor a problémádnak semmi köze a Drupalhoz.
-
#488
Sk8erPeter
nagyúr
papa019
#487
Sk8erPeter
nagyúr
Hali! Valami szobafoglalós megoldás picit átalakítva, nem szobaként elnevezve szerintem megfelelő megoldás lehetne, nem próbáltam még, de ezt kipróbálhatnád esetleg:
Rooms
http://drupal.org/project/roomsitt van róla screencast, kukkold meg, nem lenne-e jó neked:
http://www.drupalrooms.com/demovagy alternatív megoldások:
http://drupal.stackexchange.com/questions/25586/whats-the-best-way-to-create-a-booking-formitt aztán bőven vannak foglalós modulok felsorolva:
Comparison of Booking System modules
http://groups.drupal.org/node/137544 -
#486
Sk8erPeter
nagyúr
adam_
#481
Sk8erPeter
nagyúr
Nem értem, mi a kérdésed. Most azt várod, hogy helyetted megcsináljuk a feladatodat?
Kis guglizással pl. meg lehet találni az entity_type, bundle és a többi szerepét, lásd például 10 másodperces guglizás után itt van egyből egy igen nagy segítség, aminél a descriptionből ki lehet olvasni ezek szerepét:
http://api.drupal.org/api/drupal/modules!field!modules!field_sql_storage!field_sql_storage.module/function/_field_sql_storage_schema/7
Ezeket hadd ne fordítsam már le, ott van feketén-fehéren, hogy mire jók.
Példa:
entity_type
The entity type this data is attached tobundle
The field instance bundle to which this row belongs, used when deleting a field instancestb...
Ahogy követed ezeket a kódokat (RTFC!!!), szép lassan ki lehet hámozni a köztük lévő kapcsolatokat is, és azt, hogy mire való. A mindenre kiterjedő választ neked kell megkeresni, mivel elvileg pont ez a szakdolgozatod lényege, ez a fórum arra való, hogy konkrét kérdésekre igyekezzünk segítséget adni, nem kis/nagyesszéket írjunk. Mondjuk első lépésnek itt van ez a fenti link, ebből már megtalálod, amit kérdeztél. Viszont egy olyan kérdésre, hogy kábé magyarázzuk el neked elölről-hátulról a Drupal adatbázisbeli működését, ne várj komplett választ, mert ennyire senki nem időmilliomos, és ezeket a dokumentáció nagyrészt leírja, vagy ha az nem ad kielégítő választ, akkor sok-sok szakirodalom szerepel az első hsz.-ben, ezeket érdemes lenne tanulmányozgatnod, ha még nem tetted. Konkrét kérdésekre biztos szívesen válaszol itt bárki, ha tud.
Sikerült azóta előrébb jutni? Elég sok idő eltelt azóta, szóval gondolom azóta jobban beleástad magad, legalábbis remélem...
=====================================================
(#483) csabi011 :
ezt amúgy Views-zal is nagyon gyorsan össze lehet kattintgatni, de gondolom gyakorlás volt a cél, annak megfelelő. -
#477
Sk8erPeter
nagyúr
adam_
#476
Sk8erPeter
nagyúr
Ja, hát két megoldás van, megkéred a szolgáltatót, hogy kapcsolják be ezeket a dolgokat a php.ini-ben, ha ezt nem teszik meg, akkor meg jön a másik megoldás, hogy elköltözöl tőlük. Ezek a hibák több problémát is magukkal hoznak, mint látható. Van olyan osztott tárhely, ahol van külön-külön php.ini, így az valamilyen szinten konfigurálható egyedi szinten is (ez is limitált lehet persze), de általában "globális" php.ini van, ami mindenkire érvényes (konyhanyelven elmondva, így a legegyszerűbb).
Ha költözöl, akkor ne csak a fájlokat másold le, hanem a teljes (!) adatbázist is. Figyelj arra is, hogy az esetleges rejtett fájlokat is átmásold, mint pl. a .htaccess fájl, lényegében minden fájl fontos lehet.
Akikkel pozitív tapasztalataim vannak, az a Tárhelypark, de fizetős a szolgáltatásuk.
Ha átmenetileg ingyen akarsz kísérletezni, akkor esetleg a 000webhostra felpakolhatod a tartalmadat, de számíts rá, hogy lassabb lesz, mivel távol van a szerverük (konkrétan amúgy nem tudom, hol van Magyarországhoz legközelebb). Régen engem az zavart náluk, hogy tényleg lassú volt sokszor az oldal, vagy nem volt elérhető, de mostanság több pozitív tapasztalatot olvastam róluk.
Viszont ha majd saját domained lesz, végleges megoldást akarsz, akkor inkább válaszd az előbb említett szolgáltatót, vagy hasonlót, meg még másik topicban a HostGatort ajánlották, aztán van, aki a GoDaddy-re esküszik, stb... -
#474
Sk8erPeter
nagyúr
adam_
#473
Sk8erPeter
nagyúr
admin/config/regional/translate/translate
valszeg pár fordításért felelős modult is fel kellene raknod.
Itt volt egy hosszabb írásom ezzel kapcsolatban:
http://drupal.hu/forum/t%C3%B6bbnyelv%C5%B1s%C3%A9g-vissza-kezdetekhez/17510 -
#472
Sk8erPeter
nagyúr
adam_
#471
Sk8erPeter
nagyúr
Nem ártana egy kicsit ismerkedned a Drupallal, és olvasgatni a már párszor ajánlott Nagy Gusztáv könyvet.
Bekapcsolod a Contact modult, beállítod az oldal beállításai között a saját email-címedet, és küldözgetsz leveleket orrba-szájba különböző címekre.Localhoston SMTP Authentication Support használatával a legegyszerűbb belőni, pl. egy Gmail-es címet beállítva.
De még ezelőtt próbáld ki a sima contact modult, ha a szervereden jól működik az emailküldő szolgáltatás, akkor ott ez is elég. -
#468
Sk8erPeter
nagyúr
adam_
#466
Sk8erPeter
nagyúr
Honnan tudjam?
Nem ismerem a hunhostot, fingom sincs, hol van ez a felület náluk. Jelentkezz be, gondolom valahol csak írják... Még ez segíthet:
Backup and Migrate
http://drupal.org/project/backup_migrateJa, és még egy, az Access-t felejtsd el, ne keverjük a szezont a fazonnal.
(#467) Siriusb :
én úgy értelmeztem, hogy nem akar közvetlenül belenyúlni az adatbázisba, csak a változásokat akarja megtekinteni, amikor a fieldeket szerkeszti, valami ilyesmi. Legalábbis reméljük. Amúgy jogos a megjegyzés! -
#465
Sk8erPeter
nagyúr
adam_
#464
Sk8erPeter
nagyúr
Szívesen, ezek szerint láttad az óriásprivimet.
1. admin/config/people/accounts/fields
2. "Szerintetek hogyan lehet kiimportálni az adott Drupal alapú honlap adatbázisát? "
"kiimportálni" -> őőő... akarod mondani EXPORTÁLNI?
phpMyAdminban, az Export menüpontra kattintva... kijelölve az összes mezőt az adatbázison belül, vagy a komplett adatbázist kijelölve, ha a fő menüpontnál kattintasz rá...
Azutánira:
az ingyenes MySQL Workbench az egyik lehetséges módszer.
Gondolom valami ilyesmit várnak tőled:
http://www.mysql.com/products/workbench/design/
-
#463
Sk8erPeter
nagyúr
tamaszen
#462
Sk8erPeter
nagyúr
-
#461
Sk8erPeter
nagyúr
SecMan
#460
Sk8erPeter
nagyúr
Itt kérdeztem ugyanezt:
meg egy másik topicban is, és a válasz:
http://drupal.hu/comment/68977#comment-68977a lényeg, röviden:
Commerce. -
#458
Sk8erPeter
nagyúr
adam_
#457
Sk8erPeter
nagyúr
Nem, de a kereszthivatkozás jól jöhet ilyen esetben, hogy itt és ott is megkérdeztem, és ott azt mondták, stb., hogy ne legyen információduplikáció, két helyen mondják el neked ugyanazt... ha viszont látható, hogy a másik fórumban mit mondtak rá, akkor ahhoz lehet kommentálni.
-
#456
Sk8erPeter
nagyúr
adam_
#455
Sk8erPeter
nagyúr
Itt válaszoltam, mert látom a drupal.hu-n is feltetted ugyanezeket a kérdéseket egyesével.
-
#454
Sk8erPeter
nagyúr
adam_
#453
Sk8erPeter
nagyúr
a fielded beállításainál a "Search options"-nél mi van beállítva?
Nálam "Search box with Automatic Geocoding", és akkor autocomplete-tel egyből felkínál címeket, ahogy akkor, amikor a maps.google.com címen kezdesz beírni egy címet. Aztán nálam még a "City input method"-nál meg a többinél is Autocomplete van kiválasztva, így a kényelmes.
Így se jó? -
#450
Sk8erPeter
nagyúr
adam_
#449
Sk8erPeter
nagyúr
Nyelvi fájlok külön másolgatása helyett ezt a Drupal-disztribúciót ajánlom neked telepítésre, ha azt szeretnéd, hogy eleve többnyelvű Drupal-felületet tudj telepíteni (persze ez nem mentesít a többi kiegészítő többnyelvűséghez tartozó modulok telepítésétől!!):
http://drupal.org/project/l10n_install
lényege, hogy eleve már a telepítésnél ki tudod választani a megfelelő nyelvet a lokalizációhoz, és így lesz egy lokalizált Drupalod, plusz eleve telepítésre kerül az amúgy szinte kötelező l10n_client és l10n_update is.
Ettől még az i18n, i18nviews, entity_translation, title és egyebek is ajánlottak a többnyelvűséghez.===
"Most igaz azóta volt egy Windows reinstall, de most nem értem miért nem megy."
... és ment vele a MySQL-szervered összes adata is (adatbázisok tartalma), vagy azt legalább lementetted?"Próbáltam úgy is, hogy a nyelvi fájlt nem másolom be a translations mappába, ezt követően ugyan azon a részen túl is megy a telepítőbe"
Manuális b*zerálás helyett mondom, inkább rakd fel eleve az l10n_install disztribúcióval, többek közt Hojtsy Gábor a felügyelője, aki főszereplő a Drupal többnyelvűsítésében (Acquia-nál dolgozik, és jelenleg ő felelős többek közt a Drupal 8 többnyelvűsítéséért).
A többnyelvűséggel kapcsolatos cikkei amúgy is sok-sok hasznos infót tartalmaznak:
http://hojtsy.hu/================
(#448) Siriusb :
szívesen! -
#447
Sk8erPeter
nagyúr
Siriusb
#446
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.
-
#445
Sk8erPeter
nagyúr
Siriusb
#444
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.
-
#443
Sk8erPeter
nagyúr
Siriusb
#442
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.
-
#437
Sk8erPeter
nagyúr
Siriusb
#436
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... -
#430
Sk8erPeter
nagyúr
Siriusb
#429
Sk8erPeter
nagyúr
-
#427
Sk8erPeter
nagyúr
Siriusb
#425
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 ]
-
#426
Sk8erPeter
nagyúr
adam_
#424
Sk8erPeter
nagyúr
Basszus, ha még egyszer leírod hosszú í-vel a hirdetés szót, én nem tudom, mit csinálok...
A kategorizálásnál igen, beállíthatod a Hierarchical Selectet az adott mezőhöz tartozó widgetként (most nem vágom, a magyar felületen ezt minek szokták hívni).
"Ilyen egyszerű lenne?"
Én nem értelek, miért nem próbálod ki? Telepítesz magadnak egy helyi webszervert, egy helyi tesztcélú Drupallal, például úgy, hogy Web Platform Installerrel bekattintod, hogy szeretnéd telepíteni a Drupalt, az meg behúzza a függőségeket, aztán elkezded próbálgatni... (vagy EasyPHP és társai is még jó opció, most feltételeztem, hogy Windows-t használsz, ha meg Linuxozol, feltételezem, hogy nem fog gondot okozni a phpmyadmin konzolon keresztüli telepítése...). Hidd el, mi is csak úgy jöttünk rá, hogy kell kezelni ezeket a modulokat, hogy kipróbáltuk, és nem vártuk el, hogy mások a saját idejüket beáldozva vezessék a kezünket, hogy hova kell klikkelgetni.Egyébként igen, hozzáadsz a hirdetéshez egy "Getlocations Fields" nevű mezőt, csak hogy még egyszer leírjam, amit az előbb már leírtam ugyanígy...
-
#423
Sk8erPeter
nagyúr
adam_
#421
Sk8erPeter
nagyúr
Nem látok semmilyen hirdetésfeladást, mivel nem vagyok bejelentkezve, és nem is leszek... ezért mondtam, hogy dobj már egy screenshotot, hogy maga a feladás hogy néz ki. Egy Print Screen gomb lenyomása, majd vágólapról bemásolás egy képszerkesztőbe, és kép feltöltése... SnagIttel könnyen elkészítheted.
A Hierarchical Selectnek pont az a lényege, hogy egy node (tartalom) hozzáadásakor, például egy termék felvitelekor egyből kategorizálhatod, hogy hova tartozik a termék, úgy, hogy többszintű hierarchiát is tudsz vele kezelni. Olvasd el a README-t, keress róla videókat, ha nem megy.
A Get Locations modul működését hadd ne magyarázzam már el elejétől a végéig, azért időmilliomos én sem vagyok... inkább próbálkozz vele, olvasd el a README-t, a hivatalos honlapot, és aztán mondd el, mire jutottál. Ha elakadtál, akkor kérdezz bele konkrétan. Adj hozzá egy "Getlocations Fields" nevű mezőt a content type-odhoz, ahol kell a térkép."Feltelepítve már természetesen felvan a Getlocations és a Google Maps API modul egyaránt."
Milyen Google Maps API modul? A Get Locations-höz nem kell semmilyen külső modul, egyedül működik. Ahhoz, amire neked kell, nem feltétlenül kell felraknod semmilyen plusz modult. Bár kiegészítheted a működését Address Fielddel meg ilyesmivel, próbálkozz vele, hogyayn a legmegfelelőbb az igényeidnek.===
(#422) adam_ : hát ez az ember gyönyörűen beszél angolul....
A kérdésedet meg egyáltalán nem értem, ott van egyértelműen a videóban is, hogy van egy "create new item" menüpont is, mégpedig a legelső.... ez egyébként elvileg beállítható a modulban, hogy lehet-e létrehozni új elemet, vagy sem.
Azért ilyen gyorsan ne add fel, inkább próbáld meg értelmezni is, amit nyújt a modul által kínált felület. -
#420
Sk8erPeter
nagyúr
adam_
#414
Sk8erPeter
nagyúr
Gondolom nem középen a "Hozzáférés megtagadva" szöveget kell látni.
Ha igen, akkor mutass már légyszi egy screenshotot, hogy minek is kellene középen lenni, legalábbis gondolom az is érdekes, ha már egy node/add/classified címet adtál meg.
Melyik modulra gondolsz?
http://drupal.org/project/ed_classified
Ez? Nem ismerem a modult.Ami viszont hierarchikus kategorizálásra nagyon jó, és az előbbi modul oldalán is említést tesznek róla (mint az előbbi modul nagyon jó kiegészítője):
Hierarchical Select
http://drupal.org/project/hierarchical_selectAmi még ajánlott, egész új, de nagyon jó kezdeményezés, hasonló céllal:
Simple hierarchical select
http://drupal.org/project/shsKét modul van, amit én tapasztalatból tudok ajánlani földrajzi hely megjelölésére, ami Google Maps API-val nagyon jól működik együtt:
Get Locations
http://drupal.org/project/getlocationsOpenLayers
http://drupal.org/project/openlayersA nagy különbség az, hogy az előbbi egyszerű, és jó, az utóbbi komplex, és jó, de utóbbi még kiegészül annyival, hogy sok-sok térképszolgáltató API-jával is együtt tud működni, nem csak a Google Maps-ével; tehát ha neked valamilyen okból más is kell, mint a Google Maps-es, akkor mindenképp az utóbbi ajánlott. Ha viszont tökéletesen megelégszel azzal, amit a Google Maps nyújt, akkor a Get Locations-t válaszd.
Mindkettővel egyébként be tudod lőni, hogy a felhasználó csak rábökjön a térképen valahova, és azt a helyet el is tudja menteni.
A Get Locations-nek egyébként nagyon jó autocomplete-szolgáltatása is van, ha bekapcsolod (bár lehet, hogy ez a default, ez most hirtelen nem ugrik be), ami arra jó, hogy mondjuk a felhasználó bepötyög pár szót, a Google Maps API-n keresztül pedig egyből érkezik javaslat a kiegészítésre, ugyanúgy, mint amikor elkezdesz a Google Maps beviteli mezőjében begépelni egy címet.
Na, tehát összegezve: ha egyszerű, gyorsan belőhető szolgáltatás kell, akkor Get Locations, ha összetett, komplex feladat megvalósításáról van szó, akkor OpenLayers. -
#419
Sk8erPeter
nagyúr
chepavel
#405
Sk8erPeter
nagyúr
válasz
chepavel
#405
üzenetére
"Másodszor, ez már az elkeseredettség jele, azért lett core rész bántva."
Akkor sem."A webfejlesztő, aki ténylegesen készíti a weblapot (én csak a sysadmin vagyok, és véleménye szerint az IIS-el van gond.-)"
Én is IIS 7.5-öt + FastCGI PHP-t használok saját gépem webszervereként. Mivel nincs SMTP szerverem, levélküldésre localhoston épp az általad is említett SMTP Authentication Support modult használom, ami már több ízben is nagyon jól bevált, és általában a Gmail SMTP szerverét használom a saját accountommal.
Na, most a kedvedért egy tesztcélú Drupalon végigtoltam a folyamatot direkt az elejétől:
admin/config/system/smtp
smtp.gmail.com
465-ös port
Use SSL
saját account-adatok
modul bekapcsolása
teszt e-mail kiküldése, eddig rendben.contact oldalra ellátogattam, utána erről az orosz oldalról kimásoltam némi cirill betűs szöveget:
http://serho.ru/cust-modules/filtr-dlya-views-s-ierarhicheskim-vyborom-terminov
OK, levél elküldése, meg is érkezett hiba nélkül:
Tehát minden az alap Contact + az SMTP modullal ment.
De ezek után még kipróbáltam mindezt Webformmal is kíváncsiság kedvéért:
a "my email" mezőhöz beállítottam, hogy a Webform onnan szedje az e-mail-címet, a "my textfield" mezőhöz azt, hogy onnan szedje a tárgyat, a "my testtextarea" mező pedig maga a levél törzse, a lényegi üzenet.
Ez is megérkezett gond nélkül:
MINDEN csakis a default beállítások szerint ment, én nem módosítottam rajtuk semmit, és főleg nem bántottam a core-t.
Az SMTP Authentication Support modul nálam már éles oldalon is bizonyított, szóval nem tudom, mi lehet nálatok a baj.Milyen sminket használtok? Nem állítotok be abban véletlenül valami egyéb karakterkódolást, ami miatt nem UTF-8 lesz a kimenet? Chrome-ban egyébként Eszközök - Karakterkódolás alatt könnyű megnézni, melyik karakterkódolás mellett van az aktívat jelző pötty. Na meg F12 megnyomásával a Network fülön követhetők a headerek.
A lényeg tehát az, hogy a karakterkódolás ténylegesen mindenhol UTF-8 legyen, és ne legyen semmi eltérés (különösen ott, ahol a form megjelenik; de egyébként sem).
Amit még ki kellene próbálnotok:
- az admin/config/system/smtp oldalon az említett beállításokat eszközölni, tehát egy Gmail-account adatait beállítani átmenetileg, tesztcélból
- ahogy Siriusb is javasolta, más e-mail-címekre is küldeni levelet, nem csak a sajátotokra. -
#404
Sk8erPeter
nagyúr
chepavel
#403
Sk8erPeter
nagyúr
válasz
chepavel
#403
üzenetére
"Az alap mail.inc.-ben átírtam az értéket, de az elküldött levelek továbbra is UTF8-ra lettek kényszerítve."
Everytime you hack core, god kills a kitten:
Nem csinálunk ilyet.Nincs semmi gond az UTF-8-cal, azzal van baj, ha nincs megfelelően elküldve a szöveg.
"Az oldal cirill betűket használ, valamint a PHP mail() funkcióval történik a levélküldés."
Mégis hogyan? Saját kóddal, MODULBAN?
Ha nem modulban, akkor miért nem?
Ha saját modulban, akkor miért saját modullal akarod megoldani, amikor nagyon jó kész modulok vannak ilyenre, mert nem Te vagy az egyedüli, aki cirill betűs levelet akar küldeni?
Ha kész modult használtál, akkor melyiket?
Csak a SmarterMailről írtál, Drupal-modulról nem. -
#402
Sk8erPeter
nagyúr
Siriusb
#401
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.
-
#400
Sk8erPeter
nagyúr
Siriusb
#399
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.
-
#398
Sk8erPeter
nagyúr
Siriusb
#396
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. -
#393
Sk8erPeter
nagyúr
Jeno.L
#391
Sk8erPeter
nagyúr
Ja, hogy erre gondoltál! OK, bocsesz, elsőre nem volt tiszta, már értem, mi a gond.
Ebben az esetben jogos a probléma. De igazából ezek szerint ez nem "kb. olyan mint a hotlink protection", hanem ez konkrétan hotlink protection. Most random kiszedve egyet:
http://fansshare.com/celebrity/photos/934_imogen-lo-jpg-zoo-456321085.jpg
ez aztán átvisz ide:
http://fansshare.com/cached/?version=celebrity/photos/934_imogen-lo-jpg-zoo-456321085.jpg&rnd=8952
és kiírja, hogy
"Click here for full resolution
Hotlink protection activated - The domain you are viewing from has been excessively embedding - max allowance 100GB"
De ez csupán egy scripttel ráhúzott réteg a képen.Más is ír erről, amit említettél:
https://productforums.google.com/forum/?fromgroups=#!topic/webmasters/x8CnRPITLg8
[link]
[link]
[link]Végül is .htaccess-szel tényleg át lehetne irányítani a kéréseket, ahogy sh4d0w mondta, de úgy, hogy azok nincsenek blokkolva, hanem átirányítod a közvetlen kéréseket saját scriptre, és Te is saját scriptedből ráhúzol egy réteget minden ilyen módon kiszolgált képre. Kész Drupalos megoldásról én személy szerint nem tudok, de érdemes rákeresni a "drupal hotlink protection" kulcsszavakra.
===========================================
(#392) sh4d0w :
nincs mit, jól választottál. -
#390
Sk8erPeter
nagyúr
sh4d0w
#384
Sk8erPeter
nagyúr
Fix szélességű témával Dunát lehet rekeszteni, akár a Zen sminket is be lehet lőni fix szélességűre, ha olyan témát akarsz, amit Te szeretnél testreszabni (lásd a fixed-width.css fájlt).
"a fejlécben az utoljára felvitt x db írás beharangozói váltakoznak automatikusan?"
Ez teljesen független a témától, ezt bármelyik sminkben meg lehet csinálni (már amelyik nem olyan kiszámíthatatlan fos, mint az Artisteer által generált szutykok).
Ahogy Siriusb már említette, simán Views-zal öt perc alatt össze lehet kattintgatni ilyen listázó blokkot, aztán az admin/structure/block oldalon oda húzogatod a blokkodat, ahova akarod.
Persze nem árt, ha van is a témádban egy olyan régió, ami megfelelő a blokk elhelyezésére.
Ha még nem ismered a Views-t, érdemes olvasgatni: Nagy Gusztáv: Drupal 7 alapismeretek, 15. fejezet.
De ha elakadtál, itt nyugodtan kérdezősködhetsz. -
#389
Sk8erPeter
nagyúr
Jeno.L
#386
Sk8erPeter
nagyúr
"Nah már most egy fórumon linkeltek egy érdekességet ami kb. olyan mint a hotlink protection."
Ezt most nem egészen értettem. A site:fansshare.com-ra való keresés már miért lenne olyan, mint a hotlink protection?Egyébként biztos, hogy a Google képkereső az oka?
A .htaccess-szabályozás meg nem biztos, hogy jó ötlet, mivel akkor kvázi azt mondod a Google keresőrobotjának, hogy vazze, neked nem adom a képet. Azt meg nem hiszem, hogy értékeli. -
#383
Sk8erPeter
nagyúr
Siriusb
#382
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.
-
#381
Sk8erPeter
nagyúr
Siriusb
#380
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...
-
#376
Sk8erPeter
nagyúr
Siriusb
#375
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.
-
#374
Sk8erPeter
nagyúr
Siriusb
#368
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.
-
#372
Sk8erPeter
nagyúr
Siriusb
#371
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. -
#370
Sk8erPeter
nagyúr
Siriusb
#368
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.)
-
#369
Sk8erPeter
nagyúr
Siriusb
#366
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. -
#364
Sk8erPeter
nagyúr
Siriusb
#363
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. -
#358
Sk8erPeter
nagyúr
Siriusb
#357
-
#356
Sk8erPeter
nagyúr
Siriusb
#355
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? -
#353
Sk8erPeter
nagyúr
Siriusb
#352
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. -
#351
Sk8erPeter
nagyúr
Siriusb
#350
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. -
#349
Sk8erPeter
nagyúr
Siriusb
#348
-
#347
Sk8erPeter
nagyúr
Siriusb
#346
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. -
#345
Sk8erPeter
nagyúr
Siriusb
#344
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. -
#343
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Na, ez jóhír:
From Aloha to CKEditor
http://buytaert.net/from-aloha-to-ckeditorA lényeg, hogy végül úgy tűnik, az egyébként szintén ígéretes Aloha Editor helyett a megújult CKEditort fogják bevetni a Drupal 8 core-ban, aminek én személy szerint nagyon örülök, mert így is a CKEditor a kedvencem a WYSIWYG-editorok közül.
-
#342
Sk8erPeter
nagyúr
Speeedfire
#311
Sk8erPeter
nagyúr
válasz
Speeedfire
#311
üzenetére
Megkérdeztem a dolgot drupal.hu-n:
-
#340
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
vájt háusz
[link]"The White House openly endorses and encourages the use of open source and Drupal: http://www.whitehouse.gov/blog/2012/11/20/open-source-and-power-community"
-
#339
Sk8erPeter
nagyúr
Jeno.L
#338
Sk8erPeter
nagyúr
Aha, látom a választ, jónak tűnik, csak kár, hogy nincs tipp rá, hogy konkrétan vajon mi okozhatta, és miért lehet ez bármilyen összefüggésben a frissítéssel. Én legalábbis nem értem.
Lehet, hogy nem töröltél cache-t, miután frissítettél, és így átmenetileg a node-os címek látszottak Google barátunknak, de hogy miért, azt egyáltalán nem értem... az is lehet, hogy ez hülyeség, semmi köze a kettőnek egymáshoz, csak annyi mindent megold egy cache-törlés olykor, hogy már mindenbe ezt látom bele.
(Mondjuk többek közt JS-es parákat szokott okozni, pl. Get Locations modul nagyon érzékeny rá, ha nem törlöm a cache-t update után, akkor eltűnik a Google Maps-térkép.)
Amúgy ja, a hetek/hónapok is reális, tehát csak türelmesen, de simán lehet, hogy ennél gyorsabban is be fogja újból indexelni a Google az oldaladat.
Írd be ide még egyszer az oldalad címét, hátha, bár kétlem, hogy ez gyorsítja: https://www.google.com/webmasters/tools/submit-url?pli=1Amúgy bár tudtommal számít az alias SEO-szempontból, de ha tartalom szempontjából rendben van az oldalad, akkor szerintem nem kell félni drasztikus visszaeséstől a találatokban.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
"
Megmozdul a link, és egyszercsak besétál egy modul az ajtón, és mindennek szem- és fültanúja lehetsz?
Új hozzászólás Aktív témák
Hirdetés
- Csere-Beszámítás! RGB Számítógép PC játékra! R5 5600X / RTX 3060Ti 8GB / 32GB DDR4 / 500GB SSD
- AKCIÓ! Gigabyte H510M i5 10400F 16GB DDR4 512GB SSD GTX 1080Ti 11GB Rampage SHIVA Zalman 600W
- 118 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 9 7945HX, RTX 4070 - UK billentyűzet
- Microsoft Surface Laptop 3 - 15 col - Fekete
- AKCIÓ! "ÚJ" Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest