~~(  Ɛ8>× ×<83  )~~
BÍLÉ MYŠI
Hledat Seznam doupat REGISTRACE
LOGIN:
HESLO:
ÚVOD REGISTRACE VŠECHNA DOUPATA
LOGIN: HESLO:
LOGIN:
HESLO:
REGISTRACE
;

     

Nadpis:Nadpis:
Obsah:Obsah:
   

Píďa 😜 (PetaKlic) (tlustá bestie) komiksy Modré myši
není svět růžový a nejde všechno tak, jak bychom si přáli, proto bylo nutné se vypořádat s nějakými komplikacemi.....

1) opráski

stahování RSS přímo z webu https://www.tumblr.com/ není možné, protože tumblr nasadil GDPR a uživatel musí potvrdit, že tam opravdu chce, než dostane data, to platí i pro RSS soubor, takže nejde stáhnout skriptem, ani když se požadavku podstrčí cookie o tom, že tam opravdu chci

druhý web na ráně je https://twitter.com/ a RSS je zprostředkován webem https://rss.app/. zatím nezbývá, než doufat, že je tento generátor RSS nějak rozumně funkční a nebudu muset luštit zdroják twitteru.

problém je, že některé prohlížeče (firefox v anonymním režimu, o jiných zatím nevím) blokují obrázky z twitteru, protože mohou obsahovat sledovací prvky; pokud by se vyskytl problém se zobrazením oprásků, budou se muset reuploadovat...

2) garfield

garfield už nějakej ten pátek používá stejný formát názvu souboru kdesi na cloudu, stačí se tedy zeptat, zda soubor s dnešním datem již existuje pomocí exif_imagetype.

3) dilbert

stahujeme přímo z webu https://dilbert.com/, stačí porovnat adresu aktuálního obrázku s poslední použitou.

4) dilbert CZ

úplně stejně, ae z webu https://www.idnes.cz/

Píďa 😜 (PetaKlic) Autor většiny bugů. FILOVA ZÁHADA
při prvním vlezení do doupěte se udělá záznam, že tam člověk vlezl A nastaví se mu poslední nečtený (a pokud tam nic není - třeba i proto, že tam nesmí číst) na číslo 0. tím se stalo doupě navštíveným.

Pokud ovšem doupě booknu (což udělal Fila), poslední nečtený se nenastaví >> je tam hodnota NULL a při následném vlezení do takového doupěte nedojde k aktualizaci noviků, prostě proto, že pokud je výsledek odnovovátka číslo 0, tak se nezapíše (ajaxí podmínka, že má odnovit, pozná podle toho, že hodnota >0).

každopádně - existencí záznamu, který vznikl booknutím, se počítají noviki.

tedy, bude se muset pro tento případ vynaleznout výjimka.

Píďa 😜 (PetaKlic) Autor většiny bugů. Pozadí bugu s nečtenými

každé doupě si ukládá počet příspěvků a počet smazaných, aby se nemuselo při načtení seznamu počítat (což by časem trvalo jako kráva)

každý uživatel si pak pamatuje
- id posledního přečteného
- o kolika příspěvcích v doupěti ví
- o kolika nečtených ví
- o kolika smazaných ví

pokud vlezu do seznamu, tak ABYCH NEMUSEL znovu každému počítat nečtené, zjistím
- pokud se rozchází celkový počet, který si pamatuje uživatel, od celkového v doupěti, pouze se přičte rozdíl
- pokud se rozchází počet smazaných, přepočítají se noviky znovu, protože se neví, jestli se smazalo něco, co jsem četl, nebo ne (proto to nedělá lopuchookouní chybu)
- pokud si NEPAMATUJU celkový počet, přepočí tá se to

při návštěvě doupěte se pak VŽDY nastaví poslední přečtený a ODPAMATUJE se uživatelský celkový tak, aby se nečtené spočítaly znovu (pokud je jich víc

pokud mám doupě v sidebaru, tak se to přepočítá, pokud ho tam ale nemám, tak se mi to nepřepočítá (dokud nenavštívím seznam)

no a při odpovědi se doposud dělo to, že jsem k tomu uživatelsky zapamatovanému počtu přičetl jedničku, abych si ušetřil přepočítávání, JENŽE - s ODPAMATOVÁNÍM při návštěvě a NEPŘEPOČÍTÁNÍ sidebarem si to myslelo, že vím o jednom a rozdíl přičetlo.

nyní tedy odpověď na nový příspěvek NULUJE to pamatování a přepočítává se to znovu (správně)

Píďa 😜 (PetaKlic) Autor většiny bugů. navazuji na https://bilemysi.cz/doupata.php?doupe=navrhy&vlakno=580

(nevím, podle mě jsou upload od usera, tzn to, co se nahraje POSTem od usera do $_FILES, a file_get_contents, který umí načíst cokoliv odkudkoliv, dvě rozdílné věci, ale nedokážu se nikde dočíst ve specifikacích, jestli se tahle php.iniovina dotýká práce s file_get_contents)

každopádně je zbytečné to řešit, protože použitý exif_imagetype by si měl stáhnout - podle specifikace - jen pár byte, a to, co zdržuje, je hledání konektivity pro ten přenos těch pár byte, protože každá adresa mi poprvý leze dýl a podruhý to jen mrkne (pokud to není zmíněný příklad s okouním hackem, kdy - než vzdálená url vrátí aspoň nějaká data, protože pracně žvejká výstup mysqli query o pár tisících řádků - prostě ten exif čeká na odpověď)

asi zkusím to, že si udělám sobě výjimku vázanou na můj login a vyzkouším, jak se to bude chovat - localhost se často chová všelijak jinak, než potom velkej server






 Bílé myši (c) 2018, 2019 Strašlivý Píďa.   Webhosting ZONER software, a.s.   https://www.czechia.com/ 
 Stránky používají cookies.   Bez nich to nejde.   BUBUBU! JSME ZLÉ COOKIES!   Nesouhlasíš-li s použitím cookies, táhni. 
čeká se na ajax