minden browserben csekkoltam persze, (Chrome, Safari, Firefox ugyan az), amit irsz arra ranezek ,koszi, meg nekem is eleg uj a terulet 
Ha van újabb php a gépen, én nem szenvednék lokálisan apache-al. Php serve sokkal jobb.
koszi,
‘munkaltatom’ bedobott egy ilyet:
https://caddyserver.com/
(ugyis uj gepre koltozok eppen, igy teljes lesz a kornyezetvaltozas :P)
1 kedvelés
A fórumot is Caddy szolgálja ki 
Node, nem hiszem, hogy a “webserver” csereje, megoldja azt, amit tapasztalsz, mert amig nem tudod, hogy melyik komponens okozza a “hibat” (azert idezojeles, mert lehet, hogy nem hiba, hanem helyes mukodes), addig szerintem foloslegesen szivatja magat az ember, ha elkezdi kicserelgetni a stack darabkait.
ez rendben, de ahogy irtam masik projekttel is elofordult, hogy random es idoszakosan nem ‘frissitett’ a mamp php file-kat,
en is szivesen maradnek az egyszeruen hasznalhato mamp-nal mintsem az elsore kisse bonyolultabbnak tuno es lehet, hogy tudasaban/szolgaltatasaban nekem feleslegesen sokat nyujto meglodast valasszak, de az idoszakosan es rendszertelenul elofordulo ‘hibak’ megtalalsa nem egyszeru, viszont a mindennapi eletet jelentosen megneheziti, es bosszanto, hogy most megint mi van, mi nem megy.
Az a baj, amit leirtal hiba, az kb “lehetetlen”. Marmint, ha kicserelsz egy filet a webserver alatt, akkor a webserver az uj allomanyt adja. Itt “statikus” fileokra gondolok, mint pl egy css vagy egy png. Ezt tudod egyszeruen ellenorizni egy curl/wget/stb-vel is. Itt (mivel ismered, hogy hogyan mukodik az internet), tudod, hogy a kliens kerdez, a szerver valaszol es tudod azt is, hogy miket valaszolhat. Pl. valaszolhat headereket, a headerekben pedig lehet arra jelzes, ami megmondja a kliensnek, hogy “barmi tortent, akkor is cachebol add vissza”. Ezt a headert nyilvan nem magatol talalja ki a webserver, es nyilvan ezt a headert minden webserverrel oda lehet tetetni. Nyilvan valami oka van annak, hogy ez igy mukodik, mert magatol nem igy mukodik, tehat valaki ezt beallitotta. Ezt be lehet allitani barmilyen mas webservernel is, hogy kuldjon ilyen headert, tehat ha ez a hiba van nalad most, akkor ez a hiba elojohet kesobb is. Tehat meg kell keresni.
Ha modositassz egy PHP-t, akkor alapvetoen az is latszik realtime, kiveve persze ha a php futtatokornyezet ugy van beallitva, hogy pl soha nem cachel uj dolgot az opcode cache teruletre es soha nem uriti ki azt, ami mar ott van. Ilyenkor minden egyes php allomany csak egyszer es csakis egyszer fog beolvasasra kerulni. Hiaba irod at, nem valtozik a tartalma. Ennek a miertjet pedig a php futtato kornyzetenel kell keresni es annak a beallitasait megnezni.
Ezt a ketto hibat tudja produkalni a “kornyezet”, ha mas hibad van, azt mar az a kod fogja produkalni, ami fut. Pl. a Smarty template rendszer dolgozik ugy, hogy minden templatebol (amiknek sokan .tpl kiterjesztest adnak) keszit egy leforditott templatet (na pl ezt a leforditott templatet be tudja cachelni az elobb irt opcode cachelo megoldas) es a kesobbiekben ezt hasznalja. Tehat lehet, hogy torolnod kell a modositott template leforditott allapotat, ugyonakkor lehet, hogy gondoskodnod kell az adott alkalmazasszerverre jellemzo modon az opcode cache uriteserol is.
Tehat ezer meg egy oka lehet annak, hogy van ez az allitolagos “hiba”. Amit tenyleg azert teszek idezojelbe, mert lehet, hogy ez nem “hiba”, hanem ez az elvart mukodes. Nem ismerem a kornyezetet, csak azt tudom, hogy a komponens csereje, nem feltetlen oldja meg a problemat, meg akkor sem, ha a hiba abban a komponensben van.
1 kedvelés
koszi, hogy ezt igy kifejted, de igazabol par alkalommal nekialtunk mar kideriteni mi lehet, igy mamp alatt opcode cache-vel es a nelkul is produkalta, css modositast nagyjabol folyamatosan csinalja (azert ennel is akad egy apro erdekesseg ami szinten csak random jon elo, az oldalt felepito blockok css modositasait van amikor csak akkortol kezdi frissiteni, ha az oldal egyik elso blokkjaban csinalok valami valtozast :S nem minden oldalon, nem allandoan, szoval ez is idegtepo tud lenni amikor elojon)
elfogadom amit irsz csak arra nem latok magyarazatot, hogy ha ez valami beallitas beli problema akkor miert nem minden esetben es allandoan jelentkezik, es mitol mukodik utanna normalisan ha semmi beallitast nem modositok,
Kiurul a cache? Megnezted pl, hogy milyen headereket kapsz, amikor “nem latszik a css valtozas”? Egyszeruen ezek NEM tudnak veletlenszeruek lenni, hiszen “faek egyszeru” komponensekrol van szo. Tehat biztos, hogy megfejtheto, hogy miert tortenik es erre lesz egy betonbiztos magyarazat, amely minden korulmenyek kozott megallja a helyet. En tovabbra is azt mondom, hogy valamilyen cache beallitassal kapcsolatos dolog miatt “hibazik”, ami szerintem nem hiba, hiszen azert kell a cache, mert szukseged van a funkcionalitasra.
ok, de hidd el, teljesen random, es idoszakos, kivevve az indito kerdesben levo PS-smarty tpl vonalat,
Ezt én is kipróbátam, GCIjó.
Amit eddig küzdöttem az apache2-vel production servereken, az elmúlt. Köszi!
n a akkor madj lehet jelentkeznenk egy kis oktatasra,nekem ez elsore kicsit fekete oves
O Koszonom
1 kedvelés
Fúúúj, komolyanmá
1 kedvelés
bocs
1 kedvelés
[enkerekelnezest]
1 kedvelés
Ez a multi php-s kornyezet van beallitva a gepemen,
a legutobbi MacOS frissites utan ha elinditok egy projektet (headless wp) az alabbi paranccsal,
php -S localhost:8000 -t public
a browserben nem nyilik meg a project, terminalban meg dobalja az ‘Unsupported SSL request’ uzeneteket,
Chrome Incognito modban megjelniti, az mas kerdes, hogy tetubaromi lassu,
nem boritanam szet az egesz rendszert ha lenne ra valami otlet mitol van az, hogy egyszer csak unsapported ssl request lett ami eddig mukodott,
koszi
Ha unsupported a SSL request, akkor miert https://localhost:8000/-vel probalkozol? Probald http://localhost:8000/ -vel. Valamiert megjegyezte, hogy SSL van. Erre van tobb megoldas, a specko headertol, az atiranyitason at barmi, azt, hogy nalad mi van, csak te tudhatod.