Keresés

Új hozzászólás Aktív témák

  • Sk8erPeter

    nagyúr

    válasz Phvhun #12601 üzenetére

    Próbáltam értelmezni a kérdésedet, de nem sikerült. Tulajdonképpen mit is szeretnél? Automatikus könyvtárszinkronizálást? Arra ott a WinSCP, én nagyon komálom.

    (#12602) Jim-Y:
    OFF, de sztem a képeknél nem szerencsés az opacity:0.3, ami hoverre változik 1.0-ra, nagyon rontja az olvashatóságot.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Phvhun #12605 üzenetére

    Igen, a WinSCP tud olyat, hogy monitoroz egy könyvtárat, és valamelyik fájl változása esetén azonnal feltölti a módosított fájlt a távoli szerverre (felülírva ott is az eredetit a módosítottal). Ergo a problémád meg is van oldva. NetBeans-ből közvetlenül nem tudod megcsinálni, na bumm. Eleve nem is szerencsés egyébként közvetlenül buzerálni az éles szerveren lévő tartalmat. :)

    (#12606) DNReNTi :
    Attól még, mert a fájlok a fejlesztés idejére el vannak különítve, tehát külön-külön (S)CSS-fájl van az egyes részekre, attól még az éles változatba illik kinyomni egy aggregált, összesített, tömörített (whitespace-ek eltávolítva) változatot. Ezt a böngésző az egyszeri request, majd letöltés után eltárolja a gyorsítótárában, így innentől kezdve ebből a helyi fájlból szedi a stílusdefiníciókat akármelyik aloldal böngészése során. Kevésbé számít az, hogy olyan stílusdefiníciók is szerepelnek ebben az összesített fájlban, ami a böngészett aloldalnál éppen nem releváns. Persze azért az az összesített fájl azért ne legyen gigantikus méretű (ha ilyen, akkor ott már úgyis tervezési gondok lehetnek).

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz #39417856 #12619 üzenetére

    Google 1. találat:
    http://ahamlett.com/jQuery-Picasa-Gallery/
    GitHubon ugyanez:
    https://github.com/alanhamlett/jQuery-Picasa-Gallery

    (#12609) DNReNTi:
    Ha ezt így szétválasztod, az sztem teljesen jó, csak a felhasználók felé kiszolgált tartalomra gondoltam, hogy az lehetne egy minimalizált, összesített változat csak a gyorsabb letöltés érdekében.

    (#12610) Zedz:
    Az egyfájlos módszer még jobb is, mivel egyetlen request, egyetlen válasz. Persze lehetnek extra stílusdefiníciók, amiket csak akkor húzol be, ha tényleg kell, mert mondjuk nem érdemes állandóan betöltögetni.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz #39417856 #12631 üzenetére

    Ez is tud ilyet: https://pyd.io/
    Itt van egy demó a demo/demo belépési lehetőséggel:
    https://demo.pyd.io/ws-personal-files/
    Viszont arra számíts, hogy a beállítása azért 5 percnél többet igényel:
    https://pyd.io/docs/v6/getting-started/quick-start/

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PumpkinSeed #12634 üzenetére

    Hmm, a nyelvválasztó tényleg 500-at dob, úgy látszik, a demó ezen részét elkúrták. :D Amúgy vissza lehet belőle lépni az alul lévő X-szel. Ezt amikor saját tárhelyen próbálgattam, nem is teszteltem, a többi része faszának tűnt.
    A demo/demo párossal egyébként beenged, most is kipróbáltam, próbáld újra. :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Zedz #12639 üzenetére

    Azért az utolsó bekezdésedben írtak mostanra a régi állapotokhoz képest jelentősen javultak, persze ettől még például ha a caniuse.com-ot nézegeted, akkor az IE oszlopában igen sokszor nagyon erős piros szín látható. :DDD

    Amúgy ha tényleg új MS-hez köthető böngésző lesz, akkor kíváncsi vagyok, hogy vajon melyik vonalat fogják képviselni, hogy folyamatosan bővítik a funkcionalitását a böngészőnek, hogy egyre okosabb legyen (mondjuk eddig ennek megfelelő, funkciógazdagnak nevezhető (bár bugokat is bőven tartalmazó) böngésző eddig egyedül a régi, Presto-motoros, mostanra sajnos használhatatlan régi Opera volt - most már az új, Blink-vonallal foglalkoznak, ami egyelőre nem túl okos, reméljük a legjobbakat), vagy követik a Chrome-hoz kötődő gondolkodásmódot, hogy jó lesz a bot egyszerűségű böngésző (nehogy összekeverjük szegény szerencsétlen Mari nénit), cserébe legyen jó extension API, meg jó doksi, aztán majd a bővítmények fejlesztői elvégzik helyettünk a piszkos munkát, és használhatóvá teszik a böngészőt... ;]

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz martonx #12641 üzenetére

    Igen, ezt én sem értem. Kb. ennyi alapján a böngésző lényege marad, csak más külsőt/márkát kap. Az index.hu amúgy a technológiai téren sajnos elég durván igénytelen, többnyire felületesen mutatnak be mindenféle informatikai újdonságot is.
    Amúgy valószínűnek tartom, hogy ez a váltás tényleg pusztán marketingcélokat szolgál, mert sokak szemében az Internet Explorer név az aktuális javítgatások/toldozások-foldozások ellenére már összekapcsolódott valami ósdi, kék e betűvel, a fejlesztők szemében meg összeforrott a különutas, idegesítő megoldásokat választó, extra szopásokat, rengeteg plusz időt igénylő fos böngészővel. Egy ilyen váltás lehet, hogy jót tesz, szoktak ilyen marketingfogásokat bevetni (teljesen megújítanak egy márkát valami logóújítással, arculatváltással, stb., vagy akár egy totál új márkát vezetnek be inkább), ami sok esetben működik is.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Zedz #12643 üzenetére

    Az IE őskövület verzióira való fejlesztés igénye igazából már régóta inkább speckó vállalati területeken jellemző, szóval nagy általánosságban már nem érzem akkora problémának. Az IE mostani verziói már vállalhatónak számítanak, igaz, támogatott feature-ökben és kezelhetőségben, bővíthetőségben még mindig rengeteg a lemaradás. Szóval a tendencia már megvan, hogy a régi verziókat a fejlesztők kevésbé támogatják (teljesen reális egy kevésbé speckó honlapnál azt mondani, ha kérik az IE8-kompatibilitást, hogy "anyád"). Az arculatváltás a Microsoftnál alapvetően nem lenne rossz ötlet, de ahhoz mondjuk az lenne az értelmes, hogy a tényleges IE-t kivezetik szép lassan, ha nem akarnak saját maguk konkurenciája lenni... :D Amúgy ja, az tuti, hogy ha elősegítik a böngészőhöz való fejlesztést, akár a Chrome-nál (aminek kifejezetten igényes extensionökhöz kötődő doksija van), és ugyanúgy tele lesz tűzdelve példákkal (nem úgy, mint a sokszor ilyen szempontból nagyon szegényes hivatalos MS-doksik pl. C#-nál), akkor felpöröghet iránta az érdeklődés.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PumpkinSeed #12647 üzenetére

    Természetesen nem így értettem, hanem úgy, hogy sok átlagfelhasználó így is nagyon nehezen vált, ha egyszer megszokott valamit, ha pedig nem váltanak a Microsoft új böngészőjére (mert nincsenek rákényszerítve, és ott van kint a link az asztalon, jó az is), hanem maradnak a "réginél", amihez még frissítéseket is kapnak, akkor az azt jelenti, hogy a régire is komoly erőforrásokat kell összpontosítani, hogy fejlesszék, két különálló vonal fejlesztése meg előbb-utóbb igen nehézkessé válik. Ráadásul akkor még a statisztikákban is kisebb számokkal villoghatnak, ami rossz reklám, ahelyett, hogy egy böngészőre összpontosulna a felhasználóik figyelme (bár a részesedési listában immár két helyet is foglalnak). Szóval nem tűnik ésszerűnek a két vonal folyamatos különálló fejlesztése.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PumpkinSeed #12649 üzenetére

    Na de most megint olyan emberkékről beszélünk, akiknél megállt az idő, nem frissítenek semmit, warezolnak, XP-t használnak, stb... Szélsőséges esetekből nem biztos, hogy érdemes általánosításokat kihozni; nyilván vannak, akiknek muszáj lesz foglalkozni a régi verziók támogatásával is, ezt ők maguk el tudják dönteni, de most mintha csak keresnénk az okot a nyafira. :DDD
    A nagyobb verzióváltásokat kikényszeríteni egy normális felhasználónál, aki nem tiltotta le a frissítéseket, nem egy nagy dolog, az IE9/10/11 is érkezett egy Windows-frissítéssel (hacsak nem töltötted le explicite), felajánlotta a vindóz bácsi, hogy lecseréli a régi verziót, elfogadtad, megtörtént, bumm, megoldva. Pont ugyanennyi lenne leváltani az IE-t az új MS-böngészőre, amiről beszélünk.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PumpkinSeed #12651 üzenetére

    Az sem lenne jó, ha megint egyeduralkodó lenne egyetlen böngészőmotor (bár jelenleg is előnyt élvez). Az lenne a jó, ha mindenki szigorúan követné a W3C-ajánlásokat, de hát álmodik a nyomor (ez rímel a motorral, höhö).
    Amúgy Blink van a Chrome-ban is, újvonalas Operában is, nem WebKit (a WebKit egyik forkja a Blink, de a lényeg, hogy már másik fejlesztési vonal). :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz pinnacle #12656 üzenetére

    Dehogy is, az azért durva lenne, ha kívülről ilyen adatokhoz bárki hozzáférne. :)

    Azt lehet legfeljebb megnézni, hogy a domaint mikor regisztrálták. Pölö a prohardver.hu-nál:
    http://www.domain.hu/domain/domainsearch/whois.html?domain=prohardver.hu&ekes=prohardver.hu
    regisztrálva: 2001-08-23 03:00:15

    Ha saját tárhelyről van szó, amihez hozzáférsz, akkor persze más a helyzet, nézhetsz fájlmódosítási és egyéb adatokat.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12665 üzenetére

    Itt van ingyen, pontosabban egy domain áráért 1000 MB tárhely:
    http://eforce.hu/#tarhely-csomagok
    Itt nyertem még korábban egy domaint (szóval az is ingyé' volt), azóta hosszabbítgatom, túl sokat nem tudok róla nyilatkozni, mert komolynak tekinthető webalkalmazás nem fut rajta, egyelőre csak tesztelgetős hülyeségek némi PHP-kóddal, inkább több kliensoldali kóddal (már 2 éve halasztgatom, hogy tegyek oda valami normális dolgot :DDD) de teszi a dolgát, műxik, az admin-felület nem túl komoly, de elmegy.
    2000 Ft volt a domainhosszabbítás most.

    Bármit is választasz, domain-átregisztrálásra lesz szükség, ezt általában az a cég szokta intézni, akihez átköltözöl, jobb esetben nem igazán kell vele érdemben foglalkoznod, csak szólni a cégnek, hogy regisztrálják át, meg kifizetni annak a díját (az átregisztrálásnak is van valami díja az ügyintézésükért cserébe).

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Zedz #12667 üzenetére

    És tényleg! :DDD Elég érdekes, hogy így lenyúlták, túlzottan hasonlít a véletlenhez... :F

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Zedz #12669 üzenetére

    Jaja, úgy értem, hogy ahhoz túlzottan hasonlít, hogy ez a véletlen műve legyen, szóval ja, sztem is lenyúlták. :DDD Kíváncsi lennék, mit szólna a másik cég ehhez... :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12674 üzenetére

    "de nem találtam utalást arra, hogy ide kell áthozni a domain-t is, elvileg megadta a tárhelyet alapból, csak a DNS-t kell átregisztráltatnom ide"
    Fogod, és átviszed az egész Domain Name Systemet? :DDD
    Szerintem ezt a mondatot gondold át még egyszer. :)
    Továbbra is érvényes, amit korábban írtam. Az egyik cégnél regisztrált domain átregisztrálását kell kérni, amikor másik céghez költözöl.

    A 404-es hibáknak meg rettentő vicces magyarázata van, ezt már jeleztem is feléjük, hogy ez így nagyon béna: amikor olyan oldalt akarsz elérni, amihez nincs jogosultságod (mert nem vagy bejelentkezve (pl. lejárt a session cookie)), akkor az ezerszer logikusabb 403-as (Forbidden) hiba és egy bejelentkező űrlap megjelenítése helyett 404-es hibát (Not Found) kapsz, és a magyarázat az volt, hogy így legalább a rendszert cseszegetni akaró rosszindulatú automatizált robotok 404-et "látnak" kívülről, így úgy tűnhet, hogy nem érdemes az adott oldallal próbálkozni. Nem hiszem, hogy ez komolyan vehető védelmet jelentene, inkább semmi értelme, ráadásul felhasználói szempontból zavaró.
    Ettől függetlenül működik az oldal, a főoldalon tudsz bejelentkezni (hogy aztán nem kerülsz visszairányításra arra az oldalra, ahova mondjuk elmentett könyvjelző vagy klikkelt link segítségével eljutni szerettél volna, az már más kérdés... Szóval marad előbb a bejelentkezés külön...).

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12677 üzenetére

    Ja, hogy nekem csak úgy a levegőből ki kellett volna találnom, hogy neked a Forpsinál van regisztrálva és fizetve a domain, és a Tárhelyparknál volt a tárhelyed, tehát hogy eddig is két cégnél fizetted, és hogy a domaint továbbra is a másik cégnél szeretnéd fizetni, csak tárhelyet akarsz cserélni? Aha, mindenképp, ez csak úgy kiderül valahogy, anélkül, hogy leírnád. Ettől függetlenül természetesen ez lehetséges, de honnan tudjam, hogy így akarod? Hogy elmagyarázzam: azért javasoltam a teljes körű átregisztrálást, mert a Tárhelyparknál jelenlegi árak mellett DRÁGÁBB a domain fizetése, mint az eforce-nál (2400 Ft vs. 2000 Ft), és úgy láttam a korábbi hozzászólásodból, hogy neked ez a 400 Ft különbség igenis számít, tehát nem mindegy, hol fizeted (a Forpsi-nál meg az 1600 Ft-os árával a három közül valóban a legolcsóbb, de ezt eddig nem tudhattam, hogy náluk vagy), ezért elhiheted, hogy nem a rossz szándék vezérelt, amikor a teljes körű átregisztrációt javasoltam, és főleg nem tudom csak úgy az éterből kiszopkodni azt az információt, hogy te milyen módon szeretnéd kezelni a dolgot.
    Az info@eforce.hu mailcímen nekem egyébként igen gyorsan szoktak válaszolni, szóval kérdezd meg itt őket a részletekről.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Sk8erPeter #12681 üzenetére

    Ja, még annyi, hogy jeleztem nekik, hogy mást is zavar a 404-es hiba (akkor, amikor simán nincs jogosultság), elég gyorsan válaszoltak, hogy való igaz, és változtatni fognak rajta. :) Ez mindenképp pozitív, hogy figyelembe veszik. (Igaz, eleve nem így alakítottam volna ki, de az mellékes. :P)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12684 üzenetére

    Lehet, hogy a legutóbbi válaszom türelmetlenebbre sikerült a kelleténél, de ez az okoskodó "Khm.", meg a cinikusan kacsintós smiley-s "de igen, jót mulattunk. ;)", meg a "(csak hogy legyen mit kiröhögni)", és hasonló tök felesleges megjegyzések, meg úgy a hsz.-ed egésze, tehát a Te stílusod jelen esetben szerintem sokkal irritálóbb, mint az az egyetlen cinikus mondat az előző hsz.-emben, amit szerintem túlreagáltál (korrigáltam valamit, aminek abban a formában nem volt semmi értelme). Biztos én is rossz pillanatban olvastam, amit írtál, de sztem ez nem a "maximális tiszteletre" utal, amiről beszélsz, egyébként ilyenre nincs is szükség, senkinek nem kell hajbókolni, de azért vedd észre, hogy segítő szándékkal írtam az egészet, mert neked kell a segítség, nem nekem (legalább van alternatívád, ha én is leszarom a hsz.-edet, akkor asszem nem kaptál egy darab javaslatot sem ezenkívül). Igazából tényleg nem értem, miért fújtad fel ekkorára a problémát, itt kettő darab mondat volt a sokból, amin esetleg megsértődhettél (azt is minek).
    Ettől függetlenül remélem, a tartalmat is sikerült leszűrnöd, és valamennyivel előrébb lettél a rettentő sértő tanácsomtól.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12687 üzenetére

    OK. :D Szívesen. Kaptál választ azóta, vagy még nem foglalkoztál a dologgal? Most már érdekel, mi lesz. :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12689 üzenetére

    Igazából én sem értem már azt sem, hogy hogy éri meg olyan cégnek ingyen odaadni bárkinek 1000 MB tárhelyet, aki nem is annyira ismert, hogy gyaníthatóan óriási tőkével rendelkezzen... nem igazán kértek eddig cserébe semmit, egyedül a domaint fizettem, de pl. esetedben, ha másnál kell azt is fizetned, akkor 0 Ft bevételük származik ebből, és fogalmam sincs, mi nekik az egészben a biznisz. 1000 MB-nál többre meg a túlnyomó többségnek (akik igénybe veszik a szolgáltatásaikat, és nem egy nagy cégről van szó, hanem mondjuk saját blogról, ilyesmikről) egész biztos, hogy nincs szüksége, mert abba belefér egy viszonylag nagyméretű kódbázis, plusz még feltöltögetett jó sok kép is, meg akár hanganyagok. A Tárhelyparknál még legalább értettem az ingyen 100 MB-ot, mert az pont akkora, hogy bár elegendő lehet akár egy CMS-re, meg némi feltöltött anyagra, de már idegesítően pici akkor, ha bővíteni szeretnéd az oldalt, szükség van a tárhelyre a cache-elés miatt is, meg mondjuk e-maileket is szeretnél valameddig a szerveren tárolni - ezért ott jó volt az alapcsomag ízelítőnek, meggyőződtél róla, hogy megbízható szolgáltató, aztán váltottál a nagyobb csomagra, ami már fizetős (mondjuk esetedben nem ez volt, de sokszor ez a köv. lépés). De hogy egy ilyen 1000 MB ingyé' szolgáltatás kinek miért éri meg, amikor nem kérnek cserébe semmit, fogalmam sincs. :D
    Ja, amúgy majd megírhatnád, mit válaszoltak, kíváncsi vagyok. :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz DeFranco #12694 üzenetére

    Jaja. Az eforce-nál viszont még akkor sem értem, ha piacszerzés és marketing, mert nem látom be, hogy mit érnek vele: tételezzük fel, most elkezdtünk beszélni róla, hogy léteznek, és elkezdenek regisztrálgatni az emberek, aztán esetleg továbbterjed, és akkor mindenkinek lesz ingyé' 1000 MB tárhelye, amit tök jól el tud használgatni saját blogjaira, sőt, akár céges honlapra is (hiszen sok cégnél nem kell nagy adatokat tárolni), és lehet, hogy a domaint pedig hozzád hasonlóan másnál fizetik... szóval tényleg nem értem, miért éri meg nekik így ingyen üzemeltetni. :DDD Sztem a Tárhelypark megtalálta az egyensúlyt a korlátos ideig használható 100 MB-tal, az eleinte még próbálgatásokra pont jó, abba még úgy épp beleférsz nagyobb kódbázissal is (ld. CMS), hogy teszteld a szolgáltatás stabilitását, meg a lehetőségeket, aztán váltasz nagyobbra. Na mindegy, őket kéne megkérdezni, hogy összességében van-e profitjuk, és jól átgondolták-e. :DDD Végül is már működnek több, mint 2 éve, bár reklámot róluk még egy darabot nem láttam, igaz, lehet, hogy ezzel a logóval nem is kéne. :DDD

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz biker #12696 üzenetére

    Azért az más :)
    Kiváló áruk fóruma:
    Kiváló áruk fóruma

    Abstergo:
    Abstergo, Abstergo

    eforce:
    eforce

    Na mindegy, utóbbi kőkemény lenyúlás :DDD

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz AtHoS #12700 üzenetére

    Egyáltalán nem biztonságos az autofill opció a jelszókezelőkben, nem is értem, Phvhun kolléga miért sugallja azt, hogy semmi gond ne lenne ezzel... :U Valószínűleg azért alakult így, hogy egyből kitöltésre kerülnek a mezők, mert a felhasználók többsége rohadt lusta, ráadásul a képességei igen erősen hagynak kívánnivalót maguk után (vagy ostoba, vagy simán nem ért hozzá), ezért nehéz lenne felfognia egy olyan módszert, mint ami pl. a <=12.x Operára jellemző volt (ahogy írtad is), hogy Ctrl+Enter kombót kellett beütni ahhoz, hogy a jelszókezelő Wand működésbe lépjen, és automatikusan kitöltésre kerüljenek a mezők (és ne automatikusan kerüljön kitöltésre egyből minden űrlap) - de ugye manapság az a trend, hogy a gyenge képességű átlagfelhasználók igényeire alapozunk mindent. Most ez bármilyen borúsan és nyavalygósan hangzik is, akkor is így van.
    Semmibe nem kerül írni olyan extensiont, ami az automatikusan kitöltött jelszómezőből kilopja a jelszót, és elküldi valahova (most próbáltam ki content scripttel, Google Chrome extensionnel, tartott az egész kb. 5 percig :D), vagy épp átírja az űrlapoknál az action-attribútumot, úgy, hogy lopós URL-re kerüljön továbbításra először minden adat, aztán átküldje az eredeti címre is, és álcázva legyen, hogy minden pont ugyanúgy történjen, ahogy egyébként is történne. A keményebb dió az, hogy ezt az egyébként elsőre nem feltétlenül észrevehető extensiont ráerőltesd a mit sem sejtő felhasználóra. Az is gyakran alkalmazott sunyi módszer az ilyen rosszindulatú progiknál, hogy átíródik az összes böngészőben az alapértelmezett kereső (ez még a jobb eset, ha csak ez történik), annak írmagját is nagyon nehéz kiirtani (csökkentett mód, megfelelő detektáló progik beszerzése), és néha nem egyértelmű, mivel ment fel, főleg egy átlagfelhasználónak, nyugodtan sunyiskodhatna egy ilyen rohadék a háttérben.
    Aztán lehet elvileg sima kliensoldali kóddal is elérni ilyet.
    Gondolj bele: a felhasználó még nem is pötyögött semmit az űrlapokba, máris az autofill segítségével ott van minden szükséges adat a megfelelő mezőkben: tök jó, küldjük is el a csúnya bácsiknak.

    Nyilván sosincs biztonságos módszer, de az űrlapok automatikus kitöltése, ami a legelterjedtebb, semmiképpen sem tekinthető annak, sokkal értelmesebb volt az Opera régi módszere. Legalább ott TE vezérelted a folyamatot, hogy tényleg ki akarod-e tölteni az űrlapot (például mi van, ha valaki feltörte azt az oldalt, amiben korábban megbíztál), nem volt rábízva a böngészőre vagy más külső jelszókezelő progira.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz AtHoS #12713 üzenetére

    Azért senki ne kezdje vagdosni az ereit :DDD Ha odafigyel az ember, miket telepítget, elméletileg nem kell ilyesmitől parázni. Azért ilyen esetben nem olyan egyszerű ráerőltetni a júzerre jelszólopós extensiont. Meg a fenti okoskodás ellenére én is használom az autofillt :D mert sajna nincs ilyen Ctrl+Enteres módszer, pedig sztem mindenképp értelmesebb lenne rábízni a júzerre, mikor akarja kitöltetni az űrlapokat. Persze biztos van még lehetőség, ami most nem jutott eszembe. :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Phvhun #12717 üzenetére

    Itt ha jól értettem, az esetleges kockázatokra, akár szélsőséges lehetőségekre kérdezett rá, amik miatt problémás lehet az autofill - szerintem ezek köre szűkülhetne, ha valóban on-demand történne az űrlapok kitöltetése.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Rolly #12743 üzenetére

    Tedd ezt a rootban lévő .htaccess-fájlba:

    RewriteEngine on
    RewriteRule ^nyitooldal$ http://%{HTTP_HOST}/ [R=301,L]

    Természetesen a RewriteEngine on sor csak egyszer szerepeljen, ez nálad már bent lesz a .htaccess-fájlban, szóval esetedben csak a második sor érdekes. Valahova a többi szabály elé tedd be.
    Itt a protokoll be van drótozva sima HTTP-re, ha HTTPS-en is elérhető az oldal, akkor persze erre külön feltételt érdemes létrehozni.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    Azért ez HTML+JS+CSS-kombóval nem rossz (Howl's Moving Castle):
    http://greensock.com/?post_type=example&p=5966
    http://codepen.io/gordonnl/full/byouf/
    (dolgoztatja a procit rendesen :) )

    (#12745) Rolly:
    Szívesen! :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz biker #12749 üzenetére

    Ez nagyon tetszik:
    "A statikus weboldalnak vannak előnyei és persze hátrányai is.
    Előnyei:
    [...]
    - Optimálisabb a felépítése az internetes keresők számára.
    [...]"

    Say what? :DDD

    Awkward...

    "A dinamikus weblapok alapeleme az ún. motor"
    Ez még annyira nem gázos, de mókás, amikor az "úgynevezett" szót azért használja valaki, hogy szakszerűbbnek tűnjön a szöveg. :)

    "[...] amelynek segítségével ismételten végezhetőek azonos műveletek egyszerűen (például hírportálok)"
    Remek folytatás! Ezek szerint a statikus weboldallal nem végezhetőek azonos műveletek egyszerűen? :D Minek erőlködik definíciókkal, ha fogalma nincs az egészről.

    "A statikus weblapok létrehozására alkalmas a HTML és JavaScript és minden kliens oldalon futó webes nyelv."
    "és minden" - még hányféle nyelvet szeretne felhasználni a HTML, JavaScript, CSS trión kívül kliensoldalon?

    "A dinamikus weblapokhoz szükség van egy-egy olyan leíró nyelvre (például PHP, Java)"
    Nem is tudtam, hogy a PHP és a Java leíró nyelvek. :D

    Slap

    "adatbázisba betárolás"
    Szép kifejezés.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    Cyber security:
    https://www.youtube.com/watch?v=opRMrEfAIiI

    :N

    (#12753) Zedz:
    Most megmutattad neki, hogy a dinamikus oldalak "segítségével ismételten végezhetőek azonos műveletek egyszerűen"! :DDD

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Phvhun #12761 üzenetére

    "Projekt fájlok összeszinkronizálására használhattok dropbox megosztott mappákat, és akkor kb minden meg is van oldva."
    Öm, verziókezelők (pl. Git)? :F

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Phvhun #12764 üzenetére

    Ja, hát azalatt, hogy "projektfájlok", nem volt egyértelmű, hogy mit is értesz pontosan. Ilyenek lehetnek programozós projektekhez tartozó fájlok, illetve tök más jellegű, például épp grafikus tervezőprogikhoz készült fájlok is... :)
    A Photoshop-fájlokra és egyéb óriásfájlokra tényleg nem túl jó megoldás például a Git. Most rákerestem, és ez egy egész érdekes thread:
    http://superuser.com/questions/715690/can-i-use-git-to-version-control-psd-files-and-maya-projects
    Itt vannak a Facebookos tapasztalatok:
    https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

    Ez pedig egy elég jónak tűnő SVN-kliens Adobe-cuccokhoz (Adobe Photoshop/Illustrator/inDesign-pluginek formájában):
    Timeline
    http://pixelnovel.com/timeline/

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Zedz #12747 üzenetére

    Ez így rendben is van, a CDN-eket nem véletlenül találták ki, de számomra ez az egy rész érthetetlen:
    "The google.load() approach offers the most functionality and performance."
    Ami állítólag a Google eredeti iránymutatása, bár most nem találtam már ilyen mondatot a hivatalos oldalakon. Nem látom be, hogy a plusz overhead egy plusz kliensoldali metódushívással, majd a megfelelő fájl dokumentumba injektálásával mitől is gyorsítaná fel a betöltést ahhoz képest, mintha simán csak egy URL lenne bedrótozva a megfelelő attribútumba - mindkét request során a háttérben megtörténnek a megfelelő terheléselosztási, kiszolgálási mechanizmusok, csak a google.load() még hozzátesz plusz lépéseket.
    Alapvetően egy kényelmes megoldásnak tűnik, mert így a google.load() segítségével több szolgáltatás fájlja is betölthető a sok csúf bedrótozott URL helyett, és könnyű verziót is váltani, callback-et lehet definiálni, ilyesmik, de hogy ez a teljesítményen miért is dobna, az számomra érthetetlen. Ha valakinek van ötlete, megoszthatná. :D
    Azt is el tudom képzelni, hogy ez simán ki lett emelve a kontextusából, és így önmagában simán hülyeség, mert nincs ott, hogy mihez képest nyújt jobb teljesítményt.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Rolly #12788 üzenetére

    Így van, épp emiatt totál felesleges a külön mobilos aldomain. Detektálás után ki lehetne szolgálni az alternatív tartalmat.
    Mondjuk 2015 van, ideje lenne inkább reszponzív oldalakat készíteni. :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Rolly #12790 üzenetére

    Hát ja, nem két perc átállni, de pl. PeachMan most akarna készíteni mobilos nézetet úgy, hogy totál szeparált megoldást választ, ehelyett szerintem értelmesebb lenne ugyanazt az erőfeszítést abba fektetni, hogy media query-ket felhasználva reszponzívvá teszi a meglévő oldalát, és úgy készíti el a mobilon/egyéb eszközön is jól kinéző változatát az oldalnak.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz martonx #12792 üzenetére

    Abszolút egyetértek az "apró megjegyzéseddel", és szerintem nem is kell, hogy olyan apró legyen. :DDD Például egy meglévő oldal esetében egy teljesen különálló mobilnézet létrehozása az elavult, különdomaines átirányítós módszerrel szerintem ugyanakkora szopás tud lenni adott esetben, mint a meglévő oldalt átalakítani reszponzívvá. Én legalábbis nem látom egyszerűbbnek egyiket a másiknál, mindkettőnek megvan az előnye-hátránya. Abban az esetben természetesen költséges lehet, amennyiben már most is létezik egy működő változata mindkettőnek, de ha most készül éppen a mobilnézet, akkor mindenképp a jövőre gondolva a reszponzívvá alakítást választanám.

    (#12794) martonx:
    "mobilos megjelenítés, és reszponzivitás szemszögéből nézve (nem pedig dizájn, illetve használhatóság) a hardverapro.hu teljesen rendben van ellentétben a mobilos PH-val"
    Ezzel viszont már sajnos nem érthetek egyet. :DDD Miért van rendben reszponzivitás szempontjából a HardverApró? Próbáld ki a böngésző fejlesztőeszközével különböző felbontásokon. Egyáltalán nem alkalmazkodik a beállított felbontásokhoz. Újrafrissítést igényel, hogy igazodjon, tehát detektálás van oldalbetöltéskor, és ahhoz képest mutat egy alternatív nézetet, amiből van még egy darab, aztán kész.
    Nem beszélve a HardverApró okádék kódjáról.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz honda 1993 #12797 üzenetére

    Sztem nyugodtan bedobhatod ide a linket, ízekre szedjük a kódot majd jól ellátunk tanácsokkal. :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz honda 1993 #12875 üzenetére

    Szerintem eddig Phvhun foglalta össze a legjobban:
    "Ha meg mind a kettővel akarsz egyszerre foglalkozni, akkor nagy valószínűséggel megmarad mindkettő témakör hobbinak, és egy petákot nem fogsz látni belőle."

    Ezt azért fontos hangsúlyozni, hogy ilyen dizájnnal ne ringasd magad fals álmodozásokba, hogy ezzel majd be fogsz futni. Többiek is elég jól leírták, hogy jelenleg otthoni gyakorolgatások szintjén tart a dolog, ezzel eladni semmit nem lehet, akármilyen egyedi ötlet is lehetne. De igazából az ötlet sem egyedi, amivel semmi baj nincsen, egy mobilos oldal a többi közül - csak tényleg úgy vezetted elő a dolgot, mintha egy nagy durranással akarnál berobbanni, és most aztán lesz nemulass. És tényleg senki nem akarja elvenni a kedvedet (bár írtad is, hogy nem is lehetne), csak szembesít a valósággal, hogy nehogy később érjen pofáraesés, hogy miért nem dől a lóvé és a látogatók száma.
    Tervezel amúgy valami kereseti lehetőséget, vagy inkább hobbioldalnak szánod, amit élvezetből csinálsz? Csak mert valami oka biztos volt, hogy titkolni szeretted volna (még én sem jövök rá, mit titkoltál, ahogy martonx sem, de lehet, hogy van még terv, amit nem akarsz elárulni).

    Amúgy egyáltalán nem szégyen bevallani, ha az ember nem ért valamihez, én sem értek a dizájnhoz, nem is akarok, ezért rábízom másokra a dolgot. ;] (Bár azért ennél szerencsére több érzékem van hozzá. :DDD De idővel sztem ez is formálódik, és jobban ráérzel, hogy mi a ronda.)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz honda 1993 #12923 üzenetére

    "Visszatérveba responzive témára... Én egyre inkább úgy érzem hogy bootstrap helyett inkább media queriyket kellene használnol, sőt valami oknál fogva még egyszerűbbnek is tűnik számomra a media query, mint a bootsrap..."
    Ennek az összehasonlításnak semmi értelme nincs (szokás szerint), mivel a Bootstrap is media query-kkel működik, ez adja a reszponzivitás alapját, és a Bootstrap egy front-end keretrendszer, röviden és tömören egy csomó kód, csomó szopás, amit mások már megoldottak helyetted, neked csak a fejlesztői által kitalált HTML-struktúrát és osztályokat/attribútumokat kell alkalmaznod (és esetleg még rásegíthetsz JavaScripttel).

    "És egyébkent az nagy baj hogy nem használok semmi féle motort
    hanem úgy csinálom az új híreket hogy létrehozok egy másik html fájlt?"

    Kicsit gondolkozz: most ugye copy-paste-tel csinálod az összes HTML-fájlt, hol van ebben a rugalmasság? Ha akár csak a fejlécet megváltoztatod, máris vezetheted át a változtatást az ÖSSZES korábban létrehozott HTML-fájlba is. Kell még folytatni? :)
    Egyszerűsítenél a dolgodon, ha szerveroldali kóddal legalább annyival rásegítenél, hogy anélkül tudnád változtatni az alapvető keretet képező kódot, hogy 91826387534+1 helyre még át kéne vezetni a változásokat.

    (#12926):

    "Ém azt hittem hogy a media query hasonló mint a bootsrap."
    Szerintem még mindig fogalmad sincs, mi az a media query. Pedig beszélünk róla 1-2 hónapja veled a CSS topicban, elég hatástalannak tűnik. Egyszer én is írtam neked egy óriási hsz.-t, amiben egyszerű példákkal elmagyaráztam, nagyjából mire jó. A többiek is folyamatosan vezettek rá. Komolyan ennyire értelmetlen minden erőfeszítés? Ilyenkor a hozzászólásoknak úgy érzem, hogy olyan 10%-át akarod egyáltalán átengedni a felfogó-szűrőkéden.

    "Azt olvasom sok helyen hogy nem feltétlenül a bootsrap a legjobb választás, hanem jobb ha az ember saját maga írja meg az oldal responzive kódját egy keretrendszer alkalmazása helyett."
    Jó, hát végül is mi a francnak vennél meg egy autót, némi munka után összetákolhatnál egy saját készítésű szekeret is, és azzal is tudnál utazgatni. Egyébként nyilván nem a Bootstrap az egyetlen megoldás, léteznek más megoldások is, és amúgy nem árt, ha megtanulod az alapját, de ezek a keretrendszerek sok alapvető meló megspórolnak neked, ettől még nyugodtan ráhúzhatod a saját ízlésednek megfelelő kinézetet.

    "Ha én mégis úgy döntök hogy elkészítem a mobile.css t, akkor hogyan fogjak hozzá? Mármint minek kellene utánanéznem?"
    Na jó, asszem tényleg reménytelen vagy, pedig újból és újból naivan megerőltetem magam a válaszadásra, de hogy minek pazarlom a saját időmet, fogalmam sincs. :DDD
    Azért azt remélem, vágod, hogy ez nekem is és a többieknek is a középső ujjad bemutatása, hogy ezt nektek, ennyit ért a sok segítségetek, amiket magyaráztatok a CSS topicban.

    ===================================

    (#12921) biker:
    Nem tudom, követted-e az elmúlt pár hónapban a CSS topicot, az alapján az is meglepő, hogy most már egyáltalán valami elviselhető módon megjelenik az oldal, és a HTML+CSS-kód nem tűnik olyan gusztustalannak, szóval azért ne lépjünk ekkorákat, hogy motorral kéne kiszolgálnia a tartalmat. :DDD Persze normális esetben ennyi hónap után már az ember szerveroldali kódot tákolna rég, de nála ez a dolog kissé lassabban működik (kb. három hónapnyi gyakorlat után még magyarázni kellett neki, mire jók a CSS-osztályok)...

    ====================================

    (#12932) fordfairlane:
    Hát ja, jogos, én sem értem, minek erőlködöm még mindig.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz fordfairlane #12947 üzenetére

    Sztem az is érdekes kérdés lehet, hogy egyáltalán mi a jó nyelv első programozási nyelvnek, amivel elsajátítható a szemlélet, amit aztán lehet továbbvinni, bonyolítani. A Java topicban volt szó róla pont, hogy vajon mivel érdemes kezdeni (és a srác nem javasolja a Javával kezdést):
    http://prohardver.hu/tema/java_topic/hsz_6771-6771.html
    Elgondolkodtató, ez alapján lehet, hogy egy scriptnyelvvel kezdeni talán jobb egy újoncnak ahhoz, hogy azonnal kapjon visszaigazolást arról, hogy amit csinál, annak mi az eredménye. Java és C# esetén is felmerül a kérdés, hogy jó-e egy newbie-nak, hogy egy kiíratáshoz is be kell csomagolnia egy osztályba a kódját. Egyetemen C-vel kezdtünk, ami ugye elég alacsony szint, számomra elég erős volt legeslegelső programozási nyelvnek, úgy, hogy fogalmam sem volt az egészről. Mondjuk az is igaz, hogy mire ezen keresztülvergődtem magam igen nehezen, azután a magasabb szintű nyelvek elsajátítása gyorsabban ment, meg jobban tudtam értékelni, hogy mi mindennel nem kell foglalkozni.
    Vajon jó egy kezdőnek kapásból az erős objektumorientált szemlélet?

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz fordfairlane #12981 üzenetére

    Ja hát igen, ebben igazad van, a belinkelt hozzászólást én sem tartom mérvadónak, inkább elgondolkodtatónak, ettől függetlenül én sem gondolom, hogy feltétlenül olyan nyelvekben kellene elkezdenie programozni a kezdőnek, amit valamilyen hosszabb távú céljaira nem tudna felhasználni, mármint ami miatt az egészet mondjuk elkezdte - ha pl. valaki autodidakta módon tanulja, és webfejleszteni szeretne mondjuk ASP.NET-ben, akkor elég értelmetlen Haskellben tanulgatni. Talán az lehet egy érdekes szempont, hogy inkább megéri-e valami scriptnyelvben elkezdeni dolgozgatni, ahol nem biztos, hogy egy sima kiíratáshoz bármi komplexebb struktúra szükséges (pl. egy osztályba csomagolni a kódodat), csak ír egy sort, aminek lesz valami eredménye. Ez alapján akár a PHP nem is rossz kezdésnek. A gond inkább az, hogy szerintem szimplán a PHP (mint szerveroldali nyelv, most a CLI-s használata a téma szempontjából mellékes) tanulásával csak ritkán sajátít el valaki egy jó szemléletet a programozásban (ezt csak az alapján gondolom, hogy sok ilyen emberkével találkozni fórumokon, vagy akár munkaviszonyban), részben mert maga a nyelv túl engedékeny, részben meg mert sokszor finoman szólva érdekes megoldásokat alkalmaz, szóval szerintem jó, ha minél több, a PHP-nál szigorúbb nyelvet is megismer az ember, hogy érezze, hogy azért bizonyos határok közé van szorítva a tákolás.

    (#12980) martonx:
    Én is abszolút autodidakta módon tanultam az egész webfejlesztést, ahhoz, hogy valaki belemélyedjen, kell egy adag jó értelemben vett kockaság. De azért biztos vagyok benne, hogy nagyon sokat segített az is a dologban, hogy legalább az egyetem által rá voltam kényszerítve elég sok egyéb nyelv elsajátítására is, meg nyilván az is segített, hogy rámszóltak, ha valamit szarul csináltam, erre jó volt a fórum, kollégák, haverok is. :D Na, de a lényeg, hogy ha szimplán a PHP-t nyomatja valaki (meg nyilván a kapcsolódó nyelveket webfejlesztésnél), akkor nem találkozik egy csomó olyan problémával, amiből eleget tudna tanulni, a nyelv sem szól érte, hogy valami nem korrekt.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz merkucyo #12982 üzenetére

    Statikus oldalakhoz elég kis tárhelyméret is elegendő lehet, kérdés, megéri-e nektek olyan megoldást választani, aminek a változtatása adott esetben nehézkes. Nem írtad le, milyen sűrűn lenne szükség változtatásra. Akárhogy is van, lehet, hogy később kiderül, hogy bővíteni kell, és akkor eleve kiindulhattatok volna egy rugalmasabb megoldásból. A neten elérhető különböző WYSIWYG weblapszerkesztőknek nevezett valamikkel készített kód nem biztos, hogy egy hozzáértőnek egy későbbi esetleges átalakítási igénynél meg fog felelni, így ha később nekiesik az általatok elkezdett oldalnak, akkor lehet, hogy azt fogja javasolni, hogy inkább hadd alakítsa át az egészet elölről, mert a meglévő statikus kódhalmazba túl nagy macera lenne beletákolni a saját megoldását, és dinamikussá alakítani az egészet (én is vettem már így át munkát, semmi értelme nem lett volna folytatni a korábbi tákolmányt, így javasoltam a megrendelőnek a komplett átalakítást). Nyilván ez megbeszélés kérdése is.

    (#12994):
    "Egy weblapszerkesztő éves előfizetése nem tér el sokkal attól, mint amennyit egy vállalkozó elkérne, kb egyformán 60-80e Ft."
    Hogy ez az "egyformán 60-80e Ft" honnan jött, azt nem tudom, mert nincs ilyen hallgatólagos egyezmény a webfejlesztők között, hogy ennyi és annyi lesz az ár, minden totálisan egyénfüggő, amibe beletartozik az illető (fejlesztőcsapat vagy egyéni fejlesztő) hozzáértése, az oldal komplexitása, a ráfordítandó időigény, stb.

    Igényes céges honlapra rá kell szánni a pénzt, legyen amögött akármi is (és hozzátenném, hogy a CMS az itt elhangzó, kicsit félreértésekre okot adó hozzászólások ellenére nem mond ellent az igényességnek, igen sok ellenpélda van erre).

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Phvhun #12999 üzenetére

    Ja, nem, itt elmagyaráztad, mire gondoltál, szóval ezzel így egyet is értek, inkább gondoltam annak is legyen egyértelmű, aki nem vágja a témát: igényes lehet attól még, mert CMS, viszont egy kezdő nem igazán valószínű, hogy ki fog tudni alakítani egy valóban igényes oldalt (tök mindegy, miben is készült), mert nincs meg hozzá a kellő tudása, és kész. Most igazából azt mondtam el, amit Te is, csak más szavakkal. :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CactuS #13001 üzenetére

    "a www nélkül beírt domain címét átdobja a www-s változatra"

    # Set "protossl" to "s" if we were accessed via https://. This is used later
    # if you enable "www." stripping or enforcement, in order to ensure that
    # you don't bounce between http and https.
    RewriteRule ^ - [E=protossl]
    RewriteCond %{HTTPS} on
    RewriteRule ^ - [E=protossl:s]

    ##########################

    # To redirect all users to access the site WITH the 'www.' prefix,
    # (http://example.com/... will be redirected to http://www.example.com/...)
    RewriteCond %{HTTP_HOST} .
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    Ez a Drupal .htaccess-fájljából származik, ez így egy jóval általánosabb (bármilyen oldal .htaccess-fájljába átmásolható) megoldás (amibe ráadásul a protokoll sincs bedrótozva, a HTTP- és HTTPS-kapcsolatokat egyaránt támogatja).
    A fordítottja pedig (www NÉLKÜLI változatra való átirányítás) így néz ki (az előző, protossl környezeti változóra vonatkozó rész (a hashmarkkal jelzett vonal fölött) természetesen itt is legyen bent!):

    # To redirect all users to access the site WITHOUT the 'www.' prefix,
    # (http://www.example.com/... will be redirected to http://example.com/...)
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

    "viszont a /administrator oldalt is megtoldja egy kicsit www.pelda.hu/hu/huadministrator -nak, ami ugye nem túl jó, mivel így nem lehet belépni az administrator részre"
    A www.pelda.hu/hu/administrator cím jó lenne, vagy csak a hu nélküli változat (vagyis www.pelda.hu/administrator)?

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CactuS #13004 üzenetére

    Na igen, ez a rewrite condition már jóval értelmesebb, mint ami a korábbi feltételedben szerepelt. Akkor végül is ez helyesen működik?
    Amúgy a Gmail-authentikációnak ehhez az egészhez nincs túl sok köze... Hogy azzal mi lehet a gond, azt így kód nélkül nehéz lesz megmondani. :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CactuS #13006 üzenetére

    Ha jól értem, az egyik gépen megy a levélküldés, a másikon nem. Rákerestél a hibaüzenetre? :) Mert sokat tud segíteni. :)

    kapcsolódó doksi:
    https://docs.joomla.org/How_do_I_use_Gmail_as_my_mail_server%3F

    "The OpenSSL extension needs to be enabled in PHP."
    Valószínűleg ez az extension nincs engedélyezve azon a gépen, amin a probléma jelentkezik. Ha a phpinfo()-t eléred, akkor abból könnyen kideríthető, hogy engedélyezve van-e, vagy sem (egyszerűen keress rá az "openssl" kulcsszóra).

    Egyébként többek közt pont ezt utálom a Joomlában és a hozzá fejlesztett pluginekben/komponensekben (vagy minek hívják ezeket Joomlánál, asszem nem modulok), hogy valamiért bevett szokás, hogy a fejlesztők magasról leszarják a normális hibakezelést: ez is egy vicc, hogy PHP Notice formájában írja ki, hogy probléma van az SMTP-csatlakozással, de még véletlenül sem ellenőrizné le és írná ki egyértelműen, hogy mégis egész pontosan mi a nyűgje (ami alapján egyből lehet tudni, és nem úgy kell kotorászni, hogy mégis mi LEHET)...

    "Azt még elfelejtettem megkérdezni, hogy szerinted/szerintetek a phpmail vagy smtp között van különbség? (nyilvánvalóan) Úgy értve, hogy van bármilyen hátránya annak, hogy phpmaillel küldi a Joomla az emailt és nem gmailen keresztül SMTP-vel?"
    Nem értem a kérdésedet. Most mit értesz "phpmail" alatt? A PHPMailer osztályt? Vagy a PHP beépített mail() függvényét? (Utóbbi felejtős nyilván.) Az SMTP meg egy protokoll emailküldésre, szóval nem tudom, mire gondolsz. :DDD

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CactuS #13009 üzenetére

    Hát ja, akkor úgy tűnik, engedélyezve van az OpenSSL extension. Ez alapján még érdekesebb az a rettentő beszédes hibaüzenet. :D Nem értem amúgy, ha ír valaki egy ilyen modult, akkor miért nem az alapvető hibaellenőrzéssel kezdi eleve a fejlesztést, vagy ha ez korábban kimaradt, és látja, hogy bőven van felhasználója, akkor utólag miért nem hegeszti bele... (pl. mi az, hogy nem sikerült csatlakozni a szerverhez? MIÉRT nem sikerült csatlakozni hozzá? Mit kellene javítani, ha engedélyezve van az OpenSSL extension?) Esetleg a sima PHP-s logból (nem a Joomla sajátja, hanem ami a szolgáltatónál van beállítva, hogy hova logoljon a PHP hibák esetén) nem derül ki valami? Arra még azért nézz rá. Szerk.: ja, közben megnézted a logot, látom hasonlóan beszédes itt is a hibaüzenet. :DDD
    Hogy a Joomlánál az általad mutatott három levelezőszolgáltatás közül melyik miért és hogyan működik, arra sajnos nem tudok válaszolni, nem ismerem a Joomlát (nem is akarom :P).
    De amúgy most nem azt írtad, hogy működik valamelyik? Ha igen, annak mi a hiánya, ami miatt nem jó?
    Ha tudsz angolul, én a helyedben itt feltenném a kérdésemet: http://joomla.stackexchange.com
    Itt tuti, hogy tudnak válaszolni a kérdéseidre, és megoldási javaslatot kínálni.

    "Engem a legjobban az idegesít, hogy 2-3 modul/plugin telepítése után szinte garantált a Mootools/Jquery összeakadása, amit egy plusz egy modullal lehet talán rendbe tenni."
    Na ez para, eleve inkább olyan modult kéne csak feltenni, ami csak az egyik library-t használja. Az a plusz modul gondolom a jQuery.noConflict()-ot használja valamilyen módon. De kerülendő a dolog általában, nem jó, ha több ilyen library-t is be kell húznia a kliensnek, lassít, összeakad, kutyulódást okoz a kódban (elég hülyén mutat, hogy az egyik eszerint a library szerint íródott, a másik a másik szerint, miközben a szintaktika sokszor hasonló, de mégis más), stb.

    "egy CMS mellett ez ugye javarészt csak HTML és CSS"
    Ha minimálisan is akarsz fejleszteni is egy CMS-hez, akkor a JavaScript (+legtöbbször jQuery) és az adott szerveroldali nyelv (legtöbbször PHP) ismerete is szükséges (különben legtöbbször a dolgok nem értése és tákolás származhat belőle).

    Szerk.: ja, egyébként milyen adatok vannak megadva a csatlakozáshoz? A felhasználónév és jelszó nyilván nem érdekel, csak az, hogy a többi adat micsoda, ami az SMTP-csatlakozáshoz meg van adva.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CactuS #13013 üzenetére

    Szerintem az összes igazán népszerű PHP-s CMS kódja valamilyen szempontból igen erősen kritizálható. Amikor régi melóhelyen egy kollégánál nézegettem a Joomla core kódját és a pluginekét, hiába volt alapvetően OOP, egy kutyulmány szar volt, össze-vissza voltak statikus és nemstatikus metódusok/változók, anélkül, hogy bármiféle logikát vagy mintát követtek volna. Láttam a WordPress core-jának és moduljainak a kódját is, borzalmas.
    Talán még a legnormálisabb a Drupalé (ezért is választottam ezt annak idején, mert ránézésre ez még legalább követhetőnek tűnt (bár akkor még fogalmam nem volt az egészről, hogy kell kezelni, meg azért, mert ezt ajánlották a legtöbb helyen, mint relatíve rugalmas CMS-t), de összességében az is egy kutyulmány, rohadt idegesítő ez a hagyományos procedurális és objektumorientált kódkatyvasz. Sok tekintetben erősen tolódik az OOP felé, főleg, hogy a Symfony keretrendszer sok komponensét átvették, de még a 8-asban is a kód nagy része a régi procedurális fos, pedig így, hogy annyi minden változik a 8-asban, és annyival erősebb és modernebb sok szempontból, reménykedtem egy erős API-váltásban. Ezzel együtt is számomra még mindig a Drupal tűnik a legjobbnak a 3 közül rugalmasság, jogosultságkezelés, fejlesztés, a mögötte lévő elég aktív közösség és egyebek tekintetében.

    Az SMTP-s problémára: szerintem sokkal gyorsabban megoldódna a gond, ha írnál a tárhelyszolgáltatódnak az ügyben, megírnád nekik ugyanezeket a tesztelési körülményeket. :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz homeless09 #13027 üzenetére

    1-2 nap, persze... :) Még a nagyon egyszerűnek tűnő munkáknál is rákerül pluszban még egy kis idő, mert ez-az kiderül, még ez kéne, még az kéne, ez így nem túl szép, az ajánlatküldő formot is szépíteni kéne, validálni, kéne CAPTCHA vagy valami Honeypot-szerűség, blablabla... Az ember egy idő után leszokik a túl optimista becslésekről, amik még eleinte reálisnak tűnnek. :D

    Sk8erPeter

Új hozzászólás Aktív témák