Neked elég a PHPMyadmin exportja
Az export alapvetően jó legalábbis kis méretű és kis forgalmú oldalaknál.
Az export az a PHPMyadminban elérhető funkció. A PHPMyadminnal webes felületen keresztül tudod az adatbázisodat kezelni. Ennek aztán vannak hátulütői. Az egyik legfontosabb, hogy nagy méretű adatbázisnál elképzelhető, hogy elfogy az idő ami a PHP szkript rendelkezésére áll és nem fogod tudni exportálni/importálni a teljes adatbázist. (ez jellemzően csak nagy méretű oldalaknál probléma).
Amikor exportálsz közben is történhetnek beírások és lehet, hogy inkonzisztens állapotot archiválsz. Ez nagy forgalmú oldalaknál valószínűbb. Ezt el tudod úgy kerülni, hogy az export/dump idejére leállítod az adatbázist. Na ekkor nem fogod tudni használni a PHPMyadmint értelemszerűen de a mysqldumpot igen. Ehhez viszont megfelelő jogosultságok és minimum ssh hozzáférés kell. Ezt a legtöbb tárhely szolgáltató nem szokott adni, viszont készít rendszeres napi mentést. Nekem már többször segített a szolgáltatóm és visszaállította az előző állapotot. Javaslom kérdezz rá a szolgáltatódnál erre. (ettől függetlenül persze érdemes mentést készíteni néha)
Ahogyan Gusztáv is írta az olyan mentés amiből nem lehet visszaállítani az eredeti rendszert nem ér semmit sem. Szóval mindig próbáld ki a mentésedet egy teszt rendszeren.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Igen
Igen, a webáruház résznél nincs is gond.
A kérdésem egy megváltozott működés miatt jött elő most az áfaváltozás során, de valószínűleg nem az okozta a problémát.
Mi nettó árakat használunk és ehhez adja a Taxes és a VAT modul az áfát ezzel nincs is semmi gond:
A termékeknél is és a vásárlás folyamatánál is tökéletes a kimenet.
Az árgép felé mutató exportunk bolondult, meg az eddigi bruttó ár helyett elkezdett nettó árat exportálni.
A view-nél az eladási ár mezőnél van lehetőség nem csak az übercart által formázott árat választani kimenetnek hanem egyszerű számként is felvehető amit aztán további lehetőségként rugalmasabban formázhatok.
Eddig így használtuk a kimenetet, ebben még az is működött hogyha az admin húzta le a listát bejelentkezve akkor a nettó ment ki, de ha külsős (árgép) vagy csak egy sima regisztrált ügyfél, akkor neki a bruttó ment a jogosultság szabályainak megfelelően.
Egyébként ezt a modult használjuk exportra http://drupal.org/project/views_data_export, az már biztos hogy nem ez a hibás mert már az alap összeállításban is eltűnt ez a lehetőség ez pedig csak erre épít.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ötletelek :-)
node-ként ajánlanám megvalósítani az ajánlatkérést én is - csatlakozva Boros Ádám hozzászólásához.
Kérdésem: miért nem lehet ez egy terméket megjelenítő tartalomtípus (commerce webshopban, úgy nézem egyébként is az van már) = Termék ajánlatkérés, amit beküldhet az aki egyébként ajánlatot kérhet? ...majd miután beküldte az összes árajánlatkérő node-ját, azokat kosárba is teszi(vagy megoldani az automatikus kosárba helyezését azonnal a node létrejöttekor) és elküldi az igazi kosár tartalmat, megrendelésként kezelve :-))))
...a feladvány :-) is ezt kéri, nem?
- az ajánlatkérő node-ban termék attributomként működhetne az egyes termékre(az ajánlatkérés terméket kivéve minden termékre) az ajánlatkérés
- a tárolás megoldott a megrendeléseknél, de le is lehet őket válogatni a többi termék megrendeléstől, ha van ilyen
- a megrendelő-, azaz ajánlatkérő adatai a vevői profiljában
- ...
ui.: _csak_ ötletelek és nem látok okot rá elvetni ezt a szálat :-)
az infók alapján nem látok a megvalósításában további bonyodalmat, bár minden eshetőséget számba kell venni még a megvalósítás előtt
Geva
----- Számítások - Kalkulátorok
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Organic group
Persze pontosan kéne tudni mit akarsz, mert az, hogy társadalmi munkában készíted az senkit nem érdekel.(szekció és szakosztál az egy vagy külön-külön van mindegyikből, hány van, mindenhol van valaki aki megtanulja a használatot stb...) ;)
Évekig viszont nem fog működni csak úgy, mert folyamatos frissítésre és karbantartásra szükség van.
Tapasztalatom szerint az ilyen nagy beindulás után amikor látják az emberek, hogy ezzel munka is van, jól megbíznak egy embert aki feltölti adattal az összes aloldalt, majd a részlegesen úgy ahogy felvitt adatok látszódnak évekig. (ergo nem kellett volna neked akkora munkát belefektetned.)
Fontos az aldomén, miért nem jó a szervezet.hu/szakosztály? (ez utóbbit az og alapból tudja, azaldomainhez hegeszteni kell egy icipicit)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hu, elég autentikus megoldás
mindenesetre most megnézve az oldalad firebuggal látom ám hogy azok a css direktívák, amiket a témaindításban idézel, az image_attach.css -ben vannak definiálva. ez semmiképp nem praktikus.
az meg egyenesen őrült ötlet, hogy az 5.11 -es filebázis block modulját felülírod az 5.7 -el... tutira valami gáz lesz belőle, semmiképpen ne csináljad.
mindenképpen a sminked css -ébe írjad bele az .image-attach-teaser dolgait.
biztos vagyok benne, hogy ennek semmi köze a block modulhoz. hacsak nem annak a css -ébe is belekotortál még 5.7 -ben, amit most nanáhogy felülírtál az 5.11 -el. amikor új volt ez a téma, a hivatkozott css beállítások nem voltak benne az oldalban, most meg benne vannak..
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Sose bízz a felhasználótól jövő adatokban!
Az alap felállás az az, hogy a hidden mező az egy olyan mező, amibe a júzer a kliens oldalon nem írhat semmit, azt nem módosíthatja. Legalábbis ebből a totálisan téves kiindulási pontról szoktak az egységsugarú kezdők elindulni. Aki már látta a firebug-ot az tudja, hogy nevetségesen egyszerű ezeket módosítani. (egyébként se nehéz, de ehhez szakértelem se kell, csak fogod és átírod) Ezért van az talán, hogy a formAPI, melyet nagy tudású emberek írtak talán nem engedi, hogy módosított adatok menjenek feléd. (ha lesz időm utána túrok)
Van viszont egy szabály, a Nagy Tudás végletekig leszűrt sűrítménye, mely önmagában megmutatja az Egyetlen Egy Igaz Utat számodra és megválaszolja fenti és jövőben felteendő kérdéseidet a témában:
Sose bízz a felhasználótól jövő adatokban!
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
felesleges
Felesleges ilyen dolgokkal jönni, mert úgyis a konkrét feladat és oldat, illetve a látogatói csoportja határozza meg az egészet. Vannak olyan oldalak, amelyeket mindenképpen IE -kell látogatni (pl. ismerősöm digitális aláírás telepítésével foglalkozik speciális ügyfeleknek, és ők kénytelenek IE -t használni, mivel Firefox alatt nem megy az ActiveX -> nem működik a kártyaolvasó rendszere), mindig a konkrét igényeket kell figyelembe venni.
Az tény, hogy az IE mindig problémás, de sokszor messze nem olyan vészes a helyzet, ha az embernek van némi gyakorlata, és már kezdettől fogva úgy alakítja ki az oldalt, hogy elkerülje a böngésző-specifikus megoldásokat, illetve ismeri az IE nyűgjeit, és már időben kiküszöböli őket.
De ez az egész itt már nagyon off.
csak egyikből hivatkozz a másikra
annak, hogy 'intézmény' és 'kapcsolattartó' típusban is van node_reference és egyikből egyiket a másikból másikat lehet hivatkozni semmi értelme nincs az ég világon.
javaslom egyiket űzzed szám.
vagy a kapcsolattartóból hivatkozz az intézményre vagy fordítva, de a kettő egyszerre csak felesleges bonyolítás. így elsőre az lesz a kézenfekvő, ha a kapcsolattartóból hivatkozol az intézményre és az intézmény típusú nodeoknál megjelenítesz egy blokkot ami az ide hivatkozó kapcsolattartókat jeleníti meg.
persze maradhat így is, ebben az esetben viszont egy saját modul kell majd, ami a kapcsolattartó és az intézmény beküldésébe/frissítésébe szól bele a hook_nodeapi -val úgy, hogy a node_reference -en keresztül hivatkozott node adott mezőjét frissíti, de ennek nem igazán látom értelmét, inkább csak bonyolítja a dolgokat.
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Panels 3 upgrade megint
Bocs, hogy visszatérek a témára, de időközben kipróbáltam a Panels 3-mat frissen telepített rendszeren és ezen valóban működik gond nélkül. A probléma tehát valahol az eredeti adatbázisomban lehet, amely Drupal 5-ös és az ehhez tartozó Panels 2 volt az ugrade előtt. Az eredeti adatbázist viszont nem tudom nélkülözni, túl sok tartalom van rajta, tehát a nulláról újrakezdés nem lehetséges.
Mielőtt megkérdezitek, azt a kört már megfutottam, hogy kikapcsoltam és eltávolíottam a régi Panels modult, mielőtt az újat feltettem volna.
Van esetleg ötletetek arra, hogy mit csináljak az adatbázissal, hogy ne zavarjon be a Panels 3 telepítésébe? (Tehát megismétlem: a gond az a telepítés után, hogy valami Javascript nem fut megfelelően azon az oldalon, ahol a tartalmat lehetne a panelbe feltölteni.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A helyesírásról
Az emberek helyesírása jelentősen függ a koruktól. Egyszerűen nem várható el egy tizenévestől, hogy tökéletesen használja az írott nyelvet. Minél többet olvas, illetve minél többet ír valaki, ez a készsége annál jobban fejlődik. Legyen ez az időfaktor 1.
A téma egy másik megközelítése, hogy akár ugyanaz az ember, különböző fórumokon, különbözőképpen ír. Van, ahol odafigyel a helyesírására, és van, ahol ez nem fontos. Sőt, evvel akár jelentősen ki is lógna a sorból. Valljuk meg, az internetes fórumok elég nagy hányadán az átlag helyesírás csapnivaló. Tehát, egy adott illetőnek ahhoz is időre van szüksége, hogy felmérje, hogy az általa látogatott új fórumon mi a trend. Ez az időfaktor 2.
Evvel azt szeretném elmondani, hogy egy ember hozzászólásának nyelvtani helyessége első körben nem feltétlenül minősíti magát az embert. Abban viszont igazad van, ha senki nem szól rá, akkor az tudatosulhat benne, hogy ez itt, így, elmegy.
Valami olyasmi lehetne a megoldás, hogy miképpen az „új kérdésnek légy szíves nyiss új témát” című mondatot mindenki szépen le tudja írni, úgy a nagyon csapnivaló helyesíráshoz is lehetne egy hasonlót odabiggyeszteni.