Igen
En ugy mondanam hogy van "profi" munka ahol megvan hogy mit miert es van egy "amator vagy olcso kategorias" munka vagy hozzaallas. Nem erre az oldalra meg szolgatatora gondolok most hanem altalaban! Nem szeretnek senkit sem megserteni!
Altalaban az szokott lenni hogy valaki oszetakol egy oldalt ami kinezesre szep es jo, az oldalnak van keresve egy minnel olcsobb tarhely ahol az szepen megvan. Rengeteg olyan oldal van aminke szinte allig van latogatoja, idonket valaki megnezi a tulaj es a keszitokon kivul. Neha par keresorobot is megnezi. Az hogy mi mennyire van jol es optimalissan megcsinalva az addig nem is jon elo amig ilyen keves a latogato.
A tomeg viszont ehhez akar hasonlitani egy nagyobb folrgalmu helyet is vagy egy komolyabban elkeszitett munkat is. Ott csak az van hogy amaz ennyiert is megcsinalta, vagy hogy amaz olyan tarhelyen is elfer.
Ebben az esetban is nagyon hasonlo a helyezet, sok a latogato es igy mar eszreveheton nagyobb a terheles a szerverre. Ilyenkor mindket oldalrol elojonnek a gondok. Tetszik a szolgaltato hozzaallasa (gondolom meg kezdok ilyen teren) ugyerzem nem voltak tisztaban hogy a drupal mennyi sql lekerdezest general, de pozitivan allnak a dologhoz, ugyerzem korektul szeretnenek megoldast talani.
A masik oldalrol is latok hajlamot a gond megoldasara, itt azert nagyobb gondolkat latok, ugyerzem volna itt meg tanulni ezt azt ... Erdemes lenne kicsit elmenyedni a html dolgodkan, itt pl. az oldal felepiteser gondolok html, head, body stb. Tisztaban kell lenni azzal is hogy ha minden letezo es nemletezo dologgal telepakolunk egy oldalt akkor annak nagyobb lessz a terhellese a szerverrre is. Lassabban is toltodik be a latogatonal.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Még kevésbé értem!
Korábban így nézett ki egy adott taxonómiakifejezés (itt épp egy folyó) "Fordítás" füle:
Miután az imént mutatott képen látható oldalon, az admin/config/regional/entity_translation címen engedélyeztem a "Taxonomy term" számára is az Entity Translationt, azután így néz ki az adott taxonómiakifejezés "Fordítás" füle:
Ebből úgy értelmezem, a fieldeket kell külön fordíthatóvá tenni - de miért? Miért nem úgy működik, mint a node-oknál, hogy lehet külön fieldeket is fordíthatóvá tenni, meg a teljes tartalmat is?
Amit főleg nem értek: most hirtelen miért a magyar lett a default nyelv? Igaz, az az alapértelmezett nyelv, de az általános beállítás a source-ra az angol.
Plusz az rendben van, hogy mondjuk a címek fordítására meg tudom kerülni a dolgot úgy, hogy létrehozok egy külön fieldet a title-nek, majd Automatic Entity Label segítségével összetákolom, de a default "Leírás" mezőt hogyan fordítom?!
Szóval ez most számomra totál kavarodás.
===========
@eager : igen, kösz, ismerem Hojtsy Gábor írásait, de ez önmagában még a kérdésemet nem válaszolja meg, legalábbis nincs konkretizálva.
A fentiek megvilágításának nagyon örülnék.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Böngészők "vissza" és "előre" gombjainak működőképessé tétele
Szívesen, ennek örülök! :))
Még annyi jutott eszembe, hogy az oldal kényelmessé tétele érdekében meg kellene oldanod, hogy a hash akár az adott elem id-jával hozzácsapódjon az URL-hez, hogy lehessen a böngészők vissza és előre gombját használni a navigációhoz, amikor klikkelsz.
Tehát rákattint a felhasználó az "egyes oldal" linkre, akkor mondjuk
www.example.com/drupal/
cím helyett legyen például
www.example.com/drupal/#egyes
ha ilyen a linkje az egyes oldalnak: <a href="#egyes">Egyes oldal</a>
A Drupal 7 például már beletette a core-ba a jQuery BBQ plugint:
http://benalman.com/projects/jquery-bbq-plugin/
ezt használja arra, hogy az Overlay modul (tudod, az a felpattanó vászon az admin-linkekre kattintásnál) vászonjának felugrásakor megváltozzon az URL, és bekerüljön egy hash a címbe (valami.hu/#overlay=blabla/asdasd). Így a böngésző "Vissza" gombját is lehet használni a navigációra.
Elvileg a History.js meg a Statehandler pont ilyen célra való:
http://drupal.org/project/history_js
http://drupal.org/project/statehandler
Remélem, sikerül!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Amit leírtál, annak a nagy
Amit leírtál, annak a nagy részével tökéletesen egyetértek. Amivel nem, azok közül két dolgot kiemelnék:
1.) nem nézem le, sőt. Nekem inkább azzal a pár szakival van bajom, akik "kisajátítják" maguknak a drupal.hu-t ami ugye a drupal magyar közösség portálaként van meghirdetve és zavarja őket minden, zavarják a kezdők, a kérdezők, akik alapdolgokat kérdeznek, zavarja őket egy drupal suli amit nem ők csinálnak, mert az akkor már nem is lehet jó, mindenre csak szakmai szemmel tekintenek és nem akarják elfogadni, hogy az emberek többségét nem az érdekli ami őket, vagy nem úgy tekintenek a drupalra ahogyan ők. Tisztelem a szakmai tudásukat, de ezt a fajta viselkedésüket nem szeretném kommentálni.
2.) miért baj az, ha az ember kérdez? Senki sem úgy születik, hogy mindent tudjon. És én már többször is leírtam és nem szégyenlem, hogy igen, én is kérdeztem. Így utólag teljesen irrelevánsnak tűnő dolgokat is, de én is voltam teljesen kezdő. És azt is leírtam a bemutatkozómban, hogy nem foglalkozok drupal programozással, nem is áll szándékomban és azt is, hogy nap mint nap tanulok új dolgokat...Kérlek olvasd el.
Az én meglátásom szerint a Drupal a egyik legnagyszerűbb tartalom kezelő rendszer. Mint ilyen, komoly segítséget jelenthet azoknak, akik saját egyszerű céges weboldalt szeretnének készíteni maguknak vagy másoknak. És aki profi webprogramozó akar lenni, az tovább tanul, kérdez, keres, kutat, az van amit leírtál te is és már jeleztem hogy egyetértek. De nem mindenki akar profi webprogramozó lenni. A többségnek egy rendszer kell, amelyiknek a segítségével könnyen tud boldogulni és meg tudja oldani a saját problémáit. Ennyi és nem több. Ezért törekszik a drupal is arra, hogy még felhasználóbarátabb legyen, könnyebben kezelhető - a 7-es verzión is elég nagy hangsúlyt fektetnek erre. És az, hogy többen használják majd és akad aki még többet szeretne majd tudni és kérdezősködni fog? Az jó a drupalnak, a közösségnek és mindenkinek.
"A legfontosabb azonban, hogy ne hagyd abba a kérdezést." - Albert Einstein
Most épp ezt bütykölöm http://online-vallalkozas.com/drupalsuli
A megjelenés eltérhet gépenként.
Nálam a Firefox pontosan úgy jeleníti meg mint a többi böngésző. Szerintem itt a gépre vezethető vissza a probléma. Pl ha a barátod gépén nincs Verdana betűtípus akkor nyilván a CSS -ben megadott másodlagos betűtípus fog megjelenni vagy ha olyan nincs az alapértelmezett. A színekkel kapcsolatban ugyanez a helyzet. Tapasztaltam, hogy ha a CSS 3 színmegnevezési szabvány szerint peszterkedek a CSS -el és nem hexadecimális értékben adom meg a színt hanem az angol nevén akkor néhány gépen előfordul, hogy nem jelenik meg a szín. Ezért én javaslom mindig hexadecimális szín megadást. A másik dolog tudni kellene, hogy a barátod kijelzője mire volt állítva. Esetleg nem valami hót régi kijelző ami nem is képes azt a színt kikeverni.
Az utóbbi években egyre jobban el lehet hagyni az úgynevezett webtűrő színeket én régen ezzel még sokat cumiztam így elég rendesen rájuk szoktam. Nyilván nem lesz ettől hót dizájn egy weblap de a megjelenés többé kevésbé minden gépen egyforma lesz.
"Létezik ezeken kívül még az ún. webtűrő színek csoportja is. Ez arra a technikára nyúlik vissza, amikor még csak 256 színt lehetett a képernyőkön közvetlenül megjeleníteni. A többi szín illúzióját az angol szóval ditheringnek nevezett technikák valamelyikével teremtették meg, ez gyakorlatilag különböző színű képpontok egymás mellé helyezését jelenti, hasonlóan a nyomdászatban alkalmazott raszterezéshez, a szem ennek eredményeként egy „kikevert” színt lát. A módszer viszont többé-kevésbé szemcsézetté teszi a képet. Azokat a színeket nevezzük webtűrő színeknek, amelyekhez a dithering nem szükséges. Az újabb technikák folytán a weblapok tervezői egyre kevésbé kényszerülnek arra, hogy az egységes és jó minőségű megjelenítés érdekében a webtűrő színekre korlátozzák a weblapok kialakítását."
forrás: http://hu.wikipedia.org/wiki/HTML-színkódok#Sz.C3.ADnk.C3.B3dok.2C_sz.C3.ADnnevek_.C3.A9s_csoportjaik
No és persze az is simán elképzelhető, hogy a barátod felteszi a legújabb Firefox -ot és piff paff jó lesz :D Az informatika már csak ilyen.
honlapom http://dyra.eu/
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Adatbázis-karbantartás laptopon a a bemutató változatban
Felépítettem a demo rendszeremet a lokális gépemen. (Xampp, PhpMyadmin, stb) a kézikönyv szerint. bemutatóra készülve elkészítettem ennek másolatát a laptopomon. Telepítettem a Xampp-al a web-szervert, sikerrel létrehoztam a laptopon az üres adatbázist, majd export-import módszerrel zökkenő nélkül áttöltöttem az adatbázis tartalmat. Jól működött minden.
Azt hittem, nem lesz már gond, hiszen a könyvben az adatbázis importálás fejezet rövid.
Módosítottam az eredeti változaton, fejelsztettem még egy napot a site-on, majd végrehajtottam a karbantartást a másolaton, a laptopon: Átmásoltam a /site állományait, megnéztem, nem romlott el az alkalmazás, majd megismételtem az adatbázis export-importot. Pontosabban csak megkezdtem az importo, amire az sql hibaüzenet jött:
------------------------------
Hiba
SQL-lekérdezés:
-- -- A tábla adatainak kiíratása `actions` -- INSERT INTO `actions` (`aid`, `type`, `callback`, `parameters`, `description`) VALUES ('comment_publish_action', 'comment', 'comment_publish_action', '', 'Hozzászólás közzététele'), ('comment_unpublish_action', 'comment', 'comment_unpublish_action', '', 'A hozzászólás elrejtése'), ('node_publish_action', 'node', 'node_publish_action', '', 'Tartalom közzététele'), ('node_unpublish_action', 'node', 'node_unpublish_action', '', 'Tartalom elrejtése'), ('node_make_sticky_action', 'node', 'node_make_sticky_action', '', 'Tartalom kiemeltté tétele'), ('node_make_unsticky_action', 'node', 'node_make_unsticky_action', '', 'Tartalom nem kiemeltté tétele'), ('node_promote_action', 'node', 'node_promote_action', '', 'Tartalom címlapra helyezése'), ('node_unpromote_action', 'node', 'node_unpromote_action', '', 'Tartalom levétele a címlapról'), ('node_save_action', 'node', 'node_save_action', '', 'Tartalom mentése'), ('user_[...]
A MySQL mondta:
#1062 - Duplicate entry 'comment_publish_action' for key 'PRIMARY'
-----------------------------------
Adataim:
------------
Az exportált file: drupal_6_19.sql.gz
a drupal adatbázisom neve: drupal_6_19
bejegyzés a settings.php-ben $db_url = 'mysqli://root@localhost/drupal_6_19';
megegyezik mindkét gépen
Mit hibáztam, vagy mit értettem félre? Merre van itt az előre?
Válaszotokat előre is köszönöm.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Hát, nem tudom...
Mind a video modul, mint az SWFTools dokumentációja sok ponton bugos, nem naprakész. Fórumokat bogarászva, próbálgatva lehet csak rátalálni a helyes konfigra.
A helyzetet nehezíti, hogy a video modulnak jelenleg 4db különböző kiadása tölthető le a modul oldaláról. A részletes doksi a 6.x-3.9-esre vonatkozik, de a "Recommended release" az a 6.x-4.2-es. Ebben _teljesen_ máshogy működik minden, csomó beállítási lehetőség, ami a hivatalos, on-line, egyébként igen alapos doksiban elérhető, az teljesen máshogy van, illetve el sem érhető a 4.x-es verzióban (sem a jelenlegi beta2-es, sem a -dev ágban).
A kérdésem, a node-ban található file id átirása az eredeti fileról a transzkódolt verzióra, az például _pont_ egy ilyen feature, ami a 3.9-es ágban megvolt, de a 4.x-ben kivették, és máshogy csinálták meg. Erről találtam egy elég részletes threadet a drupal.org fórumában, de sehol máshol nincs rá utalás, csak itt. Nekem nem gond, hogy angolul van, de azért azt hiszem, ezzel nincs mindenki igy. Szóval egy részletes összefoglaló szerintem nem ártana.
Másik lényeges különbség a video modul 3.x és 4.x-es ága között, hogy a 3-as az csak és kizárólag a sima FlowPlayer-el hajlandó együttműködni, a FlowPlayer3-al nem.
Ezen kivül az automata transzkódolás is sokkal nehézkesebb benne - egy mellékelt php filet kell cronból futtatni -, mint a 4.x-es verzióban.
De értem és látom, hogy kicsit perifériás a téma, és igen, elég nagy munka az egészet úgy leírni, hogy értelmes nyoma maradjon. Ezt majd én elkövetem, már elég sok készen van a leírásból. Hamarosan megjelenik itt és akkor talán az up-olásom is bocsánatot nyer... :)
De ha már így végre "találkozunk", megragadom az alkalmat egy már régóta halogatott dologra is: a könyved első osztályú, mindenkinek ezt ajánlom megvételre, aki ismeretségi körömből Drupallal kezd el foglalkozni. Köszönjük szépen!!
---------------
Tátrai József
Drupler Kft.
http://www.drupler.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Hello poetro! :)
Hello poetro! :)
Az 5let alapból jónak tűnik. Tehát induljunk ki abból, hogy local képeken kellene elvégezni a módosítást.
Valahogy így indulnék neki:
1. MODULOM_preprocess_image_style. A style vuduk a theme_image_style függvényben zajlanak.
2. Állítsuk át a $variables['path']-et. Első körben tmp://amazon/[FILENAME].[EXT]-et próbálnék ki. Ez azért ok, mert a file system tmp részét fogja használni, ergo az automata takarítás biztosított, viszont nem biztos, hogy menni fog, nem másztam nagyon bele az image_style_deliver()-be, hogy mit kezd ezzel a sw-el, illetve hogyan generál style uri-t a tmp://-nek.
3. Ellenőrizzük, hogy a tmp://amazon/[FILENAME].[EXT]-hez és az adott stylehoz tartozó transzformált fálj létezik-e. Ez azért kell, mert az image_style_deliver() menu callback csak akkor kezd el dolgozni, hogyha nem létezik még a transzformált fálj, tehát csak ekkor van szüksége a forrásra.
4. Ha nem létezik a transzformált fálj, töltsük le.
Itt api szinten végig lehet követni a mutatványt: http://api.drupal.org/api/drupal/modules--image--image.module/function/t... elvileg ennek működnie kell.
A gond ott lészen, hogy mi van, ha a tmp://-vel besülünk. Na erre lett volna az a terv, hogy _preprocess_image-ben nézzük meg, hogy van-e tmp fáljunk, és töröljük ha kell. De aztán rájöttem, hogy egy file_exists minden kép kirajzolásakor már majdhogynemszinte pazarlásnak tűnik.
A b terv az lenne, hogy elvileg nincsen akadály egy effectbe belecsempészni a tmp fálj törlését. Tehát az amazonos képek stílusában az utolsó effekt az legyen, ami törli a tmp-t.
c terv a cron, igazából ezzel sincs semmi gond, sőt, talán ez a legjobb.
----
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ez eléggé bonyolult lett
- én is úgy tudom, hogy egy webhely más-más nyelveihez egy-egy külön domain az ajánlott ( valahogy úgy jött le, hogy ez azért van , mert van egy ilyen site-wide kulcsszósűrűség-nézés, és ha a minden nyelv egy domainen belül van, akkor el tudod képzelni, hogy a kulcsszavak sűrűségét mennyire higítja egy másik nyelv jelenléte - de erre nincs linkem, csak én ezzel a koncepcióval a fejemben dolgozok ).
- Úgy tudom, hogy ez nemcsak domain.hu / domain.com páros lehet, de bármilyen aldomain is megteszi, a Google azt már külön siteként kezeli ebből a szempontból.
Szóval szerintem az jó, hogy a .hu-s domain meg a .com-os ugyanahhoz a mappához (drupalhoz) van rendelve, de azt nem értem, hogy miért csináltad azt az átirányítást. A .com-os domainednek .com alatt kellett volna indexelődnie.
Az i18n kezelőfelületén lehet választani, hogy mi alapján kezelje a külön nyelveket, és ott van opció, hogy figyelje az url-eket.
Ezen belül a beállításon belül pedig választhatsz, hogy ugyanazon a domainen /hu /en almappákkal akarsz-e dolgozni, vagy pedig különböző domain-nevekkel.
Most, hogy az átirányítást megcsináltad (ha az 301-es tartós átirányítás), akkor szerintem Google-éknál már egy domain alatt, a magyar alatt van elkönyvelve a site.
Tegyük fel, hogy most utólag elintézed, hogy mégis a .com-on indexelje az angol nyelvet, akkor én a Google helyében azt hihetném, hogy a .comos oldal lenyúlta annak a másik (magyar) oldalnak a tartalmait (duplikált tartalom) (mivel az az angol tartalom már be lett indexelve valami.hu/en/ cím alatt).
Szóval erre most valamit eléggé ki kéne találni, hogy ne bukd el egyszerre mind a nyelvek domainenkénti elkülönítését, mind pedig a .com-os domaint.
Plusz: pár SEO gondolatot összeszedtem itt: http://netcompass.eu/articles/drupal-sef
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nincs arról vita, hogy szuperjó-e vagy sem
Nincs arról vita, hogy szuperjó-e vagy sem. Nem vitás, szuperjó.
Kérdés az, van-e rá "ember" aki ért hozzá, üzemelteti, átlátja. Pl, ceu, vagy a sony (Aborosnak most dagad a melle, egy mondatban ez a kettő leírva).
Én csak azt mondom, az a tapasztalatom:
Annyival "nehezebb" megoldani vele egy oldalt, hogy csak na. Sokkal több kattintás. (panel kiválaszt, variant kiválaszt, megjelenés (?), blokk kiválaszt, menü lenyit, beállítások, felugrik, beállít, oké, elment).
Teljesen más logikát igényel, mint amit más odlalaknál használtál.
Amit érdemes használni az a panel-pane - bizonyos esetekben. De mindez szervezés, és döntés kérdése.
Egy bonyolultabb címlapot sem bonya, de legalább átlátható, összerakni context, views, nodequeue, display suit segítségével.
Mert mindezeket egyszer kell összeraknod. És akkor úgy marad egy hónapig-kettőig. Ha nem jó, változtatsz rajt, és megint marad egy jó darabig. De nem naponta variálsz rajt. Biztos van olyan is, de nem jellmző.
A cache, meg egyéb dolgok: igen. Ha az oldalnak olyan látogatottsága van, akkor meg kell csinálni, nincs mese. Kispista Bármitolcsón Bt-nek meg szintén felesleges paneles oldal.
Egy bonyolult címlapot megcsinálni nem nagy kaland. Egyszer beállítod a régiókat, paneleket, és kész. A tartalom beleválogatása, kezelése ami sokkal-sokkal fontosabb, nagyobb feladat: mi van fenn kiemelve a forgatóban? Melyik cikekk, milyen sorrendben legyenek fenn kiemelve. Melyik cikkek menjenek az ajánlóba. Az egész oldal összeszervezése, a folyamat kitalálása sokka több időt, energiát emészt fel.
Az, hog panels alapú az oldal, vagy más megoldás? Szinte mind1. De ha lehet, én az egyszerűbbet választom :)
UFF.
--
Szabó Dénes - Internode.hu - Munkára fogott weblapok