szantog képe

Mondtam én:

I+thought+this+article+might+interest+you.

"
Tegnap még cirógatott a szél,
magával vitt a szenvedély,
napsugár ujjai alatt
szememben örömkönny fakadt.

Ma még bűntelenül állok,
holnapra rám száll az átok
és keserű lesz az édes,
már a hűséges is vétkes!

Csukott ablak a világra,
hervad a remény virága,
és szívemben örökre már
az öröm bús emléke jár.

2010. augusztus 16.
Bp.

"

You+can+read+the+full+article+here: http://www.hajdumaria.hu/busemlek

----------------------

(Modulfájlokban történő bármilyen nyúlkapiszka, főleg nem utf-8ban mentve) = 'hack'

Az a kis t() betűs függvény kb annyit jelent, hogy a benne lévő szöveg a drupal felületén keresztül fordítható.
Szóval admin/build/translate/overview beírod a stringet, és lefordítod. Na ez a honosítás, nem a modulban lévő angol szöveg átírása, mert az modulelromlással és ejbejnyével járó hack.

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.

Impresso képe

Nohát, végre kicsit tudtam foglalkozni ezzel a dologgal, köszönöm a segítségeket.

Sikerült Feeds-el is importálni, nagy segítségre volt ez az oldal is még, ahol videoval is szemléltetve van a működés: http://developmentseed.org/blog/2009/dec/15/importing-and-aggregating-stuff-feeds

Lehet szerkeszteni, hogy milyen adatokat importáljon a modul, pl ki lehet hagyni a létrehozás dátumát és pl csak name, e-mail mezőket is be lehet állítani.

Menjünk tovább: ugyebár egy tömeges user importálásnál, jó hogyha rögtön egy akármilyen jelszót is beállítunk (akármilyen banális, pl kezdőszó + egyesével emelkedő szám) ami jobb a semminél, később úgyis megváltoztathatja aki akarja.
Viszont ennek beállítását nem láttam választható opcióként, kérdés hát, hogy ez megoldható-e?

Az az eset sem túl szívderító, hogy mondjuk egy 1500-as user listánál nincs senkinek jelszó beállítva, arról nem is beszélve hogy esetleg egyenként állítgassuk be az Adminisztráció/peoples felületen.

Esetleg ezt az egy pass mezőt töltsük fel közvetlen sql update-el?

0
0
csy képe

EditH

Kérlek, könyörgöm, ne adj olyan tanácsokat, amik csak rontanak a teljesítményen. Ha te ezt elhiszed, lelked rajta, de másnak ne mondj olyanokat, amitől nemhogy a plafon szakad, hanem az emelet is.
"(~500.000 - 1.000.000 rekord) search* táblák lehalnak InnoDB-vel."
Kérek egy my.cnf-et, mert ebben az esetben
a-kevés cpu
b-kevés ram
c-nem megfelelő raid/hdd
d-hozzánemértés
játszik.
log db: 2millió rekord, gond nelkül kereshető, törölhető, beszúrható, majdnem realtime (0,01-2sec).
Az adatbázisok egyik kritikus eleme az elérés, ezt egyszerűen és olcsón lehet tuningolni: RAM. Ha nem értesz/ért hozzá az aki csinalja, pont ramot nem fog neki adni, mert azt látja, hogy a *** mysql megint megette a memóriát.

és ismétlem magamat:
Felhő hozzászólása 3 éves!!! Nem vehető referenciának 2011-ben.

0
-1
chx képe

Az InnoDB valamivel több memóriát eszik tehát az biztos hogy ha X memóriakeretből gazdálkodsz akkor N rekordra már kifut a memóriából (és akkor swappel, el sem indul vagy hasonló) míg a MyiSAM még eldöcög. A megoldás erre nem a MyISAM hanem több memória.

