Joee képe

Pontosan nem tudom. Egy ismerősöm javította. Leírom amennyit tudok róla, hátha össze tudjátok rakni. A hiba a CKEditorban vagy annak az utólag telepített szövegformázó almoduljában van. Két modult telepítettem a CKEditorhoz, ezek: Panelbutton és Colorbutton. Amennyire emlékszem az volt a baj, hogy nálam a domain egy külön mappában van és az nem az alapértelmezett főkönyvtár, mivel két domain és egy aldomain is van ott elhelyezve, ráadásul a Drupal is egy alkönyvtárba van telepítve. Ezek miatt a CKEditor a libraries mappát nem ott kereste ahol a modul leírásánál volt az elhelyezés előírva. Ráadásul két helyről is elérné a libraries mappát a CKEditor és ezek különböző libraries mappa helyekre mutattak. Ha valakinek a domain és a Drupal nem almappában van, ott nem biztos, hogy előjön ez a gond, mert ott jó helyen fogja a CKEditor keresni a libraries mappát.

0
0
Geva képe

PHP mail() függvénnyel küldöm ki az emailt űrlap beküldések adataival, ám az office 365-s - cloud - email fiókba nem érkezik meg mindegyik. Biztosan kiküldésre kerülnek, leellenőriztem. Egyértelműen a spam-nek minősített email-ek nem érkeznek meg - közöttük tényleges ügyfél feladóval: a Mail failure -, a tárhely alapértelmezett mail fiókjába kerül, amiből egyértelmű a spam-nek minősítés, akár tényleges ügyfél emailek is :-(

rengeteget teszteltem és próbálkoztam...

Gmail fiókba mentek az email-k már évek óta, az office-ra történt váltást követően átirányítás lett beállítva: gmail -> office mail fiók, ahova már nem érkeznek meg
az email-k

Ha a honlap tárhelyének email fiókjába küldöd a webform kitöltéseket, oda meg fognak érkezni, próbáld csak ki, teszteld és kérlek jelezz vissza mi történt nálad!

köszönöm

0
0
Illyés Edit képe

Igen, kéne. Ha nem jelenik meg, akkor nincs a Views-ban Image támogatás. Ebben az esetben csak az Image Galleries szótár alá tartozó taxonómia kifejezéseket tudod használni listázásra.

Most nincs ilyen galériám sehol beüzemelve, úgyhogy nem tudom megnézni, de azt hiszem, hogy a galériák főoldalán (ott, ahol kiírja, hogy ebben-és-ebben a galériában X kép van) felül kell írnod a linkeket, hogy ne az egyes galériák normál oldalaira (/tid/xxx típusú link, ha jól emlékszem) mutassanak, hanem az általad Views-zal készített oldalakra.

Ezek a linkek sminkből módosíthatók, bár lehet, hogy egy kicsit variálni kell, hogy a tid alapján valahogy ki tudd választani az adott galériát helyettesítő nézet URL-jét.

Egyébként meglepő, ha tényleg nincs Image támogatás a Views-ban. Én azért alaposan szétnéznék a Drupal.org-on...

0
0
Illyés Edit képe

ezt en ganyolasnak tekintem, hizsen az igazan kulturalt ha a megjelenitett adat tudja hogy oda plusz infot kell beirni, nem pedig a megjelenitesert felelos kod.

Nem lehet ilyen élesen elválasztani, hogy mi az információ és mi a megjelenítés. Ha minden node-nak a végére kiteszel egy copyright jelzést akkor az micsoda? Szerintem az ilyen fix részeket simán be lehet tenni a sminkbe. Ha nem a sminkbe, akkor hová? A smink egy fix öntőforma, amibe beleöntöd a változó adataidat. Sehol nincs az leírva, hogy a nem-változó rész csak HTML címke lehet.

A kerdes hogy ez mukodik-e a blockokra is, illetve ha igen akkor a login blockhoz nekem milyen neven kellene a filet letrehozzam, nincs kedvem a kodban lekovetni

Using different block templates for different blocks, regions, etc.

0
0
Illyés Edit képe

Nem állítottam, hogy a rövid URL rossz (vagy irreleváns) lenne keresőoptimalizálási szempontból, ezt hol olvastad tőlem? Csak azt mondtam, hogy ha elveszíted az évek alatt összegyűjtött értékes bejövő linkjeidet, abból nagyon komoly következmények származhatnak a webhely kereső-helyezésére nézve.

Vannak esetek, amikor nem érdemes a régi linkekért küzdeni, de visszakézből azt mondani, hogy indexelés után az oldal automatikusan magasabb helyezést fog elérni a keresőknél pusztán azért, mert szép URL-re váltott, ez egyszerűen nem igaz. Ha így lenne, az azt jelentené, hogy a szép URL (azaz hogy te mit állítasz magadról az URL-ben) többet számít, mint a rád mutató linkek (azaz hogy a net többi szereplője mit gondol rólad). És nyilvánvaló, hogy az utóbbi többet nyom a latban, ez logikus is, meg a tapasztalat is ezt mutatja.

0
0
kuller képe

Eddigi 1-2 napos:) tapasztalatok alapján a következő apróságokat találtam amin javítani kéne (Menükészítésre a taxonomy_menu modult használom.):
nodeperm_user.module: A tartalom beküldésénél kipipálható userenkét a hozzáfárási és edit jog. Probléma: nem lehet általános irányelveket megadni, tehát nem mondhatom, hogy ezt az oldalt mindenki láthatja. Emiatt új felhasználó felvételénél az összes eddigi nodet át kell nézni jogosultság szempontjából. (Speciális esetben jól jöhet, de általános megoldást nem nyújt.)
nodeperm_taxonomy.module: Itt a felhasználóknál állíthatóak, hogy melyik menüpontot láthatják és melyiket nem. Probléma: inaktív menüpontok is láthatóak, csak ott a "Jelenleg nincs beküldött tartalom a kategóriában." megtévesztő felirat olvasható. A másik, hogy az anonymous userek nem látnak semmit még a kezdőlapot sem, mert nekik nem lehet beállítani jogot.
nodeperm_role.module: A tartalom beküldésénél kipipálható jogosultsági csoportonként a hozzáfárási és edit jog. Helyrerakja az előző hiányosságot, evvel már lehet az anonymous userek is jogot adni különböző nodek-hoz.

