XML-RPC
Nos, a 4.5.5, 4.6.3 és a HEAD (mondjuk az augusztusi headek biztosan nem emlékszem az IXR XML-RPC commit pontos napjára) verziókban lévő XML-RPC könyvtárakban rendkívül kis valószínűséggel van biztonsági rés. Azt nem mondom, hogy nincs, de nagyon-nagyon meglepne.
4.6.2 és egyéb állatfajták sérülékenyek. Brazil népek valóban felnyomják ezeket, de sokan megússzák azzal hogy spam zombiet csinálnak a szerverükből. Van aki kap rootkitet is. Ennyi információból nem zárnám ki egy esetleges Drupal független támadást. Netán r0nin? http://lists.debian.org/debian-security/2004/01/msg00181.html Nem futtat az a www user elmaradott Drupalt, phpBB-t, miegyebet?
Ha az angol nyelv problémás, akkor nekem lehet közvetlenül biztonsági jelentéseket küldeni, emailcím karoly negyesi net, szükséges írásjeleket találjátok ki.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
huh, mégis Drupal profilok
Igaz, mégiscsak a Drupal profil modulja kell. Megnéztem neked a kódot. Úgy van elképzelve, hogy bekapcsolod a profile modult, annak a saját admin felületén (adminisztráció » beállítások » profilok) felveszel egy tetszőleges nevű és feliratú egysoros szövegmezőt. Lényeg, hogy az AdSense azonosítódat ebben fogod megadni a saját (1-es számú felhasználó) szerkesztési lapján a felhasználói adatoknál. Hogy ezt az AdSense modul is értse, annak a beállítási lapján meg kell mondani, hogy melyik profil mezőt hoztad létre erre a célra. Tehát miután megvan a profil mező létrehozása, az AdSense admin felület fel fogja ajánlani azt, ott is ki kell választani.
Ez elvileg azért van így megoldva, hogy bevétel megosztást (revenue sharing) lehessen megvalósítani a webhelyen megjelent reklámok, és az erre jogosult felhasználók között. Ez persze csak opció (mármint a revenue sharing), nem kell bekapcsolnod. De érdekes lehetőségei vannak mindenesetre, most látom, hogy megnéztem :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
php maximális futásideje
Igen, erre én is gondoltam, pl az egy megoldás lenne, hogy ha mondjuk 150 fájlt akar átméretezni, akkor a feldolgozó kódrész 10-20 fájlonként megáll és újra meghívja magát, és folytatja, ahol abbahagyta. (Mondjuk addig kiírogatja a felhasználónak, hogy "Feldolgozás folyamatban...") A comboboxos, checkboxos cuccal kb egyetértek, a fájlneveknél (az adatbázisban) nem értem pontosan, hogy mire gondolsz. Egyébként lehet, hogy tényleg azzal kéne kezdenie a feldolgozónak, hogy valahogy egységesíti a fájlneveket. (Ékezetek, szóközök, egyéb galádságok.) Továbbá hasznos lenne még (mondjuk a saját jövőbeli esetemen gondolkodva) hogy a feldolgozó nem akarm mindig az összes új fájllal foglalkozni, hanem rá lehet ereszteni egy-egy könytárra is. Gondolok itt arra, hogy a felhasználó feltölti az új képeit a files/images/datum könyvtárba, és a feldolgozó csak azt kezdi el átnyálazni, ha kiválasztom. Persze ezt lehet, hogy megoldja, a "minden új" listázásánál a leválogatási lehetőség (checkboxok).
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
i18n
Szia.
Nálam az 1.36.2.2-es verzió van fent. Arra kell ügyelni, hogy a beállításoknál a "Browser language detection" ki legyen kapcsolva és a "Language Management" -nél az "Interface language depends on content" legyen kiválasztva.
1. Ha a drupal navigációs menü nyelve változik, csak a tartalom nem, akkor az Edit által is említett "Translations" blokkot kell használni a "Language switcher" helyett.
2. Úgy emlékszem, hogy próbálgattam ezt is és működött, de nem esküszöm meg rá, mert végül nem kellett használnom.
3. Ezt sajnos nem értem.
4. Elméletileg az $i18n_variables tömbbe lehet felvinni azokat a változókat amiket több nyelven is látni szeretnél. Ha a menü nevére nincs lehetőség (most sajnos nem tudok utánanézni), akkor csinálsz egy magyar és egy másik nyelvű menüt. Ezt a kettőt összefogod egy multilingual block-kal és ezt a blokkot jeleníted meg a menü helyén.
Üdv: Zoli
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mehet != megy is
Két dolog kell a rövid webcímekhez:
1. mod_rewrite támogatás
Ezt a szolgáltatód tudja beállítani.
2. .htaccess
Ebben a fájlban van ugyanis az a szabály, ami megmondja az apache-nak, hogy mit csináljon, ha nem talál egy fájlt. Amennyiben erőforrás korlátokra hivatkozva nem teszik lehetővé a .htaccess számodra lehetőség van arra is, hogy a vhost konfigjába(ezt neked nem kell érteni;)) elhelyezze a szolgáltató ezeket a szabályokat. Ezzel csupán az a probléma, hogy Te nem tudod, hogy mit kéne beállítani, a szolgáltató meg nem tudja minek kéne történnie és ilyenkor jól elbeszéltek egymás mellett. ;) Nekem egy ilyen tapasztalatom volt nem a legkisebb szolgáltatóval. Ott azt mondta a support, hogy beállítottak mindent ami "szükséges", de hogy pontosan micsodát azt nem árulta el. A végén a szolgáltató( ! ;) ) javaslatára elvittem az oldalt.
Magánban küldök olyan szolgáltatót akinél csont nélkül megy a Drupal.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

Sziasztok - köszi
Sziasztok - köszi mindenkinek.
Na most friss erővel ott tartok, hogy a feliratkozáskori megerősítő (confirmation) e-mailt szövegét(!!) átszerkesztettem, editáltam, mert a @ után volt egy szünet -> és láss csodát, KIKÜLDI a feliratkozós emailt. Végre!
Most más gond lett :))
Most meg ha hírlevelet akarok küldeni, akkor az nem megy el - és a naplóba meg ugyan az a hiba van (bad parameter)
Itt viszont megint akkor gondban vagyok, mert a megerősítős levél az egy szövegbe volt és azt a "nyelveknél" megtaláltam és tudtam javítani.
Amit viszont már hírlevélnek küld, ott hol találok hozzá való szöveget? (ott ugye maga a hírlevél lenne a szöveg - az meg ugye nincsen a szótárba.)
Pedig itt is gondolom valamit rosszul ad át, mondjuk a címet, vagy valamit.
No ezt hol szerkesszem?
Kösz mindenkinek.
P.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A környezeti változók php-
A környezeti változók php-re mysql-re megadva.
A passwordot hozzáigazítottam a php-mysql vonalon.
Az általam bepakolt php file (drupal könyvtar alá), ami az általam létrehozott adatbázist nyitja meg, lefut simán.
Valami jogosultsági gubanc lehet, de se az apache, se a rendszer logfileaiban nincs semmi.
A conf php -ben mindent.
$base_url = "http://localhost/drupal";
$db_url = "mysql://drupal:passwordom@localhost/drupal";
Így néz ki:
x:\php5
x:\mysql
x:\mysql\data
x:\apache
x:\jana\html ----> Ez a doc_root.
x:\jana\html\drupal
x:\jana\html\phpmysql ---->itt van az adminrész. Rendesen fut.