Phoere képe

Köszi, ezt ki fogom próbálni.

Az nem tűnik jónak, hogy közvetlenül adjam meg a term id-jét, hiszen a lényeg, hogy az éppen aktuális term-hez jöjjön létre a lista, lényegében az adott szótár bármelyik term-je lehet az. A linkből kellene tehát - feltehetőleg - kivenni a megfelelő argumentumot - ezért írtam be a pathauto-val létrejött url sablont, ahol a fokategoria és az alkategoria mindig más. Próbálkoztam az arg(3) és arg(4) értékekkel a php-kód alapján való argumentum kinyeréshez, de nem jött össze.

A "gyári nézeten" azt értettem, ami megjelenik, ha egy adott kategória/kifejezéshez tartozó tartalmak listáját kérem le. Ezt tehát tudja alapból az Ad Classified, (hogy ezt Views-sal képezi vagy másképp nem tudom.) Ezt a megjelenést szeretném felülírni.

Még egyszer megnézem, hogy a taxonomy/term/% működik-e, nekem nem működött, de lehet, hogy valami más beállítás nem volt jó a Views-ban.

Köszi a segítséget.

0
0

Csökönyi Ferenc

Phoere képe

Köszi, ezt ki fogom próbálni.

Az nem tűnik jónak, hogy közvetlenül adjam meg a term id-jét, hiszen a lényeg, hogy az éppen aktuális term-hez jöjjön létre a lista, lényegében az adott szótár bármelyik term-je lehet az. A linkből kellene tehát - feltehetőleg - kivenni a megfelelő argumentumot - ezért írtam be a pathauto-val létrejött url sablont, ahol a fokategoria és az alkategoria mindig más. Próbálkoztam az arg(3) és arg(4) értékekkel a php-kód alapján való argumentum kinyeréshez, de nem jött össze.

A "gyári nézeten" azt értettem, ami megjelenik, ha egy adott kategória/kifejezéshez tartozó tartalmak listáját kérem le. Ezt tehát tudja alapból az Ad Classified, (hogy ezt Views-sal képezi vagy másképp nem tudom.) Ezt a megjelenést szeretném felülírni.

Még egyszer megnézem, hogy a taxonomy/term/% működik-e, nekem nem működött, de lehet, hogy valami más beállítás nem volt jó a Views-ban.

Köszi a segítséget.

0
0

Csökönyi Ferenc

toreki képe

Szia

Az adatbázisod méretét több minden növeli:
- maga a táblastruktúra és az userek/jogok leírása
- a benne található adatok
- a táblákra rakott indexek

Extrém esetben (pl.: túl sok index szöveges mezőkre) az index adatok mérete többszöröse is lehet a tényleges adatoknak.

saját adatbázis sql dump 36,4MB
MyISAM táblákban tárolva phpmyadmin szerint 45,5BM az adatbázis
InnoDB táblákban tárolva phpmyadmin szerint 92,3BM az adatbázis

Viszont a tényleges méret és a phpmyadmin közötti eltérés nem lehet ekkora, kérdezz rá a szolgáltatónál.

Még valami felmerült. Normálisan az InnoDB soha sem shrink-eli a fájlokat, amiben az adatbázis van. Ha a innodb_file_per_table konfig be van állítva, akkor lehet optimalizálni. Lásd itt.

Persze nem biztos, hogy nálad ez a gond.

1
0
vajdasági képe

Igen, van ra lehetoseg.

Tovabbra is kitartok az elobbi uzim melett hogy olvasgasd at jol azt a konyvet.

Tobb megoldas is letezik, es ha jol attanulmanyozod akkor leeht magad is rajossz megoldasokra. Egy lehetoseg pl. az hogy letrehozol egy hirek tartalomtipust es az a statikus oldal ala beszursz egy blokkot amibe a views oszeszedi neked az oda illo hireket.

De ez nekem inkabb annak tunik (ha jol belelatok a fejedbe) hogy a taxonomy termnek van egy szoveg resze (nalad az lenne az a statikus oldal) a hirek tqartalomtipushoz meg hozzadasz egy mezot ami a term-re mutat. es ha a termet listazod akkor latod a tartalmakat hozza.

