- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- Szoszo94: Xiaomi Mi Router 3G - Padavanra fel!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- sh4d0w: Csak a profit - emberélet nem számít
- vrob: Az IBM PC és a játékok a 80-as években
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
Új hozzászólás Aktív témák
-
Lacc
aktív tag
Esetleg rosszul van beállítva az email fejléc.
Itt a stackoverflow első válasz. Vagy maga az oldal, amire hivatkozik, nézd meg, hogy milyen üzenetet add vissza, hátha van benne valami jó kis analízis.
-
bucihost
senior tag
Sziasztok!
Adott egy üzenet küldő felület. Php + mysql.uzenet.php
A PHP úgy néz ki, hogy felül a szöveg beviteli box, alatta pedig táblázatba megjelenek sorba az üzenetek.
Az adminoknak megjelenik az üzenetek mellett egy törlés gomb is.
Itt a törlés kódja:if(isset($_GET["torol"])){
$torolni = "DELETE FROM `uzenetek` WHERE `id` = ".$_GET["torol"];
mysql_query($torolni);
mysql_close($kapcsolat);
header('Location: uzenet.php');
Die();
}Ha rányomunk a törlés gombra, akkor kitörli az adott ID-n szereplő üzenetet, viszont az oldalról eltűnik a táblázat (csak a szöveg beviteli boksz marad meg). Valamint nem dob vissza az uzenet.php-ra hanem marad pl az uzenet.php?torol=216 linken.
Mi lehet az oka?
-
Kube
senior tag
Ott sajnos nem kaptam választ. Mint kiderült nem elég minden kritériumot teljesíteni, ugyanis a host megbízhatósága nagyjából 1 hónap alatt dől el. Tehát hiába fullos az email, ha új a host.
Egyébként sokak titkosítás és totál hiányos e-mailje is a bejövőbe érkezik, ebből is látszik, hogy nem a kritériumok megléte számít.
-
Lacc
aktív tag
-
Kube
senior tag
Sziasztok! Van egy kis problémám szerver oldalon, talán közületek valaki tudja a megoldást. Postfix-el mennek ki az emailek, amik rendre a spam mappában landolnak. A host megfelelő, SPF és TLS is van. DKIM és DMARC még nem sikerült összelőnöm, de elméletileg már az előbbiek is elegendőek valamilyen szinten.
Valaki hasonlóval küzdött már élete során?
-
Lacc
aktív tag
Melyik kép konvertáló library-t tudjátok ajánlani?
Én kettőt próbáltam ki, az Imagine-et és a GD-t. Végül én a GD-t használom, többett kellett programozni, de nagyobb 7000pixeles képeknél, nincs memóra összeomlás a szerveren. Az Imagine-nél ezt tapasztaltam, tavaly amikor utánaolvastam, állítólag más is tapasztalta, nem egyedi eset. A GD-nél csak annyi a problémám, hogy egy 7000pixeles képnél képes 10 másodpercig is "eltökölni", bár hozzá kell tenni, hogy elég butított linux szerveren fut (virtuális gépben 512mb egy proci szállal) -
#18992
Lacc
aktív tag
phanfantom
#18981
Lacc
aktív tag
válasz
phanfantom
#18981
üzenetére
Hello.
Két lehetőség van, az egyik, hogy session-ben van ideiglenesen (vagy időbélyeggel, vagy törlik azonnal) és abból kiolvasva beilleszti neked az emailbe, és az email küldés után törli, vagy egy bizonyos idő után automatikusan törlődik.
Persze Cookie-val is el lehet érni ilyen turpiságot, de többlet munka, jó annyira nem
A másik lehetőség, hogy a kódolt jelszó mellett tárolják az eredetit. Nem ritka. Ezt a legkönnyebben úgy lehet kideríteni, ha kérsz jelszó emlékeztetőt, és ha megküldik az eredeti jelszót, akkor innen lehet tudni. De általában a plain jelszót, csak erre használják jobb helyeken. (Ahelyett, hogy új jelszót kérnének a felhasználótól, ez valamiért így alakult ki.)
Ha a kódolt jelszóval dolgozik a weboldal, és a plain-t csak visszaállításhoz használja, akkor úgy mond nagy gond nincs, ha tényleg körültekintően tárolják adatbázisban stb. Én már láttam intratnetes alklamazásnál ezt a megoldást nem egyszer, mert a munkahelyi kollégák nem szeretik változtatni a jelszót.
Kódolt jelszóból meg nem lehet az eredeti jelszót visszafejteni, itt arra gondolok, hogy az md5 hash függvény esetében előfordulhat, hogy az 'alma' és 'körte' sztring ugyanazt az md5 hash-t adja vissza, és vannak ilyen sztringek. -
-
Mbazsika
tag
válasz
supercow
#18980
üzenetére
Ugye a cél az az lenne, hogy az alkalmazásba bejelentkezett és a session információkba eltárolt user nevét adatbázis oldalon is tudjam, hogy a változástörténetbe beírhassam az after insert/update/delete triggerekben.
Úgy látom, hogy ez csak úgy működhetne, ha a db user megegyezne az alkalmazás userrel. -
#18989
PumpkinSeed
addikt
mobal
#18988
PumpkinSeed
addikt
Igen, de az, hogy a plain text jelszót kiküldik e-mailben se a legjobb megoldás több okból is. Regisztrálsz AWS-re és kiküldik a jelszót e-mailbe.
Hát az szép is lenne. Plain text-be, hogy a cégnél mindenki lássa aztán Hekker József betelefonál a titkárságra, hogy az Amazontól jött és kellene neki ez meg az az adat. Béna Izabella meg majd nem felkeresi programozót, hanem mert épp látta a képernyőmet lediktálja neki. -
#18986
mobal
nagyúr
PumpkinSeed
#18985
válasz
PumpkinSeed
#18985
üzenetére
Gondolom a regisztrációs űrlapon volt két email mező.
-
#18985
PumpkinSeed
addikt
phanfantom
#18984
PumpkinSeed
addikt
válasz
phanfantom
#18984
üzenetére
Ez azért is egy rossz megoldás, mert mi van ha elírod az e-mail címet? Valaki más megkapja a jelszavad és a felhasználóneved. Mivel biztos vagyok benne, hogy mindenhol ugyan az a jelszavad ezért mindened elérhetővé válik. : D
-
#18984
phanfantom
senior tag
phanfantom
senior tag
Ok, én is adtam rá esélyt, hogy ettől még lehet titkosítva, ezért is gondoltam, hogy előbb megkérdezlek titeket.
Akkor ha jóindulatot feltételezünk, szimplán csak nem túl elegáns megoldásról van szó.Köszi a válaszokat
-
#18983
edari
őstag
phanfantom
#18981
edari
őstag
válasz
phanfantom
#18981
üzenetére
Szerintem tárolhatják titkosítva a jelszavadat, az nem kizáró ok hogy elküldték e-mailben.
-
#18982
mobal
nagyúr
phanfantom
#18981
válasz
phanfantom
#18981
üzenetére
Nem biztos, hogy nincsen titkosítva.
-
#18981
phanfantom
senior tag
phanfantom
senior tag
Sziasztok,
A minap beregisztráltam egy oldalra, a regisztrációkor megadott adataimat mail-ben visszakaptam. De meglepve tapasztaltam, hogy a jelszót is visszaküldték...
Ez azt jelenti, hogy nem titkosítva tárolták el?
Ha így van, akkor ez amatőr dolog.
Viszont a jogszabályi oldaláról tudtok valamit? Arra lennék kíváncsi, hogy kötelező lenne-e nekik titkosítva tárolni? -
#18975
mobal
nagyúr
PumpkinSeed
#18974
válasz
PumpkinSeed
#18974
üzenetére
Szimfóniánál nekem az annotáció már sok volt.
-
#18974
PumpkinSeed
addikt
Lacc
#18965
PumpkinSeed
addikt
Így végig olvasva mindenkiét nekem a Symfony kifejezetten tetszett, ha valaki követi benne a Symfony ajánlásokat akkor gyors és jól struktúrált tud lenni. Persze még soha nem láttam ilyet.
Codeigniter egy hulladék szerintem. Hiányzott belőle a DI Container és sok olyan tool amik alap dolognak számítanak.
Laravel volt az eddigi legjobb amivel foglalkoztam, de azzal csak érintőlegesen. Nekem kifejezetten tetszett, hogy minden tiszta szép megoldást tudtak adni.
-
DNReNTi
őstag
válasz
Vision
#18970
üzenetére
Attol fugg mi a cel, mire akarod hasznalni.
En szeretem a lightweight cuccokat, igy peldaul a Slim szerinem egy igazan jo valasztas lehet. Felteve ha neked eppen egy REST API-ra van szukseged. A Codeigniter is eleg kicsi es gyors, viszont alapbol eleg buta, viszont bizonyos dolgok meg feleslegesek benne, igy en azt kicsontoztam, es felokositottam a sajat igenyeimre. A Phalcon-t is ki akarom probalni, nekem nagyon szimpatikus, kicsi, gyors, pont amit szeretek.(#18971) Lacc
En sem flame-elni akartam, csak velemeny / tapasztalat csere ez.
Teljesen egyetertek veled hogy a projekt hatarozza meg mire van szukseg, de ezt mar kozben eppen kiveseztem fentebb. -
Lacc
aktív tag
válasz
DNReNTi
#18969
üzenetére
Én sem használnám Enterprise szintű alkalmazáshoz, bár kisebb vállalkozásnak elég egy ERP PHP-ban.
(SEO friendly weboldalakhoz még mindig jobbnak találom a PHP-t, főleg kicsi, közepes weboldalaknál. JS-nél a SEO preloader szolgáltatással megoldható, de a legtöbb fizetős.)De, hogy lásd nekem is van személyes előítételetem, mert jobbnak találom e kettőt mint a Laravel-t.
A Yii tényleg szörnyű volt, de mivel én főleg ASP.NET-ben és Javascript PWA/SPA a használt prog nyelv főmunkaidőben, illetve találkoztam és programoztam Java-ban, Rails-ben, így kialakul egyfajta best-practice és akkor egész könnyen lehet alkalmazni a Yii-re.
Az elején nem kedveltem, illetve a Symfony mégis csak profibb, több support van hozzá stb. Bár a Yii-ben pont az tetszett, hogy igaz a doksi kevés, de ennek ellenére, egy helyen sok mindent meglehet találni, sok hasznos írás van, és felszabadító, hogy nem minden OOP. Igazából ez nosztalgia is, mert egész a régi időkre emlékeztett, amikor többen írtak native php-ban (5.3-as időszak) mindent, meg performancia szempontjából igen is előny, hogy nem minden sql lekérdezés van áttranszformálva Entity-vé, hanem lehet tömb is, és egész könnyen kiderül. (Bár architektúrában a másik kettő SF és LA jobban szervezett9
Meg ami előnye, hogy készen adja a user, login, registration, role kezelést is illetve a Grid, Listview nézeteket is és nem egy 3rd party tool-t alkalmazol hozzá, és még több mást is beépítve az FW-be.Szívem szerint ASP.NET Core-t használnék, de annak még ki kell forrnia. Scala-t meg ilyen kis weboldalhoz, felesleges, mintha ágyúval akarnék verébre lőni
.Nem flamelni akartam, csak kifejtettem, hogy miért kedvelem a Yii-t. De sokszor egyet értek másokkal, hgoy miért szörnyű, de szerintem mindig a projekt határozza meg a legjobban, hgoy melyik FW-t érdemes használni.
-
DNReNTi
őstag
Szemelyes eloitelet, mindkettovel kellett mar dolgoznom, de szerintem mindketto szornyu. Ha a ketto kozul valasztani kellene, akkor mar inkabb a Symfony, nagy enterprise szintu alaklmazasok eseten meg lehet van is ertelme, mas kerdes, hogy akkora alkalmazasokhoz meg nem jellemzo, hogy PHP lenne az alap. A Yii-vel egesz egyszeruen nem tudtam azonosulni, mondjuk lehet bennem a hiba.
-
disy68
aktív tag
Ha már szóba került, hogy a PHP miért is "szar". Nem mai írás, egy része már nem is valid, de szerintem érdemes elolvasni: PHP: a fractal of bad design
-
#18965
Lacc
aktív tag
PumpkinSeed
#18964
Lacc
aktív tag
válasz
PumpkinSeed
#18964
üzenetére
Mint például milyen framework-ök?
Én csak Symfony és Yii-ben mozgok. -
#18963
PumpkinSeed
addikt
DNReNTi
#18961
PumpkinSeed
addikt
válasz
DNReNTi
#18961
üzenetére
Ez lehet csak az én bajom, de engem nagyon zavar, hogy a függvényeknek nincs meghatározott visszatérési értéke. Például vannak symfony harmadik féltől származó függvények amelyek egy teljes entity tömböt adnak vissza és a var_dump is 2 óráig tart, ezért nem egyszerű a lekezelésük. Hiába nézem meg sokszor, hogy mit is ad vissza, esélyetelen számomra, hogy elsőre meg tudom írni a függvényt ami megjeleníti az adatot meg ilyenek. Szóval hiányzik az, hogy meg van határozva a visszatérési érték.
-
#18962
mobal
nagyúr
PumpkinSeed
#18960
válasz
PumpkinSeed
#18960
üzenetére
Szerintem amúgy egyszerű a dolog. Ha már ezek a preferenciák nem a PHP-t kell választanod. Mi a jó mégis a PHP-ban?
- Könnyen tudsz bármit csináli vele ami web - és akár ami nem is
- Ingyenes
- Olcsó fenntartani
- +1 OOPmobal,
-
#18961
DNReNTi
őstag
PumpkinSeed
#18960
DNReNTi
őstag
válasz
PumpkinSeed
#18960
üzenetére
Ha belekezdtel mos'ma' mond el mer' utalod.
Engem erdekel, tenyleg. -
#18960
PumpkinSeed
addikt
lezso6
#18958
PumpkinSeed
addikt
válasz
lezso6
#18958
üzenetére
Igazából szerintem azért "szar" (ami egy kicsit erős túlzás). Én pl. Go-ban szoktam ami nem engedi, hogy gányoljanak benne, mert annyira "strict" nyelv, hogy nagyon nehéz benne szar kódot írni. Ezzel szemben a PHP meg engedi. Ez nem azt támasztja alá, hogy a PHP szar meg minden, csak jobb lenne ha nem lenne ennyire megengedő. De mondjuk azt se lehet elvárni, hogy mindenki Symfony best practice-t követően kezdjen el programozni. Nyilván inkább az a szar, hogy mindenki PHP-val kezd ami hát szvsz nem a legjobb, mert ha mondjuk C-vel vagy valami mással kezdene, végigsz*pná a programozás nehezebb ágát is akkor egyből minőségibb kódok születnének PHP-ban is.
Amúgy én kifejezetten gyűlölöm a PHP-t, de más miatt nem azért mert lehet benne gányolni.
-
DNReNTi
őstag
Legalabb elore haladnak. Jo az irany.
En mindig azt mondom a PHP maga nem szar, csak konnyu benne szart irni, mer' joforman barmit irsz mukodik, de attol az meg szar, raadasul a net is tele van szar es/vagy outdated tutorialokkal, kodokkal. Hab a tortan, hogy ez egy ongeneralo folyamat. Jon a newbie, "programozik" 3 honapot PHP-ben, latja hogy megy ez neki, es meg motivacioja is van, erre nekiall oktatni a nepet a hulyesegeivel kulonbozo blogokon, ezzel olajat ontve a tuzre, hiszen az ujabb newbie-k, majd az o altal megosztott egyszerubb megoldast fogja valasztani, a professzionalis helyett. Hulye lenne 10 sort irni, ha azt meg lehet irni 4-ben is. Szar de mukodik. Win. Nagyon fel van higulva a PHP-s kodallomany, ez remelem valtozni fog, ha szigorubb lesz a nyelv, erre ertem, hogy jo az irany.
Nem akarok amugy senkit bantani ezzel, ez a newbie tema akar en is lehetnek, anno mikor elkeztem programozni en is PHP-vel kezdtem, es kabe minden fel ev utan mikor visszaneztem miket irtam, letortem volna a sajat kezem.
-
válasz
DNReNTi
#18952
üzenetére
Hát, az irány az jó. Sőt, már van 7.1 is, ott is van pár hasznos újdonság. De persze még mindig nem az igazi. Amit említésre méltónak tartok, fontos:
- Error nevű Exception a sima errorok helyett
- megadhatók típusok a paramétereknél és visszatérési értéknél (int, string, stb)
- jelentősen gyorsabban fut
- sok idióta cucc deprecated lett vagy eltávolították, értelmesebbre módosult -
válasz
DNReNTi
#18950
üzenetére
PHP 7 óta ugye minden error helyett hálistennek Exception van, jóval egyszerűbb kezelni. Vagy is nem. Ha túl sokáig fut a script vagy elfogy a memória, akkor még mindig sima error van és a
register_shutdown_function()nevezetű izével kell kezelni.Ami meg warning vagy hasonló, arra ott a
set_error_handler(), ott lehet dobni Exception-t mindenre. Problem solved. -
#18950
DNReNTi
őstag
fordfairlane
#18949
DNReNTi
őstag
válasz
fordfairlane
#18949
üzenetére
pluszEgy();
En is pont igy gondoltam. Nem arra akartam celozni, hogy PHP hiba helyett exceptiont kell adni a user-nek, hanem hogy az exceptiont tudod kezelni, a PHP hiba meg (optimalis esetben) nem jelenik meg prod-on, szoval lovese nem lesz a felhasznalonak mi az isten van, es neked sem, ha elmondja, hogy mit lat: semmit. Nyilvan emelle aldasos ha van log, de jobb egy hibaoldalra iranyitani. Legalabb van mit jelenteni.
-
#18949
fordfairlane
veterán
PumpkinSeed
#18948
fordfairlane
veterán
válasz
PumpkinSeed
#18948
üzenetére
De nem is ez volt az eredeti felvetés, hogy a felhasználó kap-e exception, vagy sem, hanem hogy a program dob-e exceptiont vagy sem. Márpedig miért ne dobjon exception egy metódus, ha például hiányzik egy nélkülözhetetlen paraméter, például...
-
#18948
PumpkinSeed
addikt
Lacc
#18943
PumpkinSeed
addikt
(#18944) fordfairlane
Nyilván nem úgy értettem, hogy az ilyen nincs lekezelve ELK stacket használunk logolásra, szóval ha valami hiba van akkor mi hamarabb kapjuk meg hibát mint, hogy az a felhasználónál egyáltalán betöltődne. Nem is azt írtam, hogy nem kezeljük le, hanem hogy nem tolok PHP Exception-t a felhasználó arcába.
-
#18947
lezso6
HÁZIGAZDA
PumpkinSeed
#18942
válasz
PumpkinSeed
#18942
üzenetére
Nem kell látnia az exceptiont. Szerinted itt az 5xx hibaoldalak mik? Mind exception. A PHP hibakezelése könnyen testreszabható, bár még 7.1-ben is vannak még sajnos lyukak amire érdemes odafigyelni.
-
Zedz
addikt
NetBeans nálam több mint 1GB memóriát kért el, akkor voltam úgy vele, hogy oké akkor megy az uninstall. Persze a PHPStorm is elkéri a magáét, viszont nekem sokkal jobban kézre áll a használata, és a memória használatot figyelmenkívül hagyva ez a lényeg.
Ha valakinek a babok jönnek be és azzal tud gyorsabban dolgozni, akkor szerencséje van az árát tekintve.
-
#18945
lezso6
HÁZIGAZDA
PumpkinSeed
#18939
válasz
PumpkinSeed
#18939
üzenetére
Úgy is kell.
Ha olvastad a bejegyzést, akkor láthatod, hogy én sem használok olyan változót, ami lehet hogy nem létezik. Az empty-t az üres tömb ellenőrzésére használtam mindig, csak aztán kiderült, hogy nem erre való. Az isset függvényt meg csak tömb index létezésének vizsgálatára. -
#18944
fordfairlane
veterán
PumpkinSeed
#18942
fordfairlane
veterán
válasz
PumpkinSeed
#18942
üzenetére
Elég nagy hiba. Bevett szokás az errorokat is exception-re konvertálni, aztán a nem elkapott exceptionöket meg loggolni. A user meg kap egy 500 hibaoldalt.
Ha egy változóban nem olyan típusú adat van, ami elvárható, és nem egy formmezőböl jön az értéke, tehát nem formvalidálás témakör, akkor nem érdemes sokat tökölni, jobb megszakítani a program futását.
-
#18943
Lacc
aktív tag
PumpkinSeed
#18942
Lacc
aktív tag
válasz
PumpkinSeed
#18942
üzenetére
Néhány framework tud olyat, hogy a Developer környezetben kidobja a hibát, még a Production környezetben csak 404-es hiba oldalt mutat.
A Loggolás amúgy sokat segít! Anno átkerültem ASP.NET-es csapatba, és akkor megmutatták hogy nagyobb projekteknél baromi hasznos, akár a test-ek amiket te is használsz -
Lacc
aktív tag
A NetBeans-t is lehet ajánlani, ingyenes, és többet tud alapból mint a VSCode (Félre értés ne essék, én is használom a VSCode-t de nem PHP-ra, hanem Javascript). Majdnem a PHPStorm tudása van meg neki, nekem bevált, sőt gyorsabbnak tűnik mint a PHPStorm, igaz amikor a Projekteket indexeli az néha nagyon lassú, de szerintem ettől függetlenül teljesen vállalható.
-
#18940
DNReNTi
őstag
PumpkinSeed
#18939
DNReNTi
őstag
válasz
PumpkinSeed
#18939
üzenetére
Azert az nem art, ha fel vagy arra keszulve, hogy valami megsem ugy sul el, ahogy eltervezted, aztan olyankor mondjuk jobb egy exception-t dobni, mint az, hogy beszarik a kod, azt nezegeti a user a feher kepernyot, meg riportalja a "nem mukodik ez a szar" hibat.
-
Egy kis írás az
empty()függvényről, érdemes tudni: [link] -
-
GG888
senior tag
válasz
Panhard
#18934
üzenetére
Nem használtam ChartJS-t már jó rég óta, de itt pl. valaki PDF-be szeretné kiexportálni
onAnimationComplete eseményre létrehozol belőle egy base64 stringet, azt érdemes rögtön átdobni a szerverre, a kommentek között pedig találsz php példakódot, hogy a base64 stringet hogy mentsd le képként szerveroldalon.
Mondjuk ennek annyi hátulütője van, hogy csak akkor tud a cronod friss képet készíteni, ha valaki megnyitja a kliensoldalt és készül egy új base64 string az új charttal/adatokkal.
Nem biztos hogy segítettem, de valahogy így indulnék el
-
Panhard
tag
Sziasztok!
Tudtok valami olyan megoldást, ami szerver oldalon futtat le egy weblapot, és lementi képként? Az lenne a lényege, hogy van egy oldal, amin javascript chart van. Ezt kellene a webszervernek automatikusan megnyitni és a chartot képként lementeni. Tudom, hogy a webszerver nem tudja lefuttatni a javascriptet, mert az böngészőben fut. Ezért kellene valamilyen más megoldás. Gondolom php-ben meg lehet oldani. A php automatikus futtatása nem probléma, azt cron-ban megoldható. Jelenleg canvasJS-t használok a weblapon, de igazából mindegy milyen chart van használva, az adatok adatbázisban vannak. Lényeg az, hogy egy php oldal legenerálja a chartot, és lementse képként a webszerver egy könyvtárába.
Van erre valamilyen megoldás? Előre is köszönöm. -
#18930
vakondka
őstag
fordfairlane
#18924
vakondka
őstag
válasz
fordfairlane
#18924
üzenetére
Köszi.
Az a fura, hogy néha átadja az Analyticsnek az értékeket, néha nem, látszólag random módon.Ez egy Analytics E-commerce implementáció lenne Google Tag Manageren keresztül.
A lényeg, hogy a dataLayerbe kell kerülnie minden adatnak a vásárlásról, ezt a Tag Manager átveszi és átküldi a Google Analyticsnek. -
pelyib
tag
válasz
bucihost
#18922
üzenetére
Bocsi, azt hittem a fejlesztes kozben van ez.
Akkor pedig neked a Cache-control kell: http://httpd.apache.org/docs/current/mod/mod_expires.html
(viszont amig nem jar le addig nem is fog a szerverhez fordulni)A verziozas is egy megoldas, deploy kozben kiszamolja az uj verziot es hozzacsapja a linkekhez, vagy ha nincs ilyen akkor egy bash / php script csinalja ezt x percenkent (vagy valami triggereli a futasat).
Vagy akar amit korabban irtak, hogy request kozben kiszamolja aztan cachebe lerakod y (fel napra pl) idore es kovetkezo request mar tudja hasznalni a cachet (kerdes, hogy ha valtozik valami akkor mi fogja ezt kiutni).
Szoval lehetosegek vannak boven -
#18927
fordfairlane
veterán
bucihost
#18925
fordfairlane
veterán
válasz
bucihost
#18925
üzenetére
Ennél a megoldásnál minden letöltésnél már verziószám kerül az URL-be, tehát a böngésző mindig le fogja tölteni a teljes fájlt. Ez fölösleges. Csak akkor kell változzon az url, amikor az adott fájl tartalma is módosul.
Ennél még talán az is jobb, ha szerveroldalon számolsz checksumot.
style.css?v=<?=md5_file(ASSET_PATH . "style.css"); ?>Az md5_file csak akkor ad más eredményt, ha az adott fájl tartalma változik, viszont ennél a megoldásnál a szerver végez egy plusz fájlműveletet minden oldallekérésnél.
Erre az egész problémakörre vannak automatikus megoldások is, "asset versioning" elnevezés alatt fut a téma. Kezdőnek jó bonyolultak.
-
#18925
bucihost
senior tag
fordfairlane
#18923
bucihost
senior tag
válasz
fordfairlane
#18923
üzenetére
Köszi, pont rá leletem én is a keresőben. Viszont találtam olyat is, ahol a verziózást "automatán" oldják meg. Miszerint a V=<? time() ?> ez is életképes lehet?
-
#18924
fordfairlane
veterán
vakondka
#18918
-
JoshaJosh
csendes tag
Jó hír, hogy sikerült végül kibogoznom, hogyan is indíthatnám el az oxwallt. Sikerült rátalálni a megfelelő módszerre, mindegyik szerver program alatt. Wamp, easyphp, IIS, xampp - csak épp mindnél előjött végül ez az üzenet:
És tényleg nincs elképzelésem ezen hogyan segíthetnék....
Ha valakinek van ötlete mit jelent ez pontosdan illetve miként segíthetnék rajt kérem segítsen köszönöm! -
vakondka
őstag
Sziasztok,
Van egy weboldal, Smarty-val és a checkout success oldalon le kellene futnia egy javascriptnek, viszont néha lefut, néha nem. Gondolom literal közé kellene tenni, de akkor meg a változók nem kerülnének bele
{if !empty($checkoutprocess) }
<script type="text/javascript">
dataLayer = [{
'transactionId': '{$checkoutresults.OID}',
'transactionAffiliation':'{#STORE_OWNER#}',
'transactionTotal': {round(Scheckoutresults.total)},
'transactionTax': {round(Scheckoutresults.tax)},
'transactionShipping': round(Scheckoutresults.shipment)},
'transactionProducts': [
foreach from=$checkoutprocess->getProducts() item=product}
{
'sku': '{$product->getModel()}',
'name': '{$product->getName()}',
'category': '-',
'price': {round(Sproduct->getGrossPrice())},
'quantity': {$product->getAmount()}
}
{/foreach}
}];
</script>
{/if}Van ötletetek a megoldásra?
-
bucihost
senior tag
Sziasztok. Adott egy weboldal, amiven van JS, Html, php is. A probléma az vele, hogy ha változás van kinézetben pl, akkor a böngészőkben (főként chromeban) nem jelennek meg rendesen a változások. AZ ok, hogy a böngésző cacheből tölti be a weboldalt, és eröltetve (ctrl + f5) újra kell neki tölteni a cachet. Ez ellen lehet valamit tenni szerver oldalon?
Szerk: Vagy ilyenkor elég lehet, ha pl a css-t átnevezem? pl: styles_v1.css
-
JoshaJosh
csendes tag
Nagyon köszönöm mindenkinek! Tudom, hogy valószínűleg egy mammutfenyőbe vágtam bele a kisfejszét....
De agyon btatnak a többiek, hogy csak lusta vagyok. Próbálok kis lépésekben haladni, aztán meglátjuk.Talán a régi honlapom fejlesztésével kéne gyakorolnom, az is elég ratyi. Még egyszer köszönöm!
-
SUPREME7
őstag
válasz
JoshaJosh
#18912
üzenetére
Ha windows-on csinálod, akkor töltsd le a Wampservert, kb semmit nem kell beállítani a telepítésnél, majd a
C://wamp/www/(vagy 64bites telepítés esetén wamp64/www/)mappában csinálj egy mappát mondjuk "teszt" néven, amit böngészőből a
localhost/teszteléréssel tudsz megnyitni. Itt tudsz már gyakorolgatni, de nem hiszem, hogy nulláról éppen egy ilyen oldallal kellene kezdeni.
-
DNReNTi
őstag
válasz
JoshaJosh
#18912
üzenetére
Minden tiszteletem a lelkesedeseteke, de nem lehet, hogy eloszor valami kisebb faba kene vagni a fejszet? Te magad is irod hogy "nagyon nagyon amatőr programozó vagy" illetve mar egy lokalis szerver kornyezet beallitasa problemat okoz... Nem bantani akarlak felre ne erts.
Ahhoz pedig hogy valaki a konkret kerdest is megvalaszolja, kicsit keves ez az info amit adtal, illetve en a helyedben futnek egy kort mondjuk egy linuxos VM-mel, mer' hat a szerveren is az lesz, nem IIS. Vagy ott a WampServer Windowsra, nekem azzal nem volt anno semmi bajom.
-
JoshaJosh
csendes tag
Üdv!
Nagyon nagyon amatőr programozó vagyok, de van egy lelkes csapatunk, szeretnénk egy igazi magyar közösségi oldalt létrehozni.
Ehhez az Oxwallt ajánlották. Le is töltöttem, de az egész php oldalakból áll. Szóval egy régi szokásom szerint amikor még a saját weboldalamat írtam, XAMPP-vel teszteltem, de ugye akkor még XP-m volt. Most win7 prof. 64 bites van. Szóval hiába indítom el az xampp-t meg az easy php szervert, semmiképpen nem tudom működésre bírni a php oldalakat. A régi lementett php oldalakat, amiket nagyon régen a saját honlapomhoz írtam, azokat sem.
Ezért egy itteni leírás alapján inkább az IIS-t raktam fel, jó is működik, de továbbra sem tudom, hogy működtethetném az Oxwall közösségi oldal szerkesztőt. Tudom, hogy valamiképp hozzá lehetne rakni mint programot az IIS-hez, de sajnos nem jutok előbbre. Sajnos szinte teljesen elfelejtettem azt a keveset is, amit akkor még tudtam a programozásból, de szeretném újra tanulni.
Egyébként ha van olyan programozó, akinek van elég ideje és affinitása egy ilyen projektben részt venni, szívesen látnánk!
Minden segítséget előre is köszönök!
-
pelyib
tag
válasz
hramon94
#18910
üzenetére
http://php.net/manual/en/function.strtotime.php
Végigmész a holidays tömbön, és kivonod egymásból őket:
(strtotime($holidays[$i]) - strtotime($start) > 0) && (strtotime($end) - strtotime($holidays[$i]))Innen már ízlés kérdése, h növelsz egy számlálót vagy gyűjtöd őket egy másik tömbbe...
-
válasz
supercow
#18908
üzenetére
rrdtool grafikon képeket szeretnék legenerálni.
Jelenleg úgy működik, hogy cron futtatja a generáló scripteket 10 percenként. Gondoltam proci terhelés csökkentek, és csak akkor generálom le a képeket, amikor megnyitnám.
Nem feltétlen a már meglévő bash scriptet hívnám meg php-ban, hanem cgi-ben futtatnám le a generálást (még fogalmam sincs hogy hogyan )
Viszont adathoz 5 grafikon tartozik, aminek legenerálásra (legalábbis futtatva a scripteket) 1-2mp. Ezért fetődött fel bennem a kérdés, hogy amíg a generálás zajlik, az oldal betöltése nyilván nem tart annyi ideig, így a képek sosem lesznek készen. Vagy tévedek? -
-
Zedz
addikt
válasz
DNReNTi
#18904
üzenetére
Sőt, ha egyéniben tolja az ember vagy csak otthonra kell, akkor 90 eur / év. Semmi pénz érte, tudom, csak valakinél ez nem opció, és azért szoktam említeni az ingyenes alternatívákat is.
Aki meg nem fizet érte úgy, hogy pénzt csinál vele, arra nem tudok mit mondani. Max annyit, hogy lehet fele idő alatt szerezné meg azt a pénzt, de ez se győzné meg.
Fun fact, hogy open source projektekhez ingyen szórják a cuccot, csak pár dolgot kell hozzá bizonyítani.
-
Zedz
addikt
Környezeti változóknál meg kell adni a PHP elérési útját. Ez természetesen máshogy néz ki Windows vagy Linux / macOS környezeteknél, keress rá a megfelelőre. Mondjuk ez érdekes mert nekem nem sírt ilyenért, ha meg volt adva, ha nem. Esetleg ha a továbbiakban nem sikerül megoldani a problémát, lőjj egy screenshotot és mutasd meg itt.
> MS-nak van ilyen ingyenes cucca, ami jó PHP fejlesztéshez
Visual Studio 2017-es IDE-ben is kellene lennie elvileg, de aztán a fene tudja hogy van ott. VS Code elég jó erre a célra ha a fizetős PHPStorm nem játszik. -
DS39
nagyúr
hmm, köszi a tippet, nem is tudtam, hogy a MS-nak van ilyen ingyenes cucca, ami jó PHP fejlesztéshez.
felraktam megnyitottam egy php fájlt is kiírja ezt:
Cannot validate since no PHP executable is set. Use the setting 'php.validate.executablePath' to configure the PHP executable.a settings-et megtaláltam, de mit kellene neki megadni?
(addig ok, hogy a local servernek mennie kell, hogy futtatható legyen, csak nem tudom milyen paramétert vár ehhez)
Ott végképp nincs erre lehetőség.
Teljesen egyetertek veled hogy a projekt hatarozza meg mire van szukseg, de ezt mar kozben eppen kiveseztem fentebb.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha olvastad a bejegyzést, akkor láthatod, hogy én sem használok olyan változót, ami lehet hogy nem létezik. Az empty-t az üres tömb ellenőrzésére használtam mindig, csak aztán kiderült, hogy nem erre való. Az isset függvényt meg csak tömb index létezésének vizsgálatára.
Új hozzászólás Aktív témák
Hirdetés
- LG 45GS95QX-B 45" ÍVELT OLED MLA WQHD 240HZ 0.03 MS GAMING MONITOR
- HP Zbook 15 laptop (15,6FHD/I7-G4MQ/16GB/128SSD/Nvidia2GB)
- Latitude 7450 14" FHD+ IPS Ultra 7 165H 32GB 1TB NVMe IR kam gar
- LG 45GR95QE-B Ívelt OLED 2K WQHD 240Hz, 0.03ms, NVIDIA G-Sync ,FreeSync Premium ,HDMI 2.1
- HP Probook 840 G1 laptop (14/i5-G4/8GB/128SSD) - Erős akku!
- Azonnali készpénzes Intel i3 i5 i7 i9 8xxx 9xxx processzor felvásárlás személyesen / csomagküldés
- Bomba ár! Lenovo ThinkPad T15 G1 - i5-10GEN I 16GB I 256GB SSD I 15,6" FHD Touch I Cam I W11 I Gari!
- Samsung Galaxy A14 64GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! Samsung Galaxy S21/Samsung Galaxy S21+/Samsung Galaxy S21 Ultra
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged