hát a nézetben nem szűrő kéne
hanem argumentum. most erről nem tudok 6.x screenshotot mutatni, de itt egy 7.x https://skitch.com/aboros/8t5gq/argumentum nem kell a szűrő, hanem egy user id argumentum kell, provide default, user id from logged in user. és a jokernek, ami alapból 'all' megadod, hogy '1' ami ugye az admin user idje, akkor az úgy szerintem működni fog.
ha mégse, akkor ugyan ez az argumentum, csak provide default, php code, és megnézzük ki az aktuális user és ha uid1 az, akkor visszaadjuk a joker stringet, hogy 'all' egyébként meg az aktuális idt.
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nagy nehezen sikerült
Nagy nehezen sikerült belerakni, amit szerettem volna, viszont kiderült, hogy mi a probléma.
A Drupalban alapból v1.4.4 jQuery van (vagy valamelyik másik modul rakta fel és az használja, nem tudom pontosan), viszont az én scriptem meg igényli a legalább v1.8.2 verziószámú jQuery-t, most hogy mindkettő meg lett hívva, összeakadtak.
Ha az alap jQuery-t cserélem újabbra, kiesnek egyes funkciók a Drupalból, ha marad a régi verzió, akkor meg az én scriptem nem fog működni.
Ilyenkor mit lehet tenni? Nem lehet meghatározni, hogy csak az én scriptem használja az újabb jQuery-t, minden más funkció használja a régit?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Különböző Taxonomy term view-k különböző tartalomtípusokhoz
Te csak arra az aspektusra adtál egy megoldást, amikor az oszlopok számában szeretnék különbözni. Az oszlopok számát csak példaként írtam, nem csak ebben különböznének.
Azt szeretném, hogy a taxonomy term view máshogy működjön, ha termékekről illetve ha blogbejegyzésekről van szó.
Mivel az egyik vocabularyt a termékekhez rendeltem, a másikat a blogbejegyzésekhez, alapban működik, hogy az egyik term-re kattintva csak az egyik tartalomtípus jön fel. Amit én szeretnék, hogy eltérő legyen a két esetben a taxonomy lista oldalak felépítése, és más szűrési feltételeket tudjak megadni. vagy például a termékek megjelenítési sorrendje egy term-en belül különbözzön a blogbejegyzések megjelenítési sorrendjétől (a fordított időrendtől).
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
rules event mégsem
szvsz rules event-re nincs szükség a modulodból(korábban én is ezt gondoltam), az a bizonyos Fizetési tranzakció mentése előtt/után event bekövetkezik a honlapra történő visszaléptetés után(sikertelen tranzakciót követően), így ezzel meg lehet csípni, csak ugyanúgy nem jelenik meg itt az üzenet a rulesből sem, ahogy a modulodból sem :-(
...az egy későbbi kérdés, hogy a Sikeres és Sikertelen fizetési tranzakciós állapotot meg lehet-e valójában különböztetni, ...
...talán valami oldal frissítés lehet a ludas az üzenet elnyelésében? hiszen látszik a jelentésben, hogy elvileg az üzenet megjelenítve, a szabály lefutott
...a KHB hiányolja az üzenetet a sikertelen tranzakció után :-(
Geva
----- Számítások - Kalkulátorok
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szia,
Szia,
Hasonló hibával régebben találkoztam, amikor a régi tárhelyszolgáltatónál voltak még az oldalaim. Egy bizonyos mennyiségű modul telepítése után összeomlottak egyes oldalak, majd eljutottam oda, hogy az admin oldalak nem jöttek be. Többször is újratelepítettem, de a a hiba előbb-utóbb előjött.
Végül a tárhelyváltás oldotta meg teljesen a problémát, az új helyen nem volt még összeomlás. A két tárhely közötti alapvető különbség a PHP memória nagyságában volt. A régi helyen csak 32 Mb volt, az új helyen 256 Mb.
Próbáld meg első lépésként letiltani az adatbázis naplózás (Database logging) modult, az nagyon jelentősen használja a memóriát. Talán ez segít, nekem időlegesen segített anno.
Csökönyi Ferenc
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Igen
(off: korán van, majd talán kijavít valaki, ha tévest írok)
Ha csak ezt az egy kifejezést akarod views-al megjeleníteni, az is megoldható.
A nézettel létrehozol egy oldalt, aminek az útvonalának a "term id"-re vonatkozó útvonalat add meg, pl: taxonomy/term/68
(ezt az útvonalat láthatod ha magát a kifejezést szerkeszted, a szám a term id.)
És ennél a nézetnél már olyan megjelenést állítasz be, amilyet akarsz, ez csak ennek a kifejezésnek a listájára fog vonatkozni.
Ha már általánosan felülírtad a taxonomy/term/% nézettel, akkor kicsit bonyolultabb, mert ott ki kell zárni az adott kifejezést, hogy ne mutasson két nézet ugyanarra az oldalra.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Elindulás
Keresd meg és hasonlítsd össze az Apache és a PHP hibanapló fájlait. (Amiket belinkeltél, egyik sem az. Valószínűleg nálad is *.log kiterjesztésűek és a Drupal docroot-ja felett, általában egy külön /logs könyvtárban találhatóak.)
Ha az Apache-é nem, de a PHP-é mutat friss időbélyeggel üzenetet, akkor nagy valószínűséggel már nem az Apache .htaccess fájlja környékén kell keresned a hibát (hiszen ő már rendben fut alant), hanem a felette, a Drupal szintjén kell kutatkodnod. A „The website encountered an unexpected error. Please try again later.” szöveget ugyanis már maga a D8 írja ki, tehát a Drupal az adott URL-en már tud futni, de valamilyen problémába ütközött az oldal előállítása során.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Én más irányba indultam
Igen nagyjából ez is jó, de ebben az esetben, hogy rendelhetek az alapértelmezett template helyett csak ehhez a modulhoz más kinézetet.
Én eredetileg külön akartam előállítani a linkeket, de ez a megoldás sem rossz, csak miként tudnék hozzá a book-navigation.html.twig helyett egy saját template-et rendelni, úgy, hogy az alapértelmezett navigációnak megmaradjon a saját template fájlja.
Így az alsó menü maradna az eredeti book-navigation.html.twig, de az egyedi modult külön twig fjllal formázhatnám.
Ha ebben tudnál segíteni annak nagyon örülnék, mert ekkor ez a megoldás is jó, sőt egyszerűbb is mint amit én próbáltam írni.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mire kell a Drupal
Szerintem a fő kérdés az, hogy mire kell a Drupal, ha az adataid kezelésére nem feltétlenül szükséges. Ha például csak a felhasználókezelést akarod a Drupalra bízni, akkor nyugodtan fejleszthetsz hozzá egyéni adatkezelési megoldásokat. De ha kell fejlett jogosultságkezelés, workflow, listázási funkciók (Views), eseménynaptár integrálás és még 10 másik funkció, ezek többnyire a node koncepcióra épülnek, tehát ha nem node-ként tárolod az adataidat, akkor ezeket a funkciókat nagy valószínűséggel el fogod veszíteni.
Teljesítmény szempontjából az olyan megoldások problémásak, amikor mondjuk van egy CCK tartalomtípusod, aminek az egyik mezője egy Views listát tartalmaz, aminek az elemei CCK tartalomtípusok mezői, amelyek megint csak listákat tartalmaznak, stb. stb...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm a választ!
Köszönöm a választ!
Nem, sajnos az összes tábla hiányzik :( Írtam a szolgáltatónak.
Ha ezeket mégsem tudják visszaállítani akkor viszont mit lehet tenni? Megvan a tárhelyen az a könyvtár (úgy tűnik) hiánytalanul, amibe a Drupalt telepítettem.
Ha a táblák eltűnnek, eltűnnek-e "örökre" az oldalak/node-ok, blogbejegyzések, ill. az azokhoz való hozzáférési lehetőség, vagy valahogyan visszahozhatók?
Pl. ha újra telepítem ugyanoda ugyanazt a Drupal verziót, létrehozom ugyanazokkal a beállításokkal azt a 2 db. usert, aki az oldalakat létrehozta plusz a Drupal könyvtár biztonsági mentéséből bizonyos mappákkal (gondolom : sites, modules, themes, (+?) plusz .htaccess, robots.txt, (+?) felülírom az újonnan telepítettekkel?
Köszi - Egon