pp képe

Továbbra se értem, hogy miért rossz, hibás ez a megoldás szerinted?

Írd le kérlek, hogy mi a hiba?

Az, hogy a Te ízlésednek nem felel meg a kód, attól még nem hibás. Az lehet ronda, meg nem szép, meg ilyenek, de nem hibás vagy rossz.

Legyél szíves belenézni egy alap hetes Drupalban a következő fájlokba:

includes/iso.inc
includes/unicode.entities.inc
includes/file.mimetypes.inc

Ha a logikádat követem, akkor ezek a kódok is hibásak, gányok, tákolmányok, mivel a PHP-ban tárolják az "adatbázist" és nem az adatbázisban.

Az pedig, hogy milyen változó neveket használ nagyon erősen ízlésbeli kérdés.

Szóval miért is hibás a kód? Mert az általad felsorolt ízlésbeli problémák nem hibák.

pp

5
-1
nevergone képe

Szia!

Néhány gondolat:

  • Igazából a felhasználóknak teljesen mindegy az azonosítójuk. Ha útvonal-álneveket készítesz, akkor nem is találkoznak vele. Azt csak a rendszer használja érdemben, felhasználói oldalról gyakorlati jelentősége nincs.
  • Nem tudod sorba rakni a lyukak kitöltésével, mert azt az értéket az adatbázis-kezelő adja (AUTOINCREMENT), annak pedig garantálnia kell, hogy egy adott érték mindig egy adott felhasználót azonosít, akár törli magát, akár nem: elsődleges kulcs.
  • Lyukak lesznek a sorban, mert a felhasználók törlik magukat néha, vagy te törlöd őket, esetleg a spammereket.
  • Nem gondolom, hogy az xmlsitemap modul okozza.
  • Érdemes lenne a logot megnézni, esetleg az adatbázisban, hogy a hiányzón azonosítójú felhasználoknál mi van az "users" táblában.
1
0
pp képe

Nem, nagyon rosszul fogalmaztam, ha így értetted, megpróbálom világosabban:

Az űrlap feldolgozás úgy néz ki, hogy:

Jött-e adat?
igen
Valid-e?
igen
Feldolgozom | Ha nemjött, vagy nem valid akkor kiíratom a formot.

Valami ilyesmi van a drupal_get_form fv működése mögött. Mivel Te csak azokhoz a ajánlatokhoz gyártasz űrlapot amelyiket még nem fogadták el, ezért Te a fenti mechanizmust be se indítod, ezért azok az adatok nem is kerülnek feldolgozásra. Szóval a drupal_get_form az nem csak az űrlapot generálja le, hanem végighívogatja a ellenőrző és a feldolgozó függvényeket. (mert ugye nem csak a Te függvényeid fognak lefutni, hisz, ha felteszel pl. egy spamszűrőt, akkor az jól bele is alterelhet az űrlapodba)

pp

1
0
Geva képe

kár belemenni a megjelenítés részleteibe, amikor még azt sem tudod mit kell megjelenítened, viszont ha megfelelően megtervezed, akkor azt jelenítesz meg-, szűrsz ki belőle amit csak akarsz, drupallal :-)
...amit fentebb leírsz, az pedig NEM adatbázis, mert pl. mezői biztosan nincsenek az adatbázisnak :-(

1. Válaszd külön az egyedeket(adatbázis tervezés:-): versenyző, verseny, versenyszám,...
2. milyen a kapcsolat az egyedek között

...az egyedekre kell tartalomtípus, amelyben a kapcsolataik a hivatkozások a másik egyedre, ez után vetődhet fel bármi további kérdés

...ha az egészet logikusan és a relációs adatbázis eszméi szerint felépíted(pl egy egyed egy tábla, a forrás adatokat redundancia mentesen viszed fel,...), akkor a drupal megvalósítás is menni fog és a megjelenítés sem lesz gond

0
0
HF leon képe

Részletes dokumentációt én sem találtam és inkább azok is a moduloknál alkalmazható lehetőségeket, vagy más yaml-lel beállítható dolgokat taglalnak.

A témáknál is megoldható, hogy egy téma telepítésénél a téma átrendezze a már létező blokkokat, ahogy beállítjuk azt. A blokkok részletesen konfigurálhatók.

Egyedül a blokkok label értékének fordításával állok hadilábon. Azok a megoldások, amiket találtam nem működnek.

A drupal az alapértelmezett blokkok neveit mindig lefordítja az adott nyelvre. Viszont hiába adom meg ugyanazt az angol nevet az mégsem kerül lefordításra. Biztos meg lehet oldani valahogy, de erre még nem jöttem rá.

(Pl. a kereső blokk címkéje Search, de más nyelvre váltva az lefordul az adott nyelvre - mondjuk magyarul Keresés lesz. A telepítésnél a yaml fájlal beállított címke viszont minden nyelven egységes marad.)

0
0
HF leon képe

Nem egészen értem, hogy mit jelent az, hogy régi. Arra gondolsz, hogy az adott mező a régi tartalmakból hiányzik, vagyis nem lett kitöltve, mert azok a mező létrehozása előtt készültek?

Van olyan lehetőség a views-ban, hogy mit csináljon, ha nem létezik a mező, vagyis sohasem kapott értéket.

A logikai mezőnél, nyilván az lenne logikus, hogy akkor jelenít meg valamit, ha az érték 1. Azoknál a tartalmaknál, amelyek korábban lettek létrehozva, mivel nincs a mezőnek értéke, így 1 sem lehet.

Lehet rossz az okfejtésem, csak találgatok egyelőre. Fejtsd ki részletesebben mi is a pontos probléma.

Írd le milyen tartalomtípusaid vannak. Miben térnek el egymástól, miben térnek el az újak és a régiek, valamint hogyan konfiguráltad fel a views-t!

2
0
Illyés Edit képe

Sajnos nem működik az aliasos megoldás, mert nem a beállított nézetet hozza be, hanem az eredeti nézetet találom meg álnév alatt:(

Nem jól állítottad be az URL-eket. Le van írva a fent belinkelt cikkben.

A második megoldás kivitelezésén még gondolkodom, mert nehezen tudom elképzelni, hogy minden almenü ugyanazzal a views szabállyal működjön

Mit értesz "almenü" alatt? Ha a taxonomy_menu/1/* típusú almenüpontokra gondolsz, akkor meg lehet csinálni, feltéve, hogy minden oldalon ugyanaz történik – ugyanaz a lekérdezés felépítése – és csak a * értékét kell a Views-nak kiolvasnia az URL-ből és behelyettesítenie a lekérdezésbe.

Ha argumentum nélkül jó lenne, akkor az argumentumok esetére nem lehetne beállítani az eredeti állapot mutatását?

Ezt nem értem.

0
0
Illyés Edit képe

Az elgondolasodban az az alapveto hiba, hogy ha Drupalt hasznalsz akkor ne rakjal mar bele ilyen csunya url-eket. Akkor mar inkabb vesszenek a regi cimek.

Ja, hogy közben lenullázod a webhelyet a keresőkben és ezért tönkremész üzletileg? Kit érdekel, lényeg, hogy az elgondolásod ne legyen hibás! ;)

De itt mindenre van megoldas, ugyhogy az atiranyitasra hasznald ezt a modult, mukodik barmilyen url-re: http://drupal.org/project/path_redirect

Bármilyen URL-re != Bármilyen URL-ről.

.htaccess lesz a megoldás. De előbb érdemes megnézni a webhelyet a keresőkben, hogy egyáltalán beindexelték-e a krikszkrakszos URL-eket, ill. van-e elegendő számú bejövő link ezekre az oldalakra, hogy érdemes legyen .htaccess-szel vacakolni.

0
0
pp képe

Egyszer hallottam egy történetet, amiben lemérték, hogy egy ember mennyi idő alatt tud megtanulni Prologban programozni. Az átlag felhasználó aki sose programozott 2-3 hónap alatt képes volt elsajátítani és biztonsággal használni a nyelvet. A programozóknak ehhez 6-8 hónap kellett. A szemlélete ugyanis teljesen más mint a megszokott. Valahogy így van ez a webes alkalmazás fejlesztéssel is, de ugye ez az a szál ami messzire vezet innen egyelőre.

Kiindulásnak továbbra is javaslom Gusztáv könyvét, amit azt hiszem már párszor olvastál. ;)

"Amiért feszegetem ezt a dolgot csupán az, hogy a fórumokat figyelve azt vettem észre, sok csoda dologra és jelenségre keresik az emberek néha a válaszokat, és az esetek nagy részében szerinten alapfogalmakkal és útvonalakkal való bajlódásra vezethető vissza, mint ahogy az én példám (node és taxonómia értelmezés, autopath használat) is mutatja."

Igen, ezt úgy hívják tanulási folyamat. Van motivációjuk nekiállnak próbálkoznak, ha elakadnak kérdeznek és újra próbálkoznak. Ez így normális. Szerintem adj egy pici időt magadnak. Az a baj, hogy szerintem elsőre nagy fába vágtad a fejszédet.(ami nem baj, sőt: http://palocz.hu/node/199) Próbálj meg először egy alap oldalt létrehozni az alap rendszerrel. Nézd végig melyik modul mit tud és hogyan tudod használni. Ne vesződj a backup migrate modullal, hanem kezd előröl mindig. Elsőre ez nagy időpazarlásnak tűnik de nem az. Ez az ismétlés segít téged abban, hogy egyre jobban kiismerd magad a menürendszerben, egyre biztosabban mozogj benne és mindig tudd merre jársz és hova nyúlj. Én azt mondom adj magadnak egy hetet gyakorlásra. A tanfolyamon mindig elmondom az elején, hogy jobb ha felkészülünk: Az első négy-öt Drupal oldalunk, amiről azt gondoljuk majd, hogy A tökéletes weboldal, amit úgy raktunk össze, hogy minden tuti rajta. Na azokat két három hónap múlva a kukába fogjuk dobni és újra felépítjük majd. Ez van ezt el kell fogadni, ha tanulni kezd az ember.
Kérdezheted, hogy ha nem értem akkor hogyan fogom tudni megcsinálni? Az a baj, hogy anélkül, hogy csinálnád nem fogod megérteni. Eme ördögi körből csak úgy tudsz kitörni, hogy vagy nem foglalkozol vele, hogy nem érted és csinálod, vagy elhiteted magaddal(vagy más elhiteti) hogy érted és akkor fogod tudni csinálni.
Az oskolában nekem ez utóbbit erőltették (gyanítom ez sok helyen így van, ahogy másokkal beszéltem). Hiába írtam hibátlan felvételit mégis a főiskolán állt össze az egész a fejembe és akkor mondtam azt, hogy: Ja most már tényleg értem. Szóval az előbb az elmélet utána a gyakorlat nem élvezetes út és nem is biztos, hogy a szenvedés meg fogja később hálálni magát. ;)
Figyelj, nem azt írtam melyik az üdvözítő, hanem azt, hogy egyik út sem elhagyható. Javaslom tehát adj magadnak most egy hét gyakorlást és utána próbáld meg megérteni a dolgot.

pp

0
0
Illyés Edit képe

en lebeszelnelek errol az UI-rol, mivel ezt bonyolult kivitelezni es meg rossz is

Nem engem kell, az ügyfelet. :) Nekem elég lenne a legfapadosabb drupalos interfész.

1. egy szo alapjan keresni node-okban nagyon keves.

Alapból időrendben a legfrissebbek kerülnének a lista tetejére, a kereső pedig a címben keresne. Tényleg nincs sok értelme – mekkora a valószínűsége, hogy egy régebbi cikket kitesznek a címlapra? Nulla. De ez az igény. Tapasztalatom, hogy a lefejlesztett funkcióknak kb. a felét az ügyfél sose használja, de nem lehet róla lebeszélni. De nekem végülis mindegy, én kiszámlázom. :)

2. az elonezet gomb nem azt fogja mutatni amit az ugyfel gondol, nem a listat, nem a fooldalt

De azt kell mutatnia. :)

3. ahanyszor a nyilakra kattint az egesz oldal ujratoltodik, hacsak nem akarsz igazan bonyolult javascritet az oldalra. es szinte biztos, hogy sosem fogjak itt a tobbszoros kijelolest alkalmazni.

Ezt nem értem, miért töltődik újra? Ez csak egy JS widget. Taxonomy Manager is használja. Nem triviális, de nem is megoldhatatlan.

4. minden nodeban (!nem node tipusban) minden CCK mezonek kulon lathatosagi parameter? na azt ne.

De pontosan ezt kérik. :)

+ VBO (habar ez nem olyan fontos, a cimlapra ugyis egyesevel raknak ki cikket) szerintem van hozza flag action

Igen, azzal meg lehetne oldani a több node egy felületen történő flagelését, kitesz/levesz státusz állítását. Nem is lenne rossz, csak ott az előnézet funkció lenne nagyon kemény dió.

+ a teaser nezethez helyesen beallitani elore a CCK mezoket. Egy tartalom tipuson belul ertelmetlen kulonbozo CCK lathatosagi beallitasokat alkalmazni.

Már a jelenlegi webhelyen is a node helyzetétől függ a láthatóság: első helyen kiemelt node cím+teaser(ha van)+kép(ha van), második-harmadik helyen kiemelt node cím+teaser(ha van), további node-ok csak címmel.

Innen kellene továbblépnünk, hogy tetszőlegesen állítható legyen, tehát ha úgy döntenek, hogy ez a cikk most kép nélkül legyen a vezető helyen, akkor ezt beállíthassák, annak ellenére, hogy közben van kép feltöltve a cikkhez, és az meg is jelenik a cikk saját oldalán. Hogy miért baj az, hogy a cikkhez feltöltött kép megjelenik a címoldalon is, ezt én sem értem, de az elmúlt két napban háromszor is végigmentünk a témán, és ragaszkodnak hozzá. Ez annyira engem nem zavar, meg lehet oldani, hogy flagtől/taxonómiától függően jelenítem meg az egyes mezőket. A UI és az előnézet az, ami fejtörést okoz.

+ 2 view display:
a szerkesztok a cimlapra helyez flag-gel szurt listat (view) latjak
mig a latogatok a mindket flag-gel szurt listat

Ez jó ötlet! Csinálok egy "árnyék"-címlapot, kvázi az lesz az előnézet, a flagek állítgatására pedig akkor lehet használni a VBO-t. VBO felületbe beépítek egy gombot, ami új ablakban megnyitja az árnyékot, ott lehet a látványt ellenőrizni. Talán el tudom adni a megrendelőnek. :) Majd jelzem a végeredményt, addig is köszönöm az ötletet. :)

0
0