Schmile képe

Az ultraweb PHPMyAdmin felületén feltöltötted az adatbázist?

0
0
sgabe képe

Az új adatbázisban is utf-8 az illesztés?

0
0
pp képe

Sose jó megoldás egyszerre bekapcsolni több modult - legalább is a tanuló időszakban -, hisz így nem tudhatod, hogy melyik modul mit ad hozzá a rendszeredhez és a fenti kavar alakul ki a fejedben.

Ha csak a Content Access-t kapcsolod be:

Kétféle jogosultság van abból a szempontból, hogy az aktuális felhasználó hozta-e létre az adott tartalmat vagy valaki más által létrehozott tartalmat néz éppen. Az any az azt jelenti, hogy bárki által létrehozott, tehát érdektelen, hogy ki a tartalom szerzője.

Az, hogy a saját magunk által beküldött tartalmat megnézhetjük-e kérdést megértsd kicsit el kell engedned a fantáziádat. Először is van az anonymous júzer, aki nem egy ember, hanem végtelensok, őket hívjuk látogatónak. Őket nem azonosítjuk tehát ő egy azonosítatlan felhasználó. Képzeld el, hogy engedélyezzük, hogy bárki küldhessen be hírt még ez az azonosítatlan felhasználó is. Ekkor ahhoz, hogy kontrollálni tudjuk, hogy mi jelenik meg az oldalunkon az azonosítatlan felhasználóknak le kell tiltani, hogy a saját tartalmukat nézzék, hisz az nem a saját tartalmuk, hisz nem egy emberről van szó, hanem végtelensokról. ;)
Egy másik lehetőség, hogy minden node egyben egy kérdőív is és nem szeretném, hogy az egyszer már kitöltött kérdőíveket megnézze a felhasználó. Na ekkor is jól jöhet ez a lehetőség.

A Grantos részt az ACL modul adja hozzá a node access részhez ezért van az, hogy per user adhatod meg ezeket a jogokat. Az ACL ugyanis ezt a lehetőséget adja hozzá a rendszeredhez.

Mivel két hozzáférés szabályzó modult használsz kénytelen vagy elfogadni, hogy nem egy jól átlátható és a "nem túl értelmes hozzáférés szabályozó beállításokat" nem engedő késztermékkel állsz szembe. Ez azért van, mert ha pont azt tudná a rendszer ami neked kell, akkor pont csak Te tudnád használni. :D Sajnos lehetőséged van hülyeségeket is beállítani, sőt ha egy csoportnak adtál valamilyen jogot, akkor a felhasználók között már nem csak azok fognak feljönni, akik nincsenek az adott csoportban. Ezért érdemes neked eldönteni, hogy hogyan jársz el melyik jogot fogod csak csoportra és melyiket csak felhasználóra és melyiket vegyesen.

pp

1
0
Sk8erPeter képe

Szia!

+1, először is köszi, hogy írtál a témában! :) (már tartottam tőle, hogy senki nem fog ;))

Vegyük akkor az egyszerűség kedvéért úgy, hogy ez egy "épület" tartalomtípus.
Az a baj, hogy a terv szerint 2-3 feltöltő szerepkörben lévő emberke is lenne az oldalon, akik nem hozzáértők, és akiknek az lenne az első bajuk, hogy "de mé' kell először külön feltölteni egy galériát arról, hogy hogy néz ki az épület kívülről, ezt elmenteni, aztán külön galériát az épület archív fotóiról, ezt elmenteni, és így tovább, aztán külön feltölteni magát az épületet az összes paraméterével, tulajdonságaival, és aztán ennél a feltöltésnél valahogy nagy nehezen kibogarászni az előbb létrehozott külön-külön galériákat, hogy végre hozzá legyen kapcsolva az épülethez, mert önállóan értelmetlen, hát ez tök hülyeség" - tulajdonképpen jogos lenne a problémájuk, én is macerásnak érezném külön-külön elvégezni ezeket a feltöltéseket. Ezért szeretném valahogy egy helyre összehozni a dolgot, hogy minden kategóriába lehetőleg egy felületen lehessen feltölteni a képeket.

Na, most megtaláltam ezt az issue-t, ebből kiderült, hogy másnak is volt baja már az Inline Entity Formmal, hogy nem sikerült mezei content type-pal összehozni, na de azóta úgy néz ki, ezt javították, de még így is bugosnak tűnik, megmutatom, hogy néz ki a validációnál:

Entity reference + Inline Entity Form + Building+subgallery content type

Valami ismeretlen mezőt hiányol.

