drupal.hu | A Drupal tartalomkezelő magyar honlapja

Ha valami összetettebb sminket dolgozol át az elképzelhető, hogy innen onnan behúz formázásokat. Használd a css utasítás végén a !important ez felül ír minden korábbi formázást tehát pl float: left !important; ebben az esetben az adott elemre mindenképp ez a CSS utasítás fog érvényesülni!

"Továbbá az egymás alatt elhelykedő NODE-ok (cikkek) egybefolynak, ezt hogyan tudnám CSS-ben formázni?"

Elemezd ki a sminket amin ténykedsz nézd meg, hogy az oldal mely részeiért a CSS-be milyen formázások felelnek. Ez sem ördöngös picit sem. Jó magam az Opera böngészőt preferálom ebben a böngészőben jobb egér klikkre előjön egy olyan menüpont, hogy "Elem vizsgálata" az egérkét ráviszed a kívánt elemre és már köpi is ki neked a CSS infókat.

Amúgy szeretik egyesek túllihegni ezt az egész CSS mizériát nekem a legnagyobb támaszom egy 1200 FT-ba kerülő CSS zsebkönyv (a Google mellet), tartalmazza az összes fontosabb formázási parancsot amúgy a "nyelv" tök logikus. Szóval én bátorítalak, hogy simán akár minimális tudással is ess neki egy egy CSS-nek mentés úgyis van ha más nem újra lehúzod a sminket. Tanulni meg csak abból fogsz ha élesben csinálod. A legjobb ha csinálsz egy terebélyes saját oldalt mint a mágnes úgy fogod behúzni a fontosabb infókat. Good luck!

honlapom http://dyra.eu/

Megnéztem egy korábbi D6-os oldalról küldött levelet, Gmailnél az "Eredeti megjelenítése" opcióval (ahol látszanak a metaadatok), amit én szintén az SMTP modullal küldettem ki, és ott van egy ilyen rész:
Received: from example.com
(most az example.com helyére nyilván az én egyik oldalam címét kell képzelni)
Nálad ez jelent gondot?
Csak mert korábban nálam is volt olyan para, hogy Spambe ment a levél, de akkor szerintem az volt inkább a probléma, hogy tartalmazott a levél olyan szövegeket, amitől tipikusan spam megjelölést kapnak ezek a levelek (volt az angol nyelvű oldalon egy nyereményjáték, aminél sorsolás is volt, és ha valaki nyert egy díjat, akkor arról küldtünk egy levelet, olyan tárggyal, ami azt is tartalmazta, hogy az illető megnyerte a sorsolást - na, gondolom ezekből a levelekből annyi van, mint a szemét, úgyhogy ez eleve spamnek minősült), mert más levelek meg hibátlanul kimentek: pl. azok, amiket a PrivateMsg modul küldött (hogy kaptál egy privát üzenetet XYZ-től), és az is az SMTP modullal ment ki, és nem került spambe.

A legtobb felhasznalo nem torli ki a kapcsolodo fajlokat a Drupal konyvtarabol, igy megoldas lehet a CHANGELOG.txt megnezese, altalaban a legelso bejegyzes az aktualis Drupal verzio kiadasi megjegyzese. Ezt osszevetve a drupal.org -on talalhato aktualis verzioszammal, el lehet jutni bizonyos kovetkeztetesekre.

Persze ez kozel sem szazszazalekos megoldas, de talan egy lepessel kozelebb visz.

Meg egy lepessel kozelebb vihet a modulok .info fajljanak ellenorzese. Ezekben (mar amelyik modul a drupal.org -rol van) szinten megtalalhato az illeto modul aktualis verzioszama, es szerintem a drupal.org biztosit valami api-szeruseget, amivel ez szinten lekerdezheto (vegulis a drush is igy mukodik).

Amiert en nem drush-t valasztanek erre a feladatra, az az, hogy egy oldal sokfele szempontbol lehet torott, es kozel sem biztos, hogy barmilyen drush parancs lefut az adott oldal gyokeren. Ezen felul a tapasztalatok azt mutatjak, hogy a drush kimenete varatlanul megvaltozhat, ezt parzolni szinten nem egyszeru, es hibakra ad lehetoseget.

Szoval ha csak a verzio ellenorzes a cel, en errefele indulnek. Persze, az is elmond valamit az illeto oldalrol, ha a drush mindenfele random hibakat dobal es errorral lep ki, de ehhez az is kell, hogy vilagos legyen a cel, amit el szeretnetek erni: azt szeretnetek tudni, hogy elavult-e az oldal, vagy azt, hogy kompletten rossz.

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Pár jogi szakemberrel beszélgetve az erősödött meg bennem, hogy maga a GDPR jó dolog. Elnagyolt kicsit és több része menet közben fog csiszolódni, de nem ez az első ilyen jogszabály a történelemben.
Üzemeltetői oldalról nyilván okoz pluszmunkát, de rendesen betartva (és betartatva) védi a felhasználók adatait, hiszen nem mindig egyértelmű, hogy kinek és milyen adata hova kerül, lásd pl. itt: (csak a technikai része miatt mutatom, hagyjuk a politikai részét)
https://444.hu/2017/07/27/az-adatvedelmi-hatosag-szerint-az-alvallalkozo...
https://444.hu/2017/05/15/meg-a-fovarosi-fougyesz-szerint-se-rendjen-val...

