Sk8erPeter képe

Hm, hát ha alapból UTF-8 volt BOM nélkül, akkor az úgy jó, az a helyes (NetBeans is ezt hozza létre alapból).
Egyébként engem meg szokott lepni, hogy a Notepad++ szerint legalábbis alapból ANSI a kódolása a Drupal core fájloknak, hogy ez vajon miért van.
Na mindegy, hogy a konkrét témára térjek, Notepad++-ban a sima karakterkódolások közti "átkapcsolások" helyett érdemes inkább a konvertálásra menni (alatta van párral), hogy ne okozzon gondot.
Pl. ha egy ékezetes karaktereket tartalmazó UTF-8 szöveget "átkapcsolsz" csak simán - konvertálás helyett - ANSI-ra, akkor elég randák lesznek az ékezetes karakterek.

"lehetséges, hogy alapból valami rossz volt a modulomban ami miatt nem tetszett neki a kérdőjel"
Mármint itt gondolom a kötőjelre gondoltál.
A D6-ról D7-re konvertálással kapcsolatos kérdéseidet esetleg feltehetnéd külön szálban, addig is, hátha ennek hasznát veszed:
http://drupal.hu/comment/63205#comment-63205

1
0
charlie_hun képe

Felhívnám a figyelmedet azon apróságra, hogy egy védjegy csak bizonyos kategóriákon belül add védettséget, a drupal mint védjegy csak az alábbi kategóriákban létezik:

  • 9 Adatfeldolgozási berendezések és számítógépek;hordozók szoftverekhez, melyek lehetővé teszik információk (például szöveg, kép és hang) elhelyezését, kezelését és terjesztését elektronikus úton (interneten vagy intranet hálózatokon).
  • 35 Reklámozás; kereskedelmi ügyletek; kereskedelmi adminisztráció; irodai munkák.
  • 37 Számítógépek telepítése, gondozása.
  • 38 Telekommunikációk;szöveg, kép és hang továbbítására irányuló telekommunikációs szolgáltatások az interneten keresztül.
  • 41 Oktatás (és nevelés); szakmai képzés; szórakoztatás; sport és kulturális tevékenység;tankönyvek publikálása;szemináriumok szervezése.
  • 42 Tudományos és műszaki szolgáltatások, valamint az idetartozó tervezői és kutatói tevékenység ; ipari elemző és kutató szolgáltatások;szoftverek tervezése, fejlesztése, telepítése, frissítése és karbantartása;számítógépek tervezése, fejlesztése és felügyelete.

Viszont a védjegy csak 2009-ben lett bejelentve, így előtte akármire lehetett volna használni (és ez esetben aki már elkezdte korábban használni, jogosan megtámadhatná a védjegy lajtstromozását)

0
0
Sk8erPeter képe

Feltettem a kérdést Drupal Answers-ön is, jelenleg két tipp érkezett:

Utóbbi tűnik talán a járhatóbb útnak, mert az a gondom, hogy ha utólag kell hozzákapcsolni a galériát, akkor külön-külön kell létrehozni a két tartalmat, külön felületen, és ez a feltöltő felhasználónak rendkívül kényelmetlen.

Viszont még mindig nem látom át, hogyan tudom az adott content type-on belül jól kategorizálni a képeket, mert OK, ha utóbbival létrehozok egy komplett galériát, akkor attól még csak egy külön galériám lesz...
Bármilyen ötlet jól jönne, köszönöm.

0
0
Sk8erPeter képe

"a "separator"-nak kell beállítani, hogy szépen egymnás alá kerüljenek a mezők."
Ezt hogy érted?
Táblázatos elrendezést szerettél volna, akkor balról-jobbra, egymás mellett, soronként fognak megjelenni a mezők, nem egymás alatt (normális esetben).
Biztos, hogy neked a táblázatos elrendezés a megfelelő? Te nem "Grid"-et szeretnél?

Aztán írod, hogy címkéket szeretnél megjeleníteni a táblázat celláin belül, ezt sem nagyon szokás egy klasszikus táblázatnál, vagy max. bekapcsolja az ember a "sticky" headert, hogy látható legyen, melyik oszlopról van szó.
Ha mégis ezt szeretnéd, az egyes mezőkön belül tokenek használával, a REWRITE RESULTS részen belül, a "Rewrite the output of this field" checkboxot bepipálva meg tudod ezt tenni. Példa:
ÁTÍRVA: [body]
Ha ezt beleírod, a body field előtt mindenhol mejelenik az "ÁTÍRVA: " szöveg.

Kérdés, valóban ezt szeretnéd-e.

1
0
szantog képe

http://drupal.org/project/fivestar
Na, hogy ne maradjon itt zöldség, javítsuk:
A fivestarban van egy ordenáré performance leak. Az van, hogy a widget építéséhez a form apit használja, magyarul minden egyes fivestar box egy form. És hogy ez miért baj? A drupal a form validációhoz form_build_id-t használ, amit a cache_form táblában tárol. A form cache csak a nevében cache, nem igazi cache, tehát nem lehet csak úgy kihányni pl memcacheba.

Szóval minden egyes kirajzolt widget minden egyes oldalon a cache_form táblát írja. Nálunk egy közepesen forgalmas oldalon 8 gigás tábla miatt kezdte csavargatni a tökömet a rendszergazda, meg hogy megfő a lom az io miatt.

Ez az issue sajnos kezelhetetlen, teljesen újra kellene írni a fivestar modult.

Helyette itt van ez: http://drupal.org/project/rate
A jó hír, hogy ugyanúgy a votingapit használja, szóval ízivéj lecserélhető a meglévő fivestaros mutatvány.

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.

Sk8erPeter képe

Nálad az a gond, hogy input-mezőre a .text() függvényt használod, de az egyéb jellegű HTML-elemekre használható (pl. div, span, p, stb.).
Az input-mezőkre a jQuery .val() függvénye használandó.

Esetedben így:
$('#edit-count-checked-checkboxes').val(countCheckedCheckboxes);

A korábban mutatott demót update-eltem ennek megfelelően:
http://jsfiddle.net/Sk8erPeter/kxrTS/3/

U.i.: egyébként ha nem gond, szabad megkérdezni, ezt mire fogod használni? Csak hogy biztos kell-e egyáltalán ez a JS-alapú számolás (required mező). (PHP-vel is megkapod a bepipált elemek számát, JS nélkül pedig mindig 0 lesz elmentve (persze valszeg nem lesz olyan júzered, aki JS nélkül használja a böngészőjét :P); de persze nem ismerem a feladatot, ezért kérdezem ;) )

1
0
eMeLA képe

Nem ez volt a kérdésed, de picit elgondolkodtam, vajon miért is akarsz tartalomtípust modulból létrehozni. Ha egy komplex egyedi modul fejlesztésébe fog az ember akkor talán van értelme, egyébként megérzésem szerint nem sok...

Ha az ismerkedés és a tanulás a cél, tapasztalatból azt tudom mondani, hogy érdemes körüljárni, hogyan tudod a form-okat saját modulból testre szabni (hook_form_alter). Hogyan lehet új field-et modulból létrehozni (hook_field_info) és hozzá megjelenítést készíteni (hook_field_formatter_info). Aztán ott van az egyedi token (hook_token_info) ami sokszor hasznos. Aztán érdemes körbejárni, hogy lehet beépülni a views-ba is.

Nekem ezekre volt legtöbbször szükségem, sokszor egy-egy ilyen kis modullal akár komplexebb modulokat vagy akár több modult is ki lehet váltani. Persze a sor lehetne még folytatni...

A függvényeket csak kiindulási pontnak írtam le. Érdemes a http://api.drupal.org/api/drupal/7 oldalt nézegetni. Illetve a már kész modulokból tanulni, ahogy azt nevergone is írta.

2
0

...mit tudok: http://web.termuves.hu

szantog képe

Ennek a sminknek (mint minden artisztíresnek) a kódja szembe megy az összes létező drupal koncepcióval és irányelvvel. 100%, hogy nem megfelelően működik együtt panels, display_suite, illetve egyéb _page_altereket legitim módon használó modulokkal, de még a field_formattereket is ignorálja sok (pl termek a nodeban) esetben.

Magyarán szólva sminkrétegből tesz tönkre modulszintű beállításokat.

Egyszerűen követhetelen, hogy mit művel a $content arrayal, szövegfüggvényekkel módosít spontán kész html elemeket, a teaser viewot úgy rakja össze, ahogy neki tetszik, és mindehhez nem megfelelő drupal hookokat, hanem saját tákolásokat használ.

Átnézve a kódot azt kell mondjam, hogy ezt (és a későbbiekben 100% hogy felmerülő) problémákat nagyobb időbefektetés javítani, mint keresni egy normális (nem artisztíres) sminket.

Ami miatt neked nincs pagered, az azért van, mert összeakad valamivel. És hogy mivel akad össze, az még localhoston is soksokórás debugolás.

EDIT: Szedd ki a Legújabb kínálat viewból a pagert. Szinte biztos, hogy valamilyen replace varázslattal kiszedi a második pagert, ami a search resulthoz tartozna. És hogy hogy fog ez egyszerre több pagert kezelni, elképzelhetetlen számomra.

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

eMeLA képe

Itt dönteni kell a felhasználó(vevő)barát honlap és a google helyezés között. :)

Én mint vevő azt választanám, hogy vevőbarát legyen az oldal, de ha nem találom meg akkor persze fújhatom a dolgot.

Ha elvi szinten közelítjük a dolgot és a két irány megpróbáljuk párhuzamba állítani, akkor itt van egy ötlet:
A termékváltozatok egy választólistában jelennek meg. Azt kell elérni, hogy ezek úgy látszódjanak mintha mid egy-egy oldal legyen.

Megoldás lehet egy kis modul, ami létrehoz egy linklistát a terméklapon, mondjuk olyan címkével, hogy termékváltozatok. A link végén van egy változó &termekvaltozat=1, &termekvaltozat=2 ....
Oldalbetöltéskor hook_form_alter-ban (ebben most nem vagyok biztos, hogy a terméklap form-ját itt eléred, ha nem akkor estleg hook_page_alter-ban) vizsgálod, hogy jelen van-e a 'termekvaltozat', ha igen akkor a termékváltozat select default értékét beállítod a 'termekvaltozat" változó értékére. Így a google beindexelheti az összes termékváltozatot.
(itt azér lehet elhasal az ötlet azon, hogy a termékváltozatot Jquery-vel tölti be....)

1
0

...mit tudok: http://web.termuves.hu

nevergone képe

Ennyivel még nem úszod meg a történetet, mert elhívásod vagyon. :)
Nem ismerem a talált hibajegyeket, ezért általánosságban beszélek. :)
Szóval megnézném őket, és ha van patch, akkor tesztelném ezerrel (legfrissebb változat Gitből, etc.). Amennyiben javítja a hibát, akkor beírnám oda hozzászólásba, hogy „I tested and works well!” és ha az állapota nem RTBC („reviewed & tested by the community”), akkor áttenném arra, majd örülnék, mint „monkey a tail-jének”, azaz majom a farkának télen (nem, ez sajnos nem saját poén).
Ha nincs patch és van idő (vagy hibás a patch és van idő), akkor az itt emlegetett módon megpróbálnám javítani a hibát, készítenék patch-et és mellékelném a hibajegyet, az állapotát pedig áttenném „needs review”-re, majd nagyon büszke lennék magamra, mert a közösség ereje és hasonlók! :)
Sok sikert, várom a fejleményeket! :)

1
0