Hojtsy Gábor képe

A felhasználói adatok csak egy táblában vannak, ha nem akarsz extra profil mezőket felvenni. Az uid egy szám, a felhasználó azonosítója, a name a felhasználói neve (nem az igazi neve:), pass, mail egyértelmű. Az init-ben letárolja a Drupal a regisztrációnál használt email címet, ez megmarad akkor is, ha később módosít. Mode, sort, threshold mind a hozzászólás megjelenítésére vonatkoznak, számok, a theme a választott smink (ha választhat a user, különben mindegy), signature az aláírás hozzászólásokhoz, created a regisztráció Unix időbélyege, changed az utolsó változási dátum időbélyege, status az aktív/letiltott állapotot jelöli, timezone a felhasználói időzóna beállítás, ha a felhasználó beállíthat ilyet (kikapcsolhatod), language a nyelv, picture a feltöltött avatár neve, és végül van a data. Ebben az összes többi felhasználóhoz kapcsolható adat van (a profil adatok és jogosultságok kivételével, amik 4.5-ben külön táblákban vannak). Ez egy serialize()-olt tömb, és bármelyik modul tárolhat benne adatokat. A roles bejegyzés bekerülése egy bug volt, amit a 4.5.1-es javított (vagy a 4.5.2 fog javítani, nem tudom most :)

0
0
pp képe


Gondoltam kézbe veszem a kezdeményezést

Fel is vetetted az ötletedet, amire reagáltam is. Megtisztelnél, ha ott válaszolnál nekem, miért is jó az amit Te mondasz és elmagyaráznád (úgy hogy én is megértsem) mit értesz azokon a furcsa fogalmakon amit ott leírtál.


, hiszen ahogy olvasom, többeknek is volt már gondja azzal, hogy nem kap számára megfelelő segítséget az oldalon.

Szerintem az a lényeg, hogy el lehessen igazodni könnyen az oldalon, és gyorsan meg lehessen találni a problémánkra a megoldást (már ha létezik megoldás) A Te megoldáod nem biztosítja ezt. Lehet most, vagy két-három hónapon belül igen, de gondolj bele mi lesz itt 5 év múlva?


Azt az ajánlást kaptuk Gábortól, hogy tegyük meg, amit tennünk kell! Ez szerint jártam el, de könnyen meg lehet hogy nem a megfelelő megoldást választottam!"

Pontos hivatkozást tudnál adni erre?


A megvalósítás nekem szinte mindegy, találjátok ki, hogyan a legegyszerűbb!

Már most itt az elején feladod?

Nah, nem offolom tovább ezt a topic-ot mert kapok a fejemre... :D
pp

0
0
szegedi képe

Beállítások:
név: gyoker
oldalnézet megvalósítása: pipa
url: menugyoker
view:list view
nincs lapozó és 3 node per page
fejléc lábléc: egy-egy sor, hogy látszódjon
blokk: semmi
mezők: tartalom cím, link egyebekben alapállapot
tartalom szövegtörzs: bevezető
parameter: nincs
szűrő: one of menufa (taxonomy fa)
felfedett szűrő: nincs
rendezés: létrehozás szerint csökkenő

Így elértem azt, hogy az adott menüpontba és alá beküldött cikkek közül a 3 legfrissebb látszik egy-egy mintasor között!

Amivel először próbálkoztam, hogy az URL-nek taxonomy_menu/1 -et állítottam be az jól működött csak sajna minden almenü helyén megjelen újra a 3 legfrissebb cikk, pedig ott az eredeti nézet szerinti összes cikket látni szeretném...

Most módosítottam az URL-t ahogy fennt leírtam és CREATE ALIAS gyártottam egy aliat a taxonomy_menu/1-re aminek az alias menugyoker...
Meg is jelenik a böngészősávban hogy URL/menugyoker, de ott a régi nézetet látom...:(

Mit rontottam el?

( mivel az aloldalak tartalma teljesen más kellene hogy legyen a jövőben, így nem igazán jöhez szóba, hogy mindenhol ugyanazokat a szűrőket használjam, arg-tól függő eltérésekkel...:( )
Szg

0
0
Hojtsy Gábor képe

Nem tudom te mennyit fizetsz azért az általunk igénybevettel összemérhető szolgátatásért, amit használsz, de itt sem a közösség nem fizet, sem mi nem fizetünk a hoszting cégnek. Szerintem ilyen ár/érték aránnyal kevés hoszting megállapodás büszkélkedhet.

Azt tudom, hogy mindezen körülmények mellett a cég bevételeinek jelentékeny részét pont ennek a vasnak a lecserélésére fordítja, hogy többek között mi is még jobb szerveren futhassunk. Azért azt tudjuk, hogy a raid nem csak arról szól, hogy beraksz egy hdd-t, hardver és/vagy szoftver feltételei is vannak, amiket össze kell lőni, illetve nem sok értelme van mondjuk egy régebbi architektúrájú, vagy lassú vinyót venni, amikor kilátásod van egy teljesen új jobb vasra. Ugye pont az ilyen taktikázás veszélyes, és miközben az ember sokkal jobbat akar, mint ami az aktuális helyzet, lehet, hogy elsiklik a gyorsabb áthidaló megoldások felett. (Tudomásom szerint most még ugyan nem egy friss vason fut a szerver, de a raid már megoldott kérdés).

Megismétlem, hogy azért az összegért (nulla forint), amit a szolgáltatásért kiadunk, a Drupal.hu általános rendelkezésre állása és működése szerintem korrekt. Egyelőre nem volt jelentkező, aki az általunk használt szolgáltatásokat mind átvette volna, és hosszú távon megegyező összegért hosztolta volna az oldalt, ennél jobb rendelkezésre állást és supportot biztosítva.

miqlas képe

Hello!

Szerintem az a legfontosabb, hogy az ember intelliegensen kérdezzen. A "Nem megy!!!! Miért?" Kérdésre sosem kapnék megfelelő választ :)

Hmmm, filtered html? Eszembe sem jutott, de tényleg így van! Működik. Köszönöm szépen.

Volna még egy kérdésem:
Tapasztaltam, hogy ha írok egy tartalmat, s elmentem, megjelenik a kezdőlapon. Ha ezek után szerkesztem, akkor ezután csak az admin rangúak láthatják a szerkesztett tartalmat, pedig anyonymous user-nek is van joga elérni a tratalmakat.

Ezt eddig úgy javítottam, hogy bekapcsoltam az összes modult, aztán pedig a nem kellőket ki. De ez így ugye nem a legjobb.
Viszont emlékszem, egyszer a súgóban találtam egy részt, ami valami ilyesmit tartalmazott: a jogosultságok aktualizálásához kattintson ide. Ezt kerestem, de nem találom. Nem tudja valaki, merre lelném?

Másnál is előjön-e ez a probléma? Nincs rá valami szebb megoldás?
Köszönöm előre is!

Az XML-RPC szerkesztőkkel egy programból szerkesztheted és publikálhatod a tartalmakat, így nem kell az adminfelületen bányászni.
Én ezt használom (windows-on): Zoundry. Többféle bog API-t támogat, így Wordpressel is használható :)
Hozzáadtam az img tag-et, és most már a programból tudok képeket publikálni. Köszönöm mégegyszer!

[miqlas]

0
0
Anonymous képe

A telepítő magyar nyelvű leírása alapján az 5.2-es verziót az 5.1-es magyarítással együtt töltöttem le és csomagltam ki.

Commander-rel feltöltöttem a wwwroot/ alá és egészen addig volt PHPMyAdmin SQL hozzáférés, amíg eljutottam odáig az installban ahol meg kellett adni az adatbázis hozzáférést.
Amint megnyomtam az elküld gombot, rögtön kiírta hogy nem tud rákapcsolódni a MYSQL adatbázisra és amikor gyorsan áttaboltam a MyAdmin-ra az is jelezte onnantól kezdve hogy ő sem tud.
Gondolom hogy a közös config.php okozhatta a jelenséget.

Amikor viszont a csináltam a wwwroot/ alá egy drupal könyvtárt már nem volt gondja.
Igaz jött vagy 20 Warning hogy bizonyos file-okhoz nem fér hozzá.
Commanderrel megnéztem és tényleg azok a file-ok nem is léteztek.
Ez nem tudom hogy jól van-e így?
A legtöbb könyvtár lánc végén szokott lenni egy "Po" nevü könyvtár és benne egy file, de vannak részek ahol nincs, és ezeknél jelezte hogy ...../po/mittudomen.php nem elérhető.

Lehet hogy csinálok egy kamu regisztrációt az extrán hogy utoljára kipróbáljam.
Ha megint ebbe futok bele, akkor fogalmam sincs hogy ti hogy csináljátok. :)

0
0
pp képe

Igyekeztem ontopic maradni, ugyanis ez a két kérdés volt a témaindító:

A kérdésem az, hogy ez kötelezően együtt jár azzal, ha egy rendszer felhasználóbarátabb és használhatóbb lesz, vagy kell hozzá egy jól fejlett, segítőkész közösség is?
Erre ugye nem válaszoltam, hisz erre is-is a válasz az egyik a másik nélkül nem működik, hisz a rendszer a felhasználókért van, a közösség meg a rendszert kedveli és használja.

Vajon ők sajnálják az időt arra, hogy egyénileg, otthoni körülmények között alaposabban megismerkedjenek a felhasználandó eszközzel, vagy csak egyszerűen ez az út tűnik járhatóbbnak?

Erre próbáltam válaszolni a tanulási folyamat fejtegetésemmel. ;)

Amiért kénytelen vagyok ehhez is hozzászólni az az, hogy két általam bevezetett fogalmat keversz itt össze.

őkaszupermájerek és a kismókusok nem hogy nem egyenlőek, hanem éppen hogy különbözőek.

Őkaszupermájerek, akik nem hajlandóak tanulni, mert őkaszupermájerek és mindenki más hülye(még akkor is, ha ők tették fel rosszul a kérdést)

