eMeLA képe

Ha jól gondolom, a megrendelőd úgy gondolja, ha kész a Drupal oldal, akkor egyszerűen átvált a html-esrő a Drupalra. Lusta (!?)

"Azert kell igy csinalnom mert nekem ezt adtak feladatba"

Azért a megrendelő nem mindenható, és ha megbíz egy szakembert aki látja, hogy így nem oldaható meg a dolog, akkor először meg kell kérdezni tőle mért akarja ezt, és utána javasolni egy működőkéspes megoldást (ne akartalak kioktatni, de van olyan, hogy a megrendelének téves az elképzelése, kár görcsölni egy olyan megoldáson, aminél van egyszerűbb)

Én egy külön subdomain-ra tenném a Drupalt, és ha kész az oldal egyszerűen átmásolnám a html-es oldal helyére (az SQL-el meg marad a helyén).

Az alkönyvtáras módszer szerintem nem jó, mivel az elérési utakban eltárolja az az alkönyvtár nevét is... Persze egy ügyes PHP script egyszeri lefuttatással ki lehet "írtani" az SQL táblákból, de nem túl elegáns, és van jobb megoldás is.

0
0

...mit tudok: http://web.termuves.hu

burney képe

Szerintem értelmezésben nem találunk közös nevezőre :)

Na most, én régiónak hívom azt a területet ahova blokkokat helyezhetünk el.
Pl.: sidebar-first

Blokk pedig az az elem amit a régióba belehelyezhetünk
Pl.: Elsődleges linkek

/Jól gondolom nem?/

Tehát a problémám, hogy egy régióba több blokkot is helyezhetünk és ezáltal az összes oda kerül ahova az adott régiót css-ben beállítottuk.

Ami viszont megoldást jelenthet az az, hogy ha létrehozok egy saját régiót és annak állítok float:left -et, ennek a megvalósításával egyetlen probléma van, méghozzá az, hogy soha nem csináltam még ilyet! Tehát eddig nem hoztam létre régiót és nem tudom, hogy hogyan kell. (Annyit tudok, hogy hozzá kell adni az info-ba, a css-ben, és persze a page.tpl.php-ban.
De többet nem :(

Ha valaki érezne erőt magában, hogy segítsen azt megköszönném :)
Igazából bármilyen ötletnek örülnék...

0
0
jaunty képe

Megpróbálva mindenkinek a reagálására válaszolni, nem tudom, hogy mennyi az a sok. Ezek a modulok futnak: Amazon, CCK, Composite Layout, CSS Injector, DHTML menü, FCKEditor, FAQ, String Overwrite, Token, Image, Image Assist, ImageCache, Simple Access, PDF version, Captcha, Ubercart, JQuerry Update, Views, Fivestar. Az Amazon-ból csak az Amazon Field van bekapcsolva meg az API, az ubercartból is nagyon kevés.

A szolgáltató nevét nem szívesen mondanám, mert nem akarom rossz hírét kelteni. 1,5 éve vagyok nála, eddig 7-szer kerestem meg, olyan gondokkal, mint amiről a kérdés is szól, de eddig még mindíg bunkó volt. Egyszer, amikor még abszolút csak kezdtem a Drupal-t segítettem vkinek összerakni egy honlapot. Ott a szolgáltatót egy hónap alatt legalább 5-6-szor kerestem meg trivialitásokkal, de mindíg a lehető legudvariasabb hangnemben válaszoltak. Na az a JustHost.com volt. Egyébbként is megfigyelhető, hogy az amcsi, meg UK szolgáltatók nagyon udvariasan bánnak a kliensekkel, nem úgy mint az itthoniak. :(

0
0
Vulpex képe

Köszönöm a válaszokat.

Ez a Gallery Assist valahogy eddig elkerülte a figyelmem, de egy próbát megér.

Igazából a views+cck+imagecache... megoldás is jó lenne, ha az imagecache működne.
De nem mindig működik, a php memóriát zabálja fel valószínűleg. Ilyenkor az a necces, hogy az egész portál ledöglik :(

Egyébként nemcsak nekem nem működik, más is ezzel a gonddal küzd, főleg az utolsó két bétánál.

a drupal saját belső átméretezőjével nem lehet kiváltani az imagecache-t?

Tudom, hogy 32MB nevetségesen kevés, de ez van, most ezzel kell megoldani. Majd egyszer talán lesz más is.

Még arra kellene valami megoldás, hogyha egy filefield alapú galériát készítek, akkor hogyan lehet gyorsan beszúrni onnan a képeket egy wysiwyg editorba? milyen modul van, amivel leválthatjuk az IMCE-t ebben az esetben? természetesen úgy, hogy az adott cikkbe/írásba beszúrt kép automatikusan átméreteződjön egy általam megadott méretre. :D

előre is köszi a segítségeteket

0
0
szantog képe

Szerintem eleve rossz a megközelítés. Rég vót, tán igaz sem vót, de elmlékezeteim szerint a t-comnál ez úgy volt, hogy egy lucent nevű rendszer bonyolította a központ forgalomírányítását a hívás beérkezésétől az operátor callmasteréig, illetve számítógépéig. Ennek apiján szedte össze az operátor gépe a számot, és küldte el lekérdezésre az épp aktuális töketlen szoftveren keresztül.
Szóval ahogy te írtad, ahhoz az kellene, hogy a forgalomírányító rendszer a szerverre küldje a számot, és azt a szerver dobja az operátor gépére. Jelenlegi ismereteim szerint nonsensnek tűnik, hogy egy server bármilyen request nélkül dumáljon az otthoni gépnek.
Tehát itt a következő lehet a logika, hívószámazonosítás a gépen (isdnen létezett régen egy rvscom nevű sw), annak átadása egy http requestnek, és jöhet az operátor elé az adat.

Röviden: Nem drupal kérdés, de izgi volt elgondolkodni rajta. :)
Ja, még egy, ha erre komoly igény van, és elakadtok, keressétek Maus Róbert Pétert, ő elég nagy szaki ebben.

0
0

----
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.

leonidasz képe

Mindig minden meg lehet cáfolni, vagy jobban megoldani, de több megoldás is létezik. Mint írtam, az attribute csak akkor kell ha nincs egyedi id-ja a menüpontnak.

A megoldás mindig függ az esettől. Ha Az utolsó li tagot kell használjam vmi más miatt, akkor persze nem az a jó megoldás. Készísen másik menüt, ugyan azokkal a menüpontokkal.
Kérdés az: mit ér meg egy ilyen értelmetlen dolog: 3 percet vagy 1 nap utánajárást és gondolkodást...
Sokszor a 3 perc győz, mert ha minden ilyen kis aprósággal eltölt az ember egy napot, akkor bezárhatom a céget :)

Nem minden esetben szép a 3 perces megoldás, de nem mindig teheti meg az ember hogy több időt szenteljen erre mint egy másik fontosabb projectre.... hisz ha belegondolunk ez az ügyfélnek egy apró megjegyzése lett, nem pedig egy project módosító, új megrendelést igénylő feladat... De ha ezen sokat keresel, akkor megértem a fáradozás. Ha van időd ilyen dolgokra, akkor irigyellek :)

0
0
szistvan képe

Valószínű az lesz a legjobb, ha leírom mit szeretnék, aztán a tapasztaltabbak majd megmondják, hogy merre vegyem az irányt.

Lészen egy könyvtári rendszer, benne személyekkel, könyvek kölcsönzési adataival és persze a könyvek adataival és még sok mindennel. Az egészhez van egy webes felület űrlappal, amit kitöltve kereshet szerző, cím és még sok minden alapján. Illetve az olvasó megadhatja az olvasójegyét és jelszavát, akkor láthatja a kölcsönzött dokumentumait, tartozásait, stb.

Ez az egész webes felület úgy működik, hogy van egy gateway.cgi ami kapcsolódik az adatbázishoz majd lekéri a megadott infókat és visszad egy .html oldalt. A gateway.cgi paraméterezhető, hogy ne .html-t adjon vissza, csak "tiszta" adatot, amit aztán megformázhatok, ahogy akarok.