Szóval annyira azért nem kell rettegni a GDPR-től, de tény, hogy át kell gondolni az eddigi adatkezelést.

Ha valaki Debrecen közelében él, annak hasznos lehet ez az ingyenes rendezvény: https://www.facebook.com/events/1709671565790804/

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

Azért passzol ide, mert Drupallal (is) foglalkozóként nem vagyok hajlandó olyasmiért tartani a hátam, ami nem, vagy nem kizárólag az én hatásköröm és nincs teljeskörűen az ellenőrzésem alatt. Teszem azt, nyomatékosan felhívom az oldal üzemeltetőjének a figyelmét az infotörvény rá vonatkozó előírásaira, de a füle botját se mozdítja. Miért is érdekelné, hiszen épp' azzal indította a reggelt, hogy friss családi fotókat osztott meg a világgal a Facebook-on, az Instán, meg még vagy száz helyen. Ezért is írtam, hogy sem a honlapok üzemeltetőit, sem pedig a látogatókat nem fogja érdekelni ez a téma. Mivel a fordítós kolléga már írta, hogy nem tisztán webes szakmai kérdés az egész GDPR, ergo ha már bármit is írsz róla, az mindenképpen túl fog mutatni az itteni kereteken:-).

Kicsit benn ragadtatok a szakmai burokban. A való világ nem így működik.
Csak hogy egy kiváló írót idézzek, "Minden pofon mellé nem lehet csendőrt állítani." És az élet is ehhez igazodik. Vezess egy kört a városban és számold meg hányan tartanak be minden kresz előírást:-).

Majd pár év múlva meglátjuk hogy sikerült-e valamit átültetni a törvényből gyakorlatba. Lehet hogy a nagyobb szervezetek megoldják, de a web dandárját kitevő kismillió honlapocska tuti hogy nem, vagy nem hiánytalanul.

Mit teszünk fordíthatóvá, nem mindegy.

Fontos, hogy értsed hogyan működik a Drupal többnyelvűsítése, különben eszement kavar lesz nem csak az oldaladon, hanem a fejedben is.

A menü fordításánál a menüpontok szövegének fordítását tudod bekapcsolni.

Egy menüpont áll egy szövegből és egy url-ből. Menüpont fordítás akkor kell, ha az adott url fel van készítve arra, hogy többnyelvű tartalmat szolgáljon ki. Pl. a kapcsolat űrlap (contact modul) ilyen (nagyrészt :))
Ha bekapcsolod a menu translation-t akkor le tudod fordítani a menü szövegét.

Ha egy view page-t (nézet oldal, hívja így valaki?) akkor neked kell arról gondoskodni, hogy az aktuális nyelvi szűrőt betedd, vagyis felkészítsd arra a nézeted, hogy a kódból jövő szövegeken túl vannak benne tartalmi szövegek, amiket fordítani kell. Persze lesznek még benne konfigurációs szövegek is, azt meg megint máshol kell majd fordítani. :)

A te esetedben viszont az a helyzet, hogy van két tartalmad, két node-od, amik egymásra mutatnak, hisz egymás fordításai. A menübe viszont csak az egyikre mutató linket helyeztél el, hisz itt nem a szöveg, hanem az url is változik. Ezt a menü fordítással csak úgy tudod lefordítani, hogy az angol oldalon megjelenjen angolul a magyar tartalomra mutató link. Próbáld ki a menü fordításánál. :)

Fel kell tehát venned két menüpontot. Egyet a magyar "kapcsolati tartalomra", egyet az angol "contact node"-ra. Ha ezt ugyan abba a menübe teszed, akkor alapesetben meg fog jelenni mindkét menüpont.

Ahhoz, hogy mindig csak az a menüpont jelenjen meg ami megfelelő nyelvű tartalomra mutat, be kell kapcsolnod a Multilingual select modult az i18n csoportból.

A menü szerkesztésénél persze megjelenik mindkettő, és jól össze lehet kavarni.

Természetesen neki lehet menni az Entity translation-el is a dolognak, ami a field-ek tartalmait teszi fordíthatóvá, és akkor ugyan azon az útvonalon lesz elérhető magyarul és angolul is a node, és akkor a menüt kell majd fordítanod. Persze itt is csak is majdnem lesz minden jó, mert ugye az Entity translation pont az entity-t nem teszi fordíthatóvá, tehát azok az adatok, amik nem fieldek pl. title, nem válik fordíthatóvá. Persze megoldható, csak ahhoz trükközni kell. (le kell szedni a title-t és berakni egy field-et ami már fordítható)

És a legjobb, ha az Entity translaltion-t és a Content translation-t egyszerre használod, mert akkor biztos senki nem lesz már, aki megmondja, hogy miért nem fordul le a micsoda. :)

És akkor még csak a menükről és a node-okról beszéltünk, nem beszéltünk az útvonalakról, a kategóriákról, a hozzászólásokról, stb.

A legszebb az egészben, hogy minden kis rész fordítására külön stratégia kell, mert mindent lehet legalább háromféle módon lefordítani.

Palócz István
https://palocz.hu | https://tanarurkerem.hu