Az általunk ismert magyar Drupal témákkal is foglalkozó blogokból a Drupalhoz kapcsolódó bejegyzéseket összesítjük, így könnyebb követni a releváns magyar tartalmakat.
A FireSASS évekig nagy segítséget nyújtott azoknak a front-end fejlesztőknek, akik a SASS nevű CSS előfeldolgozót használták, viszont aki úgy dönt, hogy újratelepíti a gépét, vagy most szeretné kipróbálni a FireSASS kiegészítőt, meglepve tapasztalhatja, hogy a https://addons.mozilla.org/hu/firefox/addon/firesass-for-firebug/ oldalon egy ilyen üzenetet kap:
"A kiegészítőt a készítője eltávolította."
Kicsit elhalkultam hétfő óta, de ennek meg volt az oka. Túl frissek voltak az élmények ott hogy egyből le tudtam volna írni mindent. Nem…
Bizonyára többetekkel előfordult már, hogy egy, végülis alapösszefüggésre csak hosszú idő után bukkantok rá és csodálkoztok, hogy ez eddig miért nem is derült ki.
Így volt ez velem, amikor egy webshop struktúráját megterveztem, majd elkezdtem felépíteni. Többféle terméktípus kellett, amiket kategóriákba kellett rendezni. Végül nem egy, hanem több taxonomy-t hoztam létre, mindegyik típushoz egyet-egyet.
Először akkor néztem nagyot, amikor a taxonomy views akkor sem hozott semmi tartalmat, amikor a Relationship-nél beállítottam a Produc-ot.
A Views modul csak node alapú nézetekre joinolja magától a node_access táblát. Bármilyen más esetben kézzel kell gondoskodnunk arról, hogy a felhasználó csak azokat az adatokat lássa, amelyeket valóban szeretnénk.
Mi node-okhoz kapcsolt field_collectionöket listáztunk Views-zal. Ez a pár sor kód oldotta meg, hogy a node_access tábla akcióba lépjen:
A történet ott indul hogy volt egy 2011 -es projekt ahol még a projektjeink úgy működtek hogy az egész drupal www benne volt a repóban, az…
Ez nem titok, senki se szereti, mire megtalálok benne valamit, vagy ha megtaláltam, de be kell kattintgatni miden kis pipát, a hajam is…
CsatolmányMéret
Nemrég egy projektünkben a Commerce Custom Order Status modult használtuk egyedi commerce megrendelés státuszok létrehozására felhasználói felületen keresztül. Volt azonban egy probléma a modullal: a létrehozott státuszok egy, a modul által létrehozott adatbázis táblába kerültek, amit nem lehetett exportálni.
Ha egy modul adatbázis tábláját szeretnénk features-szel exportálhatóvá tenni, 3 lehetőségünk van:
Kategória:
Leírás
Miután jó ideje foglalkozok teljesítmény optimalizálással (is), gondoltam legyen egy sorozat a könnyen elkövethető hibákról. Már csak legyen kedvem tovább írni. :)
Az első részben egy olyan hibával foglalkozunk, amibe olyan könnyen bele lehet szaladni, mint Frisco Joe Bud Spencer öklébe.
A weblapok költöztetéséről tartottam előadást a Drupal Használói Találkozón Győrben, 2014. február 27-én.
Az előadásról készült videó itt található: http://www.youtube.com/watch?v=BfVRAZzG7DQ
A prezentációs anyag pedig itt: http://www.authorstream.com/Presentation/zionduc-2088159-weblapok-ztet-se/
A beküldött fordítási javaslataid közül a jókat már elfogadtuk, az alábbiak viszont egy kicsit még jobbá tehetők. Amire kérünk:
Az utóbbi időben többször belefutottam magam is, hogy egy frissítés után "elszáll" az oldal a címben jelzett 500-as hibával.
Tapasztalatom szerint ennek oka általában az entity modul nem megfelelő frissítése. Fontos, hogy a cache-t ürítsük a rendszerből és ellenőrizzük az adatbázisban is, hogy a cache táblák valóban törlődtek, különös tekintettel a cache_boostrap táblára.
Ha ezt nem csináljuk meg, akkor szinte bizonyosan 500-as hibával fogjuk szembe találni magunkat.
Természetesen a frissítés előtti adatbázis és fájlok mentését is mindenképpen végezzük el!
Kategória:
Leírás
Elérkezett az idő, hogy sok-sok oldalunkat fel kell rugdalni a legújabb drupal verzióra. Így természetesen belefutottam az SA_2013_003 security release .htaccess átírós nyavajájába. Na most 30+ oldalnál csak nem kezdem el egyesével átírogatni a files mappa .htaccess-ét.
