Szóval azt mondod...
Azt mondod, hogy ha én a css-t is átírom úgy, hogy az nekem tetszen és az esetleges képeket is kicserélem és változtatok a html/php részén attól az még az övé? Szerintem ez nem igaz.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
nincs királyi út
Két alapvető lehetőséged van, ha a node-ot adatelemmel akarod kibővíteni.
1. hook_form_alter és hook_nodeapi függvényekkel
2. CCK-val.
Az elsőre példát láthatsz az api.drupal.org webhelyen a másikra pedig az Emela által linkelt oldalon. (az első a listában)
Ha CCK-ba vágsz bele akkor tudnod kell, hogy sokat kell dolgoznod vele, ugyanis általánosítanod kell egy probléma megoldását. Kezdetben javaslom az első módszer használatát és ha már nagyon megy az és tökéletesen érted a Drupal mechanizmust utána érdemes belevágni a CCK-ba.
Mindkét módszernél két dologra lesz szükséged.
Egy "beviteli eszközre" vagy widget-re, ami segítségével beviszi felhasználó az adatot. Ez egy egyszerű szövegdoboztól egészen bonyolult több részből álló Ajaxos csodákat tartalmazó komplexumig minden lehet. Ezt az első megoldásban a hook_form_alter függvénnyel, míg a CCK megoldásnál a hook_widget kezdetű függvényekkel tudod megadni.
A másik amire szükséged lesz az az adatbázisba mentés. Ezt az elsőnél a hook_nodeapi függvénnyel, míg a CCK-nál a hook_filed kezdetű függvényekkel tudod megadni.
Az első a nézet/view a második a(z adat) modell a vezérlést a Drupal azon belül a node vagy CCK modulok adják. (ha mond valamit az MVC modell ugye.)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
update status
Ebből a listából nekem az update status gyanús, mármint az lehet ami hozzáadja ezt az opciót.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Hosting
a második kérdésedre a válasz. Az elsőre pedig az hogy nem tudom és honnan tudom az megtudni?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
flvplayer
http://www.jeroenwijering.com/?item=flash_video_player
(csak nem fizetős szolgáltatás esetén ingyenes, egyébként fizetni kell érte!)
Az első három videót simán html kódként másoltam be, de mostanra már írtam egy minimál szűrő modult,
ami az [akarmi.flv]-t lecseréli a neki megfelelő html kódra. Az flv-ket és a hozzájuk tartozó képeket meg egyszerűen ftp-vel feltöltöm egy könyvtárba.
Paal megoldása jó lenne, de nem tartom értelmét feltelepíteni egy olyan modult, aminek a szolgáltatásainak az 1 százalékát használnám ki, ráadásul az ötös Drupal-hoz még nem érhető el a modul stabil verziója.
Miért bonyolítjuk az életünket azzal a felkiáltással, hogy egyszerűbb legyen ;) Az általam fejlesztett modul az info fájllal, szép kóddal, help szöveggel együtt alig haladja meg az 1KB méretet ;) (az ajánlott modul 60x nagyobb ;))
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
működik, de nem jó irány
Sikerült működésre bírnom a linked alapján. Ez alapján össze tudom fésülni a blogbejegyzéseimet az egyebekkel.
Ami fontos az utókornak, hogy ahhoz hogy az union működjön két dolgora figyelni kell:
- A belefésült extrás nézetből ki kell venni a lapozót, a limitet és az orderby-t, különben az union sql-je hibás lesz. (A fő blogbejegyzés nézetében lehet állítani a lapozót, limitet, sorrendet.)
- Mindkét nézet "select" részében ugyan annyi oszlop kell legyen (és állítólag azonos adat fajta is). Vagyis, ha a minden egyéb nézetéből kiszedtem az "order by publish date"-t, akkor a mezőknél mindenképp be kell rakni a beküldés dátuma mezőt.
Viszont nekem nem erre van szükségem. :( Ugyanis nekem fontos, hogy a lapozó az az alap blog bejegyzések nézet lapozója legyen (pl. 10 blogbejegyzés oldalanként, akárhány köztes egyéb extrával). Sőt ideális esetben az lenne, ha két blobgejegyzés között az extra több mint 5, akkor nem jelenik meg több / "more" felirat jelenik meg.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Egyszerűbb
A Drupallal nem kezelném az adatokat, ha nem muszáj - bár lehet, hogy ésszerűbb lenne - igaz, a biztonság itt nem számít, mert az adatfelviteli űrlap nem nyilvános (csak belépett családtagok láthatják, szóval nem kell injection-tól tartani), a kapcsolat SSL-lel védett, illetve az adatbázis nem fogad el mástól, csak a localhosttól érkező kéréseket.
Az űrlap adatai közvetlen utaznak az adattábláimba. Az adattábláimat az egyszerűség kedvéért külön adatbázisba helyeztem, hogy ne keveredjenek a Drupaléval, de nem lenne nagy gond a közös adatbázis sem, legfeljebb előtagot használok a táblaneveknél. Ahogy az adatbázis absztrakciós réteget nézem, lehet, hogy az utóbbi megoldás az egyszerűbb.
Mivel a Drupal felszín alatti világát - code-korallok, halacskAPI-k ;) - most feldezem fel, egy icipici iránytűmég kéne, vagyis merre induljon az adatom:
Űrlap vezérlőelem tartalom --> elfogja egy beregisztrált eseménykezelő, mondjuk onChange-nél (De melyik? Egy saját gyártmány?) --> átadja a megfelelő - általam dinamikusan gyártott - SQL-kéréssel egy motornak --> a PHP motor végrehajtja az SQL-t a saját tábláimon --> a választ visszakapom XML-ben --> majd azzal a saját JS kódom a megfelelőt teszi (feltölt vele egy mezőt, vagy egy select-et, megjeleníti őket egy dinamikus div-ben plusz információként, stb.), amit - gondolom - mint "onreadystatehange"-szerű eseményt a kéréskor beállítottam.
Ehhez hasonló folyamatot várnék, de valamiért az a megérzésem, más lesz a megoldás. Vagy tévedek?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Srácok, nagyon nagyok vagytok
Srácok, nagyon nagyok vagytok! Hogy mekkora nagyok, álljon itt pár gondolat:
November 28.-án hozta létre snufkin a drupalhumigration slack csatornát, akkor indult az érdemi munka, mert az előkészület (acquia hosting, git repo, stb.) már jóval korábban készen volt, csak lehetett látni, hogy ez nem két perc lesz.
Az adatbázis (~200Mb) és a fájlok (pár Gb) átmozgatása mellett a keresőt gyakorlatilag újra kellett építeni, mert az Acquia hostingon található Solr nem csak verziójában más, hanem külön modul biztosítja az elérését.
Háromszor vagy négyszer lett lepróbálva csak maga az átállás. Tehát a konkrét adatszinkronizálás az éles oldalról. Több mint 20 pull request érkezett az idő alatt és most már van CI szerver is a folyamatban: https://travis-ci.org/drupalhu/drupal.hu Maxi rispect snufkin.
Az átállás alatt tényleg csak annyit állt az oldal amennyit muszáj volt. 5:21-kor kerül karbantartás üzemmódba az oldal. 6:07-re másolódtak át a fájlok. 6:37-ig indexelődött a tartalom, ami után már élesbe is állt a rendszer az új helyen.
Szóval még egyszer gratula mindenkinek, külön kiemelve Dianiska Balázst aka snufkint.
Remélem egy DUG-on vagy Drupal Hétvégén részletesen beszámoltok a munkáról, mert igencsak mintaértékűnek gondolom, ahogy ezt az átállást végrehajtottátok.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Három különböző dologról van szó.
A legegyszerűbb, hogyha a commit hash-t nézzük. :)
A teljes hash az igazából a commit fingerprintje, vagyis újlenyomata, egyedi csak az adott kommitra jellemző azonosító. De pl a timestamp és a szerző is lehetne fingerprint, az is kb. elég egyedi. Meg igazából nem is kell az egész hash, hanem elég csak az első pár karakter (Linux kernelnél 10)
Ha arra használják, hogy ellenőrizzék, hogy az adott commitot sérült-e, akkor igazából egy checksum.
Mondjuk checksumra jobb egy jó kis crc(https://en.wikipedia.org/wiki/Cyclic_redundancy_check) mert azzal nem csak jelezni, hanem adott esetben javitani is lehet a hibát.
Az első pár karaktere (akár csak egy) használható arra, hogy a nagy commit halmot hasítsák, vagyis hash.
Tegyük fel, hogy van sok szövegünk, ekkor:
Ha vesszük egy szövegnek az első 3 karakterét az jó hash-nek(gyors keresés), de nem jó fingerprintnek, és nem jó checksum.
Ha egy teljes szövegnek képezzük a karakterek ASCII kódjainak összegét úgy, hogy nem érdekel minket a túlcsordulás, akkor az tök jó checksum, de nem jó fingerprint. stb.
Szóval nem mindig ugyan azzal az eszközzel készíted ezeket, sőt. De az igaz, hogy ha az md5-el készítik, akkor csak a felhasználás módja mutatja meg, miért hívod úgy ahogy hívod.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mindig minden útvonalhoz kell a hook_menu -ben bejegyzés
az regisztrálja az útvonalat és meghatározza, hogy mi történjen (jelen esetben fusson az ugylekerd_listazas fgv) amikor az adott útvonalat látogatja meg valaki. enélkül a drupal honnan tudná, hogy melyik útvonallal mit kell kezdenie?
-
clear: both;