aboros képe

a last use, first use oszlopot azért tettem bele, hogy lásd ilyet is lehet, szemléltetve, hogy többféle aggregation type van. (ugye az advanced reszbe kapcsoltuk be azt az aggregationt)

a nézetben ugye ott van benne a dátum, mint felfedett szűrő. a táblázatban látható first use, last use, az csak a szűrt intervallumon belülre érvényes. tehát ha beállítasz olyan dátum feltételt, hogy is less than, -42days akkor a 42 nappal ezelőttnél korábbi "tag használatot" (node beküldés) listázza majd a táblázat, a last use legfeljebb 42 nappal ezelőtt lesz a táblázatban és minden számláló is kevesebb lesz, azok a tegek amiket 42 nappal ezelőtt még nem használt senki eltűnnek a táblázatból, miegymás. ez mind megy már a fenti nézettel is.

a dátum a nodeban tárolódik amit a felhasználó beküld. a teg, a nodera vonatkozik igazából. azt számolgatjuk össze melyik tag hányszor szerepel, a dátumot a nodeból szedjük és ki tudunk még onnan más dolgokat is, ki a user aki akkor abban a nodeban használta a teget, mi a profilképe, ha van a nodeba más mező (kép, link) azt is, miegymás.

szóval a válasz erre, hogy vajon az adatbázisba minden egyes tag/term felvételkor eltárolja-e annak az időpontját, vagy csak az első és a legutolsó használat időpontját? a válasz: nem. és igen. :) nem a tag tárolja, a user nem teget küld be, hanem tartalmat, amit tegel.

0
0

-
clear: both;

pp képe

Drupal abból indul ki, hogy az olyan menüpontnak ami nem vezet sehova, nem sok értelme van. Ezért aztán ezt a fajta, előre kialakítom a menüt hozzáállás nincs nagyon támogatva.

Legyen tartalmad, és azt strukturáld. Ezt támogatja a rendszer igazán. Ez azt jelenti, hogy praktikusabb a node-okat/tartalmakat, view-kat/listákat/nézeteket létrehozni, és a létrehozás közben/után beállítani a menüt.

A kérdésed második felére visszatérve, most jobban jársz, ha Felépítés / Blokkok résznél kirakod a "Main menu" menü blokkot az első oldalsávba, az általad mutatott csík ugyanis nem menü(menu), hanem az csak egy hivatkozás gyűjtemény(links). Ez előbbi tartalmaz struktúrát, míg ez utóbbi flat, vagyis nem tartalmaz struktúrát.

Hogy a Main links/fő hivatkozások honnan vegye az értékét, azt a Struktúra / Menü / Beállítások menüpontban tudod állítani. Alapértelmezetten a Main menu-ből jön a Main links, a User menu-ből a secondary links. Ha beállítod, hogy a Másodlagos hivatkozások a Main menu-ből jöjjenek akkor egy menüpont kiválasztásakor, az almenüi itt fognak megjelenni. De ez csak két szint. Ha több szinted van, akkor ezzel a módszerrel azt már nem tudod megjeleníteni, szükséged lesz pl. a Menu Blok modulra, mellyel statikusan tudsz kirakni blokkba menüt, vagy a Nice Menus modulra, mellyel dinamikus legördülő menüt tudsz kirakni.

Remélem segítettem.

pp

4
0
Balu Ertl képe

AFAIK az XML sitemap nem humán látogatónak készül, ezért nincs rajta formázás és egyáltalán nem jelenik meg az oldalon. Csak legenerálódik rendszeres időközönként és a háttérben várja, hogy egyszer a keresőrobotnak feltérképezéskor szüksége legyen rá – hasonlóan az rss.xml-hez.

Valóban lehet CSS-sel XML-t formázni, de szerintem annál elegánsabb megoldás egy modullal human readable sitemap-et készíteni, ami lényegében nem más, mint egy oldal a smink alap kinézetével tele rengeteg linkkel a webhely különböző pontjaira, lehetőleg valamilyen hierarchikus struktúrában, átláthatóan. Ezt az oldalt lehet aztán a láblécben apró betűs ”Oldaltérkép“-ként linkelni, de ennek a névhasonlóságon kívül vajmi kevés köze van az XML sitemap-hez.

Tipp: ha már SEO-ról kérdezgettél a másik fórumban, az biztosan segít valamennyit, ha ezt a sitemap.xml fájlt feltöltöd Google Webmaster Tools-ban. Mert ugye használsz GWT-t?

1
0
Geva képe

Értelmezésem szerint annak a mezőnek a tartalmát kellene átadnod a - minden eseménynél ugyanazon - megjelenő webformmal készített űrlapnak, amelyik mezővel a calendar-hoz kapcsolódik. (a dátum nélkül nem értelmezhető a foglalás, az űrlap eredménylistájában)

egy mo.: az űrlapnál tudsz olyan text mezőt definiálni, amely az űrlap url-ből veszi az értékét, jelen esetben a dátum mező tartalmát.
%get[kulcs] - A vezérjeleket http://example.com/my-form?foo=bar formátumban létrehozott webcímekben is meg lehet adni. A példa alapján a %get[foo] vezérjel értéke "bar" lesz.

