Psi, ez az imgur beágyazás továbbra se klappol teljesen
pl:
https://rewiredhu.cf/comment/264930#comment-264930
Nem csak nekem, másnál is az első "Not Found"
a második örökre analyzing
a harmadik működik
Egy imgur album 3 képe, én töltöttem fel mindhármat, saját fotók.
Amit csináltam:
1. postoltam, elsőre discord app-os linkekkel (itt asszem a középső kép nem töltődött be)
2. beraktam a képeket imgurra
3. átírtam a kép url-eket a hozzászólásban imguros új url-ekre, itt az első not found, a második analyzin, a harmadik betölt.
Meg a pozicionálás sem működik. Itt rányomtam a linkre és +9 hozzászólással előrébb dobott be a kérdéses hozzászóláshoz képest.
pozi-ra CTRL-f5, javítva volt, de a böngésző többeknél be-cache-elte a rossz kódot.
ctrl+f5 megvolt persze de ugyan úgy szar.
nekem betöltötte mindhármat.
viszont az itteni linkre rábökve 9 hozzászólással korábbra pozícionál.
Mi voltunk azok, a Vándorok.// Kik sohasem nyugszanak. / Kik sohasem haltak meg. / Kik sohasem éltek.
Kezzel most helyretettem, de ez nem imgur problema lesz ahogy nezem.
A jelenseget egy ideje vadaszom hogy mikor/mitol johet elo, de az eddigi elcsipett infokbol itelve: egyszeruen elveszik a kiosztott "HTTP request" munkaszignal valami oknal fogva a beagyazasnal, neha. Van hogy mar az elso szignal elveszik, van hogy analizalas, stb menet kozben. Ez ahogy tapasztaltam fokozottabb suruseggel jon elo ha egyszerre tobb kepet agyazunk be a kommentben, es kisebb szazalekban, ha egyszerre csak egyet.
Hogy mi miatt veszthet el "csak ugy" rejrely mint mondtam. Nem a vilag masik vegere kuldi az uzenetet a szerver ahol kisezer szar eszkozon keresztul is atcsuszhat potencialisan, csak onmagaval beszelget, szoval minden marad lokalis halozatban, legfeljebb a legelso router-ig jut el az meg visszakuldi a szeronak.
Igen, masok is jelentettek mar es valoban, reszletesebb tesztelessel kiderult hogy bizonyos esetekben nem klappol, barmit probalok cache uritessel es hasonloakkal. Ahogy eddig vadaszgattam, valoszinuleg valami hulye bongeszo kompatibilitas kerdes lehet a levesben, pl tipikusan foxon okesan fut a kod, de chrome-on nem annyira okesan mar. Probalom majd ezt is kezelni ha elinteztem a beagyazas "szignal vesztes" problemat, addig is kitartas. :)
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Most javitottam kezzel azokat, azert.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
kézműves fórum
:D
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Azt hiszem levadasztam a gyokeret a szignal vesztesnek. Az RWHttp (https://rewiredhu.cf/content/kivanalom-rewired-20-rwhttp) modulunk aszinkronos HTTP request funcionalitasaban van.
Teljesen leegyszerusitve roviden ugy mukodik, hogy nyit egy friss kapcsolatot, de amint elkuldte a kello adatokat azonnal be is zarja azt es felszabaditja az eroforrasokat, nem varja meg hogy visszajelezzen a szero hogy "koszi megkaptam es megertettem".
Onmagaban nem kellene hogy problema legyen, de ugy fest lehet annyi kommunikacio van mar a lokalis halozaton is, hogy mire eljut az uzi a legkozelebbi router-ig, es jonne vissza a szerohoz, lehet utkozik valamivel mar es elveszik.
Van par megoldas ennek a kezelesere:
1) A legtisztabb ut a legnehezebb. At kell irnom ezt a megoldast egy joval stabilabban es robosztusabban felallitottra. Pl megtanulom kezelni a ReactPHP-t vagy hasonlo hosszu ideje tesztelt es bevallt aszinkronos library-ket. Azutan irok egy RWn kivuli masodik webszervert, aminek a kizarolagos dolga lesz hogy a weboldalunk mellett csucsuljon a szamitogepen es idozitse, delegalja az RW altal kiosztott beagyazas melokat a memoriaban.
2) Beagyazasnal a szerver 1 szignal/beagyaznivalo munka helyet mit tudom en 2-3at/beagyaznivalo is elkuld egymas utan roviddel. Ezzel amolyan brute force modon emelne sokkal az eselyet hogy ha el is veszik 1-2 valahol, a tobbi ugyanugy folytatja a munkat es remelhetoleg a hiba soha nem jon igy elo. A negativuma hogy minden egyes szignal ujabb kulon process-t nyit, ami igy mind extra memoriat is eszik, amibol viszont nem vesztegethetunk ha nem muszaj, mert szukos. Meg a masik nagy negativuma, hogy ronda megoldas, es csak ragtapasz igazabol a problemara, nem kezeli azt.
3) Megprobalom atirni a kerdeses kodsorokat hogy a server a kiadott utasitasokkal a sajat webcime helyett csak a localhost-ot celozza. A cel ezzel az lenne, hogy elmeletileg igy ki se kelljen mennie a signalnak a lokalis halozatra a routerig, majd vissza a szerverhez. Igy az egesz beszelgetes onmagaban a szerveren belul tortenne, es "nem lenne" mibe utkozzon es igy potencialisan vesszen a signal.
Nyilvan hogy a 3) megoldassal probalkozok szerintem, azutan ha valamiert elverzik ez a ravasz terv is, akkor megyek a joval nehezebb 1)-re. A 2) max ideiglenes mentoov megoldas lehet ha addig is ki kell tartson valami a kozeljovoben, amig meg nem oldom a szitut valamelyik masikkal.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
well 3) megoldas maris kilove. Mielott belekezdtem barmibe is, eszembejutott traceroute-tal megcsekkelni hogy mikent vandorolnak a packetek. Sajnos eredetileg is ugy mukodik ahogy gondoltam is hogy kellene, azaz fuggetlen attol hogy localhost-ot celzok vagy a szerver sajat IP-jet, ki sem megy a halozatba hanem azonnal megismeri es visszairanyitja a szerver sajat magara ezeket a kommunikaciokat. Csak valamiert remeltem hogy lehet megsem nekem van igazam es lehet kikandikal a routerig, potencialisan utkozve a tobbi korulotte levo szerver kommunikaciojaval, aztan ez a localhost-ra celzassal megoldodik konnyen. :/
Hat akkor marad a 1), vagy valami hasonlo trukkos atiras a jelenlegi megoldasrol. Ha szerveren beluli kommunikaciokban is veszhet szignal, akkor tuti a valasz megvarasa nelkuli kapcsolat lekapcsolas a gond az beszelt RWHttp modulban. Azaz potencialisan egy-egy melo kiosztasa pillanataban epp elfoglalt a szero akar a masodpect toredekeig is, akkor kenytelenek vagyunk megvarni a "mostmar szabad vagyok!" valaszt, ha el akarjuk kerulni a szignalvesztest.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Valami ilyen megoldast otlottem ki, teljes atiras/atdolgozas es ReactPHP kitapasztalas helyett. Low-level modon kezelve a PHP kimutatas puffereket el tudom erni vegsosoron hogy:
- ellenorizni tudom szerver oldalrol hogy megerkezett e az elkuldott szignal, egy nagyon gyorsan kimutatott visszajelzessel.
- ezzel egy idoben el tudom a megszakitas header-eker kuldeni is, igy itt a kapcsolat meg is szakad szintugy gyorsan, es nem fogja le tobbet hosszas gondolkodassal a kliens bongeszot a tovabbi reagalastol.
- de a szerveren a beagyazas script tovabbra is fut a hatterben, es vegzi lassan a kiadott melokat.
- remelhetoleg ez a gyakorlatban great success, az aszinkronos mukodes szimulalasaban. :)
Proof of concept kodban mukodik kivaloan:
Mindjart nekiesek elesben is a RWHttp modulunkba belekodolni.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Mi indokolja, hogy ennyire ragaszkodunk az aszinkron működéshez?
User szempontból nem annyira fontos szerintem , én úgyis inkább megvárnám a post végleges állapotát, nem annyira szükséges, hogy instant visszakapjam a vezérlést.
De ha a késleltetés a lényeg, és a szerver load balance, az persze más téma.
1) Az hogy kulso szerverekkel kommunikalunk. Itt kozrejatszhat hogy bazi lassu szerverre lepunk, vagy abban az idoben epp leterhelt, bazi lassura, ami hosszu ideig is foghatja a kommunikaciot kommentkuldes utan, feleslegesen.
2) Adott esetben joval hosszabb ideig is futhat egy egy munkafolyamat, mint a maximalis megegedett PHP script futasi ido, pl videoattoltesnel amig minden elintez, lehet tobb percig is. Egy hogy a crashel a folyamat ha tullep az idon es sikertelen lesz a kommentkuldes a beagyazassal egyutt (alapbol az egesz muvelet igy sikertelen lesz), masik hogy percekig fogjuk a kommunikaciot kommentkuldesre nyomas utan, amig el nem keszul az anyag.
3) Memoria igeny. Egy-egy bazi komplex es hosszan felepitett PHP script brutal sok memoriat tud enni, es siman lehet "out of memory error"-t dob adott esetben. Regi RW1.0 kodban amikor probaltam komplexebb vizsgalatokat es muveleteket vegezni, akkor az akkori max megengedett 512mb se volt eleg mert kivagta a biztositekot, es akkor 1 folyamatrol beszelunk csak, amit 1 felhasznalo 1 kommentkuldessel produkal. :) Az RW2.0 koddal igy apro, egymastol teljesen kulonallo folyamatokra bonthattuk a melolepeseket, amelyeknek kulon mind is elegendoen kicsi memoriaigenye van, raadasul amint befejeztek az adott melot, vissza is adjak az elozoleg lefoglalt memoriat, majd a kovetkezo folyamatnak vagy a rendszernek a frissbol lehet valogatnia.
4) Es igen, UX szempontbol a kommentkuldes, mint adott funkcionalitas szempontjabol nem fontosak a felhasznalonak ezek az server-to-server munkakommunikaciok. A felhasznalo egyszeruen a kommentet akarja elkuldeni ha Send-re lep es nem erdekli mi tortenik a hatterben hogy ez megvalosuljon. Nem celja varni a hattermunkak befejezesere, hanem forumozna mihamarabb tovabb. Mindennemu varakozast eleve csak kenyszerbol tesz, mert jobb hijan nincs mas valasztasa ugye.
Ez is, pl a 2. pontnal kiemelten fontos. Es az ebbol addodo kommunikacio feldarabolasa, tobb reszre torese, hogy biztosan ne fussunk ki a maximalis script futasi idobol sem.
Sot most jut eszembe hogy pl ha adott esetben egy nem reszponziv szerora lepunk a beagyazasnal, akkor ahelyett hogy azonnal feladna a probalkozast a rendszer, alszik es var 10-20 masodpercet, majd megprobalja ismet parszor, remelve hogy csak ideiglenes terheles miatt sikertelen a kommunikacio, mivelott vegleg feladna es elkonyvelne elerhetetlennek.
Ez a szempont mondjuk annyira nem fontos (marmint ha proci eroforras elosztas szemponjabol erted), mivel minden lokalis szerver reszre torteno kommunikacio ugyanazon a szerveren van, azaz ugyanazt terheli. Szerintem ez akkor jonne kepbe, ha tobb egymastol fuggetlen szeron dolgoznank. Pl ha kulonbozo mikroservice-ek kulon szerokon is lennenek.
Igen, de szvsz csak azert, mert abbol indulsz ki hogy turhetoen realis idon belul (pl max par masodperc) visszakapod a kontrollt. Ez, mint irtam a fentiekben, kozel nem mindig valosul meg, kulonbozo vad okok miatt, es rossz esetben percekbe is belenyulhat. Jobb ha nem te mint felhasznalo harcolsz ezekkel a problemakkal, hanem meghagyod hogy intezze feloled a szero ahogy akarja, es jelenjen meg a kello helyen az anyag ha keszen van mindennel.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Aha, értem. Bár nekem ez így kicsit overkillnek tűnik. Meg némileg ki is veszi a kontrolt a user kezéből. Én lehet, hagytam volna úgy, hogy megpróbálja beágyazni, ha nem sikerül, szól a usernek, hogy nem nyert, próbálkozzon újra, ha akar.
Nyilván ez megközelítés kérdése, de szerintem túl sok terhet veszel a válladra (a szerver vállára). Ha pl. még processzálódik egy beágyazás, de a user szerkeszti a postot (törli a beágyazandót), az megszakítja a folyamatot? Részletkérdés, de ilyesmi halmazati felelősségeket vízionálok.
(A load balance-ot általánosabban értettem a késleltetéssel kapcsolatban, amikor a szerver különböző időbeli rendelkezésreállását tekintjük különböző "resource"-nak.)
De most már értem, miért szükséges aszinkron, köszi a felvilágosítást!
Hat most pl beszelunk egy csomot reszletesen errol a bugrol (tobbek kozott mert szeretem reszletesen ismertetni a gondolataimat, hatha akadnak zsir otletek masoktol is amire nem gondoltam), de tobbi fejlesztesnel is rakatot irtam, ami elso latasra overkillnek tunhet. Amugy az ilyen jellegu munkadelegalas hasonlo esetekben normalis szokott lenni manapsag szvsz, mintsem mindent egy process-be irni es remelni hogy nem szakad bele. Belegondolva manapsag szinte ott probaljak delegalni a felmerulo melofolyamatokat, ahol csak tudjak. En probaltam vegsosoron realisan effektivre fogni a kerdest, azaz hogy csak ott delegalok ahogy kenyszerulok csomo ok miatt igy eljarni, feleslegesen nem nehezitem magamnak az eletet.
Majd elfelejtettem, de testing konnyuseg szempontjabol is eg es fold kulonbseg kis mikroszervizeket tesztelgetni es javitgani, mintsem egy hatalmas monolitikus, egybefuto kodszeletet. Es fejlesztes szempontjabol is.
Az felett eleve nincs a felhasznalonak kontrollja (regebben se most sem) hogy sikeres e a kommentkuldes/beagyazas vagy sikertelen. Egyedul az felett van kontrolja hogy meg e nyomja a kommentkuldes gombot, vagy leirja e azt amit.
Ha (tegyuk fel) par percig dekkolni akar az elkuldott kommentje felett, es figyelni szeretne hogy sikerul e a teljes beagyazas, ugyanugy most is megteheti. Es ha ugy alakul sikertelen, editalhatja ennek fejeben nyugodtan a hozzaszolasat. Csak nem kenyszerul ujabban varni ha nem akar, de megteheti.
A "beagyazas" mint komplett folyamat 2 nagy, egymastol kialakitasban teljesen eltero reszbol all:
1) A kommentkuldesnel az RW szerver elkezd a kulso weboldallal egyezkedni a kello informaciokert APIkon keresztul, vagy sajat kotyvasztasu algoritmussal. Majd ha megkapta a kello adatokat a lepesek folyaman, akkor elmenti azokat az szepen rendszerezve adatbazisba, egy URL-bol generalt ID nev mogott.
2) Ha valamilyen a felhasznalo betolt egy topikot es/vagy kommentet, es abban a beagyazott URL-bol generalt ID megegyezik az adatbazisban eltarolttal, akkor grafikusan formazza es megjeleniti azokat, "beagyazas formaban" ugye.
A szerkesztes igy egyaltalan nem befolyasolja a beagyazas server oldali kimenetet. De abszolut befolyasolja a kimutatott anyag verziojat. Ha pl szerkesztesz es ugy dontesz megis kiveszed a beagyazott anyagot, akkor az sohasem fog latszani. Sarkitva kicsit, de ugy is felfoghatod igy az 1. pontot mint egyfajta cache-ing, a beagyazas kimutatasnak.
De ha valaki mas is be akarja agyazni es mar megvannak a hatter szamitasok, neki sokkal gyorsabban meg fog tortenni, mert nem kell a szeronak 2x ugyanazt elvegeznie.
Inb4: "de mi van akkor ha kitalalja valaki az ID-t es ugy akaratunk ellenere meglatja az elkezdett, majd meggondolt es mutatni nem szandekozott tartalmat, az RW backendrol kezzel lekerve?"
Good luck hasadra(billentyure)csapni es kitalalni egy SHA256 hashelt hosszusagu es custom Base64-ben encode-olt IDt, hogy azzal pont elcsiped az anyagot. :D Egyeduli mukodo modszer hogy birtokaban vagy mar eleve az eredeti linknek. De hogy lekerd az adatokat azzal kapcsolatban az RW backendrol meg hashelni es encode-olnod sem kell az URL-t hozza. Ugy is mukodik a backend, ha direkt linket adsz meg neki, majd o hasheli es encodolja helyetted mielott keresne az adatbazisban. Irtam is az RWMedia backend modul topikjaban reszletesen a mukodesrol. :)
oh, okes akkor.
szivesen! Mindig orommel beszelek a technikai megvalositasokrol is, egeszen reszletesen is akar. Orulok hogy erdekel valakit az RW technikai geek oldala is. :)
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Elmeletileg kesz.
A fo beagyazas topikban dobtam egy reszletesebb hozaszolast is errol:
https://rewiredhu.cf/comment/265293#comment-265293
TLDR: a fentebb beszelt terv szerint lett a megoldas kidolgozva.
Ha masoknak is ugy fest koser, akkor lezarom ezt a bugjelentest.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
https://rewiredhu.cf/comment/275853#comment-275853
Amikor galériát posztol valaki, akkor vajon lehetne kiemeltebb színű, hogy hány képet tartalmaz még a link?
Mi voltunk azok, a Vándorok.// Kik sohasem nyugszanak. / Kik sohasem haltak meg. / Kik sohasem éltek.
Persze, ezt nem nagy gond atfesteni, mindjart meg is van.
admin mantra: "mindent le lehet kakilni oszt megy az oldal mégis magától."
életfilozófia mantra: "ideológiailag veszélyesen eltévedt kanadai szektás."
Megint nem működik.
Pl.: https://rewired.hu/comment/338437#comment-338437
Mi voltunk azok, a Vándorok.// Kik sohasem nyugszanak. / Kik sohasem haltak meg. / Kik sohasem éltek.
Srácok amúgy nincs vkinek kontaktja Psihez, hogy dobjon neki mondjuk egy SMS-t hogy nézzen mán ide egy kicsit? :))
Chief Exorcist
Messengeren rá lehet esetleg írni, nem hiszem, hogy kanadába sms-zgetne bárki is. De tudtommal másnak is van jogosultsága az oldalhoz, csak már nem tudom kinek...
Mi voltunk azok, a Vándorok.// Kik sohasem nyugszanak. / Kik sohasem haltak meg. / Kik sohasem éltek.
küldj neki egy kis donésünt paypallal, és tárgy legyen "imgur beágyazás fixre"