A kismókusok meg pont az ellenkező pólus. Ők azok aki kérdeznek és gyűjtik a tudást, mint a kismókusok télire a mogyorót. Ha nem értenek valami, újra kérdeznek és nem megsértődnek, ha lekismókusozzák őket, hanem gyűjtögetik a tudást tovább.

pp

0
0
pp képe

Ez ilyen egyszerű és van egy kis szemecske amitől még vizivig is lesz.

És kérlek ne tedd fel az aláhúzást. Irtsuk már ki! Ronda, nehezen olvasható éppen ezért tipográfiailag ellenjavallt. Ráadásul a weben teljesen más jelentést hordoz egy aláhúzott szöveg, mert az ugye a link.
Annak idején amikor a szerző kézzel vagy írógéppel írta a kéziratát egyetlen módja volt, hogy jelezze a tördelőnek, hogy mit kíván kiemelni, ez pedig az, hogy aláhúzta az adott szót vagy szavakat. Ezeket aztán a szedő szépen vastag betűkkel szedte, vagy olyannal, amit a tipográfus megálmodott. (de sose aláhúzással, azt csak a tipográfus rémálmaiban fordult elő.)
Ne használj aláhúzást!

Legyen ez az első lépés. Aztán jöhet az, hogy szemantikus HTML-t állítsunk elő és akkor a félkövér, dőlt, jobbra, balra, középre igazított is el fog tűnni. Helyette megjelennek majd a strong, em és a különböző osztályba sorolt bekezdések, melyek formátumát a megfelelő helyen, a css-ben írja majd le a megfelelő ember a "webdizájner" nem pedig az egységsugarú.

Adjunk teret a jövőnek, a jelentéssel felruházott HTML-nek, a microformátumoknak és a szemantikus webnek!

A filterről meg csak annyit, hogy éppen nem kell filter ;) Ha bármit is szűrsz, akkor nem lesz wiziwig, ha meg nem akkor meg nagygány lesz a tartalmad ;) muhahah... hajrá!!

pp

0
0
Dzsozef képe

Azt hiszem a megoldás felé haladunk ez jó tipp lehet.
Tartalom tipust külön azért gondoltam, mert a node byrol-modullal kitudom választani, hogy a "jozsi" tartalom tipust csak a "jozsi" felhasználó lássa, amikor tartalmat küld be, máshol nem jelenik meg csak neki. ..és így tovább. Így azt gondoltam, vagy a tartalom tipussal tudok szétválogatni, hogy külön lássák magukat, vagy az user névnél.

Ha jól értem, az argumentum a "jozsi" és így az userek közül kiszüri a jozsi tartalmakat?
Ez esetben nem kell tartalom szürést végezni, mert ezért akartam száz tartalom tipust.
Ez eddig nagyon oké.
A aldomain, az utvonal álnévből keletkezik, ahogy gondoltam, vagy ez is másképp?

Még egy apróság, így jó e: A menüt az első oldalra -page- egy táblába teszem, /ha valakinek nagyon kellene/, hogy konkrétan elnavigáljon egy adott oldalára.
Tehát azt sejtem, hogy már nem lehet, se a fejléchez primary, se a sidebarba tenni.

Hát már eddig is köszi nagy előre lépés azt hiszem.
Ilyenkor a cck nem kellene valamire:) Szokás együtt a viewsel?

Majd holnap azaz ma kiprobálom. De Te is fönt vagy szépen szerencsémre:)
Egy jó tanácsot ezért adok: Az éjfél elötti alvás az igazi!

0
0
d.pryke képe

Nem gondoltam, hogy ilyen parázs vita kerekedik a kiindulási kérdésemből, de örülök, hogy összegyűltek az érvek és ellenérvek.

Egy olyan eseten, amelyet Edit is említ, már átment a kérdéses portál is 2 éve: új motor, új url struktúra, melyből adódóan bejövő linkek halottak, pár nap alatt pagerank a mélyben, a számunkra releváns keresőszavakra a google első oldaláról a többszázadikra visszazuhanás, máig nem sikerült annyira visszatornászni magunkat.

És még annyi esze sem volt a korábbi átállást végzőnek, hogy egy egyéni 404 hibaoldalt generáljon, melyen szerepel mondjuk a weblap főmenüje valami jópofa felirat kíséretében.

Drupalnak mondjuk a search404 modulja is jó szolgálatot tehet egyéb rendszerről Drupalra történő átállásnál, ha nem akarják megtartani az url struktúrát, bár ha az előző rendszernek sem voltak beszédesek az urljei akkor nem sokat ér.

Na tehát az urlstruktúrának az én konkrét esetemben maradnia kell, és másnak is ezt tanácsolom, ha látogatott oldala van.

Amin viszont elgondolkodtam:
"lényeg, hogy azt kell elérned, hogy a régi borzasztó url-re is elérhető legyen a régi tartalom"
És az újra is, ezt úgy érted nyilván. De akkor fellép a DUPLIKÁLT TARTALOM esete, amit a google szintén nem néz jó szemmel. Ezzel kapcsolatban van valakinek tapasztalata?

0
0