Milyen HTTP header-t küld ki/nem küld a szerver?
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
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

nem értem
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?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

szerintem nekik van igazuk
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ne flame-elj, olvadd el amit írtam!
É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. ;))
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Bevallom, én csak d.con
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Tesztoldal!
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

szerintem nem jó
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?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Tartalom hozzáadása?
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.