lili_ képe

Maradtam ennél a modulnál:
https://drupal.org/project/commerce

A több érték/csoport ezzel sikerült megcsinálni:

http://drupal.hu/forum/price-role-e-commerce/19316

A termék importálását, képpel együtt pedig ezzel!

http://www.drupalcommerce.org/user-guide/importing-products-using-feeds

Már csak az van hátra, hogy az árakat kell szépen megjeleníteni, mert van olyan csoport, ami az összes árat látja, de a rendszer jóval számol.

Sőt azt is sikerült megvalósítani, hogy az adó értéket is a számolja a különböző csoportokra.

De ha van valakinek ötlete azért szívesen veszem mondjuk übercart-ra ezt hogyan lehetne megvalósítani

1
0

mini

mopet képe

Köszönöm a leírást, igazán hasznosnak bizonyult. Actionnek beállítottam, hogy fetch entity by property, utána végigküldtem rajta a loopot. Egyenlőre azok kapnak e-mailt, akik ugyanabban a kerületben vannak, mint a beküldő, viszont nem tudom megszűrni, hogy csak a moderátorok kapjanak.
Úgy próbálkoztam, hogy az előző action alá beküldtem még egy fetch entityt. Entitás típusának beállítottam a felhasználót, tulajdonságnak a szerepkört, de a lekérni kívánt entitás tulajdonságértéke mezőnél nem tudok megadni fix értéket, csak tokent, pedig nekem arra lenne szükségem, hogy ez a mező mindig a moderátor értéket vegye fel. Lehet, hogy rossz szintaktikát használok, esetleg az adott szerepkörnek valami rendszer által kezelt nevét, ID számát kellene használnom? Ha igen, azt hol találom.
Jó egyáltalán az az elképzelés, hogy egymás alá rendelt fetch entity-val próbálkozom, vagy van sokkal egyszerűbb?

0
0
nevergone képe

Szia!

A „fehér halál” szinte mindig 500-as hibakódú „Internal Server Error”-t jelent. Valószínűleg valamelyik PHP kódban olyan végzetes hiba van, ami megszakítja a PHP értelmező futását.
A szolgáltatódtól kellene PHP error_log-ot kérned, hogy kiderüljön, melyik fájl melyik sora okozza ezt a hibát.

Esetleg azt még érdemes lehet megpróbálnod, hogy letöltöd az oldaladhoz tartozó kódot a tárhelyedről, majd egy másik könyvtárba újra összeállítod az oldalt. (elvégre tudod, hogy milyen verziójú Drupal és modulok vannak az oldaladon). Majd valami programmal (talán a Total Commander is tud ilyent, nem ismerem) összehasonlítod a letöltött oldalad fájljait azzal, amit nulláról felépítettél.
Ui.: Hogy ne legyen gebasz, összehasonlítás előtt a letöltött oldaladból érdemes kitörölni a files könyvtárat és a settings.php-t, különben az összehasonlítás azokat is eltérésnek fogja jelezni.

1
0
Phoere képe

A kérdés nem rossz, pro és kontra lehetnek érvek. Mivel a taxonómia szótár többszintű lehet, az egyes szülő kifejezések gyermekei között lehetnek azonos nevűek. Bár elvileg ugyanazon kifejezés több szülő alá is tartozhat, ez nem mindig kezelhető utána egyszerűen a megjelenítéskor. Valószínűleg ilyesmi ok miatt nem zárják ki az azonos nevet egyazon szótárban.

Viszont egyértelműen jelzi, hogy a szabadszavas cimkézést nem célszerű bárkinek engedélyezni. Egy zárt felhasználói körben valószínűleg elérhető, hogy mindenki betartsa: ha már van olyan kifejezés, akkor azt válassza. De egy teljesen idegen csoportnál ez gyakorlatileg lehetetlen.
Mindenképpen célszerűbb fix kifejezéslistát biztosítani és legfeljebb egy egyéb mezőt, ha nincs a listában. És akkor Te egészíted ki ilyen esetben a szótárt sz új kifejezéssel és beállítod a tartalomhoz - vagy beállítasz egy létezőt, ha az szerinted megfelel az újnak.

0
0

Csökönyi Ferenc

lazar képe

