Fórumok
A jelenlegi drupal adatbazisomon nem fut le a drupal cron job. A futas helyett feldob egy letoltes ablakot a "run-cron.txt" filera. Itt mindegy, hogy mit csinalok (open, save, ...) a cron job nem fut le.
Kiprobaltam egy "ures" adatbazison egy azonos drupal verziot, illetve a hibas adatbazison tobb drupal verziot is a jelenseg ugyanaz.
Megprobaltam a drupal admin felulet alol a cachet torolni, egyelore nem segitett.
Turtam a netet, hogy milyen cache tablak vannak meg, azokat toroltem phpmyadminbol, de az sem segitett.
Tud valaki megoldast?
Hozzászólások
Azt nem wgettel kene leszedni cronbol?
Vagy mi a fenet keres egy cron job egy bongeszoben?
Elindithatod a bongeszobol kezzel is. Normal esteben a hosting crontabjaba teszed be wgettel.
De mondjuk ez nem valtoztat azon, hogy nem fut le.
Hanyas verziójú drupal? Mert pl. a 7-es már automatikusan bizonyos idő után egy-egy kérésbe beszúrja a cron futtatást.
Az mindegy, hogy automatikus vagy manualis, ah nem fut le. Probaltam 6-ossal es 7-essel is. Ez feltehetoleg egy adatbazis problema.
Abban a könyvtárban, ahol a cron job van, van futtatási jog? A file-ra van engedélyezve a futtatás? Kinek a nevében futtatnád a cron-t?
A helyzet az, hogy ha csinalok egy vadonatuj installaciot egy szuz adatbazist, akkor minden megy ragyogoan. Ha beimportalom a regi adatbazist ugyanebbe az installacioba, akkor a cron nem fut le tobbe. A filerendszerben nincs valtozas. Tehat nem valoszinu, hogy jogosultsagi problema. Egyekent ha az lenne, akkor permission denied jellegu hibauzenet erkezne.
"Abban a könyvtárban, ahol a cron job van, van futtatási jog?"
Igen
"A file-ra van engedélyezve a futtatás?"
Nem volt, de nem valtoztat a dolgon. Ahol mukodik, ott mukodik anelkul is, ahol nem mukodik, ott nem megy azzal sem.
"Kinek a nevében futtatnád a cron-t?"
A host felhasznalom neveben, feltehetoleg.
Esetleg probald meg drush-on keresztul futtatni. Az a tool egyebkent masra is hasznos, erdemes megnezni. :)
Eloszor le kene fusson manualis modban.
A nyito postbol nem derult ki egyertelmuen, hogy manualisan sem fut le. Esetleg error log?
Bocs, tenyleg nem volt egyertelmu.
Adatbázisban töröld a cron_semaphore-t. Ez szokott segíteni beragadt cron feladatoknál.
delete from variable where name = 'cron_semaphore';cron_semaphore nem volt egyik serult adatbazis variable tablajaban sem (sem a 6-sban, se a 7-eseb importaltabn), viszont a 7-es altal ltrehozott szuz adatbazisban a variable tablaban van egy cron_key meg egy cron_last, de cron_semaphore ott sincs. Gondolom ez egy atmenetileg letrehozott valtozo a cron futas idejere.
Felrakod az XDebug-ot, beraksz a cron-fajl elejere egy trace requestet, leszeded wgettel, elolvasod a trace fajlt, orulsz (vagy sirsz...)
A shared hostingra hogy rakom fel?
A problemat egy php oldal okozza (ide kikommentezve teszem be):
Ezt nem tudja felindexelni.
Ezt a kodreszletet arra talaltam korabban megoldaskent, hogy kikenyszeritsem a bongeszobol letolteskor a mentes/megnyitas abalakot. Ugyanis ha barmilyen allomanyt tolt le a felhasznalo, akkor az minden bongeszonel mashogy tud vislekedni pl. attol fuggoen, hogy van e beagyazodo applikacio az adott tartalomhoz, stb.
Ha az allomany nagyobb, a felhasznalo gyakran elkattint, mert azt hiszi, hogy nem tortenik semmi, mikozben a browser csendebn a hatterben tolt.
Szoval vagy a cron temat tekintem megoldottnak, de akkor a bongeszoablak megnyitas nem mukodik es akkor nyithatok egy uj temat a bongeszoablak probelamanak, vagy pedig sikerul olyan php kodot irni, amit fel tud indexelni a cron.
Oteltek?
Az indexelesi problemat egesz pontosan az exit utasitas okozza. Viszont ha ez hianyzik, a letoltes sem mukdik.
Mi akadályozza, h ezzel le lehessen tölteni pl. a db user/pass -t ?
Ez egy nagyon jo kerdes, ill. meg az is szep kerdes, hogy es ennek mi a fasszeh' kell futnia a cronban is?
Azert mert a drupal minden php oldalt ertelmez amikor felindexeli. Tehat nem aphp kodot indexeli, hanem lefuttatja szkriptet es az eredmenyet indexeli. Sajnos nem lehet meg a 7-es drupalnak sem kivetleket megadni.
Valaki legyen oly' kedves elmagyarazni, hogy az elso mondatnak mi a jelentese. Tudtommal a Drupal nem PHP oldalakat indexel, hanem a sajat adatbazisaban gyujtoget. De lehet, hogy tevedek, viszont erdekelne, hogy ez akkor hogy mukodik.
--
Nem tuidom, hogy mennyire fogalmaztam pontosan. A lenyeg, hogy amikor a drupalban oldalt hozol letre, akkor az egyik lehetseges tipus a php (a htaml es szukitett html mellett). A mondat pedig azt jelenti, hogy a php tartalmu oldalak eseteben nem a php kod kerul szovegkent felindexelesre, hanem a kod altal generalt html oldal.
Ha ilyen igényed van, miért nem modult fejlesztesz? Megerőszakolod a rendszert és csodálkozol, ha hibásan működik.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Nem eroszakolom meg a rendszert. Hasznalom az altala nyujtott szolgaltatasokat. Hogy ez jo vagy rossz az mas kerdes.
A PHP filtert minden jo erzesu ember nagyon-nagyon-nagyon messzirol keruli, es modulszinten kapcsolja ki. Csak nagyon-nagyon ellenorzott korulmenyek kozott szabad hasznalni - es akkor is nyolcvanotszor meg kell fontolni, hogy tenyleg kell-e ez, nem lenne-e jobb modult gyartani ra.
Roviden: A PHP filter rossz, ertem?
--
Ezek szerint nem vagyok jo erzesu ember. En egy szimpla weboldalt akarok osszerakni drupallal, es abban ket helyen is kell egy par sornyi php kod. (Ja PHP kod azert kell, mert az egesz webes technologia egy rakas ..., raadasul minden bongeszo mashogy viselkedik,) Ehhez irjak modult? Miben jobb a modul, mintha a php filteren megy at? Azzal, hogy a php kod nem az adatbazisban lakik? Hat miert nem oldjak meg rendszer szinten, hogy ne ott lakjon. Egyelore nem latom, hogy miert nem (keret)rendszer szinten van a php problema kezelve, miert is kell nehany sor php kodhoz modult gyartani, es azt allandoan karbantartani, az upgradekkel elvezni, stb.
Ha elmondod, miert kell a PHP kod, es nem csak felhaborodottan vagdalkozol, akkor lehet, hogy meg segiteni is tudunk.
A PHP filter egyebkent azert nem jo dolog, mert nagyon sokmindenre kihatassal lehet. Egy modul sokkal specifikusabb, sokkal finomabb eszkoz, mint egy node-ba/blockba beszurt PHP kod. Kicsit a kobalta meg a precizios furo esete, mindkettovel celt lehet erni, csak az elobbivel tobb kart csinalsz kozben.
A custom modulokat nem kell upgradelni. A Drupal API csak foverzionkent valtozik nagyot, de akkor amugy is olyan melyrehato valtozasok vannak, hogy az, hogy egy egyfuggvenyes modult frissiteni kell, eltorpul amellett, amennyi munka egyebkent van vele. De egy foverzion belul az API-k 99%-a egyaltalan nem valtozik (legfeljebb bovul).
--
Azt még tegyük hozzá, hogy egy ilyen node-ba írt PHP gányolással sok dolgot nem lehet kihasználni a Drupal funkciói közül. Illetve ha valami miatt hiba kerül bele (pl. PHP frissítés, elírt függvénynév), akkor törik az egész oldal és lehet az adatbázisban pucolgatni.
A PHP filter nem azért van, hogy ott programozzunk, ez igenis megerőszakolása a rendszernek. Na de majd mindjárt jön a témaindító és megmagyarázza, hogy ő márpedig ért a Drupalhoz és így kell ezt.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Nem vagdalkozom, csak a kerdesfelvetesemre vicces modon lecseszesek jonnek. Nekem a webprogramozas nem szakteruletem, ezert probalok egy kesz keretrendszert alkalmazni, hogy az eletem egyszerubb legyen. Az akkor miert csinalod kerdeseket megelozendo: egy non-profit oldalrol van szo, amit ingyen szeretetbol (es rohadt keves idobol) csinalok, es nincs mas, aki csinalna.
Szoval a PHP reszek:
Az egyik problema ez: http://hup.hu/node/114266#comment-1455895
A masik, amire php-t hasznalok az egy tablazat generalasa.
Es talan van meg egy, ahol egy automatikus mailt kuldok.
Na most ez jo kerdes. Mondjkuk az, hogy tudni kene, hogy ezt az oldalt hogy hivjak, a db-t hogy hivjak stb.
De ha tudsz jobbat annak orulnek.
az inputok ellenőrzése nem "jobbat tudás", hanem az abszolút minimum.
$file = $_GET['file'] ennek mi értelme van - azon kívül h szaporítod a változókat?
"az inputok ellenőrzése nem "jobbat tudás", hanem az abszolút minimum."
Igen lehetne, nem igazan gondoltam ra. (Nem foglalkozom alapvetoleg webes programozassal, csak kenyszerbol naha, es nem gondoltam ra, hogy ez egy tamadasi felulet.) Az inputok ellenorzese egyebkent szerintem tervezesi es nem kodolasi kerdes, ez pedig egy "quick and dirty" dolog, ahol mukodes szempontjabol minden input elfogadhato. De ertem a problemat es koszonom, hogy felhivtad ra a figyelmem. A tudsz jobbat pedig a megoldasra ertettem, de tenylegesen egy input szuressel valoszinuleg az is megoldhato, hogy a cron lefusson. Majd este megnezem.
"$file = $_GET['file'] ennek mi értelme van - azon kívül h szaporítod a változókat?"
Ket helyen van hsznalva, de mondjuk tenyleg nem letszukseg, hogy valtozoban legyen. En egyebkent inkabb hasznalok valtozokat, mint tobbszoros vagy egymasba agyazott hivasokat. De nem vagyok a PHP nagy muveloje, csak muszajbol hasznalom neha neha, tehat nem feltelenul hasznalom optimalisan.
Ha már dirty hack, akkor adj meg spéci user agentet a cron-os wget -nél, és ebben a fájlban PHP-val csekkold, h mi a user agent! Vagy már rewrite-tal elküldheted a bánatba és akkor nem kell a PHP-ban koszolni!
Eloszor is, ez a PHP kod hogyan fut? Valahogy mindenki nagyon okosnak latszik itten, pedig te nem irtal le semmi konkretumot. En meg valahogy hulyenek erzem magam, pedig nagyon szivesen segitenek.
Egyfelol a Drupal kepes a letoltesek kezelesere, PHP-n atszurve a dolgokat, a 'drupal private filesystem' kulcsszavakra keress ra (aposztrofok nelkul). Sztem erre a mokolasra szukseg nincsen.
Masfelol pedig sztem a webszerveren is ki lehetne eroszakolni egy ilyen header elkuldeset adott fajlok eseteben. De meg az sem lehetetlen, hogy van ilyen Drupal modul, csak te meg nem tudsz rola.
--
> Egyfelol a Drupal kepes a letoltesek kezelesere
Fent leirtam a kulonbozo bongeszokkel tapasztalt jelensegeket.
> drupal private filesystem
Ez hogyan tudna segiteni a probleman?
> Masfelol pedig sztem a webszerveren is ki lehetne eroszakolni egy ilyen header elkuldeset adott fajlok eseteben.
Hogyan?
> De meg az sem lehetetlen, hogy van ilyen Drupal modul, csak te meg nem tudsz rola.
A forumokat bongeszve mas sem. Ettol meg lehet, hogy letezik.
Valójában mi lenne a feladat és mivel próbálkoztál eddig?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
A feladat az, hogy bizonyos allomanyok letolthetoek legyenek egy html oldalba agyazott linkre kattintva. Korabban ezt egyszeruen ugy oldottam meg, hogy a drupal belso relativ linkjet tettem be az anchor tagbe. (pl. /files/vmi/vmi2/vmi3.pdf) Ennek az volt az eredmenye, hogy a bongeszok kulonfelekeppen kezeltek a letoltest. Van amelyik nyitott abalakot, van amelyik a hatterben toltott. Ez nyilvan egy nehany MBs allomanynal mar probelmas lehet, mert egy csomo user elkattint, hogy hat ez nem is mukodik, nem tortenik semmi. Ennek kikuszobolesere akarom kikenyszeriteni, hogy a letoltes ablak mindig azonnal megyniljon, amint a user a linkre kattint.
A topic cim pont megfelel, bar a problemam kicsit eltero. D7 alatt a cron jobok nem futnak le, ha kivulrol probalom futtatni curl-lal, csak ha drush-sal futtatom oket. Bar a D7 alapbol tartalmaz egy poorman's cron implementaciot, azert en megis jobban orulnek, ha ez a mod mukodne.
Sikerult mar vkinek mukodesre birnia? A cron_key-t meg szoktam adni, ezzel egyutt sem megy, es nem tudom, milyen jog kellene hozza.
A hibajelenseg: egy teljesen renderelt (sminkelt) drupal-os "Hozzaferes megtagadva" oldalt kapok.
--