...ehhez persze fel is kellene tenni a hívásnál a linkbe a dátumot,
Kérdés, hogy a foglalom linkkel - hogyan tudod ezt az értéket odatenni, illetve elég-e ha a dátum szövegként kerül az űrlapra.
A registration modul readme-t-t olvasva, van konfiguráció lehetősége, itt nézz körül először, utána a nézetek körül, hiszen a calendar oldalai views-l készülnek.

ha linket tudnál megadni, könnyebb lenne segíteni
érdekelne sikerült-e, ezért kérlek, jelezz vissza róla, köszönöm.

0
0
DruTa képe

Igen, ezt sejtettem, hogy a sorrend lehet a gond.

Akkor talán az a sorrend lenne ideális, hogy Felhasználó, Böngésző, majd web, mivel eu-s lesz az alapdomain, tehát azzal semmire se megy a rendszer, ha belép máris jó a felhasználói beállítás miatt, ha nem lép be, remélhetőleg a böngészőben a saját nyelvét használja.

A Munkamenet nincs bekapcsolva, mert azt nem igazán értem mit játszik.

Lehet egy kérdéssel több? :-) (Régen volt egy ilyen tévéműsor, ha jól emlékszem)

Szóval mezőket, node-okat, változókat is fordítottam az i18n modullal, kissé néhol nehézkes, mert nem egy közös helyen jelennek meg a nyelvek, hanem egyenként kell, szóval nem teljesen egységes a működése, de ez van.

Viszont amikor a Címlap menü nevét akartam lefordítani, ott nem fordítás történt valójában, hanem létrejött mindegyik nyelvhez egy címlap menü és persze azt dobja be az adott nyelven, de nem értem itt miért nem csak lefordított.

Így most a főmenűben annyi Címlap nevű menü van (adott nyelven), ahány nyelv.

OFF: ti hogy kerestek modulokat az org-on? Mert ha beírom pl. hogy access, és csak a címekben (modulnevekben) szeretnék keresni, akkor arra nincs lehetőség, és a szűkítésekkel sem érek sokat, márpedig ha profil access szerű modult szeretnék, akkor kismillió találat lesz, mivel a profil szó és az access szó is sok leírásban szerepel. Itt a hun kicsit talán jobb a helyzet.

0
0
Phoere képe

De nem így van! Nem ismered eléggé a Drupalt, a taxonómia működését.

Attól, hogy a node létrehozásakor hozol egy új kifejezést, az nem kapcsolódik a node-hoz! Fordítva, majd a node mentése után a node kapcsolódik a kifejezéshez. Ha ismered az SQL adatbázis működését, akkor ezt is megérted. Csak a megfelelő lekérdezés alapján lehet visszafejteni fordított irányba is a kacsolatot.

Mindössze technikailag lehetőséget biztosít a Taxonomy autocomplete modul, hogy a node létrehozásakor adj a szótárhoz új kifejezést. Ha ez a modul nem lenne, akkor először be kellene lépned a taxonómia szótár adminisztrálásába, hozzáadni a kifejezést, majd elkezdeni a node létrehozását. De aki ezt csinálta, az nem gondolta, hogy valakinek kellene a node-k publikusságával összekapcsolni a modul működését, és a kifejezések kiválaszthatóságát így szabályozni. Ilyenkor jön, hogy akinek ilyen kell és szerinte másnak is kellene, az ír rá egy modult és közzéteteti. De azért ez a Drupal ismeretének egy magasabb szintje, én sem vállalkoznék rá, ettől még odébb vagyok tudásban.

Hiába hozod létre a node-val együtt a kifejezést, semmilyen adat nem tárolódik a kifejezéssel együtt, ami az adott node-ra utal. Ha a következő lépésben szerkeszted a node-t és egy új, már létező kifejezést állítasz be hozzá, akkor az előzőleg létrehozott kifejezésről ember meg nem mondja, hogy melyik node-val együtt hozták létre, vagy egyáltalán, ki mikor, hogyan adta a szótárhoz. Ez a kifejezés is a szótár tagja lesz és kiválasztható.

1
0

Csökönyi Ferenc

HF leon képe

Az igaz, hogy vannak dolgok, amik, még hiányosak, de többnyire a legtöbb funkció -értem itt a külsős modulokat is -már elérhető drupal 8 alatt is. Sok olyan funkció is akad, amelyek picit máshogy mint rég csakugyan elérhetők. Valamint a CKEditor kiegészítő moduljainak tanulmányozása jó támpontot ad a jelenleg, még nem integrált funkciók egyéni integrálásához. Mondhatni mostanra, már nagyon kevés olyan probléma van, amelyre drupal 7 alatt létezett, de drupal 8 rendszeren, még nincs megoldás.

Nagyon fura volt olvasni ezt a posztot. Meg is rökönyödtem, rajta, míg meg nem láttam a dátumot :D.