Szotar (taxonomy): Erdekessegek fajtai
- erdekes kepek
- erdekes videok
- erdekes anyamfule

A tartalomtipusnal ha letrehozod az uj mezot akkor a tartalom bevitelekor csak bejelolod hogy erdekes kep vagy video vagy micsoda.

Valami ilyesmire gondoltal?

0
0
Dean képe

Mivel a Simplenews modulhoz szervesen kapcsolódik a Mime Mail modul, átnéztem annak is a beállításait.

Szerintetek az hogy az alábbi mező nálam nincs bejelölve lehet akár közvetve okozója ennek a hiba jelenségnek?

Mező:
Egyszerű címformátum használata
Az email címek a megszokott [email protected] formátumban használhatóak.

Ezt sem jelöltem be, mert nem gondolnám, hogy bármiféle hiba okozója lehet az, hogy ha nem az egyszerű címformátum van használatban.

Az itt bejelölhető mezők közül nálam csak ez van bejelölve:
Használja a webhely stíluslapjait

Csak azt próbálom kitalálni mi okozhatja azt, hogy összekeveri az e-mail címeket, amikor legenerálja a leiratkozó linkeket minden kiküldött levél végére.

Kb ilyen linkeket generál most:
http://saját_domain/hu/newsletter/confirm/remove/e2994e865419t2

0
0
Geva képe

én is így gondolom:
- Zoli, a megoldásod az img minden megjelenésére vonatkozik, míg az enyém csupán a views-ban láttatja az img alt szövegét :-)
(az alt szöveget kell megjeleníteni a views_slideshow-val elkészített vetítésben --> az én olvasatom szerint. Kérdés: mit szeretne a kérdező) ...vagyis mindketten a felvetett probléma értelmezése szerint oldottuk meg :-)

Kiss Laci írta: „oldalakra feltöltött képekből áll össze a váltókép” ezt nem többszörös mezőként értelmeztem

- többszörös image field mezőre nyilvánvalóan nem jó megoldás a plussz felirat mező, ennél az esetnél egyértelműen maradna a megfelelő templét kiválasztása, majd php kóddal az alt kijelzése.
A plussz felirat mező - egyszeresen engedélyezett img field mezőnél - jó megoldás lehet olyanoknak, akik nem beszélnek php-ül :-)

szvsz így már kerek a téma,
Zoli, köszönöm a kérdésedet
üdv
Éva

1
0
magveto képe

Hát nem ilyen válaszra számítottam, de... talán maradok az a verziónál... Neked mint programozónak, elhiszem, hogy igazat mondasz, de nálam mint nem programozó csak felhasználó az ubercart a győztes. Remélem a commerce is számba veszi egyszer az egyszerű felhasználók igényeit is. Hogyan nyert az uc.? Hangsúlyozom: a d7 megjelenése után próbáltam ki a commercet mivel annyira agyondicsérték vaciláltam, hogy talán még érdemes az átállás...

1:0 uc-comm
ubercart: telepíted, beállítod, megy. Nagy része magyar.
commerce: telepíted, nem megy azonnal még macerálni kell amit akkor csak angolul próbáltak magyarázni... akkor még az egész angol volt.

2:0 uc:comm
uc: feltöltöd a képet, ok.
comm: Kétszer töltöd fel a képet... Nekem, csak egyfajta termékem van, semmi kedvem minden képet kétszeresen feltölteni.

Szóval talán egyszer megérik a comm is, hogy átmenjek de az még nem most van... :)

0
0
druid képe

Nem támogatom a magyar nyelv rombolását, szóval maradjunk az export szónál, az legalább egyértelműen angol szó, a "ki" igekötő sem kell elé.

Ami a lényeget illeti: újratettem mindent, és nem tettem fel a Devel-t, mivel még csak tesztelem a D10-et és az ECA-t. Szeretném elhagyni a Drupal 7-est, de ez elég nagy munka lesz, főleg, mire az egész honlapot újracsinálom, mivel nem bízok semmiféle migrate megoldásban.

