Balu Ertl képe

Jól látom a hibaüzenetből, hogy a teszt.pointkft.hu aldoménről van szó? Ha simán, titkosítatlan protokollon (tehát http://teszt.pointkft.hu/index.php) nyitom meg, akkor valóban 500-as hibát kapok. Ha viszont a titkosítotton keresztül (tehát https://teszt.pointkft.hu/index.php), akkor viszont él és virul. Tehát érdemes lenne errefelé nyomozni.

  1. Ahogy Drufan mondja, minden „cache_” szóval kezdődő, plusz a „sessions” nevű táblákat bátran ürítheted (ha angol a phpMyAdmin felülete, akkor az „Empty”), de semmiképp se töröld („Drop”) őket.
  2. Miután így kiütötted a gyorsítótárat, egy privát böngészőablakban (ez azért kell, hogy kliensoldali gyorsítótár se játsszon be) kattintsd végig a webhely azon oldalait, amik eddig látszólag működtek. Még mindig jól jelennek meg?
  3. Ezután be tudsz lépni a webhelyed https://teszt.pointkft.hu/user/login címén az Egyes számú felhasználóddal?
  4. Ha igen, és azzal meghívod a webhelyed https://teszt.pointkft.hu/update.php címét, akkor mit tapasztalsz?

Ha ezekre a lépésekre megírod a tapasztalt eredményt, akkor tudunk tovább nyomozni, hol lehet a gond és pontosan miben kell majd a tárhelyszolgáltató ügyfélszolgálatának segítségét kérned (ha egyáltalán kell, még az se biztos, majd meglátjuk).

0
0
Illyés Edit képe

eddig a node-ban megjelenített nod másnak még nem jutott eszébe (csak halkan: mert én már csináltam ilyet)

A CCK node reference nem egészen azonos a node-ban megjelenített node-dal. Időnként például a node-ot nem is jelenítjük meg, csak arra használjuk, hogy a rá node reference útján hivatkozó node-okat listázzuk. Lásd például ezt a témát.

A cikkben ismertetett megoldások önmagukban nem számítanak újdonságnak, jórészt meglévő modulokra építenek. De ilyen alapon bármire lehet azt mondani, hogy "ez mért új". Senki nem üres lappal indul. A megoldás eredetisége itt abban rejlett, hogy volt egy elég komplex feladat (elektronikus lapkiadás), volt egy szokványos mód, ahogyan ezt a feladatot eddig rendszerint megoldották (ömlesztett listázó blokkok, lásd pl. a Népszabadság honlapját); ez a megoldás nem felelt meg a megrendelő teljesen méltányolható igényeinek – a fejlesztők pedig lényegében egy egyszerű Drupal szolgáltatás (CCK node reference) kreatív alkalmazásával létrehoztak egy teljes értékű szerkesztőségi rendszert.

Címkefelhő: például itt. Ez nem azt mutatja, hogy az olvasók miről szeretnek olvasni, hanem azt, hogy a blogger miről ír. A kettő ugye nem mindig esik egybe. Az Observer esetében itt is az történt, hogy volt két meglévő megoldás (címkefelhő, Drupal statisztika), és ezeket kreatív módon kombinálták.

Illyés Edit képe

Arra gondolsz, hogy a list és table nézetben "egy lekérdezéssel" kapja meg a views az összes adatot, míg a teaser nézetnél minden egyes találati sorhoz még meghívja a node_load függvényt, mely további számos lekérdezést generál?

Erre mondhatjuk azt, amit fent mondtál, de ez sem igaz mindig.

Igen, én itt a legegyszerűbb esetre gondoltam, amikor készítünk pl. egy egyszerű taxonómia listát blokkba, akkor a teaser nézet többnyire teljesen feleslegesen node_load-ol.

Érdemes elolvasni ez a jó kis odamondogatós vitát a Views fejlesztő blogján.

Also, I highly recommend using List views where possible, since you can avoid node_loads. In fact, Karoly Negyesi went so far as to write a little nodeapi hook that stores the fully converted teaser in the database so that he could utilize a List view as as teaser view. Something that is ordinarily not possible because teasers have to be processed. With a little nodeapi magic, however, he actually gained significant efficiency using Views.

De nincs köztünk vita ebben, meg kell nézni mit csinál a Views, nem ész nélkül kattintgatni, és eldönteni, hogy elfogadható teljesítményt nyújt-e, az egyszerűbb karbantartás megér-e ennyi teljesítményromlást. Ezt csak esetileg lehet eldönteni, nyilván a kérdező ismeri az összes szempontot, úgyhogy mi itt csak általánosságokat tudunk mondani.

0
0
druid képe

Megnéztem a hivatkozott témákat amiket küldtél itt és meglepő - nem akarom magam fényezni, tényleg - hogy alig egy hete használom a D10 és Composer párost és máris felvetődött bennem, hogy ugyan miért nem eleve ezt a módszert használja a webes frissítési felület. Gondolom már sok éve felmerült ez, csak még nem valósult meg, nem gondolom, hogy csak most jutott eszébe másoknak.

Amit a modulok megbízhatóságáról írsz az viszont megdöbbentett, tehát akkor semmi értelme a megbízható modul jelölésnek.
Azt gondoltam, hogy a folyamat vagy úgy megy, hogy valaki beküld egy modult és egy csapat végignézi a kódot, majd utána kerül oda a zöld szín és a pajzs, vagy hogy annyira megszabott a modulok fejlesztésének mikéntje, hogy eleve van egy keretrendszer, ami nem is engedi, hogy problémák legyen, vagy egy program átvizsgálja a kódot.

Ezek után nehéz azt gondolnom, hogy a Drupal a legprofibb CMS és már azt is értem, miért van annyi utólag kiderült biztonsági rés a világ összes webes és egyéb alkalmazásában...

Remélem nem a mesterséges intelligenciának nevezett szarságra fogják rábízni ezeket a feladatokat, mert abban még annyira sem lehet bízni, mint az emberekben.

UI. Van egy elképzelésem, hogyan lehetne felvirágoztatni a Drupal.hu oldalt, vagy akár egy másikat csinálni, úgy, hogy az anyagilag is megérje. Ha érdekel, valamikor megírom és akár összehozhatnánk...

0
0

egy újszülöttnek...

Szokolay képe

Kedves Jó Drupál-lovagok!

A programozásban csak csetlő-botló íróféle vagyok, ráadásul öregecske, mondhatni csúzos veterán :-)
Viszont lesz egy szép tárhelyem, doménem és honlapfüzetem, amelyet drupallal szeretnék felépíteni. Hozzákezdtem, ahogy írva vagyon: Apache, PHP, MYSQL, drupal ... a saját gépemre, Windows XP alá, hogy aztán már csak okosságokkal kelljen naponta feltölteni az oldalakat. Rá kellett jönnöm, hogy nem sikerül beállítanom és működőképessé varázsolnom a rendszert. Nem jár valaki errefelé (a virtuális Isten háta mögött, Pestszentlőrincen), hogy segítene az első lépésekben?! Utána, ígérem, megtanulok járni önállóan is, a jótett helyébe pedig jót várhat, aki megszolgálja.

Írások gyűjteménye ne csak a címlapon

Anonymous képe

Egy egyszerűbb több lapból álló weblapot szeretnék drupal-al összehozni, ahol minden oldalon lenne több cikk (írás). A statikus oldalakat elkészítettem, ha rákattintok a friss tartalom -ra, akkor látom, hogy pl. node/4 - Bevezetés, node/5 - Rólunk, node/6 - Linkek stb. Ezeket az oldalakat elláttam aliasokkal is, majd felvettem őket a menube.
A problémám konkrétan az, hogy ha megírok egy írást, akkor azt úgy tűnik kizárólag a Címlapra tudom felhelyezni, pl. a "Rólunk" alá nem. Ez a dolog itt a drupal.hu -n rendesen működik. Ha a hírekre kattintok, akkor más írásokat látok, mint ha a cikkek-re kattintok.

kategóriát fix szűrőként használnék

aszoditamas képe

Az érthetőség kedvéért: adott egy települések szótár és egy másik szótár pl: sport. Szeretném azt megoldani hogy az oldalt látogatók a településükre szűrve válogathassanak a sportban található kategóriákra.

Települések: Budapest, Pécs, Szeged (taxonomy1, 2, 3)

Sport: labdarúgás, röplabda, kézilabda (taxonomy4, 5, 6)

Nem élő menüpont beszúrása

tuning képe

Sziasztok!

Nagyon új vagyok a Drupal témában, de van egy dolog amit szeretnék megtudni. Lehet-e olyan menüpontot létrehozni, ami fizikailag ott van, de nem link?
Leírom mi az alapprobléma. Adott egy honlap ahol a nice_menus modult használva szeretnék menürendszert létrehozni. Azonban lennének olyan menüpontok, amikre kattintva nem lenne link (azaz nincs tartalom hozzá), hanem az almenük tartalmaznák a szükséges tartalmakat. Például:

menü1 (nem link)--
|-- almenü1 (link tartalommal)
|-- almenü2 (link tartalommal)

Cikkek hozzaferesenek szabalyozasa

Lacz képe

Hello

Szeretnem beallitani a cikkeimhez, hogy melyik felhasznalocsoport tekinteheti meg.
Letrehoztam felhasznalo-csoportokat, de igazan csak egy helyen lattam oket felbukkanni: Hozzafers-szabalyozas. Sajnos itt csak az egesz node modul tartalmak engedelyezese opciot talaltam, ami mindenre kihat. > Tehat anonymous user-t ki lehet rekesztenem, de akkor mindebol kirekesztem.
Szeretnem a kozzeteteleknel megadni, hogy kik lathatjak. Van erre mar kesz megoldas?
Amiert kellene: Egy sokfunkcios oldalt szeretnek uzemeltetni a magam oromere. Mast szeretnek kozzetenni a nagyvilagnak es mast a barataimnak, es megint mast a kollegaknak es az uzletfeleimnek.

Brossúra webhelyek adatbázis nélkül

Hojtsy Gábor képe

Jeremy Epstein szembesült azzal a problémával, hogy egy egyszerű adatbázist nem igénylő brossúra webhelyet kellett készítenie néhány alapvető dinamikus funkcióval. Gondolta, hogy saját PHP függvényeket alakíthat ki erre a célra, de inkább azt a megoldást választotta, hogy a Drupal rendszert teszi képessé erre a célra. A megvalósítás kódok törlését igényelte, az adatbázis alrendszer, felhasználók, tartalmak, jogosultságok, gyorstárazás és sok más elem elvátolításához vezetett.

Kategóriák: