- trey blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Mint a Rock & Roll ugy 60 eve... lol :D
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
- A hozzászóláshoz be kell jelentkezni
> A cikkek olvasottságánál pedig nem veszi figyelembe azokat a kattintásokat, amelyeket olyan látogatók végeznek, akik explicite tiltják a JavaScript-et vagy bizonyos blocker böngésző-kiegészítőket használnak.
Ezt hogy? Ha kinyitok egy aloldalt, akkor mindenképpen látja a szerver, hogy lekértem, ennyi erővel már akkor lehet inkrementálni az olvasottságszámlálót; miért kell ehhez külön JS?
- A hozzászóláshoz be kell jelentkezni
miért kell ehhez külön JS?
Hogy ez jó így, nem jó így, hogy ez bug, vagy tervezett feature, azt én nem vizsgáltam. Leírtam egy többször felmerült kérdésre azt, amit én jelenleg tapasztalok. Másnál kijöhet más eredmény is. Ha bug, felírom a listára. Ha feature, akkor ez van. Jelenlegi infóim szerint ez feature.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Esetleg amiatt, hogy az oldal betöltését ne lassítsa a telemetria. Hogy van-e kimérhető jelentősége, az már más kérdés.
- A hozzászóláshoz be kell jelentkezni
Aszinkron DB művelet esetén nem lassít szinte semmit, mert nem kell megvárni az eredményt.
- A hozzászóláshoz be kell jelentkezni
Akkor is látnia kellene a szervernek, ha a kérés el sem jut hozzá, mert egy külső gyorsítótár szolgálja ki a kérést?
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
A szerverig el kell, hogy jusson a kérés, mert valamit kapunk vissza. Azt, hogy a visszaküldentő eredményt a gyorsítótárból húzza elő, az nem gátolja meg abban, hogy a DB felé küldjön egy aszinkron kérést. Mit értesz egyáltalán az alatt, hogy "külső gyorsítótár"?
- A hozzászóláshoz be kell jelentkezni
Ha mondjuk Varnish van az oldal előtt, akkor beállítható úgy, hogy csak akkor jusson el a kérés a Drupalhoz, ha változott valami az oldalon, egyébként pedig kiszolgálja a Varnish, mintha statikus weboldal lenne. Az nginx is képes erre, vagy másik példa a Drupal Boost modulja, ami statikus fájlként letárolja a weboldalt és ha nem változott semmi a anonymous látogatóknak, akkor azt adja vissza.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
A Varnish tudja forwardolni cache-hit esetén a requestet a backend felé, tehát Varnishnál megoldható szerveroldalon.
NGinx esetén is van megoldás arra, hogy szerveroldalon frissítsük a számlálót, mondjuk ez a logparsing nem biztos, hogy a legoptimálisabb; egy NGinx gurut kéne megkérdezni, hogy van-e request forward-ra lehetőség NGinx cacheing esetén.
A Boost pedig a Drupal része. Gondolom így sem egy vanilla Drupal hajtja az oldalt; bele lehetne írni tíz sort a Boost kódjába, ami egy aszinkron DB kérést megereszt a cache-hit-ek esetén.
- A hozzászóláshoz be kell jelentkezni
Nem azt mondtam, hogy a Varnish vagy nginx nem tudja ezt kezelni, mint ahogy a modullal is megoldható. Azt mondtam, hogy közel sem biztos az, hogy a kérés eljut a Drupalig.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Viszont akkor ez egy irreleváns információ volt, hogy eljut-e a Drupalig a lekérés, vagy sem, hiszen, ha a számlálót a Drupal megkerülésével is lehet frissíteni, akkor érdektelen, hogy a Drupal látta-e, vagy sem.
A lényeg, hogy megoldható szerveroldalon; szükségtelen a kliens felől egy újabb lekérés, ami csak egy hit-countert léptet, így ugyanis mindkét oldalon (meg magán a hálózaton is) csak nagyobb lesz az overhead, mert két lekérés lesz egy helyett, úgy, hogy szerveroldalon az érintett DB kérést nem spóroltuk meg, csak egy második lekérés fogja végrehajtatni, viszont kliensoldalon megint van egy pluszban futó JS kódszegmens. Lose-lose.
- A hozzászóláshoz be kell jelentkezni
Viszont a Javascript tiltás leginkább a botokat érinti, azokat beleszámolni pedig felesleges. Viszont arra ritkább esetben tud az átlag ügyfél hatni, hogy egy külső gyorsítótár hogyan van beállítva.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Van olyan bot, ami futtatja a JS-t, meg egyébként is lehet őket sokféleképpen szűrni, de még ha meg is nézi pár darab, az akkora katasztrófa? A második felét úgy érted, hogy nincs root jogotok a HUP szerveréhez?
- A hozzászóláshoz be kell jelentkezni
Én most általánosságban írtam.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Értem. Akkor konszenzusra jutottunk, hogy jelen esetben megoldható szerveroldalon, nincs értelme vagy létjogosultsága a JS-alapú megoldásnak.
- A hozzászóláshoz be kell jelentkezni
Viszont mivel van egy remek kliens-oldali implementációnk, ezért nyilván nem írunk sajátot.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Remek implementáció, ami feleslegesen terhel pluszban klienst és szervert egyaránt? Amúgy nem tudom mi a "saját írása" abban, hogy a cacheing mechanizmusnak csinálnia kell 1 db aszinkron DB lekérést.
- A hozzászóláshoz be kell jelentkezni
Oké. Hajrá!
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Hajrá mi? Csináljam meg én? Hozzáférés nélkül?
- A hozzászóláshoz be kell jelentkezni
Semmi hozzáférés nem kell, fogsz egy alap Drupal 8-at és megírod, közzéteszed. Közösség örül és ha megfelelő, akkor esetleg mi is felhasználjuk.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Ehhez tudnom kéne, hogy mi csinálja konkrétan a cacheinget, mert háromfélét is felsoroltál. A Drupal Boost?
- A hozzászóláshoz be kell jelentkezni
Nem használjuk a Drupal Boost modulját, de légyszi egy általános megoldást készíts, amit utána közzé is teszel.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Mit értesz "általános megoldás" alatt? Kérsz egy pontot a Drupal backendben, aminek át lehet adni, hogy melyik topic viewcount-ját inkrementálja?
- A hozzászóláshoz be kell jelentkezni
Általános megoldás alatt azt értem, ami nem csak a HUP-pal, hanem általában bármilyen működő Drupal 8-al képes együtt működni, lehetőleg függetlenül az általa használt gyorstárazási megoldástól.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Ez így nem mond semmit. Nincs 100% általános megoldás. Mit érek azzal, ha pl. adok egy PHP-t, aminek akár shell-ből, akár HTTP kérésből át lehet adni URL-t, vagy content ID-t, hogy ennek a viewcountját kell inkrementálni, ha aztán közlöd, hogy nem lehet illeszteni a backendhez, mert nem tud PHP-t meghívni sem így, sem úgy.
Csak úgy mondom, hogy az sem általános megoldás, ami most van, hisz letiltott kliensoldali JS mellett nem működik.
- A hozzászóláshoz be kell jelentkezni
Hát akkor így jártunk.
További szép estét!
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Látod erre mondtam, hogy aki konstruktívan állna hozzá és nem az a célja, hogy téged cseszegessen, az sem kap érdemi választ. Most akkor van egy JS alapú megoldás, ami nem csak, hogy felesleges overheadet csinál mindenütt, de ráadásul a jelek szerint nem is működik rendesen, továbbá ki is kerülhető. Oké, csinálja meg a szerveroldalit, aki annyira akarja, de specifikáció nélkül implementáció sincsen; általános megoldás nincs és nem is kell: az egyik cacheing technológia ezt tudja, a másik meg azt, ennek megfelelően egy a hupon futó szerveroldali viewcount incrementernek a hupon használt cacheing technológiával kellene mennie, amit viszont nem voltál hajlandó elárulni, hogy mit használtok - elvárnád, hogy az ember vaktában dolgozzon. De marad a "remek" és "általános" JS-alapú megoldás, csak azért, hogy JS legyen.
- A hozzászóláshoz be kell jelentkezni
Nézd, én teljesen konstruktívan állok hozzá.
A jelenlegi megoldás ugyan Javascriptet használ, viszont mivel joggal feltételezzük, hogy a látogatók jelentős része engedélyezi a javascriptet a böngészőjében, ez igazából csak plusz egy lekérést jelent. Ha ez valakinek nem fér bele, akkor ott már más problémák is vannak.
Cserében viszont nem fogunk egyedi, senki által nem tesztelt és vizsgált megoldást alkalmazni csak azért, mert valaki ódzkodik a Javascripttől és a plusz egy lekéréstől. Ezért mondtam, hogyha neked a jelenlegi megoldás problémás, akkor írd meg általánosan és tedd közzé „több szem többet lát alapon”. Mivel a HUP kezdettől fogva igyekszik minél közelebb lenni az eredeti kódbázishoz, ezért biztosan nem fogunk „csak úgy” egy egyedi PHP-t betenni, amiről nem tudjuk, hogy milyen egyéb mellékhatást okoz. Ráadásul úgy, hogy az abban előforduló esetleges biztonsági hibákért nem a megoldás készítője lesz a felelős.
Majd ha a HUP tulajdonosa és üzemeltetője másik megoldást kér, akkor keresünk másik megoldást. De addig én biztosan nem fogom szorgalmazni ezt.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
A számból vetted ki a szót! Már így is messzebb járunk a "Drupal Core only" filozófiámtól a használt modulokkal, mint szeretném, vagy komfortosnak éreznék :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A gyomrom forog tőle, hogy engedtél a felhasználók ostoba kívánságainak, és utat engedtél egy becsicskult átállásnak.
:)
- A hozzászóláshoz be kell jelentkezni
Ez nem egyszerűen "plusz egy lekérést" jelent, hanem oldallekérésenként plusz egy lekérést, tkp. megduplázod az oldal HTTP query forgalmát. Hány oldallekérés van a hupon naponta? Biztos nem kevés. Ez nem arról szól, hogy a látogatónak "nem fér bele plusz egy lekérés", ennek a szerver és a sávszél sem örül. Az pedig, hogy írjam meg általánosan, az nem specifikáció. Jó lenne tudni pl. hogy hogy lesz meghívva a kiegészítés. Nagyon szívesen beleásom magam és adok egy interface pointot, ha tudom, hogy hogyan fog csatlakozni a cacheing a backendhez és mit fog átadni.
- A hozzászóláshoz be kell jelentkezni
Arra próbált nevergone utalni, hogy oké, hogy lehetne egyénileg fejleszteni valamit, de nem szeretnénk eltérni a Drupal közösség által karbantartott dolgoktól. Tehát, ha van valami, ami bekerül a hivatalos Drupal kódbázisba, vagy hivatalos és karbantartott modulja lesz, azt meg lehet fontolni. De saját fejlesztés a hivatalos forrásfán kívül vagy egyén által fejlesztett kód használata nem célravezető.
Én régóta ezt az elvet vallom, szoptam én eleget olyan dolgokkal, aminek egyszer csak megszűnt a fejlesztése, a fejlesztő eltűnt, se biztonsági követése, se semmi nem volt.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én ezt értem, csak így nem tudom hova tenni a "küldj patchet" felhívást, amikor valaki valaminek a hiányát, vagy feleslegességét reklamálja az oldalon. Hova küldjön patchet a delikvens? A Drupal kódbázisba? Szerinted mennyi eséllyel merge-elnek valamit, ha beküldöm, hogy "általános interface point viewcount inkrementálásra"?
És nem is arról van szó, hogy a látogatók szívják meg főként. Aki akarja, egy mozdulattal tiltja a JS-t és nem fogja zavarni, ha nem látja a hup; a ti szervereteket terhelik ezek a felesleges kérések.
- A hozzászóláshoz be kell jelentkezni
Én ezt értem, csak így nem tudom hova tenni a "küldj patchet" felhívást
Az általunk kedvelt nyílt forráskódú világban azért ez nem ördögtől való ...
Hova küldjön patchet a delikvens? A Drupal kódbázisba?
Például.
Szerinted mennyi eséllyel merge-elnek valamit, ha beküldöm, hogy "általános interface point viewcount inkrementálásra"?
Nem tudom, mert nekem ez kínaiul van. Ebből kifolyólag nekem bizonygathatod, hogy milyen jó lenne, nem tudnám szakmailag megítélni. Ezért vannak az ilyen projekteknél a karbantartók, akik fel tudják mérni. Arról, hogy miért nem célszerű forkolni a hivatalos kódot, már feljebb írtam.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Tegyük fel, hogy megírom és beküldöm. Ehhez még mindig tudnom kéne, hogy itt milyen cacheing megoldás van, hogy tudjam hozzá illeszteni. Egy "általános" megoldás kb. kimerül egy DB kapcsolódásban és egy aszinkron kérésben, ill. ha az URL-ből kell kihámozni a content ID-t, akkor még annyi. De hogyan fogja ezt bármi meghívni?
- A hozzászóláshoz be kell jelentkezni
Olyan gyorstárazási megoldás van, amit a core tartalmaz. Nincs itt semmi varázslat.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Ezt eddig nem bírtad elmondani.
- A hozzászóláshoz be kell jelentkezni
Pontosan ezt mondtam eddig is, hogy általános megoldást kell készíteni, ami HUP-tól függetlenül működik.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Szó szerint azt kérdezted, hogy mi van, ha el se jut a Drupalig a kérés, külső cacheingre hivatkoztál, felsoroltál háromféle cacheinget, aztán meg általános megközelítésről beszéltél...pontosan azt a látszatot keltetted egész végig, hogy itt valami Drupal-independent cacheing megoldás van alkalmazva.
- A hozzászóláshoz be kell jelentkezni
Innen olvass megint újra: https://hup.hu/comment/2405739#comment-2405739
Arról én nem tehetek, hogy félreértelmezted. Leírtam, hogy általános, HUP-tól független megoldás kell, ami minden Drupal 8-al működik. Te jöttél hozzáféréssel, meg „mi fogja meghívni”, meg „adsz egy PHP-t” stb.
Persze, ha netán megírod, az sem garantálja, hogy használni fogjuk, de ezt is leírtam korábban és az okait is trey-jel együtt.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Akkor még egyszer:
- Először azt kérdezted, hogy "Akkor is látnia kellene a szervernek, ha a kérés el sem jut hozzá, mert egy külső gyorsítótár szolgálja ki a kérést?"
- Aztán a Varnishra, az NGinx cacheingre és a Drupal Boostra hivatkoztál.
- Aztán megint azt mondtad, hogy "közel sem biztos az, hogy a kérés eljut a Drupalig."
- Utána pedig végig ragaszkodtál az "általánossághoz", konkrét válasz nélkül, mostanáig.
Ezt nem én értettem félre, hanem te vezettél félre.
> Persze, ha netán megírod, az sem garantálja, hogy használni fogjuk, de ezt is leírtam korábban és az okait is trey-jel együtt.
Akkor sem, ha a Drupal project beolvasztja? Akkor minek csináljam?
- A hozzászóláshoz be kell jelentkezni
Szinte biztos, hogy a Drupal projekt nem fogja beolvasztani, ezért kell a teljes, külső modul. A válaszaim pedig végig egy HUP-tól független, általános helyzetről szóltak, mivel egy HUP-specifikus megoldás senkinek sem áll érdekében. De ezt is leírtuk fentebb trey-jel.
Azért írtam a Varnish-t, Nginx-et, Boost modult, hogy szemléltessem neked: nem minden esetben jut el az oldalkérés a Drupalig, de a Javascript akkor is lefut. Sehol nem írtam, hogy mi ezek közül akár bármelyiket is használnánk jelenleg, bár ez nem zárja ki a jövőbeli használhatóságukat.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Nem ez volt a kérdés, hanem az, hogy ha beolvasztják - legyen az "általános, teljes külső modul" - akkor sem fogjátok felhasználni?
A JS nem fut le. A kliensre van bízva és a jelek szerint nem is működik rendesen.
- A hozzászóláshoz be kell jelentkezni
> legyen az "általános, teljes külső modul"
Valamit megint félreértettél. Az általános külső modul egy sima contrib Drupal modul, amit a Drupal Core sosem fog beolvasztani, hiszen ez külső, tőle független módon létrejött - és remélhetőleg karbantartott - modul, a Core-hoz semmi köze, a Drupal team pedig maximum security oldalról nézi majd a modult, meg szól, ha már nagyon outdated vagy, de amúgy that's all.
Az oldalban való felhasználáshoz meg szerintem kellene valami biztosíték, hogy ezt te karban is fogod tartani, meg figyelsz az issue requestekre, akkor talán Nevergone-ék is megfontolják az oldalban való felhasználást. De pusztán attól, hogy egy HUP tag csinálta, nem fogják berakni az oldalba, még ha nagyon szépen is kéred. Ezt az oldalt rajtad kívül nézik párezren, emiatt nagyon jó lenne, ha a stabilitása szabad szemmel is jól láthatóan jobb lenne, mint mondjuk a játszótéri libikókáé. Pont ezért nem talált nyitott fülekre az, hogy "küldök egy PHP-t", a problémáknak ilyen jellegű megoldása már vagy 10+ éve kiment a divatból, és senki nem várja vissza. Nézd át kérlek, hogy működik mostanában a Drupal community és a Drupalhoz történő fejlesztés, és probálj meg az alapján működni te is. Akkor sokkal jobb helyzetből beszélgethetsz az oldal fejlesztőivel erről a kérdéskörről.
Nem bántani akarlak, de ha izomból és dühből kommunikálsz, anélkül, hogy megpróbálnád megérteni a túloldalt, azzal csak saját magadnak ártasz.
- A hozzászóláshoz be kell jelentkezni
> Nem bántani akarlak, de ha izomból és dühből kommunikálsz, anélkül, hogy megpróbálnád megérteni a túloldalt, azzal csak saját magadnak ártasz.
Szerintem te itt valamit nagyon benéztél. Én végig konstruktívan álltam hozzá, nem szóltam be egyszer sem. Idézd be, hogy szerinted mi volt itt dühből, meg izomból történő kommunikáció.
- A hozzászóláshoz be kell jelentkezni
Technikailag nem hazudtal, de a fenti threadbol rohadtul nem az jon le, hogy itt marpedig csak core megoldasok vannak.
- A hozzászóláshoz be kell jelentkezni
Valóban nem csak core megoldások vannak, de nincs semmi HUP-specifikus, vagyis olyan, ami más oldalakon ne állná meg a helyét.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Sehova nem kell patch-et küldened. Egy teljes contrib modult kell írnod, ami általánosságban megvalósítja azt, amit szeretnél. Aztán az használja, aki akarja.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
A patchküldést arra értettem, hogy amikor valaki megreklamált valamit, akkor az volt a válasz, hogy küldjön patchet. Általánosságban meg nem lehet megvalósítani semmit.
- A hozzászóláshoz be kell jelentkezni
> Általánosságban meg nem lehet megvalósítani semmit.
Dehogynem. A probléma, amit leírsz, általános, több mint valószínű, hogy nem csak a HUP-ot érinti. Erre kell egy általános megoldást adni.
- A hozzászóláshoz be kell jelentkezni
Nem erről volt szó, de mindegy.
- A hozzászóláshoz be kell jelentkezni
Egyébként bejelentkezve nem is csak 1 db XHR lekérdezés van, hanem kettő. Az egyik rögzíti, hogy ki mit olvasott (history modul), a másik pedig növeli a node olvasottsági statisztikáját. Az olvasási XHR a lassabb nálam: ~120 ms, a statisztikai ~40 ms.
- A hozzászóláshoz be kell jelentkezni
Akkor meg nem is duplázza, hanem triplázza a queryket, miközben szerveroldalon el lehetne intézni egy lépésből.
- A hozzászóláshoz be kell jelentkezni
Jol megmutattad neki!
- A hozzászóláshoz be kell jelentkezni
És mit kellett volna szerinted megmutatnom?
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
iszont a Javascript tiltás leginkább a botokat érinti, azokat beleszámolni pedig felesleges.
Van bot, ami futtatja a JS-t. Van user, aki nem. Botokat értelmes filterrel kell szűrni, nem JS futtatással.
- A hozzászóláshoz be kell jelentkezni
Pontosan ezt írtam neki én is, de hát ő általánosságban értette.
- A hozzászóláshoz be kell jelentkezni
Látom, direkt csinálod a hangulatot.
Segítek az értelmezésben: általános megoldás == nem HUP-specifikus
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Azért ez már kezd egy kicsit sok lenni. Én nem csinálok semmiféle hangulatot. Azok közé az emberek közé tartozom, akik nem csak beszóltak, vagy nem csak benyaltak, hanem próbáltak konstruktívan hozzáállni. Érdemi választ szinte egyszer sem kaptam, terelést, mellébeszélést, azt annál többet. Így semmi értelme az egésznek.
Amit meg mt9-cel írtunk, az általánosságban is áll, JS-sel nem lehet normálisan kiszűrni a botokat.
- A hozzászóláshoz be kell jelentkezni
Oké, ezt a kört akkor engedjük el, jobb lesz mindenkinek. Kérlek ha ennyire fontos neked, akkor írd meg a modulodat és tedd közzé a drupal.org-on.
További szép estét!
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Miután nagyjából 100%-ig biztos vagyok benne, hogy majd a saját kis eldugott vendégkönyvedbe fogsz majd derpegni azon, hogy biiiiztos megint provokálni akarlak, így sok értelmét nem látom a kérdés feltevésének, viszont most az egyszer azért érdekelne, hogy mit csinálsz ott, ahol még van egy 3rd party CDN (pl. cloudflare, aws cloudfront, akármi) van még a saját webszervered és a kliens között?
- A hozzászóláshoz be kell jelentkezni
" A cikkek olvasottságánál pedig nem veszi figyelembe azokat a kattintásokat, amelyeket olyan látogatók végeznek, akik explicite tiltják a JavaScript-et vagy bizonyos blocker böngésző-kiegészítőket használnak. "
Ez bizonyitott, vagy csak szeretnétek ezt hinni? Gondolok itt arra, hogy sima logban realizálódnak-e a találatok és csak a Drupal nem kapja el?
Aláírás _Franko_ miatt törölve.
neut @
- A hozzászóláshoz be kell jelentkezni
Nem szeretnék hinni semmit, nem a templomban vagyunk. Tiltsd le a JavaScript-et a böngésződben. Keress egy cikket, amit már nem nagyon olvasnak, hogy más ne zavarjon be a tesztbe. Kattintsd le, figyeld a számlálót. Majd próbáld meg engedélyezett JavaScript-tel.
Növekszik, nem növekszik, mikor növekszik? Az eredményt majd oszd meg itt. Thx!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Se engedélyezett, se letiltott JS-el nem számlál (sőt, még voltam annyira figyelmes, hogy a uBlock-ot és a Ghostery-t is kikapcsoltam. FF adatvédelmi beállitások defaulton.
FF 70.0.1@Win10
Aláírás _Franko_ miatt törölve.
neut @
- A hozzászóláshoz be kell jelentkezni
Hát, ha ez így van, akkor még nagyobb számoknak kellene lennie, mint gondoltam! Kösz.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Így, hogy nem valósak a Drupal viewcountok, mennyiben változik meg a HUP értékesíthetősége? Hiszen a reklámozók számára kellenének a valós forgalmi adatok, hogy tudják, mennyit ér a HUP. A HWSW-t tájékoztattátok, hogy mostantól kezdve nincsenek a valósággal jól korreláló látogatottsági statisztikák?
- A hozzászóláshoz be kell jelentkezni
Van Google Analytics, biztosan nem a Drupal számlálót mutogatják/nézegetik. :)
Biztos, hogy nem én gonoszoltam le!
- A hozzászóláshoz be kell jelentkezni
Így, hogy nem valósak a Drupal viewcountok, mennyiben változik meg a HUP értékesíthetősége?
Szerintem semennyire. A GA mérései a mérvadók. Ezek a számlálók max. nekem adnak visszajelzést.
Hiszen a reklámozók számára kellenének a valós forgalmi adatok, hogy tudják, mennyit ér a HUP.
Független méréseket illik adni. Lásd: Google Analytics.
A HWSW-t tájékoztattátok, hogy mostantól kezdve nincsenek a valósággal jól korreláló látogatottsági statisztikák?
A HWSW-nek semmi köze hozzá, akinek van, az pedig tud róla.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni