dj képe

Ez egy olyan költség ami az ÁSZF-ben le van írva. Ha utánvétet választ ki a vevő akkor az áttekintő oldalon megjelenik egy utánvét sor a megadott összeggel. Ha nem utánvétet választ ki fizetési módnak akkor pedig nem jelenik meg az áttekintő oldalon ez az összeg.

0
0

Üdv!
Dudás József

Illyés Edit képe

A kérdés azza kezdődött, hogy mi van akkor, ha nem akarja az API-t használni. Hogy miért nem, az az ő dolga (lentebb meg is indokolja).

Pont azért nem másoltam be teljes működő kódot, hogy ne lehessen ész/gondolkodás nélkül ráereszteni az adatbázisra.

0
0
aries képe

Szerintem mindannyian ebben a szellemben fordítunk.

A problémát az okozza, hogy tömören: a hash egy jórészt nem bijektív függvény, melynek kimenete (feltehetően) egyértelműen jellemzi a bemenetet.

Leggyakoribb alkalmazása az ún. ellenőrzőösszeg, ami azt jelenti, hogy a hash érték ismeretében, az inputra ráengedve a függvényt ellenőrizhető, hogy a végeredmény megegyezik-e a hash értékével. Ha nem, akkor valószínű nem megfelelő a bemeneti érték (pl. sérült a fájl).

Ettől függetlenül nem csak erre szokták használni, sőt, eredetileg arra, hogy asszociatív tömbök kulcsait átalakítsák valami használhatóbbra. Ennek az átalakításnak az egyik lépése az volt, hogy további részekre tördelték-hasították a kulcsokat, a hatékonyabb indexelés miatt. Innen a név is, a „hash” ebben az értelemben darabolást, hasítást jelent. (Az érdeklődőknek ajánlom Knuth: A számítógép-programozás művészete c. könyvet, ahol különböző megközelítések egy matematikus alaposságával vannak kifejtve.)

Innen a neve is, hasítófüggvény. Ezt számos könyv így használja, pl. a korábban már említett Tanenbaum-féle Operációs rendszerek, az Ullmann-féle Adatbázisrendszerek és számos egyéb könyv is. Lehet arról vitatkozni, hogy ez jó név-e a hasítófüggvény vagy sem, de ha rákerestek, akkor használatban van.

Korábban ellenőrzőösszegekre polinomokat használtak (lásd CRC), amelyekkel könnyű számolni, de megbízhatóságuk a mai adatkupacokra korlátozott. Ezeket küszöböli ki az MD5, SHA1 és társaik.

A lényeg a lényeg, hogy manapság az MD5 vagy SHA1 hash értékei felhasználásuk alapján legtöbbször ellenőrzőösszegek.

Arra is van lehetőség, hogy egy idegen szót átvegyünk. Ennek legegyszerűbb módja, ha kiejtés szerint tesszük, így mindenki számára egyértelmű, hogy hogyan kell kiejteni, könnyebb a ragozás is. (Tegye fel a kezét az, akinek teljesen világos, mikor kell egy idegen szó, név után kötőjelet tenni.)

Nem, az nem érv, hogy az eredetire rá lehet keresni keresőkben, azért vegyük át 1:1-ben. Aki ezt mondja, az felteszi, hogy az angol az egyetlen, ahonnan szót lehet átültetni egy nyelvbe. Az ilyenek írják le szépen a miszó levest kandzsivel. Esetleg írhatnánk így a csákót, kalpagot, hogy ﻗﺎﭘﺎﻕ…

Számos egyéb problémát felvet még az eredeti átvétele. Mi van akkor, ha egy nyelvet nem beszélőnek kell felolvasnia egy ilyen szöveget? Tudjuk-e milyen nyelvből szó. Ha azt mondom, „marine” egy magyar mondatba ágyazva, tudható-e, hogy francia vagy angol (esetleg más) kiejtést kell alkalmazni? (Azon belül nyelvjárás, hangsúlyozás stb.) Csak én érzem magam feszélyezve, ha egy elegáns étteremben, a francia nyelvű étlapot nemhogy nem értem, de provanszi kiejtés híján megkérdezni sem tudom pincért, az szépen kinéző izé micsoda?

Én azt mondom, ha van valamire már meghonosodott, ráadásul magyar szavakból álló szakkifejezés, akkor használjuk azt, amíg szebb, pontosabb (kiejtés szerint írt vagy más magyar szó) nincs.

4
0
vajdasági képe

Most amit leirtal abba osze lett sokminden omlesztve egy kupacba :) Ha jol ertelek most ket kulon nezetet emlegetsz....

Boncsuk szet 3 dologra az egeszet.

1. Van a (legyen itt "hotelek") tartalomtipus
2. Van egy oszefoglalo nezeted abban van a kep meg jobbrol az ar meg a szolgaltatasok amiket nyujtanak, meg az az "összefogalaló elváalsztása" amit nem tudok mi lehet, meg a link a telejes nezetre vagyis a 3. esetre.
3. Itt megjelenik minden a 2. esetbol kiveve a link mert mar azt nezzuk ugyebar plussz a reszletes szoveg a holtelrol es alatta a sok kis kep.

Jol ertelek?

1. eset: A tartalomtipust ugy hozod letre hogy bennelegyen az osszes mezo es mivel sok hoteled lessz meg gondolom ok fogjak majd az adatokat bevinni ezert minden kulon mezibe kell hogy legyen vagyis az FCK editor csak a szoveg kinezetenek diszitesere kel majd az ar meg a kepek meg a szolgaltatasok amiket nyujtanak az mind kulon mezo. GOndolom leszz meg cim, telefonszam, stb. mezok is ....
2. amikor mar kesz a tartalomtipus akor a tartalom nezetenel be birod allitani hogy mit latsz a roviditett vagy osszefoglalalo nezetben (ez az amikor pl kilistazod az osszes szegedi hotelt) es ott beallitod hogy a reszletes bemuti szoveg nem kell oda meg a sok kis kep ...
3. itt minden mezo kell. meg ala teszed azt az ajanlatkeres urlapot ami mar kesz, ha jol ertettem az elkepzelesed.

Ha igy hozol letre mindent akkor a mezoket a sminkben konnyen tudod jobbra balra stb. igazitgatni meg a kinezetuket modositgatni.

0
0
Geva képe

Ha jól értem, akkor az importálás miatt vetetted el ezt a remek lehetőséget, ám nem írtad miért ne működne az import ebben az esetben.
(szvsz lényegtelen hogy hány és milyen helyről jön az import, a formátumban kell stimmelniük)

Nálam a termékek több szótár szerint vannak kategorizálva: annyi szótárba vannak besorolva, ahány szerint feltétlenül be szeretném soroltatni őket - vagyis amely kategóriák szerint szűrni, listázni, rendezni szeretném őket, keresni is szeretnék rájuk majd a honlapon. Ebben az esetben minden egyes szótár egy-egy kifejezés hivatkozás mező a termék szerkezetében,
Én erre az importálást is összeállítottam és nem tapasztaltam semmi gondot, hibát, problémát, helyesen működött :-O (az importálás csv fájlból, teszt jelleggel, még nem az élesből jött, de ez mind1 éles-neméles)

Mire gondoltál? Mi bajt okozhat az importálásnál a több szótár befűzése a termékbe?

...a megjelenítendő katalógust persze ebben az esetben már nem olyan egyszerű megoldani, mintha egyetlen katalógusba lennének a termékek befűzve(pl taxonomy menu), de vidáman megoldható akár views-zal vagy egy menü kézi felépítésével és így olyan szerkezetű kategória menüd lesz, amilyet csak kíván a tisztelt megrendelő :-), ebbe behozhatod akár az összes kategorizálás szerinti termék csoportokat is.
...így a termékek több irányból - azaz szótár szerint - kereshetők lesznek, könnyebben megtalálja a vásárló amit keres. Eezzel szemben az egyetlen-, esetleg többszintű katalógus kategória meglehetősen lazán kezeli a besorolásokat, ezt nem ajánlom

tehát mi a gond az importálásnál, ha több szótárba is besoroltad a termékeket?

0
0
HF leon képe

A GDPR kockázatai alól jó kibúvó, ha az érzékeny adatok titkosítva vannak tárolva az adatbázisban. A korábbi e-mail titkosító, már nem jó a 8-on. Az újhoz, aminek függőségi moduljai, amit ajánlottál szükség van olyan külső könyvtárra, amihez shell is kell.

Nagy könnyebbség, ha bármilyen hiba folytán egy támadó adatokhoz jutna az adatbázisból, akkor azok olvashatatlanok lennének. Ekkor ugyanis nem kell jelenteni az esetet a naih felé. Sajnos volt, már olyan eset egyes szolgáltatóknál, ahol mások hibája folytán történtek incidensek.

Mivel az e-mail cím egy fórum és egy blog esetén is szükséges a regisztrációhoz ez alap. Egy áruháznál a megrendelő adataiban név és cím, stb is lehet. A legjobb megoldás, ha ezek titkosítva tárolódnak, mert ekkor az adatbázis szivárgás kivédhető. A rendszerben pedig erősen korlátozható az adatokhoz való hozzáférés. Így minimalizálva annak az esélyét, hogy bárki hozzáférhessen személyes adatokhoz.

Mivel Amerikában is terveznek a GDPR-hez hasonló szabályozást, talán nem lenne rossz, ha mondjuk egyes mezőket ki lehetne választani a drupal-ban és azokat a rendszer alapból titkosítva tárolná. Szerintem ezt a funkciót érdemes lenne a maghoz adni, mert erősen az adatvédelem irányába halad a világ.

Szerintem nem lenne rossz, ha egy mező létrehozásakor ki lehetne választani, hogy az abba kerülő adat titkosítva tárolódjon. Illetve mondjuk a settings.php már alapból lehetőséget adna, hogy az alap titkosítás bekapcsolására, amikor mondjuk az e-mail címek titkosítva tárolódnának.

Úgy gondolom nem lenne haszontalan a drupal mag és a mező rendszer ilyen irányú bővítése.

0
0
Anonymous képe

Azt hiszem, hogy többen vagyunk, akik "vajúdunk" ;-) ... s mind névtelenül (persze ha bejeletkeztem volna, akkor egyszerűbb lett volna a helyzet).

Az én bajom, hogy:
- a tárhelyet csak ftp-vel érhetem el (habár az adatbázist a rendszergazdi létrehozta nekem)
- a tárhelyen nincs phpMyAdmin (annak segítségével - természetesen a kézikönyv leírását követve - az uw-re simán "felgyakoroltam" a Drupalt)
- programozói tudásom gyakorlatilag 0 a köbön

- s ezek eredményeképpen nem igazán tudom, hogy mit is kezdjek a kézikönyv köv. soraival: "Amennyiben parancssorból kívánjuk betölteni az adatbázis sémát, a következő parancsot használhatjuk: $ mysql -udrupal -pdrupal drupal < database.4.x.mysql ahol az első három adat a fent létrehozott felhasználó neve, jelszava, és az adatbázis neve, az x pedig értelemszerűen a használt verziónak megfelelő."

Ugyanis nem tudom, hogy hol kellene használjam a fenti parancsot (az adatokat talán még ki tudnám tölteni ;-))

aries képe

Én is arra fordítanám, ha nem pénzért adnák a kenyeret. Az 1 Bekezdés (váltópénz az 1 Mondat) nem konvertibilis valuta. :) Lefordítani az összes modul összes stringjét meg az összes kézikönyvet hatalmas munka. Abból, hogy eddig mennyi fordítás keletkezett úgy, hogy csak egy töredéke, kb. 5-6%-a van meg az összes modulnak, én egy Révai lexikon mennyiségű szövegre saccolok, AMI FOLYAMATOSAN VÁLTOZIK. Nem értékálló, ahhoz képest, hogy mekkora nagy munka, ingyen, úgy, hogy önző módon gondolkodva csak konkurenciát teremtünk vele magunknak, mert az, aki azt a 100 angol szót nem akarja megtanulni, az később sem fog nagyon tenni semmit a lecsóba. Aki fejleszteni akar, az áldozzon egy hetet arra, hogy megtanul egy kicsit angolul, ez a kommunikáció nyelve.

Aries
http://aries.mindworks.hu

0
0
ady képe

Az "installáláskor" sajnos nem történt installálás. Az új helyen megpróbáltam beállíttatni a szükséges környezetet, aztán átmásoltam a Drupal fájljait, és végül az adatbázist is átmentettem. Ez így kivitelezhetőnek tűnt, egy jó darabig párhuzamosan futott a két helyen a két rendszer, amíg az új elérte a stabil(nak látszó) állapotot, ekkor átálltak a domain-ek, és azóta élesben fut. Ha a PHP csak egyszer is hibaüzenetet dob a mail() miatt, észrevettem volna, de épp ez az, hogy nem sikítozott.
A rendszergazda egy chroot jail-en keresztül enged hozzáférést, így a PHP el sem érte a sendmail parancsot, pedig az ott van a gépen.

A Drupal admin naplója alapbeállítás szerint fut, abból semmi használhatót nem tudtam kiszedni. Az Apache2 logjai között megtaláltam a POST kérések fejlécét (access-log) és egy másikban (error.log) a hibás sendmail parancs hívásokat, de semmi mást. Így megvannak az időpontok, de csak annyi.

0
0
feherbt képe

Az adatbázisban csak az első pár karakter van meg, még az eredeti exportban ott van a teljes megnevezés.
Egyébként Drupal 5.7, de ezek szerint nem itt van a gond.
Az exportot a cwi-s php-myadmin adminnal csináltam, nem módosítottam semmit abban amit felajánlott, és a kozos.info-n sem módosítottam semmit az importkor.

Sem az export, sem az import nem adott hibát.

A mysql verziókat nem tudom sajnos.
Az export így kezdődik:

-- phpMyAdmin SQL Dump
-- version 2.6.4-pl4
-- http://www.phpmyadmin.net
--
-- Hoszt: mysql
-- Létrehozás ideje: 2008. Okt 09. 16:17
-- Szerver verzió: 5.0.51
-- PHP Verzió: 5.2.5

0
0