Valaszok
Koszonom a hozzaszolasokat. Igyekszem a kerdeseket megvalaszolni.
1 - valtozott a helyzet - a fizetos tartalom letoltheto lesz, miota raakadtam a hurricane video encryption tools nevu kis programra (atkodolja a videokat, majd tobb opcio is letezik, pl miutan letoltotted, eloszor egy ablak jelenik meg, aktivalnod kell a videot, utana mindig gond nelkul lejatsza de csak a te szamitogepeden)
2 - a cel nem az h ne lehessen masolni, terjeszteni, hanem h az atlag felhasznalo ne tudja ezt egykonnyen megtenni.
3 - attol drupal kerdes, hogy hogyan lehet ezt drupalban kivitelezni. Eppen ezert le is irom, hogy eddig mit tettem, talan van jobb otletetek es leirjatok, talan masoknak is otletet adhat ha hasonlo problemajuk akad.
a.) - atallitottam privat letoltesi modra a fajlrendszert, a fajlokat egy olyan konyvtarban tarolom el ami a root-on kivulre esik, tehat direkt weben keresztul nem erheto el.
b.) - letrehoztam egy kulon csoportot - ennek a csoportnak lesznek a tagjai azok a felhasznalok, akiknek majd joguk lesz letolteni a fizetos anyagokat - igy a jogosultsagoknal mar konnyen allithatom, hogy milyen tartalomtipushoz milyen csoport ferhet hozza. Egyik elkepzeles, h a fizetos tartalmat csatolt allomanykent teszem fel es a csatolt allomanyokat csak ennek a csoportnak a tagjai lathatjak.
Ami az uzleti modellt illeti, rem egyszeru : egy weboldal ami sajat keszitesu anyagokat tartalmaz. Mivel ezeknek az elkeszitesevel sok melo es rengeteg befektetes van mogotte, nem szeretnem ingyen szetosztogatni es amennyire lehet korlatozni a konnyu terjesztest.
Termeszetesen a weboldal nem csak egy egyszeru sales page lesz, hanem ki lesz egeszitve forummal, bloggal, hirlevellel, ingyenesen hozzaferheto anyagokkal - mindezeknek a hozzafereset is csoportositani kell, de ezt jatszva meg lehet oldani a jogosultsagoknal - es igy mindennek a kivitelezesere igy egyben a Drupal egy nagyszeru lehetoseg.
Az egyetlen gondom a fizetos tartalom volt, amit eleinte nem akartam h le lehessen tolteni, de igy h valamennyire tudom "akadalyozni" a konnyu terjesztest, batrabban merek belevagni.
Ha van otletetek szivesen veszem.
Most épp ezt bütykölöm http://online-vallalkozas.com/drupalsuli
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
grafikus vagyok, sajnálom...
Kezdjük ott hogy nem vagyok webgrafikus. Ennek ellenére elvállaltam olyan munkákat, ami már túllépi a statikus weboldalak építéshez szükséges ismereteim határait. Mégis meg szeretném csinálni, az egyik szempont hogy motiváció hiányában rendkívül lusta tudok lenni :) ezt meg egy remek lehetőségnek tartom hogy kicsit tanuljak is valamit, és a következő hasonló munkámat már több ismeret birtokában csinálhassam meg!
Nagy fába vágtam a fejszémet, ha gányolás lesz akkor gányolás lesz, de addig úgysem fogom kiadni a kezem közül a weboldalt amíg nem működik, ha kell átadom másnak a programozás részt, de ezután nem értem miért ne hívnának vissza mint designer, ha működik is az oldal, és jól is néz ki??
És hogy minek vállalok el ilyeneket? A kihívás és a motiváció amiről beszéltem! Meg tudtommal rajtam van a felelősség, és nem máson. Az a célom hogy megoldjam nemde?
Nem vagyok programozó, nincs is türelmem megtanulni, ezt a feladatot vagy átadom egy programozónak, vagy olyan megoldásokat használok/keresek amikor nem nekem kell írogatni a kódokat. Utóbbi miatt nyitottam ezt a topikot, olyan alternatív lehetőségek után kutatva, amit egy mezei grafikus is előszeretettel alkalmazhat dinamikus weblapok készítése során!
Kezdetben ugye találtam (vagyis ajánlották) a drupal-t, laikus szemmel nézva tökjó rendszernek tűnik, már csak a "grafikai" kérdést kell(ett) valahogy megoldani. Azért vagyok itt :)
Kaptam is erre egy jó tippet, az artisteer nevű programot most tanulmányozom... nem kell full profi oldal, a megrendelőknek éppen hogy egyszerű, letisztult weboldalak kellenek... azt meg meg lehet csinálni artisteerben is!
Ha meg nem felel meg a végeredmény, vagy nem sikerül összehoznom azt amit elterveztem, akkor úgyis átadom a grafikai terveket egy hozzáértőnek. Azzal én is egyetértek hogy ha valami VÉGKÉPP nem megy akkor azt minek erőltetni, ennek ellenére mégis meg szeretnék bírkózni a feladattal, és kitartok a végsőkig! :)
Záró gondolatként pedig van aki PHP-ban profi, van aki PhotoShop-ban, de a kettő együtt igen ritka... én is csak az egyikhez értek, fogadjátok ezt el :)
aj aj
http://www.pingvinpasztor.hu/ ez az oldalad? Kinél van ez egyáltalán? Talán szolgáltatót kellene váltanod.
A regisztrátor: Internet Megoldas Kft.
A névszerverek: srv7.dataergy.com ns1.dataergy.net
Életemben nem láttam még ilyent, az a szolgáltató akinél vagy még szerverekkel sem rendelkezik. Azért ez durva. Még nekem is van 2 névszerverem és ugyan az a címük mint az oldalamnak csak az előtag más (ns1.valami.com és ns2.valami.com)
Másrészről, a Discounts_alt modul a hibás ez egyértelmű. Lásd: a hibaüzenetet! Pl: "* user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-1)) AND (d.filter_type<>2 OR dt.term_id IN(-1)) AND (d.has_expiration=0 OR ' at line 8 query: SELECT DISTINCT d.* FROM uc_discounts d LEFT JOIN uc_discounts_products dp ON d.discount_id=dp.discount_id LEFT JOIN uc_discounts_terms dt ON d.discount_id=dt.discount_id LEFT JOIN uc_discounts_skus ds ON d.discount_id=ds.discount_id LEFT JOIN uc_discounts_classes dcl ON d.discount_id=dcl.discount_id WHERE (d.requires_code=0) AND (d.has_role_filter=0 OR d.discount_id IN(SELECT dr.discount_id FROM uc_discounts_roles dr, users_roles ur WHERE (dr.role_id=ur.rid AND ur.uid=1) OR dr.role_id=-1 OR dr.role_id=2)) AND (d.filter_type<>1 OR dp.product_id IN(,-1)) AND (d.filter_type<>2 OR dt.term_id IN(-1)) AND (d.has_expiration=0 OR d.expiration>0) ORDER BY weight in /www.pingvinpasztor.hu/modules/uc_discounts_alt/uc_discounts/uc_discounts... on line 1140" UTOLSÓ SOR!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Hello, Sokmindent leírtak
Hello,
Sokmindent leírtak már, pár dologgal kiegészíteném:
Linux disztrónak nem csak Ubuntu jó, sokak által kedvelt választás a Fedora, openSUSE, Mandriva (csak azért írom, mert ha Ubuntuval valami gond van, akkor ne add fel, próbálj ki másikat). Alapjában véve bármelyik disztró megfelel, Ubuntu alatt a csomagok felrakása után elég csak a "sudo a2enable rewrite" parancsot kiadni, és készen áll a rendszered a Drupalra. Más disztribúciók esetén sem nehezebb, pl.: openSUSE-n van yast, Mandriván drakconf [lehet azóta átnevezték, régen néztem], ott grafikusan tudsz sok dolgot állítgatni (többet közt az apache-ot is).
Linux alatt van tonnányi szerkesztő, KDE alatt van kate/kwrite, GNOME alatt van gedit, amit szoktak szeretni (van bennük szintaxiskiemelés, behúzásokat automatikusan kezelik, és képesek nagyon alap szintű kiegészítésekre is). Ha komolyabb _szerkesztő_ kell, akkor nézd meg a gvim-et.
Total Commander helyett a következő alternatívák vannak:
- krusader
- mc (ez konzolos, a norton commanderre hasonlít)
Ha nem ragaszkodsz a két paneles fájlkezelőhöz, akkor tudsz olyat GNOME-mal, hogy egy "mappaként" csatolod a távoli FTP helyet, és bedobálod oda a fájlokat, KDE alatt pedig bárhova beírhatod a címsorba, hogy ftp://, és lokális fájlrendszerként tudod kezelni (mintha egy másik meghajtó lenne).
Én Linuxon NetBeanst használok, mert az jó, és "mindent tud", bár a verziókezelést jobban szeretem kézzel intézni (megszokás). Ezen kívül fent van egy apache, mysql, postgres, és a mod_php, az ahhoz tartozó kismillió kiegészítővel. Apache-hoz mod_userdir is be van kapcsolva, így minden egy helyen van a home-omban (ez nem muszáj, nekem így kényelmesebb).
PSD-k megnyitására a GIMP nevű programmal lehet próbálkozni, vagy megpróbálni felrakni a wine segítségével a photoshopot (nekem a 7-es könnyedén felmegy, bár az régi; állítólag még a CS2-t is fel lehet rakni).
Zenére nézd meg az Ubuntu Studio nevű disztribúciót, lehet, hogy neked beválik. Ahhoz is fel lehet rakni bármilyen csomagot, amit Ubuntu-hoz, így a Drupalhoz szükséges csomagokat is.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Éreztem, hogy nem véletlenül
Éreztem, hogy nem véletlenül nincs ilyen téma :-)
Bár eszme cserélni jó lett volna róla.
Annyit akartam, hogy mások is leírják mi tetszik nekik, miben találtak hibát, stb. Közös épülésre.
Hibaüzenetet szándékosan nem küldtem, mert nem akartam, hogy az én spec. problémámmal zargassak itt bárkit. De ha már válaszoltál: a legfrissebb XAMPP-om van, tudok ezen kívül valamit tenni, hogy localon is tesztelhessek, vagy ebbe sehogy se fog belekerülni az a micsoda? :-)
Mondod te is, hogy lassabb, de benne vannak amik benne vannak. Vajon a 6-os verzió, ezekkel a plusz modulokkal együtt szintén ilyen lassú volt?
Windowson én sem adminként dolgozom, tehát egyetértek, hogy ne superuserként használjam a drupalt, viszont, ha már csináltak egy ilyen plusz admin nevű felhasználót, legalább ennyire várt dolog volt szerintem nem csak nálam, hogy a jogosultságokat ne ilyen táblázatszerűen kelljen kezelni, hanem mint pl. a phpBB-ben, bár ott se a legjobb, ugyanis ha véletlenül van vagy 10 jogosultsági kör, akkor így vízszintesen "vonalzózva" nézegetni, hogy a utolsó oszlopokban melyik jogosultságot is állítom, meg ráadásul olyan sincs benne, hogy all/none, hogy kicsit gyorsítsunk a dolgon, szóval ezt felhasználóbarátabbá kellett volna tenni.
A felugró ablak megoldás kikapcsolását az összes menüben végignéztem, ezek szerint a modult kell kikapcsolni, erre nem gondolhattam...).
Kösz a válaszokat, mindennel egyetértek kivéve azt, hogy human interface error: nem hiszem, hogy ne lehetne úgy megírni a programot, hogy a superuser ne tudja magát kitenni magából :-) És állítom, hogy ez tök értelmes dolog lenne.
Egyszerűen az az oka ennek szerintem, hogy modulszerűen programoztak és pl. a jogosultsági beállítások, ilyesmik mindenkire vonatkoznak, így történhetett ez meg.
Ha így van, akkor ráhibáztam :-)
UI: Lehet itt saját blogom? Biztos nem erre céloztál, hiszen "vendég" vagyok itt :-)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A kérdésed még mindig messze
A kérdésed még mindig messze van a konkréttól. :)
Ha egy fieldről beszélünk három dologról beszélünk:
1. Adatbázis reprezentáció
Ez egy vagy több mező a field adatait tároló táblában. Ebben a táblában ezek mellett a filedek mellett még számos információ tárolódik, amivel nem kell foglalkoznod, lévén a FieldAPI-t használod.
2. Beviteli elem (Widget)
Ez a beviteli űrlapon megjelenő formelem(jelen esetben egy olyan select ami multiple). Ezt egy jóízű form alterrel tolja bele a FieldAPI.
3. Megjelenítés (Formatter)
Hogyan jelenjen meg amikor a felhasználó nézi az adott elemet.
Miért nehéz a kérdésed?
Alapesetben, azt az esetet, amikor az elemből több van a Field API úgy kezeli, hogy egy táblázatba beletossz annyi, widgettet, amennyi szükséges. (ha végtelen, akkor ajaxxal bővíthető vezérlőt rak oda).
Természetesen ez felülírható. Pl. ha 1 elem van akkor egy sima select, ha több akkor egy multiple select form elem kerül bele az űrlapba. Lásd a core options widgetet.
Nem tudom, hogy Te mit szeretnél, mert ugye azt is akarhatod, hogy mindig multiple select legyen, és ha a field multiple, akkor a FieldAPI jelenítsen meg neked több multiple select form elemet. Ekkor nem kell csinálnod semmit se.
Ekkor még csak arról beszéltünk, hogy a field multiple. Ha a widget multiple akkor meg kell oldanod azt, hogy hogyan tárolja azt az adatbázisban, tehát egy widget -> db field átalakítást kell végezened a megfelelő hook segítségével.
Érdemes megnézned a examples modul, field_example modulját, ami egy több részből álló widget értékét tolja bele egy adatbázis mezőbe.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
konzol?
Konzolon (F12, Ctrl+Shift+I) látszik valami hiba?
A kódodban meg ebben a formában szintaktikai hiba van, bár lehet, hogy csak a click esemény lezárásaként maradt ott a });, és ide csak a lényeget másoltad be.
Ettől függetlenül az értékek felhasználása előtt nem árt leellenőrizni az elemek meglétét, pl. ezt is kiírathatnád console.log-ra, csak példakóddal:
console.log( $("#edit-field-locality-tids-hierarchical-select-selects-1 option:selected").length ); if($("#edit-field-locality-tids-hierarchical-select-selects-1 option:selected").length > 0){ // itt már használhatod az értékét... }
A lényeg, hogy a validálás után csekkold le, hogy egyáltalán léteznek-e az elemek az oldalon, van-e konzolon hiba, stb.
Ja, meg most látom, hogy használod a :selected selectort. Biztos lehetsz benne egyáltalán, hogy valamelyik elem ki lesz választva?
Nem látom a markupodat meg a kódod egyéb részét, úgyhogy ezeket nem ártana tudni.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Haaat...
Haaat...
Az elso es legfontosabb dolog az, hogy azokat a hivatkozasokat, amiket igy, hekkelve csinaltal, azokat egyenkent at kell alakitanod abszolut hivatkozasokka. Eleve nem ertem, hogy ez igy miert volt jo, vagy miert kellett, de nyilvan megvolt ra a jo okod, bar egeszen biztos vagyok benne, hogy a Drupal lehetoseget adott volna arra, hogy maskeppen is megoldd a felmerult problemat.
A kovetkezo, amire szukseg lenne, hogy atnezd a router_path mezoket a db-ben. Ahogy a peldakat elnezem a sajat db-imben, a router_path minden olyan link eseteben ures, amely abszolut, vagy a <front> szoveg van benne. A tobbi eseteben a router_path megegyezik a link_path ertekevel. De mindenkeppen figyelmesen nezd at a bejegyzeseket, illetve ha tudod, egy teszt oldalon vegyel fel minel tobbfajta linket, hogy lasd, peldaul a tobbnyelvu linkek hogyan neznek ki db oldalon. Nagyon korultekintonek kell lenned, es nagyon oda kell figyelned.
Szoval, eloszor is csinalj egy mentest (!!!), majd a db-ben modositsd a fentieknek megfeleloen a router_path mezoket.
Ha ez igy mukodo site-t eredmenyez, akkor utana probalj meg (mentes utan!) egy eredeti Drupal 6.19 -et kicsomagolni, felulirva ezzel a hackolt fajlokat.
Ha meg mindig mukodik az oldalad, akkor eljott az ideje annak, hogy frissitsd 6.25-re, mert tudomasom szerint volt security frissites is a 19 ota.
Es a jovore nezve megjegyzed, hogy a lustasag fel betegseg. Csak a szerencsen mult, hogy az oldaladat meg nem tortek fel kulonbozo, azota mar javitott sebezhetosegek okan. Barmilyen modositas a core kodban ugyanis egy frissithetetlen, menedzselhetetlen oldalt eredemnyez, ami raadasul konstans hibaforraskent szolgal.
Valamint: Nem tudom elegge hangsulyozni, hogy a fenti javitasi tippeket szigoruan csak mentes utan hajtsd vegre, es minden egyes lepes elott/utan mentsel. Ne lustald el, ne hagyd ki, es ne felejtsd el. Igy is eleg eletveszelyes muvelet kessel belevagni a Drupal szivebe kulonosebb hozzaertes nelkul, nem kell ezt meg tetezni.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
jaja, de mit kéne? taxonomy term többször is felhasználható
De így legalább eleve a core kínálja azt a lehetőséget, hogy kilistázd azokat a node-okat, ahol szerepel mondjuk a piros szín a zászlóban. :D
Amúgy ilyet taxonomy-val nekem is nyakatekertnek tűnik, de őszintén szólva most hirtelen nekem nem jut eszembe az igazi megoldás sem, amibe ne lehetne szintén belekötni. Neked van ötleted rá?
Szerk.: ja, de most fogom fel, amit írtál:
"nem tudom mihez kezd a taxonomy azzal, hogy 1 node többször tartozik ugyannaba a termbe, nem ilyesmire van az kitalálva. (piros, fehér, _piros_ ?)"
Dehogyis, nincs duplikáció, és nincs másfajta elnevezés! Egy taxonomy term listázásánál csak egyszer listáz egy node-ot, akárhányszor szerepelhet a node fieldjeiben a term reference.
Azzal nem értek egyet, hogy nem használható arra a taxonomy, hogy több fieldben is fel legyen használva ugyanaz a szótár egy adott content type node-jainál (vagy többnél). A taxonomy term szerintem nem csak arra való, hogy aztán tök jól be legyen linkelve a field, mint a cikkekhez tartozó tageknél, és aztán lehessen listázni az összes node-ot, ahol ezek a termek szerepelnek. Szerintem arra is való, hogy egy fieldhez tartozó lehetséges értékeket tetszőlegesen lehessen bővíteni, átrendezni, átnevezni, aztán annyi fieldnél lehessen felhasználni, ahánynál csak szükség van rá, hogy legyen egy bővíthető lista.
Az egyik oldalnál én is olyan megoldáshoz folyamodtam, ahol egy node-hoz több Term reference field is tartozott, ami azonos szótárt használt fel, mert épp arra volt szükség. Több fieldnél is ugyanabból a listából kellett választani, de kicsit más adatokat tartott nyilván.
Persze biztos lehetett volna kitalálni rá alternatív, nyakatekertebb (bár lehet, hogy akár jobb) megoldásokat, de minek? :) Végül is még mindig ott van a Views, amivel aztán olyan módon listázom a tartalmakat, ahogy nem szégyellem. :D
De ellenérveket is szívesen fogadok!
Az biztos, hogy általában nincs "jó" megoldás, hanem jók és kevésbé jók, meg kifejezetten rosszak vannak.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ehez akkor még kéne 1 view,
Ehez akkor még kéne 1 view, de azt nem tum hogy oldod meg taxonomyval. :/
Időközben alkottam egy egész cool galériát. A recept a következő :) :
- cck
- imagefield
- filefield_paths
- views
- views attach module(node content nézett miatt)
- imagecache + imagecache action(opcionális)
- image_fupload
- lightbox2
Létrehozok 1 új tartalom típust(galéria), hozzáadok egy fupload mezőt, a filepaths beállításba beállítom hogy az url-t és a file nevét tisztítsa meg, naqy betűket kicsinyítse le. A mező megjelenítésben label-t kikapcsolom, bevezetőre beállítok egy lightbox2 kép megjelenítést, a teljes nézetet meg elrejtem.
A viewsban létrehozok 2 nézetet, (mivel nekem sajnos csak így sikerült vmi bug van a levesben, ha page-nél ugyan azt a pathot adom amit álneveknel is pl page=referenciak, autopath node galéria = referenciak/[title-raw]) az egyik a egy page nézet a másik meg a node conent nézet.
A page nézetben összegyűjtöm a galéria típusokat, egy imagefield mezőt kirakva minden galériához(field részen csoportosítani kell őket és korlátozni 1-re)
A node content nézetben meg magát a tartalom típust állítom mikor full nézetben van. Szűrő = node típus galéria, mezők ugyancsak az imagefield, de itt nem csoportosítjuk a képeket, és a node content részen beállítjuk a tartalom típust szintén, az arguments-nél beállítom hogy csak a node id paraméteres galériát fogadja el.
Ezzel kapunk egy majdnem perfect galériát(ajaxos pagerrel ha kell), könnyedén törölhetünk képeket mivel tartalom típus szerint tudjuk szűrni és ha szerkesztjük akkor látjuk is a képeket amit törölni sztnénk(ellenben taxonomyval mivel a tartalom oldalon csak taxonomyra tudunk szűrni de képeket magát nem látjuk hogy mit is törlünk), jah és ha az össze képet ki szeretnénk törölni egyszerre azt is könnyedén meg tudjuk tenni a node eltávolításával.
És hogy miért nem tökéletes, azért mert nem lehet galéria a galériában funkció, vagyis ezt még nem próbáltam, bár vszínű megoldható lenne a node reference url modullal.
Ha van igény rá leírom teljesen részletesen képekkel illusztrálva.