Így már nagyjából látható, mire gondolok.
Tehát össze szeretném kapcsolni ezt a folyamatot, nem teljesen szétválasztani.

De ne kímélj(etek), ha van esetleg alternatív ötleted, bármilyen tanácsot szívesen fogadok!
Köszi!

Tehát tulajdonképpen első körben magát a feltöltést szeretném ésszerűbbé, kényelmesebbé tenni, hogy a mezei júzer ne szidja az anyámat, hogy miért így csinálta meg a szemét fejlesztő :), a megjelenítés már a további macera, de persze az is megoldandó kérdés.

0
0
Phoere képe

Én költöztetésnél kihagytam a drupal-migrate-ot, inkább manuálisan végeztem, eddig sikerrel:
- az új helyen telepítettem egy tiszta Drupalt. Ha ez működik az adott domainnel, akkor már működnie kell az oldaladnak a végén. (Ezzel kell kezdeni az egész műveletet, hiszen ha ez nem működik, akkor valóban szerver beállítási gond van!)

- teljes fájl állomány lementése a régi oldalról a sites/all és a sites/default könyvtárból (kivéve a settings.php-kat). (Ha Windows platformra mentesz, akkor figyelembe kell venni, hogy a Windows nem kezeli a kis és nagybetű közötti különbséget, ilyen esetben felülírás lesz). Az egyéb fájlokra elvileg nincs szükség, hacsak nem került valami egyéb helyre is, ami nem szerencsés.

- az eredeti adatbázist darabokban importáltam. Kérdés mit jelent a nagy oldal. Volt ahol elég volt egyes cache táblákat kiüríteni, utána már a PHPMyadmin is lekezelte egyben az egész adatbázist, de volt, amikor 8-10 csomagban exportáltam, majd importáltam.

- az új telepítés teljes adatbázisát lecseréltem az exportáltra. Ha az importálás során hiba jelentkezett, akkor megnéztem, melyik tábla akadt ki és arról külön exportot készítettem a régi helyről - persze a nem működő mentés többi tábláját is újra exportáltam, ha kellett. Szóval ez volt igazából a macerás része. Főleg a cache_pages, cahe_menu és még egy-két cache tábla okozott gondot, de ezeket ürítettem és úgy exportáltam. Ekkor már nem volt hiba.

- a sites és default könyvtárakat feltöltöttem.

Mivel az új Drupal settings.php-ja változatlan maradt, így azonnal működőképes volt az oldal.

Annyi gond fordult még elő, hogy a régi tárhelyről a fájlok letöltése esetenként nem, volt tökéletes, megszakadt a kapcsolat, ez az új oldal indulásakor derült ki, de ezek egy-egy érintett modul/fájl ismételt felmásolásával orvosolható volt.

Ha kisebb oldallal működőképes másolatot tudtál létrehozni, akkor feltehetően a nagynak is működnie kell.
Okozhat még gondot, ha eltérő PHP-verzió fut a két szerveren, pl. az újon 5.4, ezzel akadnak problémák, de elsősorban a Drupal 6-osnál.

Az elmúlt 2-3 hétben 7 önálló Drupal oldalt költöztettem sikeresen a fenti módszerrel. Remélem ezzel előbbre jutsz.

2
0

Csökönyi Ferenc

niel képe

Vissza kellene állítani az eredeti node jogosultság tábla tartalmat, ha kikapcsolod a modult, az nem elég, attól még a beállításai megmaradnak az adatbázisban.

Na ezt hol tudom?

Üdv,
niel

0
0

Üdv,
niel

digand képe

Hy

A user ugyanaz de másik az adatbázis!!!
Persze a másik adatbázist irtam a drupalhoz ugyhogy nem az a gond!!
A drupalhoz(ez az adatbázis neve) be van állitva ez a user!!

0
0
eMeLA képe

310-re állítja a TYPE értéket. A baj az a Saját adatok-kal, hogy dinamikusan állítja elő (ugyebár az user után íraja a felhasználó id-jét) és az adatbázisban nem tárolja. Magam is ezzel kezdtem.

0
0

...mit tudok: http://web.termuves.hu

pp képe

A hibaüzenet arról szól, hogy az 509-es user(gondolom az ftp usered) által létrehozott könyvtárba nem tud új könyvtárat létrehozni az 508-as user(gondolom evvel a juzerrel futnak a skriptjeid)

pp

0
0
pp képe

"Enter the title or NID of a post "

írd oda a tartalom címét vagy az azonosítóját(node id). Ez ugye egyedi, és ezt az egyedi id-t hiányolja az fckeditor.

pp

0
0