ugyanez a felállás
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
Geva
----- Számítások - Kalkulátorok
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

kéne
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...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

block-user-0.tpl.php
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

ezt hol olvastad?
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
tapasztalatok a node level permissionssal kapcsolatban
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
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
#DANGEROUS_SKIP_CHECK
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
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Oldal elemeinek aránya
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
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Címzési hiba
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.