Értem mire gondolsz, de nem ugyanaz. A nézet első mezője ugye megkapja a views-row-first class-t, ezt sminkelhetem. Csakhogy amint új cikk kerül a nézetbe, a fenti class már az új mezőé lesz. Nekem pedig az lenne szükséges, hogy ezt a class-t továbbvigye magával a második helyre.
Tehát a nézet eredményei közül pl. az első cikknek adok egy sárga backgroundot (kiemelem, mert fontosnak tartom), ezt vigye magával a következő a második helyre - ott is ugyanazzal a backgrounddal jelenjen meg. Azonban, ha nem tartom annyira fontosnak, akkor nem szeretném kiemelni, tehát csak simán listázzam, background nélkül.
P.S.: azt hiszem nem jó úton vagyok,, s valahogy másképp kell összeállítani az oldalt ... :( A nodequeue is jó megoldás (talán jobb is), de egyelőre itt is ugyanaz a gondom: hogyan adjak hozzá még egy class-t :(

0
0
Atesz76 képe

Kedves Drupálosok!

Egy olyan segítségre lenne szükségem, hogy van egy Drupálos óra webshop oldal, amiben nem működik rendesen a kereső nem én készítettem az oldalt, és aki csinálta az már nem elérhető sajnos.

Ebben szeretném a segítségeteket kérni, hogy mit hogy kellene beállítanom, hogy úgy, működjön a kereső, hogy érzékeny legyen vagy is, pl. ha beírom, hogy 3500 vagy Casio 3500 akkor, amit talál, kiadja, mert ez most sajnos nem működik, csak akkor van találat, ha az órák pontos típusát megadja, az ember a keresőben úgy megtalálja amúgy nem.

Én nem nagyon vagyok még jártas a Drupál világában eddig csal joomlás oldalakat csináltam.

Ez a weboldal címe, ha valaki megnézné: http://www.oraker.hu/

Előre is köszönöm szépen a segítséget!

0
0
Sweetchuck képe

Most hogy ilyen szépen összeszedtünk, hogy melyik hogyan működik és mire való, el kéne dönteni, hogy hogyan honosítjuk őket. :-)

Talán a legkönnyebb a checksum => ellenőrzőösszeg
Nekem egy pici bajom mégis van az összeg végződéssel.
Magyarban az "összeg" kifejezés több dolog együttes értékét jelenti. Viszont a checksum 1 adatból készül.
Ezért számomra az ellenőrzőazonosító vagy ellenőrzőkivonat kifejezőbbek lennének. (Ahogy elnézem egybeírva helyesírási hibának számítanak)

A hash => hasító párhuzam nagyon idegen számomra.
A "hasító" hallatán nekem egy balta jut eszembe. Mégpedig az a balta amelyikkel szívesen felaprítanám a kitalálójának a nyelvét :-)

Mindig arra a következtetésre jutok, hogy könnyebb modult írni mint honosítani.

0
0
DruTa képe

Kiegészítés: nincs lehetőség az angol értesítő szöveget szerkeszteni, ezért a Felület fordításnál tettem meg.

Van egy ilyen:

Recent nodes - !count 

Lefordítottam, hogy ne "New", hanem "Új" szó legyen, és tartalom. Működött is, most meg ez is visszaállt "New"-ra.

Nem, nem frissítettem a fordítást, és eleve úgy van beállítva egyébként is, hogy a manuális változtatásokat ne írja felül egy esetleges frissítés.

Ez az adatbázisban tárolódik, és amikor átírom, akkor át van írva, nem? Pontosabban az angolnak megfeleltetődik az a magyar szó.
Ez h. a pikulában tud magától visszaállni?

0
0
Pasqualle képe

https://www.drupal.org/project/webform
https://www.drupal.org/project/libraries

Ha jol latom a pajzs szine megegyezik a sor szinevel.

- dev, alpha, beta, rc releasnek nincs pajzsa (mivel nem "stable" release)
- zold a recommended release
- sarga supported release

-recommended release azt jelenti, hogy ezt a kiadast javasolt hasznalni egy uj weboldalon
- supported release azt jelenti, hogy ha ezt a kiadast haznaljuk meglevo weboldalunkon, akkor az (update modul) "Available updates" oldal nem fogja rank eroltetni a legujabb kiadas letolteset. Az adott kiadast hasznalhatjuk, a modul keszitoje szerint az adott kiadas megfelelo minosegu (csak kevesebb funkcioval rendelkezik).

fekete alapszin gondolom csak az egyszeru css szinezes miatt letezik.

2
0
Drufan képe

Kerestem, de nem találtam ezt, de kösz.

Akkor ez egy alapbeállítás lehet, mert az én oldalamat sem mutatja és mint írtam a drupal.org-ot se. Először az aldomain-ra gyanakodtam, de akkor ezek szerint nem.

És mi a különbség ezen oldalak működése, és a böngészők F12-vel elérhető webfejlesztő eszköze között, azok ugyanis működnek, amikor ott nézek meg pl. más eszközöket, bár azok elég kamu nézetek, lehet, hogy ez a Responsinator és társai valódi eszközt emulálnak, bár megnéztem olyan oldalt, amit én is tudok egy eszközön és más volt az eredmény, szóval nekem úgy tűnik ezek az oldalak is csak a felbontás alapján mutatják a különböző eszközöket.

Tudsz olyan megoldást, amivel Drupal oldalt is meg lehet nézni valódi emulált környezetben?

0
0