Ez sucks.
Ez sucks.
Sajnos most nincs előttem commerce install, de ebben az esetben jó eséllyel fel kell menned egy olyan entitásig, amihez van nyelv rendelve. Gondolom a payment transactionnek tutira nincs, de az ordernek már esetleg lehet. Line item/node-oknál nem tudom, van-e értelme keresgélni, mert mi van, hogyha a cart-on különböző nyelvű line_item-ek vannak.
Ha nincs az ordernek nyelve, akkor csinálj neki! :)
Adj egy mezőt az orderhez, pl field_language. Keress egy olyan rules eventet (most ezeket sem vágom hirtelen, hogy mi lehet (pl egy status váltás az orderen: after updating existing order; conditionben meg megadod, hogy az unchanged order status = valami and order status = ujvalami) Na akkor beállítod a field_language-t a [site:current-page:language]
Így a Data to compare az order field_language mezője lehet.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hasonló a kérdésem
Hasonló a kérdésem, de egy kicsit más.
Hogyan lehet (gondolom 1000 féle képpen, de hogyan szokták...) megoldalni az olyan 2 szintű menüt, mint ami a weblabor.hu -n is van? Azaz hogy a második sor attol függ, hogy az elsőn hova kattintottam.
Mivel az én esetemben nem kell általánosra megcsinálni, vagy ilyesmi, ezért arra gondoltam, hogy talán smarty-val if-ekkel. Azért gondoltam erre, mert az oldalam több aldomain-ből állna, amik az site egy-egy komolyabb funkcióját valósítaná meg. Mivel ennek nem kellene látszódnia (az url -en kívül) a felhasználóknak, ezért arra gondoltam, hogy beilleszteném ezt a header-t minden index tetejére. Így esetleg meg tudom oldani, hogy a drupal headerjének egy linkjéből eléressem pl. a mediawiki felett futó wiki-met, aminek ugyanaz a header lenne a tetején, és az alatta lévő skint is egy kicsit hozzá igazítanám.
Ezzel az egyetlen egy gond, hogy nem értek a smarty-hoz, és azt sem tudom, hogy ezeket hogyan kell összefűzni egybe.
Summázva: a weblabor ezt hogy csinálja? Ti ezt hogy csináltnátok?
Köszönöm!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
RC = kiadásra jelölt, még nem stabil
Ez a változat már funkcionalitását tekintve nem fog változni, de számos hibajavítást még fog tartalmazni, ezért változik a forráskód.
Én személy szerint nem javasolnám, bár van 2-3 oldal amit már én is az 5-össel üzemletetek, de ezek éles indulása január vége, február közepe.
Gondot jelenthet még, hogy spec modulok (amik 4.7 alatt tök jól működtek) nem érhetőek el, vagy nem túl stabilan működnek ezzel téve az egész rendszert instabillá.
Amit át kell gondolnod
- szükségesek-e az 5-ös plusz szolgáltatásai.
- milyen plusz modulokra van szükség az oldal működéséhez.
- a kezdeti bizonytalan időszak, vagy a későbbi átállás lesz a munkásabb. (ugyanis a 4.7-et az 5-ös kijövetele után csak egy bizonyos ideig fogják javítani, mint ahogyan 4.6-hoz sem jelnik meg túl sok hibajavítás ;))
Ez utóbbinál segít az, hogy a szerződésben az előállítás, vagy a később nyújtandó support költségéi közé számolod ezt be. (esetleg már az ajánlat adásánál gondoltál egy jelentős verzió cserére)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szerintem elbeszélünk egymás
Szerintem elbeszélünk egymás mellett.
Ha létrehozok egy menüt és feltöltöm menüpontokkal, és megcsinálom a CSS-t hozzá. Akkor az vasalva van (a tpl.php-s változtatást kivéve, ez nekem új). Vagyis a létrehozott menű ID csak akkor változik, ha törlőm és létrehozok egy másikat, de ugyebár akkor már nem az eredeti menüröl van szó, hanem egy másikról. Szerintem aki eljut egy végeredményhez az nem fogja újrakazdeni, tehát vasalva van az ID.
Ó persze, egy adatbázisban minden bármikor változtatható, de ha létrehozol egy új menüt, vagy installálsz egy modult, akkor attól az adott menü ID-je nem fog megváltozni. Márpedig a hozzászólásból nekem úgy tünt, hogy a hozzászóló azért van gondban, mert elképzelhető, hogy a menük ID-je egy kissebb ID számú menü törlésekor átszámozódik. Ez persze lehetséges, nem próbáltam, ha így van akkor pehh ;)
Tegyük hozzá, nem vagyok programozó és az agyam is másként működik, és az "elképzeléseim" is mások... Az biztos, hogy nem vagyok szakszerű... :))
...mit tudok: http://web.termuves.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szerintem meg jól látja.
Amiről Te és Goba beszél az az, hogy ne kelljen egy tartalmat kétszer postolni és az adott oldalhoz igazodni, meg az hogy minden meglegyen egy helyen.
Akkor miért nem a nyitó oldalon jelennek meg ezek az aggregált hírek? Mert azért valljuk meg ott lenne a helyük.
Nevergone arról beszél és amire például én is használom a trackert, hogy megnézze milyen aktuális probléma (fórum téma) van, illetve milyen a magát a közösséget érintő téma van. Lehet, hogy amiről nevergone és én beszélek megoldható lenne a HUP-hoz hasonló fórum témák legutóbbi válasz alapján rendezve megjelenítéssel - ha már lúd legyen kövér, akkor szerepeljen még, hogy ki volt az utolsó hozzászóló. Talán ez azért is van, mert mindketten ott is megfordulunk :-)
Szóval mindenki mást keres, de ezzel csak azt tudom mondani, hogy az eddig megszokott eszközt másképpen kell használni, vagy érdemes lenne +1 feature: a tartalom típus rendezhető legyen és fordított rendezésnél már ki is esnek az aggregált hírek :-)
Páldi Zoltán
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ennél egyszerűbb megoldást nem tudok
ráadásul ez is csak félmegoldás, hiszen az űrlapelemeid továbbra is ott vannak a forrásban és kötelezőek is (ezért fel is töltöd értékkel: "személyes átvétel") csak elrejted őket a humán elől.
sminkréteg szinten sima ifekkel nem fogsz tudni egy űrlapot módosítani, ez egyátalán nem így megy, van egy form API annak a szabályai szerint kell az ilyesmit csinálnod, általában a hook_form_alterben. ebben a hurokban ott lesz az egész űrlap. minden űrlapnak van egy idje. azt figyeled rögtön a hurok elején, hogy arról az űrlapról van e szó, amibe ezzel a hurokkal bele akarsz piszkálni és ha igen, akkor megteszed.
ez eddig még ok is, csakhogy ez nem kliens oldalon történik, új oldalletöltés nélkül ezzel a módszerrel nem fog az űrlapod módosulni. plusz még ott van az is, hogy a drupal biztonsági okokból csak egy pont olyan űrlapot fog elfogadni válaszként, mint amit kiküldött, emiatt az űrlapok kliensoldali mahinálásának sajátos módja van a drupalban, ha jól gondolom ez az AHAH.
annak pedig, hogy ez egy kész oldal e vagy sem ehhez semmi köze nincs. :)
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
számlaszám
A commerce_billy folytonos számlasorszámot csinál. Ahogy elnéztem átírja rendelés számát a számlasorszámra. (A rendelésszámok nem számlaszámok.)
Értem mire gondolsz, de a felhasználó nem tudja módosítani a számlaszámokat (elvileg). Persze az adatbázisba mindig bele lehet nyúlni (aki ért hozzá). A nem webes számlázóprogramokba is bele lehet nyúlni - aki tudja hova kell nyúlni az adatbázisban.
De jogos amiket írsz.
Az apeh-nál egyszer anno valahogy így magyarázták el ezt:
Tehát ha a kézikönyv szerinti használat esetén nincs lehetőség "adathamisításra", akkor az a szoftver rendben van. Az más kérdés, ha ezt megkerülve a felhasználó átír adatokat - ilyenkor a felhasználó a felelős érte, mert nem "szabályosan" használta a szoftvert.
Pl. sok régi DOS-os számlázó szoftvert láttam, amit hivatalosan lehet használni. De mégis aki ért hozzá, az adatbázisban (pl. a dbf állományokban) simán át tudja írni az adatokat utólag.