Laci85 képe

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.

0
0
DruTa képe

Kösz, megpróbálom így!

Még előtte a WYSIWYG-hoz felteszek egy editort, hátha akkor megy, bár nem akartam. Az fckeditort akartam, de a letöltésnél csak ckeditor volt, azt viszont nem támogatja az a verzió, ami nekem fent van, a 7-es, legalábbis ezt írja az admin felület, így kipróbálom a tinymce-t.

Egyébként ez annyira alap dolog, hogy akár a drupal core is tudhatná, engedélyezni egy be-kikapcsolással.

Valószínűleg azért nincs működő modul, mert aki ért a programozáshoz, pár perc alatt csinál ilyet, mások meg nem foglalkoznak azzal, ha egy böngészőfagyás miatt szegény felhasználók elvesztik a beírtakat.

---

Na, editorral sem megy. Töröltem ezt a modult, meg a WYSIWYG-et, editort.

Megkeresem, hol tudom jelezni, hogy ez az autosave modul nem a drupal.org-ra, hanem a szemétbe való.

Remélem a homokozós változat menni fog...

---

Igen. És nem.

Ment automatikusan, majd kipróbáltam, hogy a mentése után kilépek a node szerkesztéséből (amit korábban elmentettem már, mert ha egyszer sem volt a node elnevezve, akkor nem mentett, pedig lenne értelme, hogy egy ideiglenes néven mentse, mint a gmail a levél írásakor piszkozatot), és nem maradt meg amit írtam (szerkesztettem a node-ot manuális mentés nélkül), pedig kiírta felül, hogy mikor mentette utoljára.

Lehet, ezzel van baj?

" Storage place

- CTools object cache
- Munkamenet

Enable autoload of saved node "

Itt a CTools-os van kiválasztva csak.

1
0
aruna képe

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

3
0
eager képe

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.
0
0
eager képe

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

0
0
Sk8erPeter képe

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.

2
0
makgab képe

Sikerült működésre bírni a dolgot. Szépen muzsikál.

Hátha később másnak is kell, leírom hogyan működik. Célszerű VPS-re tenni, mivel sima tárhelyen nem nagyon lehet Media Szervert telepítetni, itt van egy kis segítség.

    Tehát:
  • JAVA install
  • ANT install
  • Subversion install
  • Red5 MediaServer install
  • Videowhisper media application install (Red5 szerverre):
  • * wget http://www.videowhisper.com/downloads/videowhisper_red5-4326.zip
    * unzip pl.: /opt/red5/dist/webapps
    * Ennek kell léteznie, pl.: /opt/red5/dist/webapps/videowhisper/WEB-INF

  • Videowhisper Drupal modul telepítése
  • Drupal-ban az rtmp szerver address beállítása: rtmp://red5_server_IP/videowhisper
  • A php.ini módosítása:
  • short_open_tag = On
    (error_reporting E_ALL & ~E_NOTICE)

    Megjegyzések:
  • Az "short_open_tag = On" nélkül nem megy a video streaming kép átküldése (üres kép látszódik a live video helyén), tehát fontos!
  • Nálam az admin/config menüben nem látszódik a Videowhisper szekció. De az admin/config/videowhisper/vls ...stb. url-ek működnek. Érdekes...

update:
A beágyazott channel nem igazán akar nálam megjelenni: "Visitors not allowed" üzenetet ír. Pedig admin-ként vagyok bent a Drupal-ban.

4
0
Mary Jane képe

Egyebirant nagy felreertes mert nem surgettem senkit, ugy gondolom a feladatot amit kaptam leirtam ertehtoen sot amit a kereses soran talatam azt is belinkeltem .hogy megerthetobb legyen.
Kesobb olvastam a multsteps formrol amirol ugy gondolom hogy akar az is egy fele vonal lehet, es meg video tutorialok is vannak hozza nem ugy mint par modul eseten kirakva hogy van screencast es kozben vagy halott a link vagy csak seo vegett a linket kovetve nem relevans tartalmat kapok. Latod itt kioktatsz engem a jotancsokkal viszont en arra kerlek hogy egy picit gondolkodjal ha mar osztotgatod a tancsokat, mert szerintem nem kell hogy autod legyen es kepebe legyel a gumicserevel kapcsolatban, de egy idopont kerdeshez ne kelljen mar diploma, mert ha egy fogorvoshoz is bejelentkezel reggel 10 orara, egyertelmu legalabbis szamomra hogy reggel 10 orara mar mas ne tudjon idopontot foglalni. Egyebirant a jotancsodat megfogadom, s az appointment calendart megnezem. Amugy pedig rengeteg modul letezik sot az osszehasonlito oldalt is megtalaltam ezt itt, mivel nem napi szinten kellett drupalal foglalkoznom igy a kozosseghez fordultam hogy kapjak nemi iranymutatast mint ahogy azt masok is teszik pl itt S a peldanal maradva szerintem semmivel sem fogalmaztam meg rosszabbul hogy az ne lehessen ertheto. Megegyszer koszonom hogy idot szantal ram.
Udv,Jane

0
0
Joee képe

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.

0
0
HF leon képe

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.

0
0