Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. január 24. 15.49

„Egy olyan függvény kellene…” Ilyenkor az api.drupal.org-on érdemes kezdeni a keresést: theme_image_style

<?php
$vars = array(
  'style_name' => 'képstílusod neve',
  'path' => 'a/kép/útvonala',
  'alt' => 'alt szöveg',
  // stb. lásd az API-t.
    );
$output = theme('image_style', $vars);
?>
0
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. január 24. 18.05

Biztos, hogy ki kell printelni? Egy file_get_contents() meghívása nem elég rá?

0
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. január 29. 02.16

Például: http://mattkersley.com/responsive/

5
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 2. 01.40

Nem ismerjük a webhelyet, de 92 lekérdezéstől Drupal körökben nem szoktak a szívükhöz kapni az emberek. :)

A gond ott van, hogy ha többségében nem belépett felhasználókról van szó, akik gyorstárból (cache_page tábla) kapják az oldalt, akkor az elvileg 1 db lekérdezés. Tehát vagy nem működik a gyorstárazás, vagy a belépett felhasználók által lekért, nem gyorstárazott oldalak indítanak el extrém sok lekérdezést.

Ezért szerintem Memcache és hasonlók helyett első körben a webhelyet kellene egy kicsit körbenézni, pl. modulok egyenkénti kikapcsolásával. Kezdve a kevésbé népszerű, egzotikusabb modulokkal. (Egy Views vagy egy CCK rendeltetésszerű használat mellett kevésbé kockázatos, mint egy zöldfülű által írt kismodul.)

Lehet-e a lekérdezési dömpinget időbeli eloszlás szerint vizsgálni? Pl. délután 2 és 3 között jött kismillió lekérdezés – pont akkor, amikor az adminok moozogtak a webhelyen.

Kérdezőnek: Drupal naplóban látsz-e valami furcsaságot? PHP hibák és hasonlók, beragadt cron…

2
-2
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 2. 13.05

„Egy oldal megjelenítéséhez 92 lekérdezés semmi esetre sem mondható normálisnak véleményem szerint (ha ez aztán megy a cache-be, és legközelebb onnan jön, más a helyzet.)”

Ahogy írtam, megy a cache-be, és onnantól kezdve 1 lekérdezés. Nem belépett felhasználók kapnak nem betárazott oldalt, de ott is több kisebb oldal-komponenst betáraz a rendszer, és a következő lekérésnél már jelentős részben azokból építkezik. Nézd meg menyi ilyen-olyan cache_ tábla van az adatbázisban. 92 lekérdezés/oldal akkor fordulhat elő, ha teljesen üres a gyorstár.

Teljesen igazad van, hogy nem éles környezetben kellene az ilyen problémáknak kijönnie, de sajnos ezt elég nehéz a megrendelőkkel elfogadtatni. Ő annyit lát, hogy kész az oldal, színes, szagos, és nem érti, miért kellene még tesztelésre, hangolásra, optimalizálásra költeni. Sokszor arról nehéz meggyőzni az átlag megrendelőt, hogy webáruházat, komolyabb webhelyet ne 500-1000 Ft/hó alsó kategóriás osztott tárhelyen próbáljunk futtatni, mert előbb-utóbb nagyon ráfizetünk.

2
-1
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 2. 13.36

Létrehozol 10 hirdetési blokkot:

  • 1. cikk utáni hirdetés
  • 2. cikk utáni hirdetés, stb.

Ezeket az ügyfél szabadon szerkesztheti. A nézet .tpl.php-jében számolod a kiíratott sorokat, minden sornál megnézed, van-e tartalom a kapcsolódó blokkban. Ha van, kiíratod, ha nincs, lépsz a következő sorra.

D6-ban könnyű volt lekérdezni egy-egy blokk tartalmát, ez most problémás, de mintha valamelyik megoldás működött volna nekem, csak most nem találom.

2
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 2. 21.41

A D7-es Workflow modullal be tudod állítani, hogy mikor (óra, perc) lépjen át egyik státuszból a másikba: szerkeszthető > nem szerkeszthető. Talán már 6-osban is megvolt ez a funkció. Hasonló példa: Közzététel után a szerkesztés tiltása a beküldőnek

Taxonómia alapon: erre saját modult kell írni, hook_node_insert()-ben, hook_node_update()-ben megvizsgálni a $node taxonomy értékét, és attól függően beállítani a határidőt. Kicsit el kell mélyedni a $node-ban, de gondolom valami $node->workflow_scheduled_timestamp-szerűségbe kell betenni a határidő időbélyegét.

0
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 7. 13.37

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
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 15. 19.55

Folyamatosan várja a cég a jelentkezőket, sok szép feladat van náluk kisebb céges honlapoktól a komoly portálokig. Korrekt partner.

0
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2012. február 21. 16.40

1. van-e hátránya ennek a szerintem szép, logikus megoldásnak?

1 helyett 2 tartalmat kell kihúzni az adatbázisból. Nagy terhelésű oldalon ez esetleg problémát jelenthet.

2. View-ban hogyan tudok a beágyazott kép tartalomtípus mezőire hivatkozni?

Az Advanced > Relationships résznél nézz szét, ott tudod megmondani a Views-nak, hogy a kapcsolódó kép típusú tartalmat is hívja be a nézetbe. Amikor új mezőt, szűrőt, stb. veszel fel, akkor lesz választási lehetőséged, hogy pl. egy cím mező az alap tartalom, vagy a relationship útján behívott kapcsolt tartalom címét jelenítse meg.

0
0