Nem tudom van-e kevésbé munkaigényes módszer.
a CSS-ben, de én felül szoktam írni mindent, amit kell:
#valami ul {} #valami ul li {} #valami ul li a {} #valami ul li a:hover {} #valami ul li ul li {} /* Ha többszintű a menü */ ...
Ha minden az utolsó vacakig felüldefiniálsz akkor ez megvalósul:
ehhez tartozó régióhoz a menü css formázásom független legyen
Mindig nézd a firebug-al hogy érvényesül-e az új szabályod, mert előfordulhat, hogy az eredeti menü szabálya valamiért specifikusabb, felülírja az új szabályodat. Ilyenkor ha specifikusabbá teszed a szabályt, akkor be tudsz "előzni".
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ezek szerint arra gondolsz,
Ezek szerint arra gondolsz, hogy ha a te saját modulodban van egy t('Submit'), akkor annak a fordítását találja meg a már meglévő fordítások között (gondolom a core .po-ban vagy x egyéb helyen van már rá fordítás, hogy 'Beküld'), és töltse is ki a te sablonodat a már ismert fordításokkal, hogy neked már csak azokat kelljen fordítani, amit máshonnan nem talált meg?
Ha igen, akkor bocs a fenti tájékozatlan hozzászólásért, ennek az opciónak a megléte fel sem tűnt. (Bár ott az a legalsó form-elem csekkbox annak tűnik.)
EDIT: Körbejártam a kérdést.
1. A php potx-cli.php --help
alapján én a cli implementációban ilyenre való opciót nem találtam.
2. Viszont az adminfelületen igen:
A lényeg, hogy ne a nyelv-független sablont válaszd, és kérd a "Fordításokkal együtt"-et.
- Ha a "magyar fordításhoz tartozó sablon"-t választod, de a "Fordításokkal együtt" checkboxot nem, akkor kapsz egy .pot kiterjesztésű file-t (a t=template, gondolom), amiben semmi nincs még lefordítva (viszont a "fejlécében" azért már előre ki van töltve, hogy magyar fordítás lesz ez).
- Ha a "magyar fordításhoz tartozó sablon"-t választod, és a "Fordításokkal együtt" checkboxot is bepipálod, akkor kapsz egy kész .po kiterjesztésű file-t, és ebben már ottvannak az ismert stringek fordításai, és csak azok hiányoznak belőle (csak azokat kell kitöltened benne), amikre nem talált már létező fordítást.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Vissza a kályhához: mi és hogy nem működik?
Persze azt is félreérthettem, hogy mit és hogy értesz kinyerés alatt, mert én fordított logikával, először elkészíttetném a .po file-t, és abban töltögetném ki a maradék fordítani valókat egy szövegszerkesztőben, majd úgy importálnám vissza.
Viszont vissza az eredeti kérdéshez: írod, hogy nem aktív linkek vannak az admin-oldalon.
A képeden benyilazott fieldseteket egy js normál esetben legördíti, és belül radio-gombokkal választhatsz fordítandó könyvtárat. Ezek szerint neked le sem nyílnak ezek? Gondolom, ha nem aktiválsz egy radio buttont sem ezeken belül, akkor nincs mit feldolgoznia?
(Nekem, ha a formon egyből a Kinyerésre kattintok (és előtte semmi másra), a Stark theme sablonját adja... (nem ismerem a Drupal formokat eléggé, hogy tudjam, hogy hogyan tesz bele default choice-t, vagy hogyan emlékezik korábbi választásokra).)
Szóval még mindig nem világos, hogy mi hogy nem működik nálad.
(Arra is gondoltam, hogy ha ezek a cuccok nem nyílnak le, ahogy kéne, akkor hátha az admin interface-ed törött el, mindenesetre egyszer megnézném a javascript konzolt ezen az oldalon, nem ír-e hibát)
(Vagy hogy Firebugban a problémás <fieldset>
-eknek a collapsible collapsed form-wrapper collapse-processed
classai mellett nincs-e valami további beszédes class-uk, amiből lehetne továbbgondolkodni.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Öröm!
Szívesen!
Tényleg fura, hogy mi bírálhatja fölül az email-beállításokat, hacsak nem került egy $conf['site_mail']
beállítás a settings.php
-be, vagy nem került felülírásra az admin/config/system/site-information
oldalon is látható e-mail-cím adatbázisszinten - de még ha így is történt volna, tudtommal a Webformnak a számára beállított From-címet kellene használnia. Szóval a probléma eredetét én sem teljesen értem, de amúgy sem volt haszontalan, hogy telepítetted az SMTP-modult (ami a PHPMailer osztályt használja, de a Swift Mailer modul is hasznos egyébként (ami nem meglepő módon a Swift Mailer osztályt használja)), mivel az alapértelmezett mail() függvénynek amúgy is megvannak a maga korlátai.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Vírusokhoz
Azok a felhasználók biztosan nem valósak és nagyon valószínű, hogy a vírushoz van közük. Én eltávolítanám ezeket a felhasználókat. Az könnyen megnézhető, hogy a tevékenységük milyen IP címre mutat. Biztosan külföldire. A vírust ugyan kiirtottad, de a víruskereső a random létrehozott felhasználókat nem tudja vírusnak ítélni. Ezek a felhasználók létrehozhattak valamilyen tartalmat, ami külső hivatkozásokra mutatnak. Ezek a hivatkozások jobb esetben már nem léteznek (404-oldal) és ez a te szerencséd, különben újra megkapnád a vírusokat. A felhasználóidat vizsgáld át és a nem kívánatosakat vagy gyanúsakat töröld a létrehozott tartalmaikkal együtt! Egy jó ideig még utána is kísérd figyelemmel a felhasználóid által indított sikeres vagy sikertelen külső kéréseket! Egyáltalán szükséged van ezek engedélyezésére?
A rendszered újraépítése mit is takar konkrétan? Teljen lecserélted a rendszer állományait újakra vagy csak lefuttattál egy víruskeresést és utána a maradtakat felülírtad egy új verzióval? Van olyan, hogy a víruskereső nem talál meg minden kódot. Általában nem. Szemmel kell belenézni a rendszerfájlokba és vírusszekvenciák után kutatni és találat esetén azt kézzel eltávolítani. Főleg a php fájlokat kell vizsgálni. Ahol túl sok gyanús és ismeretlen karakterhalmazt találsz az nagy valószínűséggel vírus, de ha nem tudod magad eldönteni akkor mutasd meg valakinek aki fel tudja ismerni. Némely szekvenciagyanús kódra az interneten is rá lehet keresni, mert biztosan nem te vagy az egyedüli aki kapott belőle és ők már feltölthették. Ha találtál egy szekvenciát akkor arra vagy annak részletére már futtathatsz keresést a rendszerben.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Talán üzleti döntés
Tudom fura lehet egy ingyenes nyílt projektnél üzletről beszélni, de a váltásnak alapvetően üzleti okai lehetnek.
A Drupal túlnőtte magát és akárhogy is nézzük sajnos a pénz a lényeg. Sok komoly cég alapoz a Drupal-ra. A rendszer pedig feléjük mozdult el. A D8 nem tökéletes az első igazán új rendszer a D9-lesz, amely teljes mértékben demonstrálja majd azt a sok munkát, amit a közösség tagjai belefektettek a D8-ba.
A közösség egy része a váltás idején nem értett ezzel az irányvonallal egyet és a klasszikus utat választotta. Így született meg a Backdrop.
Szerintem egyik rendszerrel sincs baj, sőt jónak tartom a két irányvonal meglétét. A Backdrop-ra könnyen átalakíthatók a régi D7 modulok. A Drupal9 pedig elhozza majd a D8 újdonságait az elavult dolgoktól mentesen. Így sebességben, talán a Drupal9 lesz releváns. A modulok, már keményebb tészta. Míg szinte bárki képes egy átlagos D7 modult Backdrop modullá alakítani, addig a D7 modulok Drupal8/9-re történő átalakítása, már nem ilyen egyszerű. Nem azt mondom, hogy nagyon nehéz, de merőben új szemléletet követel, ami megnehezíti a kezdők munkáját. Abban a szegmensben, ahova a Drupal9 pozicionálja magát ez nem olyan nagy gond.
Szóval várjuk ki, hova vezet a Drupal8 és milyen lesz a 9.
Szerencsére eközben a Backdrop is rendelkezésre áll a mérsékeltebb erőforrásokkal rendelkezők számára. Én sem örültem azoknak a hátrányoknak, amitől a Drupal8 szenved. Viszont van benne fantázia, egyáltalán nem tűnik rossznak az elgondolás. Ezért vagyok kíváncsi, hogy mit hoz a 9 -ami nincs is, már olyan messze.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nálam volt gond
Hát nekem volt probléma és ez a módszer oldotta meg. Lehet régebbi verzióm volt, bár mindent megfrissítettem a telepítés után, de a Superfish nem frissített.
Ha nem lett volna bajom vele szerinted töltöttem volna hosszú órákat kereséssel és variálgatással?
Nálam vásárolt smink van, az ingyenesek között nem találtam számomra megfelelőt egyedi megszerkeszétsére meg nincs szabad kapacitásom a munkáim mellett, illetve nem is vagyok jártas ilyen területen, így kész megoldást választottam.
Egyéb tartalmi részekben viszont vannak a fordítással létrehozott duplikációk, amikor a magyar és angol nézetben is mindkét nyelv látszik egyszerre, valószínűleg az egyedi smink sajátossága lehet, amit még meg kell oldanom. Rengeteg előre megszerkesztett tartalomtípus és modul van benne, ezek mindegyike angol, szóval van még feladatom bőven.
Ha nem végzek Superfish frissítést az nagy baj? Gondoltam, hogy nem elegáns megoldás beleírogatni a modulba, de már órákat töltöttem el azzal, hogy megoldjam ezt a problémát és ilyen megoldást találtam.
Patch írás és annak publikálása a megfelelő helyen nem tudom hogyan működik, nem vagyok Drupal szakértő, sem web programozó, más területen dolgozom, az hogy ilyeneket csináljak csupán a kényszer visz rá. Ha valaki elmondja hogy kell annak rendje és módja szerint egy ilyet megoldani, akkor úgy csinálom, de a legtöbb hasonló probléma megoldását több külföldi fórumon is olvastam és nem egy helyen ezt a megoldást javasolták, ezért is csináltam így, persze a biztonsági mentés megvan, ha gond van vissza tudom állítani.