Hogy....
Én nem ezt írtam? Lehet én nem értem csak...
Itt a kép. Nekem fos neobase regisztrációm van és ott ugye alapból a drupal van telepítve,méghozzá emígyen.
http://kepfeltoltes.hu/090713/drupal_www.kepfeltoltes.hu_.jpg
Ott az a themes mappa,mégpedig ez már korábban kiderült itt,hogy ez az ALL-on belül van állítólag. De leírtam,hogy eddig így működtek a sminkek és hogy jelenleg is máködik egy "beach" nevezetű smink.(az más kérdés,hogy az sem 100%osan)
Ami még fontos lehet ide,hogy valami gáz van lehet a drupalommal,mert ha pl. frissítek egy modult vagy egy újat akarok felrakni,akkor miután felmásoltam a szerverre,az oldal nem jön be. Csak egy nagy fehérség jelenik meg semmi más.
Találkoztatok már ilyennel gondolom. Remélem könnyen megoldható a probléma
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Én voltam a leggyengébb
Én voltam a leggyengébb láncszem :)
Okulásul:
Amikor létrehoztam a szótárat (az i18n már be volt kapcsolva), a nyelv választásnál kiválasztottam a magyar-t. Majd kijelöltem a "Localize terms. Terms are common for ..." lehetőséget (ekkor a nyelvválasztó inaktívvá vált). Ez azt eredményezte, hogy a magyar és nyelvfüggetlen tartalmak beküldésénél igen, az angol tartalamaknál nem jelent meg a szótár a node beküldés ürlapon. És mivel nem lett kiválasztva az angol nyelvnél kategória, nem is jelenhetett meg a kategórialapon a node.
Mit tettem:
Kiválasztottam a szótárnál a "Set language to vocabulary. The vocabulary will have ..." opciót, mentetem majd ismét megnyitottam. Aktívvá vált a nyelvválasztó, ahol az üres opciót választottam ki, illetve bejelöltem újra a "Localize terms. Terms are common for ..." lehetőséget. Mentés után megnyitogattam a már meglévő kifejezéseket, és röftön el is mentetem őket. Ezek után az angol fordítás beküldése lapon már megjelent a szótár, és így helyére kerülhettek a fordítások...
...mit tudok: http://web.termuves.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ez igen hasznos is lehet
Kedves pp!
Számodra ez lehet, hogy spam, de nekem, aki kezdőként most keresek tárhelyszolgáltatót, igazán hasznos volt átolvasnom. Tehát kérlek - így hónapok távlatából is - nézd el a többieknek, hogy olyanról írtak, ami téged nem érdekel.
Ugyan azt írod, hogy "Nem lehet elképzelni, hogy van még itt a fent nevezett pár tárhelyszolgáltatón kívül számos olyan cég aki nem csak hogy hosztinggal foglalkozik, hanem még ezerszer is többet tett a Drupal Közösségért.", de gondolom, az ellenkezőjét akartad sugallni (pont helyett a kérdőjel, nemde?). Ha így van, kiegészíthetnéd a listát az említett cégekkel. Lehet, hogy ez reklámnak is számíthat, de ha az embernek csak két hete van weboldala a saját gépén, és nem általában tárhelyszolgáltatót keres, hanem olyan helyet, ahol a Drupalja jól fut, minden információnak örül.
Az ilyen információk mindig jól jönnek, gondolom, nem én vagyok az utolsó, aki webhelyet fabrikál Drupallal.
Üdv: M. Gy.
Üdv: M. Gy.
Mindenkinek megköszönöma segítséget
Mindenkinek megköszönöm a segítséget. Örömmel jelentem, hogy egy kis háttér segítséggel a tárhely tulajdonosától sikerült az oldalt 5.20-ról 6.14-re frissíteni. Mindezt adatvesztés nélkül.
Sajnos nem tudom leírni, hogy végül is mi volt az igazi megoldás, mert mindketten, vagyis a tárhely tulajdonosa, és én is egymással párhuzamosan dolgoztunk.
Azt tudom, hogy nagy segítség volt az, hogy minden fajta változtatás előtt egy teljes backup-ot csináltam, és ezt át tudtam adni a szolgáltatónak.
A lényeg, hogy minden probléma megoldódott.
A fórum is nagyon sokat segített, mert sok fontos információt kaptam, és sokat olvastam.
Most már csak egy két apróság van (pl: az Analitics modul nem akarja elfogadnia a követő ködomat, meg a pdf szerkesztőt kell finomhangolni) amiken gyorsan átrágom magam, és utána mehet a régóta halogatott weboldal fejlesztés.
Ismét köszönöm az értékes hozzászólásokat.
D.Z.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
te jó ég...
(Tekintettel arra, hogy a Microsoft számtalan kódját nyitottá fogja tenni (pl. amiatt, hogy nem tervezi további Windows operációs rendszerek fejlesztését)
Ne érts félre, de kérlek erősíts meg abban: ezt viccnek írtad.
az IIS7 sokkal fejlettebb technológia mint az Apache WEB szerver
Nem akarok parttalan vitát robbantani, de Netcraft-ot néztél már?
Amúgy ha körülnézel, akkor láthatod majd, hogy elég sok külső modulnak gondja akad a PHP 5.3-mal, és az alaprendszert is csak nemrég készítették fel rá, te pedig az alaprendszer moduljait soroltad fel. Nyilván nem viccből írjuk az ilyesmit, hiszen nekünk mindegy, mivel szívatod magad.
Ui.: Egy kis adalék még a "miért ne használjunk PHP 5.3-at Drupal 6-al" témához: Eltűnt karakterek nyomában
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
valóban rossz a kérdés
vagy legalábbis nem túl jól megfogalmazott.
értelmezésem szerint a megrendelő kb ezt akarja:
- legyen egy adatbázis: x
- legyen egy adminisztrációs felület, ahol van írási, szerkeszési, törlési jogosultság a megjelenő tartalmak vonatkozásában, de ne csak "logikai szinten" kerüljön ez a jog megadásra (drupal access control) hanem ennek az admin felületnek legyen csak gyk. insert, update, delete joga az x adatbázisra
- legyen egy adminisztrációs felülettől független megjelenítő felület, ami olyannyira szeparált, h az a felület csak select joggal bír az x adatbázison.
- ugyan ez a jogosultságkezelés file szinten is megvalósításra kerülne, tehát mondjuk az admin felület olyan user nevében fut (mármint a keretrendszer, tehát pl php) aki tud írni a docroot-ba, míg a megjelenítő felület olyan júzer nevében fut aki a docroot alatti dolgokat ugyan olvasni tudja de írni nem.
legalábbis én így értelmeztem a topik indító kérdését.
na erre nem való a drupal.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Tapasztalatok:
Köszönöm az eddigi javaslatokat.
Aboros javaslata fél megoldás.
Ha bekapcsolom a HTML-szűrőt (alapból nem használom) és tiltom "a" taget, akkor hazavágja az adott tartalom összes hivatkozását, tehát a beillesztett pdf -ek sem működnek.
Ha viszont csak az URL szűrőt kapcsolom ki (ez alapesetben ON), akkor a pdf -ek működnek, csak a "copy - paste" hal el, ennek megfelelően.
Esetmben már ez is elég lenne, de annyira azért inteligens a célközönség, hogy ugyanazta módszert alkalmazza egy külső hivatkozás beillesztésére, mint az állományokéra.
IMC segítségével előbújó ablakban beírja a kívánt url -t majd ment és kész...
Thamas:
Megnézem ezt a modult, a leírásod alapján használhatónak tűnik.
Ha a modul forrásába piszkálok, akkor az gondot okozhat frissítéskor, nem?
Vagy készítsek egy saját modult ennek alapján és azt töltsem be?
KocsiT
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Örülök
Örülök, hogy ekkora az érdeklődés, bár csak haladnék vele...
A megjegyzéseddel nem 100%-osan értenék egyet, amennyiben nem érted félre.
Elég sok bkk modulom működik áruházakban (eddig még nem Drupal, hanem osCommerce), és van rálátásom a trx számra.
Én magam, aki ebben a témában utazom közel 10++ éve meglepődtem, mert a Mo-i bankkártya használat (és kereskedői hozzáállás) azt sugallta, hogy kevés trx lesz, de amelyik áruházban bevezették ott azonnal áttértek rá az emberek, pedig megmaradtak az utánvétes és utalásos módok is.
Azt gondolom, hogy az ok abban keresendő, hogy a drágább holmik kifizetéséhez kp kéne mikor jön a postás, és ez gond. Így viszont akár a nagymama is átveheti, nem kell otthon kp-t tartani, az átutalás meg macera, főleg, ha nincs online bank, meg + min 3-5 nap, mert a kereskedő sem figyeli real-time a számláját, hogy megjött-e.
üdv
Péter
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
htaccess, cache
Elvileg a .htaccess fájlban ki tudod tiltani a gyanús IP-címeket, átmeneti tűzoltásnak megfelelhet.
Hosszabb távon az oldaladon gondolkoznék el. Mivel azt írod, hogy a captcha-n nem jutnak át, ezért úgy gondolom, hogy anonim látogatók. Ilyenkor felmerül a kérdés: Biztosan jól van beállítva az oldalad, a szolgáltatónál sincs gubanc? A legtöbb esetben az anonim látogatók a tartalmakat az oldal cache-ből kapják, személyes tapasztalatom, hogy egy normálisan beállított oldal és normális erőforrásokat biztosító szolgáltató esetén ekkora terhelést a Drupal alap gyorstárazási mechanizmusa is probléma nélkül kiszolgál.
Egy nap alatt több 400 látogatást produkáló IP is volt, elég sok a 10 perces oldal generálási idő
Például erre körülnéznék, mi az, ami a bejelentkezés nélküli látogatóknál is ilyen terhelést okoz? Mivel nem tilthatsz ki minden látogatót (hiszen a keresőrobotok is így érkeznek), ezért inkább felkészülnék a fogadásukra. Ha több kell, APC, esetleg Memcache segíthet.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Alapvetően nem
Alapvetően minden függőség kérdése, de legfőképpen attól függ, hogy milyen módon történik a frissítés.
1., Ha update manager programmal (jelen esetben nevezzük nevén: YUM), akkor:
Mivel a "gyári" repositorykból nem oldható meg a frissítés, akkor maradnak a third-party repositoryk, amelyekben vagy megbízik az üzemeltető vagy sem. Ez a könnyebbik eset, de meg kell bízni a csomagok készítőjében.
2., Forrásból telepítésnél:
A rendszergazdától több figyelmet és munkát igényel, de ebben az esetben saját maga rakja össze a komponenseket és gyorsabban követheti a verzió változásokat.
3., A kettő keveréke:
A forrásból a rendszergazda elkészíti az RPM csomagokat, majd a kész csomagokat telepíti. Ez kifejezetten RPM készítési ismereteket is igényel.
Ha alapból a gyári csomag van fent, akkor nem akarlak elkeseríteni, de kicsi a valószínűsége, hogy frissíteni fogják a LAMP stacket.
Páldi Zoltán