A MyISAM, mint csy helyesen írja (legalábbis a tényt helyesen, a stílusa más tészta) tábla szintű zárolást használ az InnoDB pedig sor szintűt. Tehát, egyszerre egy folyamat fog egy MyISAM táblába írni (más kérdés hogy mennyi ideig tart egy írás művelet -- hacsak nem írsz nagyon sokat egyszerre ebből nem lesz gondod). A MyISAM azért népszerű mert régi MySQL-eken az InnoDB finoman szólva sem volt egy tempós darab és bár kb. öt éve ez már nem gond, ez a legenda máig megmaradt. A másik, míg a MyISAM konfigurálása majdnem mechanikus, az InnoDB-t egyáltalán nem triviális jól beállítani. De ha egyszer megvan, akkor bizony gyorsabb http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB

1
0
Balogh Zoltán képe

Modul nevét általában nem fordítjuk le, hanem em tag-ek között, vagyis döntve meghagyjuk angolul. Ennek sok oka van, például az, hogy ha valaki rá szeretne keresni a modulra, hogy az mégis micsoda, akkor a lefordított névvel nem sokra megy. Tehát mondatban, folyó szövegben „... <em>modulneve</em> modul ...”.

Mégis vegyesen fordul ez elő, tehát van olyan, ahol célszerű lefordítani. Ennek tipikus esete, amikor az angol modulnév megjelenik önállóan a menüben, tehát oldal címeként is. Pl Weather. Ez megjelenik az UI-n, tehát muszáj lefordítani, de ha mondatban van, akkor nem Időjárás modul, hanem <em>Weather</em> modul

Amúgy nagyon jók a fordítások, csak apróságok vannak, mint például olyan, hogy a magyar nyelvben a „Beágyazott Médiamező” összetételben sem indokolja semmi a második szó nagybetűvel írását.

A 7-es változatban a már lefordítottak természetesen megmaradnak, de például a jogosultságok nagybetűsödtek, így azok biztosan változnak (Meg nehezebb lesz kiszúrni, hogy az egy jogosultság)

0
0
vajdasági képe

Bocs hogy beleavatkozk, de szerintem nem jo iranyba vezeted.

Tekintettel hogy hotelokrol van szo, vagyis tobbesszamban, es o is irta hogy sok ilyen tartalma lesz. Sot megkockaztatom azt is feltetelezni hogy esetleg majd a hotelok sajat meguk viszik be az adatokat, de ha o maga is lessz az egyeduli adatbavivo, akkor is sokkal egyszerubb dolga lessz ha nem egy FCK vagy hasonlo szerkesztoben illesztgeti a kepeket meg a tobbit (vigyazva hogy egy uniform (minden hotelnal hasonlo)) kinezetet kapjon, (persze ha nem az a cel hogy mind kulonbozoen nezen ki egymastol), hanem egy formot tolt ki. A kepeket egyszeruen kivalasztja es feltolti, csak a 2 szovegmezonel kell neki egy kicsit (ha akar) buveszkeni a szoveg kinezetevel.

Szerintem ha a kinezet elore megavn es csak egy formot tolt ki az sokkal egyszerubb es hatekonyabb lessz a sok adat bevitelenel.

De maskulonben ha visszaolvasol akkor a 2011. április 7. 12.41 uzenetemben eziranyban mar erdeklodtem tole es a valaszabol szerintem egyertelmuen kiszurheto hogy nem az altalad javasolt megoldas lessz neki a jo.

0
0
Ilusha képe

- Nézem Boobaa ötletét, ha jól sejtem, ez egy valami olyan megoldás, hogy egy másik szerveren csücsül a font, és egy a honlapodba szúrt java script fájl onnan a betűtípust a látogató böngészőjébe rendezi.

De ha ilyen létezik, akkor megoldható az is valahogy, hogy a font a te szervereden csücsüljön.

- Ezenkívül még megoldható úgy, hogy nem szöveget írogatsz, hanem a képet, ami így megjelenik, azt képfájlként csempészed be valahogyan a sminkedbe.

A Drupalnak és az Artisteernek ehhez semmi köze, mert a Drupal alá tett smink kódjában hiába van oda írva az, hogy milyen betűtípust kellene használnia a böngészőnek a megjelenítéshez, ha a látogató gépére az a betűtípus nincs feltelepítve, akkor nyilván hogy abban nem tudja megjeleníteni.

- vagy a látogatók kénytelenek lesznek feltelepíteni a saját gépükre ezt a betűtípust, de ez elég beteg ötlet, mivel minden látogatót nem lehet megkérni ilyesmire.
Az Office-nak ennek csak annyi köze, hogy a szóban forgó betűtípust nyilván ez pakolja fel. Egyébként a Windows/Fonts mappában szoktak lenni, ttf kiterjesztéssel.

0
0
tzotyu képe

Sziasztok!
Akadt egy kis gondom a telepítéssel, leírnám, hogy mit csináltam:

- Letöltöttem innen az FCKeditort (6.x-2.1 verzió) és feltöltöttem a modules könyvtáramba. (Ezt töltöttem le: http://ftp.drupal.org/files/projects/fckeditor-6.x-2.1.zip) - tehát van egy modules/fckeditor könyvtáram
- A moduloknál bekapcsoltam.
- Ez után az modules/fckeditor/fckeditor mappába bemásoltam a legújabb frissítés állományait, így eltűnt a hibaüzenetem is, miszernte hiányzott az fckconfig.js fájl.
- Mindezek után beállítgattam a jogosultságokat, de sajnos nem látszik a szerkesztő. (Ha állítok az exlude/include opción, akkor a meglevő tartalom szövege helyett mutatja a kész oldalt.)
Próbáltam a beviteli formáknál variálni valamit, de ott semmit nem találtam, ami az FCKeditorra utal.

Mit csináltam rosszul, esetleg telepítenem kellene még valamit mellé, hogy használni tudjam?
Hibaüzenetet már nem ír ki, tehát működnie kéne... :S

Köszönöm!

0
0
Luigi.hu képe

Igen, ez jól hangzik, de van-e erről tapasztalatod, vagy láttál-e ilyet itthon, esetleg ismersz vkit, aki ebben szakértő?

Az a pár ezer regisztrált user Magyarországon azért nem olyan kevés, bár a több milliós itthoni tag sem lenne rossz. :-)

Azért az 5-10 ezer usert kiszolgáló nem fut el tetszőleges vason, nem szeretnénk túl kis szervert venni vagy túllőni a célon és beruházni vmibe, amire nincs szükség.

Van itt erről egy másik cikk: http://www.johnandcailin.com/blog/john/scaling-drupal-open-source-infrastructure-high-traffic-drupal-sites
Jó lenne tudni, hogy milyen jellemzők alapján választják ki az egyes konfigurációkat.

Nagyon kíváncsi vagyok még arra, hogy az ilyen nagyobb terhelhetőségű oldalakhoz milyen Drupal "rendszert" használnak, most hirtelen a Pressflow-t találtam: http://fourkitchens.com/pressflow-makes-drupal-scale de lehet vannak más "rendszerek" is ilyen feladatra.

Érdekelne az is, hogy milyen modulokat érdemes felhasználni/kerülni egy ilyen oldal elkészítése során, vagy lehet, hogy ott már saját, oldalspecifikus modulokat fejlesztenek?

1
0
szantog képe

Ez így most már ok.

"Ezért gondoltam, hogy ha valami két különböző helyen változik az nem túl jó."
Igen. Illetve majdnem. Esetedben ez így lesz pontos:
Ha két különböző helyen tároljuk ugyanazt az nem túl jó.

Szóval ha az adott rekordokat szerkeszteni akarod drupalból, akkor a webform lesz a gereblye ez esetben ugyanis felesleges a drupalban tárolni az adatokat, főleg nem inkonzisztens módon.

Nem tudom, van-e olyan modul, amivel direkt lehet másik db adatait szerkesztni, de én kb annyit csinálnék, hogy egy saját menüelemet (hook_menu()) biztosítanék egy formmal, amin a szerkesztést lehet elvégezni. Gondolom a másik db rekordjainak van valami egyedi azonosítója, mondjuk id, és akkor a masikdb/%id/edit útvonalra kell egy form, aminek a default adatai a frissiben kiolvasott másik db mezői, submitkor pedig frissíteni a másik dbt. Ehhez még az eddig emlegetetteken kívül a Form api beható tanulmányozása szükséges.

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