Összefoglalásként: Minden kapcsolaódó probléma megoldható ezekkel a modulokkal, csak az inaktív menüpontokat nem tudtam eltüntetni.

ÜDv:K

0
0
pp képe

hozzá kell adni a feltöltendő select mezőhöz a

'#DANGEROUS_SKIP_CHECK' => true

sort. Forrás: _form_validate

Érdemes ellenőrizned, hogy tényleg valós adatot kaptál-e, tehát újra lekérni az adatokat amikkel feltöltötted a selectedet és megnézni, hogy a kapott adat benne van-e a választható értékek halmazában.

Érdemes azt is átgondolni, hogy hova is készül az alkalmazás. Ha ez egy intranetes belső oldal lesz, akkor evvel a hozzáállással semmi probléma, hisz ilyenkor megkövetelheted, hogy milyen böngészőt használjanak és legyen bekapcsolva a JS. Azonban ha internetre fejlesztesz a helyes eljárás az, hogy először elkészíted úgy az oldalad, hogy js nélkül is menjen, majd ezután rárakod a kényelmi funkciókat. Így akinél nincs js az is tudja majd használni az oldaladat.

pp

0
0
pakati képe

Köszi az eddigieket!


Kipróbáltam mind a kettőt:

  • links package - 5.0 alá - kicsit bonyolult, és nem tiszta mi mire való, de ezt úgyis csak kiváncsiságból tettem fel...
  • weblink - 4.6 alá, mert az 5.0 csak teszt, 4.6-on kell megoldanom ezt - eddig nagyjából az amire gondoltam. Létrehoz egy node típust, és van egy cím meg egy URL mezője (a törzs rész nem is kell). Ellenőrzi a linkek egyediségét (úgyhogy ez is ki van pipálva).



A kérdésem az, hogy lehet-e valahogyan egy node-ba kilistáznom az összes weblinket? Van-e erre lehetőség a weblinken belül, s ha nem, akkor van-e valami modul, ami nekem ezt megvalósítja?

Elvileg nem lenne olyan nehéz egy SQL lekérdezést írni, s kilistázni, csak nekem gőzőm sincs arről, hogy hova is tegyem azt a lekérdezést, hogy végül egy node-ba jelenjen meg az eredmény...
help?

Thanx
//pakati

0
0

//pakati

nevergone képe

Valamit félreértettél, a fórum nem erre való. Ha segítséget szeretnél, akkor írd le, hogy hogyan indultál el, hol akadtál el, stb. Ha téged nem érdekel annyira a feladat, hogy legalább elkezdj egy kicsit piszmogni vele, akkor engem miért érdekeljen annyira, hogy írjak neked egy kisalkalmazást?

Teljesen igazad van, és az általad vázolt segítség fel sem merült bennem. Ami segítség érdekelne a témában (hogy a jó irányban el tudjak indulni), az az lenne, hogyan lehetséges valamilyen módszerrel az összes tartalmat "bejárni" egy programban.
Utána a többivel már megpróbálkoznék én (az adott tartalom típusának lekérdezése, ha megfelelő, akkor a szükséges adatok kinyerése, stb.), csak erre a (szerintem) egyszerű dologra nem találtam sehol sem mintakódot. És ehhez sem teljes alkalmazás, csak valami "snippets", töredék. Bevallom, nem igazán foglalkoztam eddig a Drupal alapú PHP programozással, ezért szeretnék pl. ilyen apró kódtöredéken át belelátni kissé a lelkivilágába.
Mindenesetre nagyon köszönöm a segítséged, és az általad javasolt megoldást is mindenképpen ki fogom próbálni. :)

0
0
thamas képe

Köszönet, hogy felhívtad a figyelemt erre az írásra és, hogy összefoglaltad a lényegét!

Az angol eredetit még nem olvastam végig, így nem tudom jól gondolom-e: az oldalakon a dobozok (pl. "vezércikk", ízelítők" stb.) mérete és elrendezése fix-ugye? Mármint, a szerkesztők nemigen tudják változtani a "layoutot" úgy mint egy nyomtatott kiadványnál, hogy "a tegnapi számban három hasáb volt a fő cikk és kettő a másik, ma viszont öt hasáb a fő cikk és nincs mellette más".
Ez valamelyest kezelhető lenne CSS-sel, de gondolom egy olyan sminket készíteni, ami vizuális eszközökkel kezelhető (ide oda huzigálom, méretezem a dobozokat) kicsit macerás lenne (hm, bár blognál láttam már ilyesmit, js-sel)... - vagy megcsinálták ezt is?

Más: érdekes az URL kialakítás is: úgy látom azonosító számként csak az évet tüntetik fel az URL-ben, egyébként pedig a cikk címégől származik - ez így nagyon elegáns, ember- és keresőbarát, viszont feltételezi, hogy egy éven belül nincs két azonos cikk cím. Azért egy napilapnál ez izgalmas!

Üdvözlettel:
Hajas Tamás

Üdvözlettel:
Hajas Tamás