visszamenőleg nem érvényes
Gondolom a multisite-nál lassítja is a működést, hogy ugyanazok a file-ok szolgálnak ki adott esetben ugyan abban az időben indított lehívásokat. Mivel több honlap működik róla egy időben.
Ki szolgál ki mit? Ne haragudj, de nem értem pontosan a logikát, amelyet követni próbálsz. Amúgy miért függne ettől bármi sebessége?
Bár nem szorosan ide tartozik, de: tegnap áttettem a default/files mappát a sites/files helyre és nyilván nem voltak elérhetőek a korábbi tartalmak. Majd mindent átmásoltam ebbe az új file mappába, de akkor sem találta, pedig a File rendszer beállításnál megadtam az új útvonalat.
Talán az adatbázisban vannak az egyedi útvonal megadások és azért?
Ez a beállítás visszamenőleg nem érvényes, csak az ezután feltöltött fájlokra. Az adatbázisod "files" táblájába less bele.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Akkor még egyszer :)
Az autoassignrole és og moduloknak semmi közük egymáshoz.
Azaz nem lehet megcsinálni az OG-vel, amit az autoassignrole-lal. Kivéve persze, ha mondjuk a rules.module használatával további hegesztéseket nem csinálsz, de szerintem a probléma továbbra is abból adódik, hogy az alaprendszerbeli "role" és az OG által használt "group" angol kifejezéseket egyaránt „csoportnak” fordítottuk, és ez nehézséget okoz annak megértésében, hogy a kettőnek nem túl sok köze van egymáshoz.
A webhely elindításakor (nagyközönség számára való elérhetővé tételekor) létező csoportok elegek/megfelelőek lesznek-e a további működéshez? Ha igen, akkor én az alaprendszerbeli "role" csoportok mentén indulnék el; ha nem, akkor pedig az OG-t használnám annak "group" csoportjaival, amelyekből később is tetszőleges számút létre lehet majd hozni. A kettőt azonban nem keverném össze semmi esetre sem.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nálam is ez van (vagy nem?)
Ugyan ez a problémám, de nem a rendelés visszaigazolására érkező levéllel, hanem a rendelés állapotváltozásáról érkező levél jön "egybe öntve". Nekem fel van telepítve a két modul, be van állítva, de az állapotváltozásról érkező e-mailt nem találtam sehol, csak a nyelvi fordításoknál, amikor rákerestem a szövegre. Beírtam a magyar fordítást, de ott nem vesz figyelembe semmilyen tag-et, pedig az eredeti angol szövegben sincs formázás, az mégis szépen sorokra tördelve jelenik meg. A beírt fordítás meg bármit írok át, nem akar "tördelődni". A uc_order/templates/uc-order-customer.tpl.php file-ban szerintem nem az állapotváltozás értesítő található, csak a vásárlás visszaigazoló "számla". Gyanítom, hogy az indító post is az állapotfrissítés értessítőre vonatkozik. Ha nem, akkor bocs a tévedésért. Azért ettől függetlenül boldog lennék, ha valaki tudna megoldást találni az állapotfrissítésről érkező levél formázására.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Pont ezért fura, mert
Pont ezért fura, mert leellenőriztem, minden jó volt neki, lefutott az adatbázis-frissítés, megmutatta szépen, hogy milyen táblákban módosított.
Mondom, király, kész vagyok.
Ma meg csinálom az aloldalt, megcsinálom az adatbázist, a könyvtárát, jogosultság, symlink, install.php, Hungarian és pukk
Call to undefined function lock_acquire() in system.module
Ránézek a főoldalra, hopp egy Adatbázis-frissítési kérelem, ez eddig nem volt itt. És most a lehető legkevesebb gonddal szeretném megoldani a dolgot, és remélem nem tűnik el az adminfelület, mert az egyetlen akit találtam google-ön, ezt tapasztalta.
Legvégső esetben vissza az előző adatbázismentésre, de azt most nem nagyon szeretném.
Azért kérdeztem, hogy lehet-e olyan gond, ha az alaptémákat nem frissítettem le, mivel a 810-es sor themes-re utal.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azokat a mezőket amiket
Azokat a mezőket amiket egymás alatt akarsz megjeleníteni azt a views-ben a stílus beállításainál tudod megtenni.
Az oszlopnál ad meg a mezőnek, hogy melyik oszlopba kerüljön bele. Így akkor az is abban az olszlopban lesz mint az őt megelőző mezö.
Példánál maradva:
Készítesz egy öt oszlopos nézetet.
Első oszlop:
A kép az elsö oszlop (kép_mező)
A második oszlop:
az őt követő mező a név (név_mező), szélesség (szél_mező), gyártási év mező (gy_év mező) kereskedő mező (ker_mező)
Itt jön a trükk a stílusnál megadod hogy minden oszlop a (név mező) oszlopa legyen. És így kapod meg a második oszlop mezőit egymás alá rendezve. A többi oszlopnál ugyan ez a séma. Ha megvagy az elrendezéssel akkor lehet sminkelni stb, stb...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
alkönyvtár
A problémát szerintem az okozza, hogy az eredeti oldal közvetlenül a webszerver DocumentRoot könyvtárában volt (http://foobar/sites/default/files/…) itt pedig alkönyvtárba került (http://localhost/siker/sites/default/files/…)
A Drupal az általa kezelt linkeknél automatikusan kezeli ezt, viszont azokat, amelyeket a sminkben vagy a tartalomban közvetlenül adsz meg, nem tudja módosítani.
Ha pedig valahol teljes eléréssel adtál meg egy linket (pl. http://foobar/sites/default/files/alma.png vagy http://foobar/node/3) akkor aztán másolhatod az oldalt bárhova, az mindig az éles helyre fog mutatni.
Tedd a lementett oldalt közvetlenül a DocumentRoot-ba (htdocs könyvtár), az esetek nagy részében segít.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Igen, a max_allowed_packetet
Igen, a max_allowed_packetet mindenképp érdemes alápakolni, pont az általad emlegetett dblog szokott elhasalni miatta.
Viszont ez egy statikus dolog, ha ez a baj, akkor az a mirror szerveren baj (feltételezve, hogy ugyanazok a mysql paraméterek).
Egy lock_release_all() viszont nem az az erőforrászabáló valami, amitől ledobja a láncot a server. :) Ez sokkal inkább arra utal, hogy az adott pillanatban volt az utolsó csepp a pohárban, szóval inkább terhelésfüggőnek tűnik
Baar.. Most lehet, hogy én írtam zöldséget, hogyha az /admin/config oldal minden esetben elhasal, akkor hülyeséget beszéltem.
Itt amúgy vannak ötletek, hogy milyen mysql változókat érdemes még bántani: http://stackoverflow.com/questions/1178736/mysql-maximum-memory-usage
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Kösz, ez sokat segített,
Kösz, ez sokat segített, akkor ebbe az irányba indulok.
Egyébként hidd el nem mondanám, ha nem jelent volna meg az a settings.php üzenet, és már eljöttem onnan, nem ezért, de egyébként az egyik legnépszerűbb tárhely volt az is. Ha jól emlékszem akkor nem volt letiltva a Drupalon belül a hibaüzenetek kiírása, de már nem emlékszem mi váltotta ki, valahol egy levelezésben utána nézhetek, amit a szolgáltatónak írtam az ügyben.
Ami a teszt tárhelyet illeti, hát persze, hogy úgy csinálom (de nem bonyolítom aldomainnal, külön domaint meg minek vásárolnék ezért, simán egy külön mappában van, nem a főgyökérben), mivel most készül az oldal, nincs közhírré téve, csak gondolok arra az időszakra, amikor már éles, és akkor nagyon nem szeretném, ha fellépne egy ilyen dolog.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
na azert....
Szia
Ezzel az open_basedirrel nem ertek egyet, en a sajat szerveremen is open_basedirben futtatom az osszes php-t, es szerintem ez a minimum amit vedelem szintjen megtehet az ember, es azert ezeket az alapdolgokat jo lenne szemelot tartaniuk a fejlesztoknek.
York.
------------------------------------------------
http://openproject.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Egy szóval nem mondtam, hogy
Egy szóval nem mondtam, hogy meg kell csinálni helyettem. Sőt az egészet azért találtam ki, hogy tanuljak belőle (és esetleg más is, aki a fórumot böngészi).
Természetesen örülök minden segítségnek, ne gondoljátok, hogy hálátlan vagyok. De ez a "csinálj saját modult", emlékeztet arra amikor ismerősöm felhívta az autószerelő barátját, hogy megállt az autó az isten háta mögött, és semmit nem hajlandó csinálni, mire a autószerelő: "Hát, biztos elromlott. Meg kéne javítani.". Tényleg kösz! Eszembe se jutott! xD
Ráadásul az eredeti kérdés az Aardvark topsites-ra vonatkozott. Régóta fejlesztik, már az 5.2-es verziónál tartanak, ha vért izaddok se tudok jobbat csinálni nála. Nem szeretném újra feltalálni a kereket, ha nem muszáj.
És tényleg köszönöm mindenkinek. Még annak is aki csak annyira foglalkozott a problémámmal, hogy elolvasta.