nekem is gondom van a magyarosítással :(
Több sikertelen (memoria hiba a modulok telepítése közben) webes használta után a localhostra telepítettem (volna), mert ugye csak jobb az, ha van 4 Gb ram a gépben és nem 32mb hanem 128mb a php memória limit... De már a telepítésnél megbukott a nyelvi telepítővel, idő túl lépéssel. A max_execution_time-t (alapban 30 sec) átállítottam 600-ra, majd 1200-ra. Ugyan arányaiban többet rakott fel a magyarításból, de a hibák megvoltak továbbra is. És itt hagytam abba... Próbáltam a telepítésnél is a bemásolt nyelvi file-t és úgy is , hogy angolul feltettem, és hozzá a nyelvi frissítő modult, és azon keresztüli nyelv telepítését, a hiba mindkettőnél meg van. A webes telepítésnél ezt gond nélkül végrehajtotta (2-3 sec), de a localhost-on elvérzett. Win7 X64 ultimate Wamp server 2.2a-x64 friss telepítésű, alap beállításokkal. Továbbá localhost-hoz képest elképesztően lassú az egyéb oldalmegjelenítésekben is. Biztos, hogy csak beállítás kérdése, de mindenhol csak találgatások vannak. Nem találtam olyan megoldást, ami mondjuk a wamp server beállításait ecsetelné, vagy egyéb beállításokat, ha az alap beállítások nem felelnek meg a Drupal-nak, esetleg az adatbázisét... Joomla telepítéskor felhívják a figyelmet, hogy mit mire kell beállítani. Itt nem találtam rá utalást. Továbbá a modulok, sminkek a Drupal oldalán számomra átláthatatlanok, vagy legalábbis ha van benne rendszer, túl van bonyolítva a Joomla, vagy a WP hasonló témájú oldalaihoz képest. Pedig már 2 napja próbálok rájönni, hogy tudnám életre kelteni a localhost-on a dolgot, mert tetszik és kipróbálnám, de egyszerűen nem tudom elérni 2 nap után sem hibátlanul azt amit a fenti 2 CMS-ben pár perc alatt megoldottam.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
részben működik, részben nem
A helyzet a következő. Az alap dolgoknál, modulok címsorainál, normál oldalaknál, blogbejegyzéseknél működnek a fordítások. A menünél volt probléma, illetve most a slider fordításával küzdök már tegnap este óta. A sliderem tartalmaz egy képet, illetve a kép alatt két sor szöveg jelenik meg, ami lehet szlogen, vagy bármi. Ezt én át is írtam szépen, viszont fordítás után az adott slide-ból kettő lesz és egymás után jelenik meg az angol és magyar verzió is.
Bartik sminknél is kipróbáltam, a szitu ott is ez.
Php kóddal már megint sikerült eredményt elérni, de ez nem túl szabályos már csak azért sem, mert adott slide-ra kattintva betölt a hozzá tartozó oldal, viszont a nyelvválasztás nem működik, mivel maga a slide tartalma csak egy nyelven lett létrehozva, igaz az tartalmazza mind a két nyelven a megfelelő tartalmat, de van még benne egy php kód is, ami a hu és en prefix alapján csak egyiket, vagy csak másikat mutatja meg. Gyakorlatilag működik is a fordítás, meg nem is.
Találtam olyan verziót is, hogy js fájlokba kell átírkálni ezt-azt, de azt inkább még nem piszkáltam meg.
Fel van rakva egy halom modul, ami a fordításokért felel és ilyen buhera módszerekhez kell folyamodni hogy működjön is valami? Azért ez kicsit gáz. Elismerem, hogy nem vagyok profi ezen a téren, de pont azért választottam komplett CMS rendszert, hogy ne kelljen a kódok szerkesztésével vacakolni, mint anno mikor csak html szinten szerkesztettem a weblapomat. Nem hiszem el, hogy nincs erre normális megoldás.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ezt felejtsd el!
Bocs, de most kivételesen kellett nyomnom egy -1-et a hozzászólásodra, mert core-fájlokat NEM módosítunk!
Ez nem megoldás, amit írtál, sőt, kifejezetten rossz módszer. Nem tudom, hol láttad ezt a tanácsot, de ezt felejtsd el.
A Drupal által használt
$temp_name = drupal_tempnam('temporary://', 'file');
sorral semmi probléma nincsen, ez úgy jó, ahogy van. Ne is akard ezt bántani.
Az a megoldás, amit írtam, anélkül, hogy hozzányúlnál a core bármelyik fájljához. Gyorsan tedd vissza az eredeti kódot, és többet ne tákolj bele közvetlenül a core-ba. :) Hidd el, az a sok jó fejlesztő nem véletlenül dolgozott annyit rajta.
A lényeg, ami nálad probléma volt: nem volt beállítva nálad olyan temporary-könyvtár (ideiglenes fájlok létrehozására, tárolására szolgáló könyvtár), ami írható lett volna. Létre kell hozni egy ilyet a megfelelő jogosultságokkal, beállítani az admin/config/media/file-system oldalon, és kész.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A mod_rewrite modul engedélyezése
Igen a mod_rewrite modul engedélyezése, az nem volt meg.
Röviden tehát:
sudo ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load
sudo gedit /etc/apache2/sites-available/default
A /var/www/ -re vonatkozó Directory részben
„
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
”
az
AllowOverride None
sort
AllowOverride all
sorra cseréltem.
Aztán:
sudo /etc/init.d/apache2 restart
A két telepítés közti különbség szerintem a következő volt:
A kattintgadós telepítésnél (d7) nem volt beállítva a rövid URL-ek használata, hiszen még az ellenőrző teszt is azt mutatta, hogy nem lehetséges. A mode_rewrite modul engedélyezése után a teszt sikerült, és tudtam engedélyezni a rövid URL-eket.
A Drush által telepített változatnál (d7d) viszont, (azt nem tudom hogyan) valószínűlega Drush engedélyezte ezt, viszont használni nem lehetett. Ezt abból láttam, hogy a fenti engedélyezési művelet után már be tudtam lépni adminként, majd a rövid URL beállításnál nem a teszt elvégzése gomb jelent meg, hanem rögtön a Enable clean URLs feliratot láttam, előtte a kipipált négyzettel.
Szóval a Drush ezt eleve engedélyezi telpítéskor és mindenki intézze úgy, hogy működjön is.
Péter kérdése a clean_url lekérdezéséről jól jött, mert elsőre nagyon nem értettem az eredményt. A fenti hipotézisemet viszont igazolja.
Mindenkinek köszönöm a segítséget.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hát én ebben semmi nehézséget nem látok
simán felveszel egy entity reference mezőt amivel aztán a user meg tudja adni hogy adott nodenál melyik másik nodeot akarja megjeleníteni a "blokkba" és erre kell egy nézet aztán viszont látásra.
azt is el tudom képzelni, hogy ezek a "tartalmak" amiket a blokkba lehet kérni, valójában termek egy taxonómia szótárban. amikor beküldök egy node, csak berakom abba a taxoba amelyiknek a 'leírását' vagy akármilyét meg szintén egy nézettel kiteszem a node mellé.
nálunk például van egy 'spotlight' nevű feature, ami nagyjából ez csak fordítva, egy ilyen "banner rendszer" szerűség. nem a nodeba adom meg, hogy melyik banner jelenjen meg, hanem a bannerba adom meg, hogy hol akarom látni. a 'spotlight' tartalom típusban van egy 'display at' entity reference mező, ahol page, article, event, egyéb típusú nodeokra lehet hivatkozni, itt lehet megadni hogy adott "banner" hol jelenjen meg. erre van egy nézet, ami contextual filterként használja ezt a mezőt és kész is, ha a node/42 oldalon állok, egy blokkban megjelenik az a "banner" amelyik a negyvenkettes nodera hivatkozik a 'display at' mezőben. persze lehet cifrázni, hogy a display at mellet van még esetleg egy 'position' mező is, top, bottom, left, right, ilyen értékekkel, és akkor nem csak egy nézet van, hanem ahány position, annyi nézet (illetve csak egy nézet, az van újrahasznosítva page managerben a négy külön pozícióba) és akkor a user mikor beküld egy új "bannert" megadja hogy node/42 meg node/69 oldalakon akarja, 'left' pozícióba. slusz. az egészhez tartozik egy "admin" felület ami listázza az összes spotlight -ot meg exposed filterekkel lehet közöttük keresni és ámen. tökre szeretik.
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nyugodtan vesd fel a kérdésed itt.
Leveledből arra tippelek, hogy nem azonos a linkek data-lightbox tulajdonsága.
Egy lehetséges megoldás:
Vedd fel a views-ba rejtett mezőként a Content: Path mezőt. (magyar drupal-nál persze magyar neve van). Ügyelj rá, hogy a Content: Image mező elé kerüljön a listában.
A Content: Image mezőnél válaszd a Rewrite results lehetőséget és pipáld ki a jelölőnégyzetet. Majd az alatta lévő szövegdobozba írd be például ezt:
<a href="[path]" data-lightbox="roadtrip">[field_image]</a>
Egy mező eredményének felülírásánál szabadon használhatod az adott mezőt és az azt megelőző mezőket. Természetesen a fenti egy egyszerű példa. Olyan linket, vagy tartalmat írsz, amilyet csak szeretnél :).
A képmező neve persze más is lehet, ha nem a már alapértelmezetten létrehozott képmezőt használtad, hanem újat hoztál létre. Akkor nyilván használd annak a nevét.
Nem tudom, hogy az NG Lightbox modul pontosan, hogy módosítja a beállításokat a sima Lightbox-hoz képest. Lehet, hogy a lapozást ott másként kell beállítani.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
:active
Az ~:active egy úgynevezett pseudo-class (nem tudom, hogy mondjuk magyarul), a ~:link, a ~:visited és a ~:hover rokona. Ezzel tudod meghatározni, hogy a klikkelés pillanatában hogyan nézzen ki a link.
Ami neked kell, az egy sima class selector, amit a Drupal tesz rá a linkre akkor, ha a link célja és az aktuális oldal címe megegyezik. Ha megnézed a forrásodat, megtalálod:
<div id="primary"><a href="/contact" title="" class="active">Kapcsolat</a></div>
Erre a CSS stílus:
a.active { color: #ffcc00; }
Tehánt ~:active és ~.active nem ugyanaz. Az előbbi egy állapotjelző, a második egy közönséges CSS osztály.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ez egy megjelenítési probléma
Egyébként nem hiszem, hogy ha valaki olyan oldalt csinál, ahol ez fontos, azt ne érdekelné.
Ha olyan oldalt csinálsz, ahol ez fontos, akkor ne csak a linket rejtsd el, hanem tedd elérhetetlenné a fájlt. Amit te itt követelsz, az annak a megfelelője, hogy a lakáskulcsot a lábtörlő alá rejthesd. Ha fontos a lakásodban lévő értékek biztonsága (= a fájlok hozzáférésének korlátozása), akkor erre állíts be egy komolyabb megoldást.
Megkockáztatom, hogy lehet, hogy akkor nem is a Drupal a megfelelő megoldás a feladatra. Ez egy webes tartalomkezelő, és lehet, hogy neked inkább egy dokumentumkezelő kellene (van hozzá több integrációs lehetőség).
Egyébként én is jobbnak találnám, ha az rss.xml nem tenné ki automatikusan a linket. Ahogy alább is írták, nyugodtan beszállhatsz a fejlesztésbe (pl. átveheted az elhagyott modul karbantartását, és kedvedre továbbfejlesztheted), vagy akár jelentheted a biztonsági csoportnak is a problémát. Bár szerintem tőlük is ugyanezt a választ fogod kapni: ez igazából nem biztonsági hanem egy megjelenítési probléma. A biztonság ott kezdődik, hogy privát fájlkezelést használsz, és felteszel egy fájl jogosultság kezelési megoldást.
Ha tényleg csak a lábtörlő alá akarod rejteni a kulcsot, akkor egy saját kis modulból hook_menu_alter()-rel letilthatod az rss.xml elérését és készíthetsz egy saját RSS csatornát. Ha egyébként is fent van a Views, akkor azzal még egyszerűbb a feladat, kattintós felületen megoldható.
Sulineten is
Abonyi-Tóth Andor volt olyan kedves, és írt egy összefoglalót az előadásokról a Sulinet oktatási részének informatika rovatába.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
szerintem nem kell ennyit
szerintem nem kell ennyit okoskodni; ezért most én teszem ugyanazt :) Tény, hogy a web nyitott és minden adat másolható, de ez nem minden esetben jó.
Luigi elmondta, hogy van pár év tapasztalata e téren és rá lehet bízni a döntést.
@Luigi: én megpróbálok a kérdésedre válaszolni.
Ugye a PDF, kép, flash jöhet szóba. Flash-ben le lehet tiltani a szövegkijelölést, a sifr projekt pedig dinamikusan létrehozza a szövegedet.
http://drupal.org/project/render#sifr-v2
Ami gond lehet
1. Írtad hogy tábálázatot szeretnél, nem tudom ezzel hogyan bírkózna meg
2. Valószínüleg alapból kijelölhető a szöveg, és ha nincs tiltási opció a beállítások között, meg kell majd buherálni kicsit a flash részét.
Persze ez is visszafejthető és kilopható a szöveg.
Huncutságnak annyit még megtehetsz hogy egy olyan beágyazott fontot használsz amiben fel vannak cserélve a betűk, és php-ben ugyanúgy felcseréled a bemenetet. A végeredmény értelmes szöveg lesz, kimásolva pedig zagyvaság. (pl. A helyett B-t írsz, de a font B-je A betűnek néz ki)
de ugye ott az OCR, és az ellen nem véd ... viszont lehetnek olyan karakterkészletek amiket a szem még felismer, az OCR pedig nagyon hibásan (amíg meg nem tanulja). Szóval ne Arial-t meg Vardana-t használj.
Minden biztonsági védelem kijátszható, a lényeg hogy többe kerüljön a kijátszása mint amennyit az információ megér. Talán ezek után már nem fognak a visszafejtéssel fáradozni. Kérdés, hogy neked megér-e ennyi munkát :P