A feladat az lenne, hogy a gateway.cgi által visszaadott eredményt a drupal alapú weboldalba integráljam iframe tag nélkül.

Erre egy modult kezdtem el készíteni, a saját block megvan, a többit nem írnám, inkább megvárnám a véleményeteket, javaslatotokat.

0
0
pp képe

Nem árt, ha az ember tisztába van azzal is, hogy az adott modul hogy működik.

Kéne az a verzió amihez a folt való. Értelmezni kell, hogy a folt mit változtatott, vagyis a működésbe hogyan szólt bele, majd ennek függvényében kell elvégezni a változtatásokat az új verziójú modulon, figyelembe véve az azóta történt változtatásokat. Mivel pusztán a változtatások ismerete nem mindig elégséges a megértéshez, ezért nem árt, ha a verziókezelőben meg lehet nézni, hogy miért történtek azok.

A végén lehet, hogy egy teljesen más megoldást kell választani, de természetesen, az is elképzelhető, hogy könnyedén orvosolható az adott probléma.

Mondjuk már évszázadokkal előrébb lennénk, ha a kérdés feltevője a foltot, és azt a verziót is megadta volna, amit foltozni akart, mert így picit nehéz érdemben válaszolni. Az issue-ról már nem is beszélnék, ami azt is leírná, hogy minek kell itt foltozgatni. Vagy ez csak egy olyan öncélú patchwork a magunk szórakoztatására? :)

pp

0
0
osimester képe

Én is ugyanezt a hibát tapasztaltam. Nekem a lightbox2, imagecache kombóval okozta a hibát. Nem volt kis (átméretezett) képem csak URL az eredetihez.

A DBlog-ban jelezte, hogy meghiúsult a kép generálás.

Addig piszkálgattam míg rájöttem, hogy az ImageCache akciók megfogalmazásánál követtem el hibát:

Átméretezést választottam mint akciót. Azt akartam, hogy egy max 1280x1280 pixeles képből készítsen 300 pixel körüli kicsi másolatot.

Először hibásan adtam meg a két értéket (szélesség magasság): 300px 400px

Másodjára jól (px nélkül) és úgy működött is. Végül százalékosan kiszámoltam az átméretezést és úgy is jó volt.

VISZONT! Ha az egyik értéket (szélesség v. magasság) üresen hagytam, akkor az ImageCache lementette, viszont nem figyelmeztet, hogy ebben az esetben felüti a fejét a probléma és nem generálja le a képeket.

Lehet ez teljesen más hiba mint az itt jelenlévő, de az eredmény ugyanaz.

Bocs ha kicsit hosszú lett a leírás.

2
0
ipeto képe

DE!!! Igazából nem nagyon értem, hogy miért van szükség az Oktató tartalomtípusra.

Ez többtényezős döntés volt:

  • Az LDAP-modul akkor hozza létre a usert a drupalban, amikor az bejelentkezik. Megfigyelésem szerint "előre dolgozni" nem igazán lehet, mert az adatbázisba egy mezőbe belerak mindenféle LDAP-os információt, tehát a drupalban kézzel létrehozott és az ldap által létrehozott felhasználó nem ugyanaz.
  • A gyorsabb, egyszerűbb karbantartás okán a frissítést Excelből, pontosabban csv-ből egy Feed Importer segítségével végeztük. Ez meg nem tudja kezelni a Profile mezőit, sima node-oknál viszont remekül működik.
  • Ez egy rendkívül szerencsés módon "dinamikusan" alakuló projekt, sokáig arról volt csak szó, hogy az oktatói adatokat nem maguk az érintettek tartják karban, tényleges felhasználóként nem nagyon jelennek meg, így ezért is lett külön tartalomtípus.
  • Ill. nem lehetett kivárni, amíg mindenki veszi magának a fáradságot és bejelentkezik, korábban kellett az oktatói listát prezentálni
0
0