Hirdetés
- Felháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Linux kezdőknek
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Mikrotik routerek
- Facebook és Messenger
- Mozilla Firefox
- Freemail
- Kaspersky Antivirus és Internet Security Fórum
- Gmail
Új hozzászólás Aktív témák
-
GG888
senior tag
Sziasztok!
PHP Sessionnel kapcsolatos gondjaim vannam.
Eddig a következőképp működött az oldal:
- jön a guest, elindul a session
- kosárba rakja a termékeket, megy tovább a session
- vásárláshoz regisztrál, aktivál, belép, még mindig megy tovább a session.
- ha kilép a user akkor session_destroy van, egyelőre ez a kosarat sem kíméli.A probléma ott van, hogy a kosár mintájára csináltam egy wishlistet, ami sokáig kéne, hogy megmaradjon, még azután is, hogy a user bezárja a böngészőt. Elég komplex megoldás kellene, igyekszem összeszedni:
- jön a guest, elindul a session($a)
- berak valamit kosárba, meg wishlistbe, ez hozzáfűződik session($a)-hoz
- X inaktivitás után mentődik a session($a) az adatbázisba.
- Ott tárolva van, mondjuk 7 napig, majd törlődik.
- ha visszajön a guest, akkor újraindul, eddig szép és jó, főleg ha a guestből user lesz, bevásárol
- hasonló a helyzet akkor is, ha a user érkezés után belép, majd életre kel egy korábbi sessionje, mert a usereké mondjuk 30 napig marad meg.- a gondom az, hogy ha jön a guest, aki rak 15 terméket a kosarába, 10et pedig a wishlistbe, majd utána belép, mert mondjuk másik böngészőből van most épp, vagy a haverjánál lebzsel, vagy mittudomén.
Ekkor a 2 wishlistet és 2 kosarat össze kellene hasonlítani és megkérdezni a usert, hogy a korábbi munkamenetében voltak még termékek itt-ott és döntse el melyiket akarja megtartani.Szóval erre lenne valami ötletetek vagy létezik best practice jelen esetben?
Bármi megoldás érdekel, az is jó, ha sütibe lementem a a termékazonosítókat a wishlisthez összefűzve mondjuk egy ~ karakterrel.
Csak akkor meg apu fog meglepődni, mikor rájön, hogy anyu már járt az oldalon és wishlistre rakott egy 40 centis fekete dildot. Egyébként hardver shopról beszélgetünk, csak idevágott a hasonlat.
Előre is köszi
pcmodding.hu | PC MODDING | Minden, ami modding, verhetetlen árak.
-
Zedz
addikt
Sziasztok,
VM-en csinálok épp egy projektet, amihez szükségem lenne egy .htaccess fájlra. A fájl tartalma a következő:
RewriteEngine on
RewriteBase /weboldal
RewriteCond $1 !^(index\.php|assets|robots\.txt)
RewriteRule ^(.*)$ index.php?/$1 [QSA,L]Az oldal címe VM alatt: http://192.168.0.13/weboldal/
A problémám az lenne, hogy nem működik a htaccess. Szóval ha bármilyen linkre kattintok, az oldal elszáll, mondván nem találja a keresett oldalt. A host gépen megnéztem, ott tökéletesen működik. Mi lehet a baj?
-
Lacces
őstag
válasz Sk8erPeter #12977 üzenetére
A válasz: Python.
Rákaptam a coursera.org és edx.org oldalakra, és ott az összes (na meg a Stanford, MIT egyetemek) kezdő kurzusa mind Python-ban van. A Python azért jó, mert magát a programozási szemléletet lehet megtanulni, szerintem a legjobb tanuló nyelv, bár a { } hiányzik nekem . -
Lacces
őstag
Hello.
Leírom a szituációt: Van REST Api megvalósítva, az angularJS az oldalon jól tudja használni, de akár a jQuery is, a lényeg, hogy lenne egy HTML részlet, mondjuk egy table (stílusokkal), amit más oldalak számára is elérhetővé szeretném tenni, mint beágyazott HTML, azaz amit a youtube is csinál, kapsz egy beszúró iframe-et vagy object?
Én is ezt akarom, de nem tudom, hogy pontosan melyik megközelsítést érdemes használni.
Az Iframe azért jó, mert akkor a komplett table a css (bootstrap) stílusokkal (ami meg lett csinálva responzive-nak), csak azt az adott table és a hozzátartozó css-t...
Vagy egy komplett jQuery kódot, ami a REST-en keresztül lekérdezi az adatbázisból a szükséges információkat, max még a css fájlt behúzza, és aztán ott a böngészőben felépíti a html-t.
Én elsősorban a az iframe-re szavaznék, de nem tudom, hogy lesz-e probléma a css miatt, szerintettek?
Bár, ha a belegondolok, kell majd neki javascriptet is importálnia a hide/show miatt. -
bigbuda
aktív tag
válasz Sk8erPeter #13044 üzenetére
Köszönöm
-
Sk8erPeter
nagyúr
válasz bigbuda #13043 üzenetére
Inkább nagy eséllyel az első megoldás, mint a külön aldomain, ezt olvasd el:
http://prohardver.hu/tema/kereso_optimalizalas_seo/hsz_337-338.htmlSk8erPeter
-
bigbuda
aktív tag
Sziasztok, van egy .hu domainem, egy általános egyoldalas információs html5 oldal. Lefordított angol nyelvre is és érdeklődnék, hogy melyik megoldás lenne SEO barátabb?
*****.hu/en vagy en.******.hu
Mindenképpen maradna a hu domain, mert nem találok semmi releváns szabad külföldi domain alternativát.
Köszi
-
artiny
őstag
Brackets ben valaki tudja miert nem megz a live update nekem ? Csak akkor frissul ha nyomok egy ctrl+s -t.
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13039 üzenetére
Ilyen egyértelműen nincs leírva, mindösszesen a minimális php verzió van megadva. Amúgy így rákeresve néhány helyen riogatnak, hogy az fopen-t engedélyezve sebezhetővé (vagy sebezhetőbbé) válhat az oldal:
"Basicly if you allow php 'allow_url_fopen' you then can fopen files from remote locations but if somone found a flaw in your code they could easily write up some code, upload it to their own site then execute it from yours."
Mondjuk azt nem tudom, hogy az számít-e pl, hogy FTP védelem van az oldalon, azaz alapból mindenki ki van tiltva, egészen addig, amíg az admin felületen be nem jelentkezek. Akkor az adott IPre a következő nap 4:00-g engedélyezi a belépést.
Az elmúlt kb 6+ év alatt eddig egyszer volt baj, az is azért, mert a régi szolgáltató egy régi verziójú Plesk-ek használt (amiben még plain text-ben tárolták a jelszavakat) és szépen befertőzték az oldalt az ismert és kiszivárogtatott réseken keresztül. A hosting cég meg ennek ellenére b*szott frissíteni, sőt még azt bizonygatták, hogy nálunk van a hiba, biztos a mi gépeinken van keylogger... Aztán váltottunk hosting céget.
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13036 üzenetére
Így van, bár így utólag lehettem volna sokkal figyelmesebb is, de a lényeg a végeredmény.
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13034 üzenetére
Szép magyar neve van az admin felületen, mi? (allow_url_fopen)
És mivel hiába volt külön subdomain a teszhez, meg külön adatbázis, domainenként csak 1 php változat elérhető, átváltáskor anno nem figyeltem és utólag már nem tűnt fel a beállítás, hogy nincs bekapcsolva. Helyi szerveren meg naná, hogy minden tökéletesen működött.
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13024 üzenetére
Meglett a kis g*ci és még égő is. Php váltáskor nem minden beállítást vett át és a külső file-elérés le volt tiltva. Ennyit elb*szni egy ilyen hülyeségre... Viszont hibátlanul működik. Köszönöm mindenkinek az ötleteket és a segítséget.
Ezt így hallani elég eléggé lehangoló. Akkor gyakorlatilag egyik kutya másik eb kb. Utólag tényleg sajnálom, hogy a Joomlával futottam össze elsőnek. 4-5 év után már baromira nehéz átállni egy másik rendszerre. WP ilyen téren barátságosabb, bár pont azért szerintem, mert jóval többet rejt a motorháztető alá.
HummeRC, #13023: Nem leszólni akartam, mint fentebb látható ez is eléggé alap dolog volt, de pont elsiklottam felette. Amúgy nincs webshop az oldal alatt - más téma -, magát a céget regisztráltam be, amikor még ingyen lehetett. 10 email címig ingyenes, saját domain/email címek, gmailes spamszűrés, gmailes felületen olvasható levelezés. "Hawaii, dizsi, napfény"
Webshopból tökéleteset még CMS alá nem láttam, mindnek van hibája (főleg olyat, ami minden magyar jogszabálynak megfelel, kezeli normálisan faszerkezetben a termékek linkjét (breadcrumb), + lehet CSVvel importálni. Bár az új virtuemart-ot még nem volt időm megnézni J3 alá. Legutóbb WPn a Woocommerce-et néztem, az egész közel járt, viszont a termékek linkjeit botrányosan szarul kezeli.
#13028
Ezt a főnököm szokta mondani, hogy: küldtem át egy képet, ki kéne tenni ide és ide, de kéne egy kis csinosítás a képen itt, meg itt, nem sok, csak, hogy pofás legyen, meg az oldal ahova kerül is nézzen már ki valahogy, ok? Ha még némi Seo/adwords-öt hozzádobunk máris néhány hétvégés meló lesz.
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
G.F.
aktív tag
-
Sk8erPeter
nagyúr
Ne a fogaskereket keresd, hanem a "Megosztás" melletti három függőleges pöttyre kattints, és utána lesz ott majd a beágyazásra szolgáló menüpont:
Viszont a beágyazáshoz nyilvánosnak kell lennie a térképnek, úgyhogy előtte állítsd át privátról nyilvánosra a Megosztás menüpontban.
Sk8erPeter
-
homeless09
őstag
válasz Sk8erPeter #13028 üzenetére
Persze azzal számolok, hogy útközben azért csorog hozzá még valamicske.
'Nobody, nobody does it better than Manchester United'. |
-
G.F.
aktív tag
Sziasztok! Ha GoogleMapson csinálok egy saját térképet, azt hogyan tudom beilleszteni egy weboldalra, mikor nincs ott az a kis fogaskerék az alján, amire nyomva kiadná a beillesztési kódot.
-gf-
-
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.
Sk8erPeter
-
homeless09
őstag
válasz Phvhun #13026 üzenetére
A szövegeket megkapom, hogy mik szerepeljenek, esetleg ahhoz kis kiegészítés, képekkel ugyan ez a helyzet. Design annyiban lesz tőlük, hogy a színösszeállítást megkapom igazából, de a többi rajtam áll. Funkcióknál egy ajánlatkéréses email küldő felület legyen, meg lehessen a nyelvet változtatni magyar és német között. A többi csak egyszerű menüpontok képekkel és szöveggel.
'Nobody, nobody does it better than Manchester United'. |
-
Phvhun
őstag
válasz homeless09 #13025 üzenetére
Az ezért elég sok mindentől függ.
Van valami design ami tetszik nekik, vagy tök mindegy?
Esetleg el van készítve a design?Szövegek, oldalak struktúrája ki vannak találva, képek össze vannak gyűjtve, vagy mindent neked kell csinálni?
-
homeless09
őstag
Sziasztok!
Olyan kérdéssel fordulnék hozzátok, hogy ismerősnek kellene csinálni egy weblapot, pontosabban a cégének. Nem lesz nagy munka, semmi extra funkció nem kell a weblaphoz, valószínűleg 1-2 napos munka. Mennyit "illik" kérni ilyenért?
'Nobody, nobody does it better than Manchester United'. |
-
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
-
senior tag
válasz CactuS #13021 üzenetére
Értelek. Elnézést a sértő kérdésért, de annyira evidens a dolog, hogy gondoltam rákérdezek. Egyébként gondolom felvettél egy új felhasználót a joomla webshop tulajdonosának, akinek az a gmail a címe, amit szeretnél smtp-nek. Nekünk úgy máskor ment ugyanennél a szolgáltatónál. Ha így van neked és mégsem megy, akkor nincs több tippem látatlanban és nem okoskodnék tovább.
-
senior tag
válasz CactuS #13019 üzenetére
Bocsi, hogy belavau a nagyok dolgába, de ugye a mediacenternél be van fizetve az évi 5000Ft-os smtp díj? Csak mert mi futottunk bele ilyenbe. Náluk az smtp fizetős szolgáltatlás, de a sima php mail az megy alapból, a csomaghoz tartozó küldhető mail darabszám erejéig..
[ Szerkesztve ]
-
CactuS
Arcképgyáros
válasz fordfairlane #13018 üzenetére
Akkor nem értem. Most lehúztam az egész hóbelevancot és feltettem Xampp alá, onnan tökéletesen működik SSL/465, se a TLS/587-es porton az email küldés.
Bár nagyon távoli lövés, de a 2 php info-t összehasonlítva és az SMTPre rákeresve egy dolog különbözik:
Localhost:
curl
Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftpMediacenter:
curl
Protocols tftp, ftp, telnet, dict, ldap, ldaps, http, file, https, ftps[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz fordfairlane #13016 üzenetére
Ezek a kérés korlátozások elvileg minden php verziónál különbözőek lehetnek?
A régi honlap (1.5-ös joomla) ugyanezekkel a beállításokkal futott 5.2.17 -es php-n. Az új honlap a 3as verzió miatt már minimum 5.3.10-est kér, ahhoz legközelebbi az 5.3.29-es verzió.
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz fordfairlane #13014 üzenetére
Ha jól értem, akkor az ügyfél részéről ez annyit tesz, hogy a feladó pl nem a noreply@pelda.hu lesz, hanem xy@mediacenter.hu (mediacenter a tárhely szolgáltató), ugye?
Amúgy ezen a hibakezelésen lassan b*szarok. Átállítottam SMTPre, de most TLS, 587-es port, majd 25-ös (itt már tuti, hogy rinyálnia kéne, hogy legalább a port nem stimmel), de ugyanaz:
[04-Feb-2015 12:41:04 Europe/Budapest] SMTP -> ERROR: Failed to connect to server: (0)
[04-Feb-2015 12:41:04 Europe/Budapest] Sikertelen SMTP-csatlakozás
[04-Feb-2015 12:41:30 Europe/Budapest] SMTP -> ERROR: Failed to connect to server: (0)
[04-Feb-2015 12:41:30 Europe/Budapest] Sikertelen SMTP-csatlakozás
[04-Feb-2015 12:41:46 Europe/Budapest] SMTP -> ERROR: Failed to connect to server: (0)
[04-Feb-2015 12:41:46 Europe/Budapest] Sikertelen SMTP-csatlakozásHave you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
fordfairlane
veterán
válasz CactuS #13013 üzenetére
A PHP mail függvénye unix-linux rendszereken a sendmail-t használja MTA-nak (message transfer agent). A sendmailt az adminisztrátor tudja beállítani az adott kiszolgálón. A másik két Joomla "postázó" opció gondolom az, hogy vagy direktben csatlakozik egy MTA SMTP portjára, ebben az esetben az SMTP autentikációs adatokra szükség van, vagy pedig közvetlenül hívja meg a parancssoros sendmail-t.
x gon' give it to ya
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13011 üzenetére
Jaja, ez a beszédes dolog már a display_errors (A PHP saját hibakezelője által talált programhibák megjelenítése) által generált file. A joomla saját /log könytárában továbbra sincs semmi.
Elven jó lenne tanulni, csak mellette - lévén kis cég -, kellenek a grafikai, nyomdai munkák, honlapok, hardverek + munkatársak nyűgjeinek kezelése. Tudom, van az a mondás, hogy jack of all trades is master of none, de jelenleg ennyire futja az időmből.Főleg, hogy a cég egyedi munkamenete miatt lehet még a nyakamba szakad valami jó kis adatbázis kezelős buli is, de ez már nagyon off...
A Joomla másik nagy baja a verziók hajkurászása mostanában. Késtek legalább fél évet a 3.x-vel, a stabilnak mondott 3.5 még ki sem jött és a láthatáron sincs, de már a 4.x-et kezdik el hegeszteni... A modulok készítői is magyaráznak valamit, hogy részükről nem annyira frankó, de ehhez a részéhez nem értek. Bár olvastam olyat is,hogy aki ott van az Objektum orientált programozásban az meg a WPtől undorodik, lévén nincs tapasztalatom, így nem tudom melyik mennyire igaz.
fordfairlane: Eleddig semmi. Igazából érdekelt, hogy van-e valami hátulütője (azt leszámítva, hogy így az adott fiókban nem lesznek meg az elküldött levelek, mint eddig). Illetve érdekelt - most már egyre jobban -, hogy mi a fene baja van, amiért nem megy az eddig megszokott módon.
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
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. 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.
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 ).
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
-
CactuS
Arcképgyáros
Kicsit turkáltam joomla php file-ok között, az smtp.php-ban:
public $SMTPDebug = true;
public $Debugoutput = "error_log";Az eredmény legalább így a logban látható, de nekem sokkal többet nem mond. (google sem )
[04-Feb-2015 11:11:37 Europe/Budapest] SMTP -> ERROR: Failed to connect to server: (0)
[04-Feb-2015 11:11:37 Europe/Budapest] Sikertelen SMTP-csatlakozás[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13008 üzenetére
Igen, a doksit láttam a beállítás stimmel.
Joomlában a postázó három féle lehet:
Eddig SMTP volt, most egyedül a phpmail megy sajnos.Nekem ez alapján az jön le, hogy az OpenSSL megy (Joomla -> Rendszerinformációkból jött adatok)
PHP Version 5.3.29
System Linux s35 2.6.32.61 #3 SMP Fri Nov 29 02:11:34 CET 2013 x86_64
Build Date Aug 21 2014 12:36:47
Configure Command './configure' '--prefix=/usr/local/php5.3' '--enable-fastcgi' '--with-gd' '--with-mysql' '--with-zlib' '--with-jpeg-dir' '--with-png-dir' '--with-freetype-dir' '--with-pcre-regex' '--enable-track-vars' '--enable-wddx' '--enable-sysvshm' '--enable-sysvsem' '--enable-standard' '--enable-shmop' '--enable-sockets' '--enable-session' '--enable-posix' '--enable-mbstring' '--enable-iconv' '--enable-gettext' '--enable-ftp' '--enable-filepro' '--enable-exif' '--enable-dba' '--enable-ctype' '--enable-calendar' '--enable-bz2' '--enable-bcmath' '--enable-dbase' '--with-gettext' '--with-xml' '--with-iconv' '--with-curl' '--with-imap' '--with-kerberos' '--with-imap-ssl' '--with-openssl' '--enable-soap' '--enable-memory-limit' '--enable-intl' '--with-xsl' '--with-mysqli' '--with-pdo-mysql' '--with-mcrypt' '--with-tidy' '--enable-zip' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-libxml-dir=/usr/src/mediacenter/libxml/libxml2-2.7.8'openssl
OpenSSL support enabled
OpenSSL Library Version OpenSSL 0.9.8g 19 Oct 2007
OpenSSL Header Version OpenSSL 0.9.8g 19 Oct 2007
Phar
Native OpenSSL support enabledSajnos anno én - részben a munkahelyem miatt- a Joomla-val kerültem kapcsolatba, még az 1.x kijövetelekor. Azóta már van drupalos és wordpress-es oldalunk is. Drupal nekem sajnos nagyon idegen a node-okkal a Joomla/WP után, képtelen voltam átszokni. 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. (mondjuk "hasonlóba" futottam drupalnál is, amikor az UC_Addresses modul szétfagyasztotta a webshop importját CSVből, olyan szinten, hogy rollback kellett). Nem vagyok egy nagy programozó, bár a felsőoktatásban tanultam pár nyelvet, gyakorlatban megmaradt annyi, amennyi muszáj (egy CMS mellett ez ugye javarészt csak HTML és CSS).
Visszatérve a hibára, igen az külön idegesítő, hogy a hibajelentés maximumra van állítva, de a logban sehol nem szerepel, hogy nem sikerül csatlakozni a kiszolgálóhoz, vagy valami...
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
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.[ Szerkesztve ]
Sk8erPeter
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13005 üzenetére
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?
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13005 üzenetére
Igen, úgy tűnik, hogy jól működik. (kivéve az otthoni gépemet, ott szerintem még a cache elmentette a régi átirányítást, de invisible ablakban ott is megy, melóhelyen tökéletes).
Kódrészletet nem tudok, mert igazából a joomla nem menti ki logba, csak annyit ír ki (még ha csak belső levelet akarok küldeni): sikertelen SMTP csatlakozás (Notice: SMTP connect failed). Azt nem tudom, hogy vehetném rá, hogy részletesen loggoljon, de a beállításokban a hibajelentés: maximális-ra van állítva.
Most elindítottam a Xamppot az eredeti gépen, ott meg fut, 3.3.6, PHP Version 5.4.19-vel, igaz, bő két hónappal ezelőtti változat, de fogalmam sincs, hogy mi lehet az, ami miatt kiakad.
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
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
-
CactuS
Arcképgyáros
válasz CactuS #13003 üzenetére
RewriteEngine On
RewriteRule ^ - [E=protossl]
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=protossl:s]
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_URI} ^/$
RewriteRule (.*) http://www.pelda.hu/hu [R=301,L]Így működik az admin felület is. (A joomla gmail authentikáció viszont nem. Lehet, hogy a mediacenter-nél van valami beállítási bibi?)
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
CactuS
Arcképgyáros
válasz Sk8erPeter #13002 üzenetére
Köszönöm, kipróbálom a fentit kettőt. Csak a www.pelda.hu/administrator a jó cím.
Edit: Az megoldható egyben, hogy a pelda.hu egyből a www.pelda.hu/hu-n landoljon?
RewriteRule ^ - [E=protossl]
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=protossl:s]
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Vagy ezek után kéne még átdobni a / -ból a /hu-ra?
[ Szerkesztve ]
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
-
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
-
CactuS
Arcképgyáros
Sziasztok!
.htaccess redirect-ben szeretnék egy kis segítséget kérni. A cél az lenne, hogy a www nélkül beírt domain címét átdobja a www-s változatra, illetve, hogy a root foldert átirányítsa a /hu végződésre (kétnyelvű oldal lesz, a régi változatban csak a / volt, az újnál a nyelvkezelés miatt alapból a /hu-ra kell érkeznie.
Nekem ez így nézne ki:
RewriteCond %{HTTP_HOST} ^pelda\.hu [NC]
RewriteRule (.*) http://www.pelda.hu/hu$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^(www.)pelda.hu$
RewriteRule ^(/)?$ http://www.pelda.hu/hu$1 [R=301,L]Működni működik, 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 (plusz lehet ez tesz be, hogy a joomla-nak nem sikerül smtp-n gmailhez kapcsolódnia? )
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac? George Carlin
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest