Chamber képe

Ha létrehozok egy új terméket pl magyarul akkor létrejön hozzá az új node (mondjuk node/10), ha ezt lefordítom angolra akkor generál neki egy új node-ot (lesz node/11). És valahol megjegyzi, hogy a 11-es node a 10es angol fordítása. Az SKU-t, árat stb ugyanarra állítom mindkét node-nál.

Namost a felhasználó tud váltani nyelvet az oldalon ugyebár... kosaram viszont csak egy, nincs külön angol/magyar kosár.
Ha magyar nyelven áll, akkor csak a magyar termékek látszanak ha angolon akkor az angolok, ez eddig rendben van. De ha berakja a magyart a kosárba majd vált nyelvet angolra és aztis berakja, akkor 2 sor lesz a kosárban, nem pedig a rendelt mennyiséget növeli meg 1-el (ahogy azt tenné, ha ugyanazt a terméket mégegyszer berakja valaki a kosárba).

Úgynézem a kosár működését kéne valahogy meghackelni, hogy nyelvváltásnál fordítsa le a saját tartalmát!? Pl berakok 1x almát váltok angolra >> kosár megkeresi a megfelelő másik node-ot és lecseréli apple-re... így ha most hozzáadok 1x apple-t akkor nem 1x alma + 1x apple lesz benne hanem 2x apple. Ha visszaváltok magyarra akkor meg 2x alma.

A te oldalad hogy működik? Mert ha nemis rakok ki nyelvválasztó blokkot, a felhasználó mindenképp be tudja állítani a saját nyelvét csak kicsit körülményesebben (saját beállítások).
Vagy nálad a felhasználó NEM tud nyelvet állítani hanem mondjuk az admin mondja meg hogy ki milyen nyelven lássa az oldalt? Ez lenne a megoldás? 0_o

Más a neve, node id-je, de az ára, cikkszáma (SKU) ugyanaz nem? Akkor az nem egy termék?
Én is azt hittem hogy az SKU dönti el hogy mi "egy termék", de úgylátszik ehelyett a node-ID dönt.

0
0
dj képe

A „tanár úr kérem oldalon” bemutatotthoz hozz létre egy view-t ez egy alapértelmezett nézet lesz, névnek add azt, hogy "cimlap". Itt állítsd be azokat az alap dolgokat amik minden nézetnél azonosak lesznek. Az egyszerűség kedvéért elsőre válaszd a "Row style" opciót "node"-ra, később macerálhatod a mezőket is, ha már érted a működését. Aztán állítsd be a szűrőt ( Filters ) a + gombra kattintva: "Node: Published True" ( ez a közzétett ), majd újra a + gombra kattintva: "Node: Promoted to front page True" ( ez a címlapra kerül ), újra + gomb: "Node: Sticky False" ( ez a nem kiemelt ). A rendezést ( Sort criteria ) a plusz gombra kattintva állítsd a beküldés dátuma szerint csökkenő sorrendbe: "Node: Published desc". Ezzel az alapértelmezés megvan.

Hozz létre blokk nézeteket: a Defaults alatti legördülő listából válaszd a "Block" opciót, majd kattints az "Add display" gombra. Az elsőnél a "Name" mezőnek add meg azt, hogy "kiemelt". Itt válaszd a "Node: Sticky False" szűrőt és állítsd True-ra, mert ebben a nézetben a kiemelteket akarjuk látni majd. Annyi a nehezítés, hogy nem az "Update default display" gombot válasszuk, hanem jobb oldalt az "Owerride" gombot, majd az ennek hatására megváltozott "Update" gombot.

Rendre létrehozod még a megfelelő blokkokat ( Block -> Add display, mint fentebb ) a taxonómia szerint ( neveket ne felejts el adni a blokkoknak ) és a szűrőben a taxonómia nevét választod ( Taxonomy: Term ), itt is ügyelsz, hogy ne írd felül a default displayt, hanem használd az owerride gombot, majd update.

Ha mindennel megvagy akkor mentés, így a view-k elkészültek.

A létrehozott panel content menüjében látnod kell sematikusan a panel felépítését amit választottál. Ha ott a + gombra kattintassz akkor kapsz egy listát amiben fel vannak a view-k is sorolva amiket elkészítettél. Értelemszerűen válaszd a megfelelő view blokkot a megfelelő helyre.

Üdv!
Dudás József

0
0

Üdv!
Dudás József

aboros képe

tudom, hogy mi ajánlottuk, de mégse oldja meg az egész problémádat, mert nem arra van amit szeretnél, illetve csak részben. (van a modulhoz egy readme.txt file, olvasd azért el azt szerintem)

ez a modul alapvetően arra van, hogy az egyes nodeokhoz korlátozza a hozzáférést az alapján, hogy milyen kategóriába tartozik az a node bizonyos szótárban.
ez eddig ok is, arra, hogy ki melyik galériában lévő képeket láthatja. (figyeld meg, hogy itt már benne van a kép a galériában!)

az már egészen más, hogy ki melyik galériába tölthet fel, mert ott meg azt kellene szabályozni, hogy a node (kép) beküldő űrlapon, a "galériák" szótárban ki melyik kifejezést láthatja/választhatja ki.

ha az is jó megoldás, hogy egyikből sem választhatnak, hanem egy harmadik személy a megfelelő jogosultsággal fogja a beérkezett tartalmat galériákba rendezni, akkor talán az a legkattintósabb megoldás, hogy a content taxonomy modullal "mezővé alakítod" :) azt a szótárat és akkor már a cck részeként elérhető field permissions segítségével el tudod azt tüntetni a kívánt csoportok elől.

ha mindenki fel is tölthet abba a galériába, amit láthat is, akkor már bonyolultabb lesz kicsit, de nincs lehetetlen csak tehetetlen, saját modullal is meg tudod oldani ha minden kötél szakad, de most hogy így írom a dolgot, eszembe is jutott a vörkeránd.

sose próbáltam, de:
mi lenne, ha nem taxonómia kifejezések lennének a galériák, hanem azok maguk is nodeok lennének, így a hozzáférést a galériákhoz is lehetne szabályozni és az egyes képeket node referencel köthetnénk a galériához, amibe, ha jól tippelek már csak azok a galériák kerülnek majd be eleve, amikhez van megtekintés joga a felhasználónak.
a galériák megjelenítését meg views modullal csinálnánk, némi sminkelés és még jobb is lesz, mint az image modul dolgai.

0
0

-
clear: both;

patron képe

Köszi eager!

Meggyőztél, tényleg nem túl tetszetős minden leszállást egy leborítással indítani, sőt az egészségre is roppant káros :)

Ami elindította bennem ez a gondolatot, az egy vékony internettel, kevés idővel és be kell vallanom lustasággal is vegyülő érzés volt.
Ráadásul, első felindultságomból meg is tettem ezt a file-ban meta tagos átirányítást, ami a FF és Safari esetében jó is volt, de az IE nem ette meg. Egy önmagába visszatérő ciklus lett belőle. Sok időt eltöltöttem a problémával, mire beugrott, hogy a hosting oldalon csak van valami átirányítás / GoDaddy /. Persze, hogy volt.
Tegnap elkezdtem felrakni a 7.7-el. Természetesen elsőre megborult.
Előtte pedig csak gyakorlás miatt és hogy le tudjam mérni mennyi időbe is telik, telepítettem egy alkönyvtárba. Minden simán ment.
Na mindegy, maradt az átirányítás, mert a régi oldalt már töröltem.

Közben néztem a keresőket és elég előkelő helyen jön elő a régi oldal. Nem egy nagy forgalmú lap / tavaly 7000 látogató, 27000 oldalnézés /, de 2 év alatt jól feljött.
A mostani átirányítás a régi laptalálatokat nagyon szépen átviszi az új oldal elejére, ha megszüntetem, akkor csak 404-es hibával zaklat.

Mindenféle képpen át fogom helyezni az oldalt a gyökérbe, ez nem is kérdés, főleg ilyen repülős példa után :), de megfordult a fejemben , hogy nem e jobb ötlet egy kicsit átirányításban tartani és majd amikor lekopik a keresők elejéről a sok régi lap, akkor átmozgatni.

Lehet, hogy nem túl helyes az okfejtésem, de nézzétek el nekem.
Azt hiszem még mindíg jobban tudok leborításból leszállni, mint megérteni, hogy a bit az nem bájt, bár küzdök és küzdök.

Köszönöm az okosságokat.

0
0
aruna képe

hogy mit csináljak, ha van összesen 10 oldala a site-nak, pl. 5 elektronika és 5 informatika, és ezek még statikusak is, de egyedi menü, banner és blokkok kellenek.

Ámde nem szeretnék ágyúval verébre lőni, és nem hiányzik multisite és domain access tanulás és használat, pláne két "törpe" site kedvéért.

Én ezt a megoldást találtam a problémámra a legegyszerűbbnek:

Minden oldal használjon prefix-eket (informatika- vagy szerszamok-) az url aliasokban, pl.:
szerszamok-szolgaltatások
szerszamok-kapcsolat
informatika-szolgaltatások
informatika-elerhetoseg
...

Ezután az alias-ban lévő prefix vezérel mindent, így a smink, a menü és blokkok megjelenését:

- Létre kell hozni két menüt a két különböző prefix-nek, és az alias-tól függően vagy az egyiket vagy a másikat jeleníted meg. Pl. egy php 'if' feltétellel a smink könyvtárban lévő page.tpl.php-ben vagy az egyiket vagy a másikat jeleníted meg az alias-ban lévő prefix alapján.

- Ha változik a banner (vagy a smink más részei), ezt is le tudod kezelni az előző módszerrel, a fenti fájlban máshová is raksz 'if' feltételeket.

- A blokk-ok láthatóságát is tudod állítani a blokkok beállításainál, hogy melyik oldalon jelenjenek meg vagy ne (informatik-*, szerszamok-*). Tehát mindkét törpe "site"-nak saját blokkjai lesznek.

-----

A kérdésed másik része egyszerűbb:

"Az a tervem, hogy a kezdőlap egy profilválasztó ablak lenne csupán"

Itt egyedi front-page kellene, erre van külön modul is: http://drupal.org/project/front
De ez a modul sem kell feltétlenül, ha létrehozod a smink könyvtáradban a page--front.tpl.php fájlt, és azt raksz bele, amit akarsz profilválasztó linkeknek, pl. ezeket az alias-ú oldalakat: szerszamok-fooldal, informatika-fooldal

0
0
kepes képe

Sziasztok!

Örültem a sok hozzászólásnak, és mivel szeretnénk megoldani az esetet ami nem egyedi, csak esetleg máshol nincs ennyi látogató, leírok pár adatot, információt. Az oldal címét írja meg a tulajdonosa ha gondolja.

- A szervereken memcached nincsen (még lehet, de ez hosszabb folyamat), ellenben van Varnish, saját oldalaink azon keresztül mennek! Ezt azonban mi nem merjük kiajánlani, mert konfigurálni kell egyedileg minden oldalhoz. Szerintem már találtunk általános Drupal konfigot hozzá, azonban ez általában a feltelepített egyéb dolgok miatt nem megfelelő, mert POST után nem mindíg jelenik meg a frissített oldal (pl. oldal comment). A konfiguráció idő, szakértelem, pénz...

- Az említett oldal statikusnak mondható, kb. napi 2000 látogatóval, napi 4-6000 találattal. Naponta ez az oldal (tegnapi adat) 464.186 lekérdezést indított. Matek: 92 lekérdezés / page. Ma eddig 123.472.

- Sajnos a mysql query logból igen nehezen gyűjthető ki egyetlen felhasználó ténykedése. Aki látott már ilyet az tudja miről beszélek. Külön eszközök vannak az elemzésére, egyszerű szűrés nem megvalósítható rajta. Ráadásul az adatmennyiség is hatalmas, a szervereken átlagosan 300-400 lekérdezés fut másodpercenként de nem ritka a több ezres TPS sem.

Kérdés:
1. Van olyan cache esetleg, ami az oldalakat első kéréskor legenerálja, és utána csak ezeket a statikus fájlokat jeleníti meg? Pl. WordPress cache megoldások ilyenek. Kb. az összes fájl elférne memóriában zéró adatbázis művelettel, aztán óránként ezek a fájlok újragenerálódnak.

2. Ha beizzítjuk a memcached-et ezen a szerveren, ahhoz van standard plugin, ami különösebb konfigurálás és ismeret nélkül működik?

Észrevétel:
Mindenkinek javaslom, ha nagyobb marketing kampányba fog, előtte teljesítmény tesztelje oldalát (ne a szolgáltató szerverén, hanem fejlesztői gépen), és egyeztessen a szolgáltatóval is! Sok nagy látogatottságú oldalunk van, úgy gondolom a megoldás csak odafigyelés kérdése.

6
-1
Anonymous képe

T. Goba!

Mint bátorkodni jeleztem, a lapra nyomtatják az oldalt. Ha egykutya, akkor két dolog össze van kavarva...

A fő kérdés az, hogy kikerül valami, ami nyelvhelyességi szempontból meglehetősen pontatlan, - ezzel önmagát minősíti; avagy helyes szabatos kifejezéseket tartlamaz, ami szintúgy önmagát minősíti.

Számomra mindegy, mert a saját webhelyemen úgyis a megfelelő kifejezések használatára állok be, a pongyolaságot, összemosottságot kerülve.

A kérdés még úgy is érdekes, hogy: megfertőzzünk másokat a helytelen nyelvhasználatunkkal, avagy az igényesebbjét késztessük elég sok pluszmunkára, netán jól használható, egyértelmű, pontos kifejezések használatával némi rendet segítsünk kialakulni ebben az "egykutya" - eléggé igénytelen és ... - világban.

Üdv': AT

0
0
mggsm képe

de 2 napja küzdök az exportálással, és nem akar sikerülni... Ha megadnám a hozzáférést, valaki megnézné, milyen beállításom nem jó? Ha a kiszolgáló serverére az alap adatbázist rakom fel, minden ok. Ha az exportáltat, ez az eredmény.:

Fatal error: Duplicate entry '65d4eae7756b42b3c2b10e037cd9db37' for key 1 query: INSERT INTO sessions (sid, uid, hostname, timestamp) VALUES ('65d4eae7756b42b3c2b10e037cd9db37', 0, '80.98.247.106', 1118317629) in /USER/mggsm/mobilgaleria_hu/www/includes/database.mysql.inc on line 66

Nem értek hozzá, jól jönne egy kis segitség!

0
0

Papi

Sweetchuck képe

Szerintem átláthatóbb lenne ha minden modulnak külön fórumja lenne, és azon belül lehetne topic-ot nyitni.
Ha valakinek kérdése van egy modullal kapcsolatban akkor át kell (kéne hogy ne legyen kétszer ugyan az) nyálazni az egész modul fórumot. Bár nem a duplikáció a probléma hanem az, hogy nehéz rátalálni az információra. Néhányszor a téma címe nem is elég arra hogy megállapítható legyen hogy mit tartalmaz.

Nekem személy szerint nem tetszik, hogy a Kézikönyv oldalakon jobb és bal oldalon is van block. 800×600-as felbontáson teljesen harmadolja a képet.

Azt már jeleztétek hogy lesz új filter Syntaxhighlighter-rel remélem megvalósul.

bye

0
0
Hojtsy Gábor képe

A biztonsági frissítés megjegyzés valóban fontos, kösz. Az, hogy érdemes mindig a legfrissebb stabil verziót használni és hogy ezt mennyi erőbefektetésbe telik megvalósítani a mérleg két oldalára helyezendő szerintem. Nem biztos, hogy az jön ki, hogy frissítesz. A Drupal belső berkeit ismerők könnyen kódmódosításra adhatják a fejüket, vagy ha addig nem is mennek el, legalábbis jópár saját modult adhatnak a rendszerhez, amiket maguknak kell átírni, esetleg újraírni (például a 4.7 kapcsán az űrlapok miatt főleg). Többek között az ilyan nagyobb döccenők elkerülése érdekében igyekszünk alacsonyan tartani a drupal.hu-n használt modulok számát, de ahogy egy frissítésnél lenni szokott, itt sem ment minden olyan egyszerűen, ezért kezdtem el írni ezt a sorozatot.