ipeto képe

Ha pl. az a cél, hogy regisztráció nélkül is tudjanak tartalmat létrehozni, azt a jogosultságoknál (admin/people/permissions Node csoport) tudod beállítani a látogató felhasználóknál. Mondjuk ennek az lesz a következménye, hogy kettő perc alatt teleszpemmelik az oldat.

0
0
pp képe

Meg kéne nézni, hogy milyen header-eket küld a szervered. Attól, hogy https a protokoll, az csak annyit jelent, hogy a http kommunikáció az egy titkosított csatornán keresztül zajlik, de az ugyan úgy http kommunikáció.

pp

0
0
Illyés Edit képe

Azt mondod, ha rákattintasz az űrlap adataira, akkor egy űrlapot sem érni el. Ezt én nem értem. Kicsit pontosabban ha lehet. Mi az ami nem elérhető? A Views által készített táblázat? Vagy maguk az űrlapok?

0
0
Illyés Edit képe

A szolgáltató nagyon korrekt. Itt neked kellene utána nézni, mi volt az a félmillió insert. Fut valami elszabadult modul vagy szkript a webhelyeden, ennek a kilövése a te dolgod, nem az övék. Az adatok alapján teljesen jogosnak tűnik a lekapcsolás.

2
-1
pp képe

Én olyat nem írtam, hogy a node tábla ismerete az általános műveltség része lenne (pláne olyan baromságot, hogy a node tábla maga)

Nem írtam a node tábláról egy szót sem, és azt sem, hogy része lenne(múlt idő). Én azt írtam, hogy bizonyos informatikai ismeretek az adatbázis kezelés témaköréből az általános műveltség része kell hogy legyenek(jövő idő).

Ezt mint tényt írtam le, mivel nem az én agyszüleményem. Az Oktatási Minisztérium által kiadott Kerettantervben található a szöveg amit idéztem. Ez a kerettanterv a szükséges minimumot fogalmazza meg, amivel egy gimnáziumi érettségi után rendelkeznie kell a diáknak.

Én azt írtam, hogy nem csak a programozónak kell tudnia, hogy mi az az adatbázis, és mi az a tábla, miért kell indexelni stb. Nem gáz, ha nem tudja valaki, de ha tudja könnyebben boldogul a Drupal-al.

Ha valakinél eltűnik a node tábla és nem tudja mi az a "tábla", akkor az valami olyasmit csinált, amihez nagyobb szakértelem kell, mint amivel rendelkezik. Ekkor vagy megtanulja azt, vagy kezdi előröl és reménykedik, hogy még egyszer nem fut ebbe a hibába bele. Ha belefut akkor kezdheti megint előröl, mert más módszere nincs arra, hogy ezt a hibát elhárítsa.

Nekiindulni meg azért nehéz, mert olyan ködös elképzelései vannak, hogy ez programozói tudás, tehát ahhoz, hogy ezeket a fogalmakat megismerje meg kell tanulnia programozni. Na erre írtam azt, hogy ez nem így van. Az adatbázis alap ismeretek egy jól körülhatárolt halmaz, mely megismerése jóval könnyebb mint gondolnánk. Ezt a megismerendő halmazt másoltam be a hozzászólásomban.

pp
(én mindent leírtam. ;))

0
0
Sólyom képe

Az első bejegyzéseim kuszának tűnhettek, mert magam sem sejtettem mi lehet a gond, ezért leírtam mindent.

A publik_html könyvtárban volt két külön mappa (2 drupal oldal), mindegyik mappának az adott oldal domain neve volt a neve.

Én az egyik drupal 5-ös oldal csinálom meg éppen 6 alatt, ezért az adott oldal mappáját átneveztem mydomain.com-ról mydomain-ra és a domaint erre a mappára irányítottam át. Majd létrehoztam egy üres mydomain.com könyvtárat és elkezdtem felépíteni az új (6-os) oldalt. Illetve csak kezdtem volna, mert a fent leírt hibákba ütköztem. Lehet bezavarhatott az adatbázis neve is, amiben csak egy 2 (kettes szám) volt az eltérés.

Mivel mindenre gondoltam csak nem a könyvtárstruktúra helytelenségére, így amit csak itt a fórumon tanácsoltatok, illetve amit csak a googliban olvastam, azt megváltoztattam, majd ha nem volt jó, akkor vissza. Az egyik ilyen változtatás után összeomlott az oldal. Vissza is alakítottam a legutolsó manőveremet, de mint kiderült, maradt némi szemét a settings.php-ban, így maradt a fehérség. Erre begurultam és töröltem az oldalt.

Új, megváltozott névvel tettem vissza a 6-os drupalt, és lássatok csodát. Minden a legnagyobb rendben van.

Ha ismerősöm nem hívja fel erre a problémára a figyelmem, én még sokáig kerestem volna a hiba okát.

Ne haragudjatok, hogy raboltam az időtöket, de ezek a bejegyzések sem lesznek feleslegesek, mert ugyan ezeket a hibákat leírta itt már más is, és nem született megoldás akkor a problémára.

Köszönök minden segítséget!

Üdv: Sólyom

0
0

------------------------
Mint a sivatagban víz nélkül, a naptól kiszáradva, remegő hangon, alig hallhatóan kiáltok az életet jelentő nedűért: Az Örök Igazságért!

aries képe

Bevallom, én csak d.con alkalmával találkoztam olyan „sminkessel”, aki képes bármilyen felhasználói felületet egymaga kivitelezni, mert megvan benne az a vizuális kreativitás és kézügyesség, a mély alapokkal bíró fejlesztői tudás no és persze se kutyája, se macskája, ideje, mint a tenger dolgozni és tanulni, jónak maradni. Nagyon kevesen vannak és még kevesebben vannak (világszinten), akik ezt a képességet és önfeladást meg is tudják fizetni.