Bárki szeretne komolyabb oldalt fejleszteni bátran ajánlom a 8-as rendszert, hosszú távon pedig mindenképpen ez a jobb választás. Talán csak a tárhely igény, ami lényegesen nagyobb. Pár száz megás tárhelyre semmiképpen sem javaslom. 500 MB felett, már érdemes lehet vele próbálkozni, de nagyobb mennyiségű tartalom esetén inkább az 1 GB, vagy több az ajánlott (itt, már nagyban függ a projekt jellegétől az elfoglalt tárterület).

Nekem tetszik a 8.4-es verzió és az új fejlesztések is biztatóak, amelyek megjelentek benne. Nincs már messze a 8.5-ös változat sem. Kezd kialakulni egy logikus sok funkcionalitással és lehetőséggel rendelkező alaprendszer. Ez azért is dicséretes, mert az alaprendszerbe integrált funkciók garantáltan folyamatosan karbantartottak, jól együttműködők és biztonságosak.

Kíváncsi vagyok bedől-e, még valaki a 2015-ös topiknak XD.

Kellemes karácsonyt és közelgő 2018-as újévet minden látogatónak!

1
0
HF leon képe

Tulajdonképpen a koncepció egy amolyan legó struktúra. A szerkesztői felületen a cikk írója előre elkészített "legó" elemekből választhat, amelyek mind fixen testre vannak szabva. Ezekből az elemekből pedig összelegózhatja a cikket. Vannak fix elhelyezkedésű mezők a cikk elején és végén, de a közepe egy paragrafus, ahova a különféle paragrafus elemeket szabadon választhatja ki. Így html, vagy egyéb kód nem nagyon kerül elmentésre szinte majd minden esetben csak szöveg, kép, videó, audió. A paragrafusokat a szerkesztő tetszőleges sorrendben, számban használhatja, de a bennük lévő elemek a paragrafus egyedi sminkjein keresztül kerülnek kialakításra.

A továbbgondolt változatban a szöveges rész is felbontásra kerülne, így lenne néhány címsor, felsorolás, szöveges rész, -ahol csak erősen korlátozott lehetőségei lennének az írónak -valamint néhány egyedi blokk.

Amin viszont elgondolkoztam az az adatbázisban létrejövő rengeteg mező. Nem okoz-e ez hosszú távon sok cikk esetén komolyabb lassulást.

Erre lennék kíváncsi. Az angol oldalakon megoszlanak a vélemények a különböző módszerekkel szemben, hogy melyik módszer a jobb strukturált tartalom készítéséhez a média entitások, vagy más tartalomrészek behúzásához.

Ezekhez én kényelmes megoldásnak érzem a paragrafusokat. Amikor fixen előre eldöntött a struktúra ott nem szükségesek. Viszont a drupal nem ad alapból lehetőséget, még csak a tartalomtípusban megjelenő mezők szabad rendezésére sem. Persze admin felületen igen, de ott is az összes tartalomra egységesen. A tartalom felvitelekor erre már nincs lehetőség.

0
0
Illyés Edit képe

Ha a jelenlegi helyen is van PHPMyAdmin, akkor az Export funkcióval tudod exportálni. Jelöld ki az exportálandó táblákat (az összeset), pipáld be a "Tábla eldobás" opciót (ez előbb törli az új helyen lévő adatbázis tábláit, mielőtt beimportálná a feltöltött tábláidat), válassz tömörítést, kattints a Végrehajtás gombra. A lementett tömörített állományt pedig az új helyen beimportálod.

Ha nincs PHPMyAdmin, akkor a MySQL mysqldump alkalmazásával tudsz dumpot készíteni:

mysqldump --user adatbazishasznalo --password=jelszo opt adatbazisneve > adatbazisneve.sql

Az adatbazisneve.sql fájl a dump, ezt felmásolod a szerverre és beimportálod parancssoron keresztül, ha van hozzáférésed:

mysql adatbazisneve < /dump/utvonala/adatbazisneve.sql

Ha nincs hozzáférésed a parancssorhoz, akkor meg lehet próbálni PHPMyAdmin-on keresztül. Régebbi verzióknál gyakori a karakterkódolási probléma, ha előjön, kérj segítséget a tárhelyszolgáltatótól.

0
0

Egy tartalom több menüpontból - pathauto - D7

ha5abe képe

Sziasztok! Az alábbiban kérem a segítségeteket (D7):

Már minden működik ezzel kapcsolatban, csak az álnevek hiányoznak! A felhasználó jelölhesse meg (jogosultságfüggően, menütérképszerű megjelenésből) hogy a tartalmát melyik menüpontokból kívánja elérhetővé tenni és pathauto-val automatikusan felvetetni minden menüponthoz egy-egy útvonalálnevet.

FoMenuA
---A1
x--A2
---A3
FoMenuB
---B1
---B2
---B3
x--B4
x--B5
---B6

Ahol x jelöli a megjelölt menüpontokat. Az alábbival próbálkoztam:

Melyik modulhoz, modulokhoz kapcsolódik a téma?: