Letöltés újra
Sziasztok :)
Van egy weboldalam ahol a PHP-Fusiont használtam eddig de már igencsak eljárt felette az idő és ezért átváltottam Drupalra.
Kellene nekem egy letöltéseket kezelő modul amivel könnyedén lehet hozzáadni cuccokat, azokhoz leírást és videót hozzáadni, számolja a letöltések számát, kilistázza és alkategóriákat is képes kezelni.
Van ilyen mert eddig nem találkoztam vele?
Mint például az alábbi 3 képen:
1) http://kepkezelo.com/images/lbx7h6ezpagfrw06m3q7.jpg
2) http://kepkezelo.com/images/aazpyw5t23ahevyki1zo.jpg
3) http://kepkezelo.com/images/6qtg4svktowyg00rsm.jpg
Vagy itt az alábbi linken lehet megnézni mire gondolok:
http://euro.truck-simulator.hu/viewpage.php?page_id=10
A CCK, az IMCE, a DownloadFile, a File Force Download fenn van de úgy tűnik ezek nem megfelelőek.
Előre is köszönöm az esetleges segítséget :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Kb. soha nem lesz olyan
Több tényező is meghatározza a böngészőben megjelenített képet, de ugyanolyan minőséget csak az "eredeti kép" megnézésekor fogsz látni:
1. Drupal képstílus
A tartalomban megjelenő képhez rendelhetsz (ahol a colorboxot is beállítottad) "képstílust", azaz hogy mekkora kép jelenjen meg a tartalomban. Gyárilag 3 méret van a Drupalban beállítva, de te is hozhatsz létre újakat.
És ez már egy átméretezés.
2. Böngésző méretezése:
A böngésző is méretezheti a képet (kicsinyítés), ha az nem fér el a befoglaló elemében. Például van egy 1000px széles képed, egy 1000px széles képernyőd, és az oldal úgy van összeállítva, hogy a szöveges tartalom mellett a kép kap helyet, fele-fele arányban. Ilyenkor hiába is tölteted be az eredeti méretű képet, a böngésző lekicsinyíti 500px-re.
3. Responsive
Jobb esetben már olyan sminket használsz, ahol a képernyő méretétől függően is változik folyékonyan a képek mérete.
A képen lévő szövegeknél tűnik fel a leginkább, mert a szövegtől elvárjuk az éles körvonalat.
Legjobb megoldás talán, ha megnézed mekkora hely is kell a képnek egy átlagos monitoron (vagy ahogy a responsive sminkedben a legnagyobb media query adja) és a szerint méretezed Photoshopban a képet és akkora méretben mented el.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nálam is hasonló a helyzet!
Sziasztok!
Drupal 7 webshopot építek commerce megoldással... a termékek még nincsenek feltöltve.
Szintén kaptam egy felszólító levelet egy hazai nagynevű tárhely-szolgáltatótól (meg vagyok velük elégedve...eddig :))
Elvileg átléptem a csomagomban foglalt adatbázis tárterületet (100mb)
kérték, hogy próbáljam optimalizálni az adattáblát, de ugyan ott vagyok vele.
Namost... nem teljesen értem, hogy egy
-2,3mb-os gzip-elt drupal adatbázis (tömörítetlenül 11mb)
-phpmyadmin-ban 42,6 mb
- a cpanel-ben meg már 122,61 mb!!!
mint írták:
"..(Ha phpmyadminban nyitja meg, akkor az egyes táblák, valamint alul az összegzés alatt a hasznos adatterületet látja.
A cPanel ellenben a foglalt adatterületet számítja.
A két érték azért különböző, mert nem pusztán adatokat tárol az adatbázis, hanem táblaszerkezeteket, adatstruktúrákat.
A nagyobbik szám az adatfájlok által foglalt terület, a kisebbik a hasznos adattartalom.
A foglalt tárterület többek közt függ: ...)"
Ha valakinek lenne valami ötlete, hogy mit tehetnék, kérem ossza meg velem, milvel ha pár napon belül nem csökkentem a méretet, kapok a fejemre :) .
Nagyon szépen köszönöm előre is!
(nem használt modulok kikapcsolva, log kikapcsolva, cache beállítva stb stb.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Csatlakozom a bátorítók táborához
A backdrop olyan, mint egy drupal 7 / korai drupal 8 fork.
A backdrop cms egészen más irányvonalat képvisel, mint a kései drupal 8. Egyik sem rosszabb a másiknál. Mindegyiknek van helye.
Én szívesen foglalkozom objektumorientált programozással és kedvelem a drupal 8 irányát, de jól láthatóan a drupal 8 végleges formája várhatóan a drupal 9 környékére alakul csak ki. Nem is csoda. Hatalmas változásokon ment és megy át a rendszer. Ez egyáltalán nem elítélendő irány.
Viszont nem várható el a hobbi fejlesztőktől, hogy megszeressék ezt az irányt. Az objektumorientált programozás jóval bonyolultabb. Ezért is született meg a backdrop cms. A backdrop cms a klasszikus drupal 7 vonalat viszi tovább a korai drupal 8 fejlesztéseit integrálva.
Van akinek az egyikre van szüksége, van, akinek a másikra. Lehet az egyik projekthez az egyik előnyösebb a másikhoz a másik.
Én nem utálnám ki innen a backdrop cms-t. Mégiscsak drupal alapú rendszer. Lehet, hogy kisebb nemzetközi táborral rendelkezik, mint a drupal 8, de, ha a lelkes közössége megmarad, akkor egyszerre két pozíciót is kiszolgálhat a drupal.
Drupal 7...:
- Drupal 8 (közepes és nagy projektekhez -profibb fejlesztőknek)
- Backdrop CMS (kis és közepes projektekhez -hobbi és átlagosabb fejlesztőknek)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A Drupal mindenképpen kell,
A Drupal mindenképpen kell, mert rengeteg funkcióját ki fogjuk használni. Csak éppen lesz néhány olyan oldal amit kézzel szeretnének összerakni.
Én idáig jutottam a megoldásban:
Ennek a funkciónak egy külön tartalomtípus, ahol a HTML tartalmat vagy a body field-be írják bele szép html syntax highlight-tal, vagy egy file field-be feltöltik. Egy másik fieldben (field_html_attachments) pedig beledobálják a css/js/kép fájlokat.
A megjelenítés pedig úgy néz majd ki, hogy a node--static.tpl.php teljesen ki van ürítve, és egyszerűen a html tartalmat (body field vagy feltöltött fájl) jeleníti meg.
A page.tpl.php-bam vannak dolgok, amelyeket adott esetekben el akarnak majd rejteni ezeken az oldalakon:
- title
- breadcrumb
- messages
- sidebars
Ezeknek egy-egy pipát beteszek ebbe a tartalomtípusba és hook_preprocess_page alatt szépen elrejtem ezeket, ha bepipálták az elrejtést.
Igazából ez már majdnem az amit én akartam, "mindössze" annyi a gond, hogy a html/css/js szerkesztése macerás így, illetve csere esetén átneveződik, emiatt aztán hivatkozni nehéz rá a html-ből. Ha az egyszer már feltöltött fájlokat, mondjuk WebDav-val, utólag szerkeszteni lehetne, az tökéletes megoldás lenne.
Kalandjaim a Drupal és PHP világában.