Leírnám ide a tapasztalatokat, hogy mások is okuljanak, de látom ez az oldal halott.

Írod a Configuration Manager használatát. Azt csináltam vele, hogy időnként exportálom az adott állapotot, és ha valami elromlik, akkor importálom a korábbit, a Devel-en kívül még ez lehet, ezek szerint nem lehet megbízhatóan használni, ahogy korábban a Feature modult se. A Backup and Mugrate modul meg úgy szar, ahogy van, azt is sikerült elkúrniuk.

Pedig jó lenne, ha a Configuration Manager jó lenne arra, hogy visszatérjek egy korábbi állapotra (ami a tartalmakat érintetlenül hagyja, tudom, bár ebből is lehetnek problémák, mert ha egy későbbi tartalom alól kiszedjük az adott modult, amivel készült, mármint a korábbi állapotra visszatérés miatt, akkor gondolom a tartalmak ott maradnak az adatbázisban, de már sosem lehet kezelni azokat, csak szemétként maradnak ott...).

A Drupal org-ra tettem fel pár hibajelzést egyes modulokkal kapcsolatban, kérdeztem a Drupal Answers-en, de elég körülményesek ott az adminok.

A Slack oldalt meg egyszerűen nem értem. Regeltem, de hiába kattintok az adott linkre, semmi. Az egész olyan, mintha egyszerre rúgnák ki a régi Drupal-osok lábait, a múltat végképp eltörölni jegyében.

Amúgy már az is eléggé kiakasztó, hogy ha valami kis hiba történik, pl. egy rosszul megadott ECA szabály, vagy más modulnál valami, akkor elszáll az egész honlap a

The website encountered an unexpected error. Try again later.

hibaüzenettel, és adott esetben részletesen ki is ír olyan infókat, útvonalakat a Drupal, ami nagyon kényes. A biztonsági dolgokat itt kéne kezdeni, hogy ne írjon ki ilyeneket a honlap, csak az admin számára, alapból.
Nem is értem, ezt hogy gondolják a Drupal fejlesztői...

0
0
zeniten képe

Ez a fehérlap-jelenség az én problémám is.
De konkrétan két modul okozta, mindkettő nagyon kéne.

- Az egyik a MENU ROLE - ha be van kapcsolva akkor az az érdekes jelenség, hogy az általam létrehozott menüpontokat nem tudom utána szerkeszteni, mert fehérlapba futok. Ennek nagy a memória-igénye? De ha a "gyári" menüpontoknak adok hozzáférhetőséget, akkor nincs gond - kivéve, hogy nem működik a dolog, ugyanúgy megjelenik mindenkinek...

- A másik az import html, de ott a server oldalon több gond is akad...

Kérdésem: elképzelhető-e, hogy ez a memória miatt van, korábban azt a választ kaptam a rendszergazdától (hostingolok), hogy nincs memória limit - ezt kezdem kétleni ezt a fórumot olvasgatva... (pl. a color module smink-szín állító grafikus része sem jön be)

0
0
pp képe

Gyakorlatban nem javasolt ilyen megoldás számtalan hátránya miatt. Ha már fizetős szerver, igazán rászánhatnád azt az évi 2000 Forintot egy normális domain névre. ;)

Lehet az IE nem hagyja bejegyezni azt a cookie-t amit egy másik szerverről küldesz, hisz a főoldal és az aloldal más domainen van. Próbáld csökkenteni a biztonsági szintet az IE-ben. (ez csak kísérlet, hogy kiderítsük mi a baj.)

A problémák a megoldással:
1. UW szerintem ezt nem szereti, de Te olvastad a felhasználási feltételeket nem én.
2. A Google-t nem érdekli a frame és a kis genya mindig a valami.fizetos.hu domain-ra fogja dobálni az oldalt. (persze belehekkelhetsz egy kis tündibündi js-t...)
3. Nem lehet bookmarkolni az oldalalkat.

pp

0
0