ügyiteli integráció
Hello,
Nekem több kérdés is felmerül, mivel csináltam már ilyet más rendszerhez.
Egyrészt ez a csv-s kommunikáció napi szinten kell, mivel a termékek raktárkészlete, ára folyamatosan változik, és egy nem 30, csak 10.000 termékszámnál ez a művelet elég sokáig szokott tartani, mivel a szövegfilet fel kell olvasni, esetleg átmeneti táblába berakni, és utána sql updatek ezrei futnak le.
Másik alapkérdés, hogy és mi az az ügyviteli program mely támogatja az exportot automatizáltan?
Mert amikkel eddig dolgom volt, szinte mind vmi dbase alapú szutyok volt, de akadt foxpro-s is.. de legkevésbé sem volr sql alapú, és igen nehéz belőle adatokat kinyerni naponta akár több alkalommal is, teljesen automatikusan.
És akkor ez egy irány, hogy a bolti rendszer megfrissíti az áruházat, ami adatok alatt ugye, csak cikkszám, db, ár, megnevezés értendő, mivel a termékleírás, fénykép(ek)-et nem támogatják ezek a raktári/számlázó rendszerek, így ezt kézzel kell egyenként megtenni, és szükséges egy vissza-irány, lehetőség szerint szinte realtime, ha megrendelés történik a shop-ban akkor az a termék az ügyviteli rendszerbe megjelenjen foglalásba, vagy netán, már számla előkészítés, vagy rendelés formájában.
Nagyon sok baj van ezen a téren, mivel ha van olyan termék, amiből 1db van, akkor azt rendszerint eladják a boltban, és közben a shop-on keresztül is, majd jön a telefonálgatás, mérgelődés.
Én most vettem fel a kapcsolatot egy számlázó/raktár rendszer fejlesztő céggel emiatt, hogy dolgozzunk össze, mivel a legtöbb gond ott van, hogy ezek a cégek elzárkóznak a webshop-ok felé történő kommunikációtól. Ez a cég végre vette a lapot és jó irányba fejlesztenek, sima http get-en keresztül jönnek mennek az adatok, így ha pl. eladnak vmit a boltban, meghívják az áruházat megadott url-en és átadják neki ezt, így már nem tudják eladni 2x a terméket és a, rendelés feldolgozás is kezd kialakulni.
Tehát érdemes ezt jól körüljárni, mert csv-kkel ez a kérdés nehezen kezelhető le, inkább a SOAP, vagy ha az túl bonyolultnak tűnik, sima http get-ekkel megoldani, mert az azonnal meg tud történni, nincs késleltetés.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm
mindenkinek az értékes hozzászólását.
Igazából az eredeti kérdésem arról szólt, hogy alkalmas-e a Drupal erre a feladatra. Persze tudom, hogy vannak nagy forgalmú Drupal alapú oldalak a világban, de arról nem volt infom, hogy azok vmi speciális rendszert és beállításokat használnak-e.
Hasonlóan a rallyhoz, ahol mondhatjuk, hogy egy rally autó pl. Skoda Fabia, de annak a nevén kívül elég kevés köze van az autószalonban kapható kocsikhoz. :-)
Nagyon fontos kérdés az, hogy milyen modulokat szabad használni és mi az, ami helyett saját fejlesztés kell. Mondjuk a CCK, Taxanomy, Rules, Views és vmi user profile nélkül nehéz elképzelni ezt a funkcionalitást, de azért kíváncsi vagyok, hogy mit szabad és mit nem (jó, a Panels "vszínűleg" nem lesz telepítve :-) ).
Ja és persze kellenek a jól beállított, "cachelést" végző megoldások is.
A szerver témájáról annyit, hogy sokáig egy multicég IT vezetője voltam és 20+ ország infrastruktúrája tartozott hozzám, ami most csak azért érdekes, mert emiatt van némi "sejtésem" a szerverekről, a megbízható üzemeltetésről, még ha nem is én fagyoskodtam a szerverszobákban. :-)
Ettől függetlenül a mi szakmánkban nagyon gyorsan változnak és avulnak el az ismeretek, így az ember itt 1/2 évente lehet pályakezdő. :-)
Azért kérdeztem a szerver oldalát a témának, mert a Drupal "viselkedését" és erőforrás igényét nem ismerem ennyi regisztrált + sokkal több anonymus user napi ügyködése mellett. Persze a hw igény nagyban függ a feladattól és annak okos megvalósításától, de szerencsére vannak itt többen, akiknek gyakorlati tapasztalata van erről.
Tudom, hogy ez nem az a hobbi projekt, amikor kipróbálunk néhány új modult, összekattintgatjuk vele az oldalt, majd felrakjuk a Boost modult és azután megnézzük, hogy működik-e. :-))
Ez nem a kísérletezgetés helye, ezért eredetileg is úgy gondoltam, hogy a témában jártas kollégával szeretnék együtt dolgozni, ezért is adtam fel az ajánlatot a Munkaközvetítőre: http://drupal.hu/node/14902
Ha "kivitelezőként" vagy csak tanácsadóként érdekel ez a lehetőség, akkor keress meg nyugodtan.
Köszönöm.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Kép nem jelenik meg a Cikk tartalom hozzáadásakor.
Üdvözletem Mindenkinek!
- A clean-urls engedélyezve lett már telepítéskor. Írtam egy álnevet is, és valóban a node/4 helyett, 2011 álnévvel beírva a honlapunk - volt technikumi osztálytársaimé, akikkel 2 hét múlva lesz az 50. éves osztálytalálkozónk, és megígérteem, hogy meújul a honlapunk - címét, azonnal a megfelelő oldal töltődik le. Ez jópofa dolog, de nem látom, hogy köze lenne a "Cikk" tartalom keretében feltöltött képek megjelenítéséhez.
- E-mailben megkérdeztem Nagy Gusztávot, aki javasolta hogy a drupal.hu-n tegyem fel a témát - ez már előbb megtörtént, és mondta, hogy nézzek meg egy útvonalat, a következőt:
- Nagy Gusztáv tanácsára megnéztem az admin/config/media/file-system
útvonalat. Ezt az "Implement hook_watchdog()" őrzőprogram megakadályozza, kikommenteltem az utasításokat. Itt azt látni, hogy a "Nyilt" fájlok a sites/default/files mappába fognak kerülni. Ezt a kézikönyvben is olvastam, és már erről meggyőződtem, azzal a kiegészítéssel, hogy a files mappának még kellett csinálni almappákat - field/image - mert a képfájlokat ide tölti be. Ide lehet más útvonalat írni, de minek? Egyebet meg itt sem lehet tenni.
- A feltöltött képfájl tehát kerül EGY helyre, megjelenítéskor átalakítva a megfelelő méretre egy MÁSIK helyről akarja a program elővenni, de nincs ott a fájl.
Amikor a "Cikk" tartalom hozzáadását végzem, és be kell jelölnöm, hogy milyen legyen a kép stílusa, pl. thumbnail, azt gondolom, hogy ez lenne az az utasítás, ami elindítja a kép átméretezés és az új helyre töltés végrehajtását. De mint mondtam ez nem történik meg.
- Megnéztem a www.rakosmentetv.hu honlapot, amit Nagy Gusztáv csinált. Megnéztem hogy pl, az első képet honnan veszi elő a program:
http://www.rakosmentetv.hu/sites/default/files/szepesi_nikoletta/image00.... Mint látható ebben nem szerepelnek azok a mappák, ahonnan az én programom elő akarja venni: /sites/default/files/styles/thumbnail/public/field/image/erd1cs.jpg
- Gusztáv könyvében nem is tesz említést erről az útvonalról.
Itt tartok. :(
gyuszi
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Tök jól haladsz, így tovább!
Az a helyzet, hogy a Drupal előtt Wordpress oldalam volt, azon valahogy sokkal egyszerűbb volt minden
Már sokszor volt erről szó itt drupal.hu-n is, de általában az ilyen összehasonlítások értelmetlenek és a legtöbbször tévesek is. Ha lenne hosszú távú tapasztalatod Drupallal, akkor meg valószínűleg a Drupalról Wordpressre áttérésnél mondanád azt, hogy "pedig ez Drupalban sokkal egyszerűbb volt". :) Azért egyszerűbb, mert volt vele tapasztalatod, jobban kiismerted azt az adott felületet.
A többnyelvűség eleve egy nagyon összetett probléma. Ha esetleg egy smink nem úgy lett megírva, hogy az a többnyelvűséget helyesen kezelje, az nem a Drupal fejlesztőinek hibája! :)
Hogy miért én vállakoztam a weblap megszerkesztésére és miért nem bíztam meg egy hozzáértőt?
Ezt szerintem nem kell megmagyaráznod, nincs azzal semmi probléma, hogy Te szeretnéd megoldani a saját oldaladat, és bevállaltad, hogy kiismerj egy komplex rendszert. Ezzel jelentős költségek is megspórolhatóak, plusz az ember kiélheti a kreativitását, ezenkívül nem mellékes, hogy esetleg még valami hasznosat is tesz le az asztalra.
A kétnyelvűsítés már egészen jól működik, minden részt sikerült fordíthatóvá tennem és lefordítanom.
Ez nagyon jó hír!
Annyi van, hogy a .hu domainről még mindig angolul jön be az oldal.
Ezt itt tudod átállítani:
admin/config/regional/language
Konkrétan így:
Egyébként jól haladsz, jó látni, hogy a nehézségeknél nem rúgtál bele az egészbe, és adtad fel, hanem tovább próbálkoztál, utánaolvastál, videókat néztél, gratula!
A Drupal logikájának megértése szerintem nagyon nehéz, nekem is nagyon sokáig tartott, míg valamennyire ráálltam, és még elképesztő sokat kellene tanulnom hozzá, de összességében szerintem nagyon megéri.
(Az lesz még nagy kihívás számomra, hogy a 8-as megjelenésével a Symfony működését is megismerjem valamilyen szinten: http://symfony.com/blog/symfony2-meets-drupal-8.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
calendar_multiday.css, Views
sites/all/modules/calendar/css/calendar_multiday.css
http://drupalcode.org/project/calendar.git/blob/17fceb75ad1d0e9ae6d4ec00...
ez az, amiben meg vannak határozva a stílusok. Ne ezt szabd át, hanem az aktív sminkedbe rakd bele a saját módosításaidat, az a betöltési sorrendben úgyis később lesz, tehát az fog érvényre jutni.
Az aktuális nap a miniblokkban "today" és "mini" osztályokkal van ellátva, meg a nap nevének rövidítését tartalmazó osztálynévvel, ezenkívül "has-no-events" vagy "has-events" osztállyal, attól függően, hogy van-e esemény aznap, vagy nincs.
A böngésződ fejlesztőeszközével könnyen meg tudod vizsgálgatni a továbbiakat is (Ctrl+Shift+I vagy F12), Chrome-ban például ha rákattintasz az elemre jobb gombbal, majd az "Elem megtekintése" menüpontra, akkor megnyílik a megfelelő rész:
gondoltam nem adok halat, hanem inkább megtanítalak halászni :)
Konkrétabbat pedig akkor tudnánk mondani, ha látnánk az oldaladat élesben.
Végül hol tudom beállítani, hogy amikor a hónap nevére kattintok, csak a hónap naptár jelenjen meg és ne jelenjen meg a többi (éves, heti, napi) fül bontásban?
Views-nál le tudod tiltani, vagy feltételektől függővé tenni, esetleg átszabni az egyes fülek megjelenését.
Nálad konkrétan ez lesz a korábbi exportod alapján az elérési útja:
admin/structure/views/view/napt_r/edit
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
"A sorok súlyának mutatása" / "A sorok súlyának elrejtése"
Ahol átrendezős táblázat van, ott jó működés esetén mindig van egy "A sorok súlyának mutatása"/"A sorok súlyának elrejtése" (Show row weights/Hide row weights) link, ahogy nálad például a harmadik képen látszik:
A misc/tabledrag.js core-fájlban van ennek a működése meghatározva: amennyiben a JavaScript be van kapcsolva (nyilván ez az elvárt), akkor a klikkelés utáni állapotot egy cookie-ban tárolja, a felhasználó böngészőjében. Ennek a cookie-nak a lejárati ideje egy év, úgyhogy ez elég hosszan tárolódik, amennyiben nem kerül törlésre. Ez a beállítás tehát állandónak tekinthető: ha egy helyen "A sorok súlyának mutatása" linkre kattintottál, akkor elvileg az kerül megjegyzésre.
Amennyiben beszúrod a tartalmat, és nálad mégis úgy kerül megjelenítésre, hogy a súly el van rejtve, és az áthúzó célkereszt jelenik meg, az következhet hibából is.
Próbáld meg azt, hogy először is az összes sütit törlöd a böngésződből (legalábbis az adott domainre vonatkozót, hogy a teszt eredményét legalább ez ne befolyásolja), majd bejelentkezel, és itt még a beszúrás előtt rákattintasz arra a linkre a táblázat fölött, hogy "A sorok súlyának elrejtése", amennyiben ez elérhető. Ha nem, akkor kattintsd be, hogy jelenjenek meg a súlyok, majd vissza. Lényeg, hogy az alapbeállítás az legyen, hogy legyenek elrejtve a súlyok.
Mivel ez cookie-ban tárolódik, ez nyilván felhasználófüggő beállítás is. Tehát az, hogy nálad el van rejtve a súly, nem jelenti azt, hogy a többi felhasználónál is; de legalább így tesztelheted, megoldódik-e a probléma, így tudsz segítséget adni gond esetén a felhasználóknak.
Ha ez nem oldja meg, akkor esélyes, hogy az aktív sminkkel kapcsolatos a probléma (esetleg modullal, amely hatással van erre). Azt is ellenőrizhetnéd (amennyiben a fentiek nem jöttek be), hogy nincs-e hibaüzenet kiírva a böngésződ fejlesztői paneljének (pl. Chrome DevTools, Firebug, Dragonfly, stb.) konzol fülére (Ctrl+Shift+I vagy F12).
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nyiss új topicot!
Jó lenne ezeket már új témában megbeszélni, mert nem kapcsolódik az eredeti kérdéshez (az 6-os, és más modulokról van benne szó, mint amiről itt beszélgetünk).
1035-ös irányítószámnál Hollandia egy része jön be, 1038-nál Budapest, a több pár vidéki irányítószám, amivel próbálkoztam azok is helyesen jelennek meg.
Feltételezem, ennél a címnél nincs eltárolva, hogy Magyarországon kellene kotorásznia az adat után, tehát nincs fixálva az ország.
ha túllépi valaki, akkor máris számláz, vagy csak leáll a működés?
Nyilván nem számláz, ha még nincs hova/kinek. :) Szóval előbb azt be kell állítani. :) Aztán gondolom ha nem fizetsz, akkor marad az ingyenesen elérhető korlát.
Amúgy az 1-2 ezer kattintást nem tudom, hol olvastad, mert most nézem a Console-on belül az "All services"-nél:
Google Maps API v3
Courtesy limit: 25,000 requests/day • Pricing
Google Maps Coordinate API
Courtesy limit: 1,000 requests/day
Google Maps Engine API
Courtesy limit: 10,000 requests/day
Google Maps Geolocation API
Courtesy limit: 0 requests/day • Pricing
Azért azt megnézem, hogyan léped túl ezeket a korlátokat NAPONTA. :))
nem tudok képet csatolni, mert itt sajnos nincs lehetőség, csak url-ből, ahhoz fel kéne töltenem valahová
http://imgur.com
http://snag.gy
Amelyik modulpárost ajánlod, azt a gmap és location helyett ajánlod
Nem modulpárost ajánlottam, hanem vagy-vagy lehetőséget. Vagy Get Locations VAGY OpenLayers modul. Válassz, melyik a jobb neked. Utóbbi nem csak Google Maps-es.
Az jó lenne, mert nem jó, ha minden lehetőség a google-nál van.
Most ez szokásos Nagy Testvér-paranoia, vagy milyen "lehetőségekre" gondolsz? :)
most a google modulba írtam az irányítószámot
Mi az a Google modul? :) Sztem olyanról még eddig nem volt szó. :)
Tényleg beszéljük meg ezt inkább egy új topicban. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Van nekem egy hobbi oldalam.
Van nekem egy hobbi oldalam. dyra.eu Mostanság nem nagyon foglalkozom vele kevés az időm. De mikor heti szinten kitoltam egy nagyobb lélegzetvételű írást akkor azért szépen ment (napi 1000 - 2000 látogató).
Valahol találkozni kell az emberek vágyainak és a te tartalmadnak. PL a Linuxos tartalmak alig hoznak látogatót, ellenben mikor berobbant az Android a legegyszerűbb blogbejegyzésre is kismillióan kattintottak.
De pl amin meglepődtem, hogy a szájbarágós bootos USB írásomra is a mai napig elképesztően sok látogató érkezik.
Ami egyértelműen működött nálam és érezhető látogatónövekedést tapasztaltam az bizony az igényesen megírt, szépen formázott, leírások voltak. Persze a napiszar szintű oldalak nem éppen így csinálnak naponta hatalmas forgalmat, ott fognak egy képet, adnak neki egy hangzatos nevet kiposztolják Facebookra meg még pár helyre és láss csodát özönlenek a látogatók.
Nincs erre szerintem tuti recept, próbálkoztam annak idején link építéssel. Eleinte talán volt értelme, de aztán a Google fejlesztett és teljesen értelmét vesztette. Azért a jó linkek még most is számítanak. Pl régen itt a drupal.hu be lehetett mutatni az elkészült oldaladat pár sorban. Többet ért mint 100 kispista féle katalógus. Szóval vannak oldalak továbbra is amik erős linket adnak. Csak oda nehéz bekerülni.
Vagy pl a szállásoldalak. Ott van kb 5 - 6 katalógus - foglaló pl booking.com , a SEO-val annyiban kell foglalkozni, hogy legyen egy igényes weblap ami igazodik a szállás hangulatához, aztán beregelsz ezen katalogusokban jól végzed a dolgod (ekkor ugyanis nem kapsz negatív visszajelzést) és ezek az oldalakon keresztül özönleni fognak a megrendelések. Igaz a jutalékot szépen leszedik de hát valami valamiért. Egy szálláshelyet szerintem teljesen felesleges SEO-ni. Fel ezekre a katalógusokra tényleg csak pár van ami szóba jöhet.
Összességében, azt tudom mondani mint az előttem szólok. Az igényesen megcsinált nem lopott tartalommal operáló weblap előbb - utóbb előre kerül a keresőkben, de általános leírást képtelenség adni, mert ugye más napiszar szintű oldalaknál a SEO és más pl egy komoly tartalommal bíró oldalnál amit nagyságrendileg kevesebben fognak olvasni akármit is csinál az ember. A tömegek egyszerűen nem keresik. Szóval nem akarok itt okoskodni. Lehet azért kell SEO-s szakihoz menned, hogy ő megmondja neked tulajdonképpen nincs is szükséged SEO-ra :)
honlapom http://dyra.eu/
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm a választ. Kezdem
Köszönöm a választ. Kezdem érteni. Elméletben. :)
Most jön a gyakorlat.
Rövid távú célom: itt az asztali gépen módosítok egy css fájlt, majd ezt a változást kiteszem a github-ra, majd onnan az éles gépre.
Az éles gépről lemásoltam a helyi localhostra egy oldalt. Működik is.
De már itt elakadtam. Hogy hogyan lehet egy már meglevő drupal projektet verziókezelő alá vinni?
lemásolom - git init - git add . - git checkout -b projektnév a jó sorrend?
Illetve lehet, hogy fogalmi zavaraim is vannak.
A 'dev' alatt az asztali gépen levő (localhostos) mappát értjük vagy inkább a neten kinn levő webszerveren egy almappát, amire egy dev.domainnév.hu mutat?
------
Update:
Én így vontam már neten kinn levő éles oldalaimat veziókezelés alá:
1. localhoston üres projektmappába:
- git init
- az összes weboldalfájl bemásolása ebbe a mappába
- adatbázis export - import localhostra
- weboldal beélesítése
- git add .
- git commit -a -m "Alaphelyzet"
- módosítottam egy css fájlt
- git commit -a -m "css fájl változtatva"
2. github-on
- új repositoryt készítettem neki
- az url jét kimásoltam a vágólapra
3. localhoston
- csináltam egy összerendelést: git remote add origin + vágólap url
- git origin mester
- név jelsz megadása után már kinn is van a kód, amit a weben le lehet ellenőrizni.
4. éles szerveren:
- kiüríteni az üres mappát, a . gitignore, settings.php és a sites/default/files/ mappa kivételével
- git init
- távoli elérés összerendelése: git remote add origin + vágólap url
- git pull origin master
S tadamm! Már a webszerveren is változáskezelés alatt áll az oldal az új css-el.
------
Most jön az, hogy
- mit is lehet szinkronizálni / változást kezelni
- azokat hogyan is kell megcsinálni
- ha valamit elrontottunk hogyan lehet mondjuk visszalépni 2 - 3 committel
Péter
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Egyszerűen nem is értem
Egyszerűen nem is értem a kérdést, ha ez benned felmerül, akkor Neked tényleg nem való semmilyen CMS. Miért akarsz megírni Te egyedül mindent, amikor a fél világ az évek során már megírta mindezt helyetted, rááadásul biztonságosan.
Mondok Neked egy konkrét példát, bár lehetne ezret: Az a feladatod, hogy a fehasználók minden tartalomhoz küldhetnek be képeket, Neked pedig meg kell jelenítened a címlapon a tartalmaktól függetlenül az utolsó 30 beküldött képet szépen csinosan úgy, hogy valamilyen módon el is lehessen ugrani ahhoz a tartalomhoz, amiben a kép van. Ezt barátom 2-3 hétig is kódolhatod, akkor is bugos lesz, sebezhető és lassú mint állat. Ha kihasználod, hogy megírták helyetted a Drupalt, a CCK-t, az ImageCache-t, a LightBox-ot, akkor Te írsz hozzá egy saját modulban 30 sort és készen is vagy. Gyorstárazással, megjelenítéssel cakk-pakk.
Az a mondatod, hogy a modulprogramozás hihetetlenül bonyolult, egyszerűen nem igaz. Ezt tudod mi mondatja Veled? A lustaság. Nem jársz utána, nem olvasol, nem keresel, hanem ránézel egy modulra, húúú ez bonyolult, nem akarom megtanulni. Senki nem mondta, hogy ha életedben először feltettél egy Drupalt, akkor 1 hét múlva már kened-vágod az egészet. Sokan vagyunk itt főállású programozók, mégsem magunk kódoljuk a webhelyeink nagy részét, hanem Drupalt használunk, evvel a kódolásunk 98-99%-a készen is van. Csak azt az 1-2%-ot tesszük hozzá, amit az adott webhely megkíván.
Szóval, mint mindent, a Drupalt is meg kell tanulni, ami persze leginkább években mérhető. Viszont abban a szerencsés helyzetben vagy, hogy a Drupal irdatlanul jól van dokumentálva, és a közösséghez is fordulhatsz segítségért. Először meg kell érteni, hogy miként épül fel a rendszer, hogyan jönnek létre az oldalak, stb. Amíg evvel nem vagy tisztában, és fogalmad sincs, hogy hová nyúljál egy bizonyos problémát illetően, akkor érthető, hogy úgy gondolod, hogy inkább Te lekódolod, aztán készen van. Holott az is lehet, hogy egy kereséssel, majd 3 kattintással túl is van tárgyalva a dolog, mert előtted 134 ember már megszívta ugyanazt és van rá kész megoldás.
Egy dolog viszont biztos: a Drupal használata tényleg nem kötelező!