Eleve két dolgot vegyél figyelembe:
A computed field értékét PHP kóddal beállítva a termék mentésekor létrejön, amit akarsz.
Azonban az ÁFA kulcs módosítása - mivel a computed field nem része a webáruház modulnak - nem fogja ezt módosítani, tehát erre egy szabályt is létre kell hozni.
A mentéskor a következőképpen kell megalkotni a php-kódot:
- ne tedd a szokásos <? ?> jelek közé
- szükséged van a haszonkulcsra és az ÁFA kulcsra. Az ÁFA kulcsot le kell kérned egy db_query-vel az adatbázisból. A haszonkulcs esetében kérdés, hogy globális haszonkulcs van, vagy termékfüggő.
Az előbbi esetben a haszonkulcs is valahol tárolva van, onnan kell lekérni. Ha egyedi, akkor nyilván egy CCK mezőben adod meg, ezt kell használni az alábbi formában:
$haszonkulcs = $node->haszonkulcs[0]['value'];
Ezek alapján a kívánt eredmény:
$brutto = $netto * $haszonkulcs * $afa ;
A kapott eredményt pedig így kell visszaadni:
$node_field[0]['value'] = $brutto;
Összefoglalva tehát valahogy így nézne ki:
$query_afa = db_query("SELECT ..... ");
$afa = db_result($query_afa, 0, 'mezo' ; /* a pontos adatok az adatbázisból kinézhetőek; */
$haszonkulcs = $node->haszonkulcs[0]['value']; /* amennyiben a terméjkhez CCK mezőben kapcsolódik a haszonkulcs */
$brutto = $netto * $haszonkulcs * $afa ; /* nyilván a megfelelő kerekítési függvénnyel kiegészítve*/
$node_field[0]['value'] = $brutto;
Remélem, így sikerül elindulni.
Csökönyi Ferenc
Szervusztok,
Látom régi ez a kérdés, de válaszolok hátha más is kűzdött ezzel a problémával. Nem rég én is ezzel szenvedtem én is használom a webform modult mert kényelmes, ha adatgyűjtésről van szó és az eredményeket nem kell megjeleníteni.
És itt a probléma... A Webformal beküldött eredmények nem tartalmak ezért simán views-zal nem lehet őket megjeleníteni.
Egy baromi bonyolult és robosztus megoldás van rá. Nyilván ha írnánk rá egy egyedi modult, akkor egyszerűbben is megoldható lenne.
Szóval az alábbi modulok kellenek az eredmények kihámozásához:
(Igazából csak a Views MySQL és a data kéne, de ezek bekapcsolásához szükség van az alábbiakra is.)
Ami gond lehet ezzel a megoldással, hogy ha olyan szolgáltatónál vagy aki SQL jogokat is korlátoz akkor a Data modullal gondok lehetnek (tábla jogosulások miatt).
Egy kis segítség a modulok beállításához:
http://dev.nodeone.se/node/666
Őszintén miután megcsináltam, lecseréltem ezt a megoldást CCK-val és sima views-zal. A webform eredményeket kiexportáltam csv-be és node importal feltöltöttem az eredményeket az új "űrlapba", és így a beküldött eredmény felhasználója is az eredeti maradt...
Simán lehet, hogy csak a szerver sz@r, amin próbálkozom, mert az admin/status/report megjelenítése során meg exceptiont kapok ezzel a hibával (a vonal utáni rész az érdekes): http://pastebin.com/SZ5qxVHZ, miközben ugyanezt az adatbázist és fájlrendszerbeli adatokat felhasználva localhoston hibátlanul működik ez az oldal is.
Tehát lehet, hogy localhoston a fenti para sem fordult volna elő. (Amúgy tudom, éles szerveren nem próbálgatunk, csak gyorsan kellett átszabnom a megjelenést, a megrendelő által elvárt formára, és hát nyilván ilyenkor jelentkezik a hiba.)
De még ha így is van, nem tudom, mi lehet az oka, milyen beállítás kevés neki, mert a memóriakorlát miatt már szóltam, hogy emeljék már meg 128 MB-ra, és meg is tették.
Amúgy én úgy teszteltem, hogy rengeteg (20-30) field volt berakva többféleképpen egymásba ágyazott field_groupokba, majd rámentem a "One column" layoutra, sok szülőelem a groupokból Disabledre került, és amikor vissza próbáltam mozgatni a szülőelemet a tisztes helyére, akkor sok AJAX-os kérés elindult (lásd sok-sok throbber mindegyik field mellett), és ezután kaptam az 500-at, és többé nem értem el a "Manage display"-t. A node-ok megjelenítése legalább nem ütközött hibába, még ha hiányoztak is belőle fieldek.
De az szerintem eleve nem valami értelmes megoldás a Display Suite-nál (vagy a Field group fejlesztőinek kéne megoldania), hogy széjjelvágja a field_groupokat, ezeket egyben kéne tartani.
mint ha vmi "horror kóddal" programoznád a kapcsolatokat, árakat, lehetőségeket. Többnyire vannak olyan feltétek, amik nem választhatók az egyik-másik pizzánál, ezért a kivételek lekezelése még bonyolultabbá tenné a kombinációk létrehozását.
Ráadásul, ha kedvezményeket is adnak pl. x összeg fölött, vagy ha a két feltét együttes díja nem pont a kettő matematikai összege a kedvezmény miatt, akkor megnézném azt a "jól átlátható" kódot, ami ezt lekezeli és soha nem lesz benne semmilyen elírás, ha időnként azt módosítod. :-)
Ha a legegyszerűbb kivitelezésre, módosíthatóságra törekszünk, akkor egy sima Excel táblázatban Copy-Paste módszerrel létrehozod a lehetséges verziókat, kombinációkat árakkal (pl. x pizza + y feltét + z feltét = 1200 Ft), majd azt a Commerce Feeds modullal beszippantod.
Ekkor veszettül egyszerűen jön létre az összes terméked és azok kombinációja, ill. ha vmi változás lenne, pl. árak megnőnek vagy kombinációk megszűnnek, akkor azt az Excelben módosítod és jöhet a Commerce Feeds. :-)
Az még ennek az előnye, hogy a módosítások elvégzéséhez nem kell rakétatudóst keríteni, aki módosítja a bonyolult kódot, hanem az ügyfél legyártja az Excel táblázatot, egy kezdő Drupalos pedig a Feeds modullal simán feltölti.
Én nem a Commerce Customizable Products modult használtam, de előtte azért futottam vele egy kört. Nagyon jó videók vannak fenn erről itt http://commerceguys.com/blog/commerce-module-tuesday-commerce-customizab... , és itt http://commerceguys.com/blog.
A Kickstart a jó beállításokon túl csak 3 "proli" terméket tartalmaz, de már ezen is jól látható a DC működése.
A kérdésre azért nehéz választ adni, mert azt kell tudni első körben, hogy mitől is kapcsolódik az a termék.
Ha a kérdésre az a válasz, hogy "Ha az adminisztrátor azt mondja" (és legtöbb esetben ez a jó, mert olyan bonyolult a logika, hogy nehézkes a megvalósítása) akkor references egy tökéletes megoldás lehet, field slideshow-modullal.
Ekkor azt tudod megmondani, hogy egy termék oldalán milyen termékek jelenjenek még meg. Ez a legteljesebb kontroll.
Lehet azt is, hogy Egy terméknél megmondod, hogy mihez kapcsolódik és egy views-al jeleníted meg egy terméknél, hogy melyek azok akik hozzá kapcsolódnak. Ezt teheted egy blokk-ba és egy régióba, lehet panelba rakni és lehet a views_field modullal is megjeleníteni.
Lehet a kérdésre az a válasz, hogy azonos kategóriában vannak, ekkor views, szövegkörnyezeti szűrők + kapcsolatok (kategória) + kapcsolatok (tartalmak).
Lehet a kapcsolódó termék az is pl. hogy akik ezt a terméket vásárolták mit vásároltak még, vagy táskarádióhoz elemet ajánlasz, vagy alaplaphoz processzort, vagy stb.
És akkor itt el lehet menni nagyon messzire, amik automatizálásai akkor lesznek igazán jók, ha ezres nagyságrendet jóval meghaladó termékkészleted van, mert ha nincs még mindig egyszerűbb az első megoldáshoz visszatérni. Ez ugyan nagyobb munkával jár, de egyrészt jóval kisebb a belépési küszöb, mint bármely más megoldásnál, másrészt extrém jól testre szabható és eszméletlenül jól kezeli a kivételeket és a (jajerrenemgondoltam) utólagos változtatásokat a kiválasztás szempontjain.
Szóval, ha nem Amazon nagyságú áruházat építesz, vagy nincs atomstabil, kivételektől mentes válaszod a kérdésre, akkor az első kézi módszert ajánlanám. Ár/érték arányban verhetetlen.
Palócz István
https://palocz.hu | https://tanarurkerem.hu
'tehát akár követhetné is a rendszer'
Milyen rendszer? Már ne is haragudj, de ez már a sokadik, fogalmatlan, *szaradrupal* szintű megnyilvánulásod.
A 'rendszer' nem fogja kezelni a nyilvánvaló fejlesztői hibát! Nem lehet módosítani utólag a mező sql struktúráját sem, ha már van benne adat. Hjakérem, gondolkodni előre kell!
Ezt mégis hogy képzelted el? Szimpla search-replace az adatbázisban, ahol a machine name a külső kulcs? Mi van, ha a machine name nem mező, hanem struktrúrált adat? És mi van forráskóddal, ahol $node->type == 'whatever', azt is írja át magátó a rencccerl? Mi a francot csinálsz a mezőtáblákkal, ahol a bundle érték biza a machine name? Természetesen az összes kérdés megoldható, de csak egyedi szinten.
'Azért tűnik logikusnak, hogy követnie kéne, mivel az ID az nem változik, tehát...'
Hjaa.. A drupalnak már tudnia kéne az időutazást, és saját apiról vezérelni a marsra szálló kolonizáló űrhajókat.
'Biztos van ilyen megoldás, mert egy az enyémnél százszor komolyabb és nagyobb honlapnál ez végképp követhetetlenné válik.' - a komolyabb és nagyobb oldalakat hozzáértők tervezik, készítik (jó esetben). Csináltam egy párat, és még csak fel sem merült, hogy egyáltalán bármikor machine name-t kelljen módosítani. Ha pedig valami hülyeségem miatt mégis muszáj lenne, akkor erre való a hook_update_N, természetesen gondos tervezés, tesztelés után.
Amin itt feszengsz, az egyszerű pebkac, hozzá nem értés és nem a drupal hibája.
----
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.
2018-ban ne legyen már gond biztonságosan elhelyezni egy file key-t egy serveren!
Szóval hol a probléma? Miért nem tudsz AES-t felrakni?
Ismét: A biztonságnak ára van. A cég meg eldönti, hogy hajlandó-e megfizetni az árat. Amúgy ebben semmi újdonság nincs, ugyanúgy az az alap, hogy egy entitás milyen kockázatot, milyen árért hajlandó felvállalni. A gdpr ezt a folyamatot annyiban befolyásolja, hogy a kockázat - az esetleges büntetések miatt - nagyobb.
Amúgy meg nem kell a pánik. Nem fognak május 25-étől gdpr crawlerek szaladgálni a neten, hogy a józskapistabt.hu-t majd jól megbüntessék, mert nincs kukielfogadó csekkbox a honlapján. És nem kell a 10-20 millió EUR büntetéssel sem ijesztgetni a népet. A közigazgatási bírság kiszabásának összetett feltételrendszere, az erre vonatkozó rész ráadásul tudtommal csak iránymutatás, ezt még a magyar jogszabályoknak is alkalmazni kell. De az egészen biztos, hogy nem kezdenek eurómilliós büntik röpködni a magyar kkv-nél május 25-től.
'Átnéztétek a GDPR teljes szabályozását?' - Minek? Én fejlesztő vagyok, nem jogász. Több helyen, akiknek dolgozok, komplett jogi csoport dolgozik rajta velünk és a vezetőséggel egyeztetve a gdpr megfelelőségen. Ehhez nekem nem kell értenem a egész gdpr-t, azért van a jog, hogy értelmezze, azért vagyok én, hogy kitaláljam, hogy kell megcsinálni amit a jog kér, és azért van a vezetőség, hogy eldöntse, hogy megéri-e megcsinálni, amit a jog kér.
És te hiába 'nézted át' a gdpr-t, az nem úgy megy, hogy majd jól átnézem, és mindent tudok. Ez egy olyan rendszer, hogy még a jogászoknak is komoly fejtörést okoz, mert hiába EU, attól még Mo-n a magyar jogszabályok érvényesek, a jogharmonizáció pedig a kormány feladata.
----
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.
Szerbusztok !
Véletlenül rákattintottam az RSS gombra az oldalamon. És azt láttam, amit a formázatlan CCK nodenál. Vagyis nem úgy nézett ki a tartalom, mint a .tpl-el formázott CCK, hanem kiírta a mező nevét és utána a tartalmát.
Hogy lehet rávenni az oldalt, hogy az RSS-nél is az legyen a kinézet, mint az oldalon ?
Az alábbi problémával szenvedek: Adott egy webhely. Szeretném megcsinálni 2 nyelvűre, az alapértelmezett nyelv, természetesen a magyar. Egy kattintással szeretném, hogy választani lehessen magyar, és angol között.
A node-ok már le vannak fordítva angolra, viszont valamiért a menük, és az oldal többi eleme nem változik angolra. :( Gondolok itt elsősorban az adminisztrációs menüre, az új felhasználók blokkra, és az összes többi olyan elemre, amit eredetileg po(t) fájlokból olvasna ki...
Tényleg bonyolult ....
Szia Gábor, csak véletlenül találtam meg a témádat és Drupalos kezdőként semmit nem tudok szakmailag tanácsolni.
Egy érdekes dolgot viszont cégtulajdonosként, marketingben és CRM-ben járatosként látok : meg akarják spórolni a személyes kiszolgálást, mert gyenge az ügyfélszolgálatuk. Ezt a témát kultúráltan egy wordben elkészített nyomtatvány kitöltésével el lehet intézni web nélkül egy az egyben üzleti találkozón. (a linken levő doc fájlra gondolok kinyomtatva pl.)
Mi a céges ügyviteli rendszereink fejlesztésénél fel szoktuk ilyen dolgokra hívni a figyelmet, mert szerintem nekünk, mint informatikusoknak felelősségünk is van az elkészített rendszer használhatósága szempontjából. Véleményem szerintem le kellene erről beszélni őket, mert nem vezet a megoldás hosszú távon sehova. Ezt majd 30 év tapasztalata mondatja velem. A szabály egyszerű, ha az üzletkötőt/tanácsadót mint embert és kapcsolatot kiveszed a folyamatból akkor a vevő előbb utóbb eltűnik. A dologhoz egy szakkönyvet is javaslok először talán neked, hogy felkészült lehess : dr. Erdei Magdolna : Öfelsége az Ügyfél avagy CRM a gyakorlatban - Bagolyvár kiadó. Másképp fogod látni az ilyen "fontosnak látszó" feladatokat, és még talán a tanácsaidon is el fognak gondolkodni... Először nem lesz könnyű, abban biztos vagyok, azonban az ügyfélcentrikus beállítottságod ebben hatalmas segítségedre lesz.
Remélem talán egy más nézőpont is segít valamiben neked. Ha gondolod, irj és mondok tapasztalati dolgokat ilyen témában.
És végül, azt gondolom ezt valahol te is érzed, mint ügyvezető :
" A kérdőív is elég kesze-kusza, de hát ha ezt kérik mit lehet erre mondani? "
Hááát, lehet hogy a fentieket ...
Szép estét és jó munkát kívánok neked - Németi Vilmos Budapest.
Németi Vilmos - méregzöld kezdő Drupal-os