A valóság ezzel szemben az - és ez a Drupal igazi érdeme - hogy külön lehet választani a felhasználói interakciókat és a látványt az adatokkal való feltöltéstől úgy, hogy egymás területével a lehető legkevesebbet, a saját specializációval a legtöbbet töltve. Épp ezért az én tapasztalatom az, hogy a theme_image(), theme_item_list(), l() és még néhány sminkfgv erőltetése inkább hátrány, mint előny. Mitől szemét, ha egy .tpl-ben img src van? Milyen hátránya származik belőle, ha így használja? Az előnye az, hogy

  • nem lesz a designer területe PHP kóddal tele
  • nem kell minden Drupal kiadásnál újratanulnia változásokat
  • nehéz megindokolni, mitől lesz az ő munkája könnyebb/hatékonyabb, hiszen az adatokat a backend fejleszőt fogja beletenni
  • nem lesz tele first-last-active és a bánat tudja még milyen ballaszt, az esetek döntő többségében felesleges classekkel, hogy a theme_image() getimagesize() alapértelmezett bekapcsolását ne is emplítsem
  • a theme_item_list() -nél sem a wrapper div classét, sem a fejléc típusát, classét nem tudod beállítani; ha felülbírálod, akkor ismét mindenhol át lesz írva, rakhatod az átláthatatlanságig tele if-ekkel

Tudnám még ragozni, szerintem a fent említett fgv-ek a ló túlsó oldala.

0
0
kepes képe

Nagyon jó a kérdés, és a válasz: igen, az éles oldalon kísérletezik, ami több szempontból is rossz, és sajnos napi rendszerességgel fordul elő más oldalaknál is.

1. Rossz a szolgáltatónak, azaz nekünk, mert hibás szkriptek, beragadt redirect-ek pillanatok alatt borítják a szervert. Van ellenszer természetesen, de nem túl felhasználóbarát, és fikázó posztok lesznek belőle, hogy szolgáltató így meg úgy kill-el meg limitál.

2. Rossz az oldal látogatóinak és szerintem igen nagy presztízs veszteség amikor a potenciális vevő azt látja az oldalon, hogy PHP Warning, meg notice, esetleg Internal 501... Az elvesztett ügyfeleken keletkezett veszteség kisebb oldalnál is összevethető egy saját VPS pár ezres árával, vagy egy saját Virtualbox-os környezet telepítési költségeivel (idejével).

3. És nem utolsó sorban rossz az oldal tulajdonosának is, mert az éles környezetben nem ritkán ki vannak kapcsolva olyan figyelmeztetések pl. security okok miatt, amikből látható lenne mi is a a hiba. Így legtöbb esetben meg kell elégedniük a "nem megy" jelenséggel, amivel aztán kereshetik a szolgáltatót.

Megoldás:
Mi ebből a fórumból sokat tanultunk (ez úton is köszönöm az elindítónak, aki mint írta is, már nem ügyfelünk) és próbáljuk levonni a megfelelő következtetéseket. Ebből az elmúlt hetekben az az ötletünk nőtt ki, hogy ügyfeleinknek fejlesztői környezetet biztosítunk a jövőben külön szerveren, aminek infrastruktúrája megegyezik az éles környezettel (cpanel, ftp, drupal telepítő stb.), de csak egy felhasználó lesz rajta egy időben. Minden log fájl elérhető, és még a szerver statisztikákra is rá lehetne nézni. Így mindenki tesztelhet, fejleszthet és megoldhatja a problémákat.

13
-2
nroland16 képe

Ha ezt a gondolatmenetet folytatom, de belenyúlik másik témába, akkor új topicban tegyem fel a kérdést?

A probléma ugyanaz, a megoldás más, kicsit rugalmasabb ill. egyszerűbb.

Neten olvasgatva ráakadtam a Display Suite modulre. Egyedi megjelenést adhatunk a különböző tartalmaknak. Ezzel a modullal sikerült elérnem a kívánt eredményt, DE:

- Az oldalon használt sminket nem használja a "Links", ami azért felelős, hogy kiírja az alábbi linkeket: további információ, új hozzászólás, stb...

Display Suite modulnál, ha módosítom a bevezető részt, a 2-es csatolmánynak megfelelően, akkor látszik, hogy pl. a "tovább" (read more) linket a láblécben helyezem el, ÉS meg adhatok neki külön classt. Ha itt megadom a sminkem által használt CSS-t, akkor annak megfelelően jelenik meg az a link.
Azonban a képen az is látszik, hogy a "LINKS" elemnek nincs beállítható értéke, így a smink által használt class-t nem tudom neki megadni. AZ eredmény az egyes csatolmányban látható. A linkek sima linkként jelennek meg, nem úgy mint az alatta látható Blogbejegyzés bevezetőjében.

Amit szeretnék ezzel kapcsolatban kérdezni és megtanulni az az, hogy miként lehet a display suite modult úgy használni, hogy a feltelepített sminkem CSS fájljai legyenek igazak rá. Egyelőre nem sikerült megérteni a sminkelési eljárást drupalban.
Iszonyatosan jó lenne ez a display suite modul, ha az éppen használt sminket alkalmazná az újonnan létrehozott layoutokra.

1

2

0
0
Anonymous képe

megnéztem és ki is próbáltam de szerintem így nem jó...

tehát a gondom az volt az ilyen megvalósítással (és most is az) hogy ha jelen esetben az alap kezdőoldalt lecserélem node -ról a modulban meghatározott path -ra (azaz jelen esetben pl 'cimlap') akkor a címlap kivételével minden más eltűnik ami a főoldalra van küldve (oldal, írás stb.)

ezen hogyan lehet segíteni?

0
0