Stefan Kalscheuer

Forum Replies Created

Viewing 15 replies - 106 through 120 (of 157 total)
1 2 3 … 7 8 9 10 11
  • Forum: Plugins
    In reply to: [Statify] Zeige Gesamtzahlen – Dashboard
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years ago

    Es sollte das Datum des ältesten angezeigten Eintrages sein, also identisch mit dem Tooltip des ersten Punkts im Diagramm – bei Default-Einstellung 14 Tage zurück.

    Bei mir stimmt es auf allen Installationen überein. Wenn es bei dir weder das älteste Datum der Anzeige noch das älteste Datum der Datenbank ist, wären ein paar weitere Details hilfreich, um das Problem nachzustellen (welches Datum, eingestellte Zeiträume, Zeitzone, etc.)

    Gruß,
    Stefan

    Nachtrag: Ich habe gerade nochmal genauer hingesehen und auf einem kleinen Anzeigezeitraum per Hand nachgerechnet… Meine Aussage zum Datum ist korrekt, aber die Gesamtzahl entspricht allen Aufrufen, nicht nur den angezeigten. Die Daten passen also nicht zueinander.
    Kommt auf die Liste für 1.7.1

    Forum: Plugins
    In reply to: [Statify] Zeige Gesamtzahlen – Dashboard
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years ago

    Hallo André,

    tatsächlich wird hier die Gesamtzahl des angezeigten Zeitraums ausgegeben, der ja nicht mehr gleich Speicher-Zeitraum sein muss.

    Hier haben sich ein paar Neuerungen gegenseitig überholt, daher passt die Bezeichnung nicht perfekt. Ich persönlich würde hier eher noch 1-2 Werte mehr ausgeben: Heute, Gesamt in Anzeige, Gesamt in Datenbank (falls abweichend).
    Ggf. noch Gesamtzahl seit Beginn, auch wenn keine Details für den Zeitraum mehr bekannt sind.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify] AMP Support
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years ago

    Hi @dieter93 and @jamesosborne,

    Statify 1.7 has been released today which includes the named changes.

    It worked on my test instances (otherwise we probably would not have released the feature) with the AMP plugin active and no additional changes.
    Javascript Tracking should be enabled (settings descrition is extended by “… or AMP”), otherwise only the first hit before any caching will be counted.

    Hopefully it also works for you. Would love to see you feedback on this.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Statify] favicon.ico
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years ago

    My question is still, who is asking for the favicon?

    About everybody. The webbrowser tries to find an icon to display in the title bar. If nothing is specified, the default is “favicon.ico” and most browsers try this, even if not specified explicitly.

    WordPress integrated a redirection to the default “W” icon, if there is none. Otherwise you would see lots of 404 errors in the server logs, because there is no icon.

    Cheers,
    Stefan

    PS: Statify 1.7 has finally been released today! This solves the “favicon.ico” problem even without JS tracking.

    Forum: Plugins
    In reply to: [Cachify] Changelog entries missing in wp.org
    Stefan Kalscheuer

    (@stklcode)

    6 years ago

    This has already been addressed by myself (https://github.com/pluginkollektiv/cachify/pull/189)
    Wondering why is hasn’t been published yet… Will trigger the team on that.

    Based on the title I assume you might have already found the changelog somewhere else. If not, the full changelog can always be found on GitHub: https://github.com/pluginkollektiv/cachify/blob/master/CHANGELOG.md

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Statify] favicon.ico
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years ago

    Good catch, Thorsten.

    We should probably add an exclusion for this in the upcoming Statify release.

    Edit: To be fixed with 1.7 (https://github.com/pluginkollektiv/statify/pull/144)

    The client is redirected to the real favicon (HTTP 302) by WordPress. Apparently plugins are already loaded at this point, s.t. Statify has tracked the visit.

    200ms TTFB for the favicon redirect – I got sites that are served within 20ms (uncached) total.. You want to fix this at the other side, e.g. by copying the “favicon.ico” file to the root directory or defining a custom icon path in the theme.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Statify] favicon.ico
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years ago

    Hi,

    the favicon URL appears in the top list because it is really accessed that many times and dynamically served through WordPress, not provided as a real static file. About every client will access this icon, so you likely have twice as much hits in total.

    I guess you are not using any kind of caching backend and Statify in default configuration, i.e. JavaScript Tracking disabled.
    In addition you are most likely using a theme or plugin that servers the favicon dynamically, because Statify would never notice access to static files.

    Please provide some additional information on your setup, s.t. we can reproduce the scenario and investigate on a fix for Statify, if possible.

    Besides such scenario being close to worst case in terms of performance (but that’s not the point here), the most simple solution for your case would be turning on the „JavaScript Tracking“ option. Doing so, the client browser triggers the tracking action through JS included in your posts/pages, but definitely never in favicon or similar cases.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Statify] Feature request: Downloads countable
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years, 1 month ago

    There are several possibilities to track downloaded files.

    Serve through PHP
    * breaks with caching
    * probably way out of scope for Statify

    Intercept through PHP with redirect to real file
    * can get tricky with caching, but possible
    * does not accurately track number of downloads, only number of redirections to the actual link
    * also way out of scope for Statify

    Intercept with JavaScript
    * only works with JS tracking
    * can get tricky on which links the interception should be appended and which not
    * does not actually track downloads, but clicks on the link

    All assuming you use default WP file management. There are several Download manager or monitoring Plugins available for WordPress which provide such features. I don’t think such feature is really suitable for Statify

    Regards,
    Stefan

    Forum: Plugins
    In reply to: [Statify Filter] IP Blacklist für Subnetze?
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    6 years, 1 month ago

    Hallo Rolf,

    eine Bot-Erkennung hat Statify selbst bereits integriert. Diese ist bis Version 1.6 in der heutigen Zeit zugegeben nicht mehr ideal, mit 1.7 wird sie noch einmal deutlich verbessert.

    Aktuell greift ein Positiv-Filter, der auf die Wörter Windows, Macintosh, Linux, iPhone und iPad im User-Agent String. War sicher mal gut, passt gerade für viele Mobile-Bots aber leider nicht mehr. Das wird sich mit dem nächsten Update auf einen Negativ-Filter der Wörter bot, slurp, crawler, spider, curl, facebook und fetch ändern.

    Ein User-Agent Filter, analog zum Referer wäre aber grundsätzlich keine schlechte Idee, dann hätte man das bereits jetzt haben können (die Version hängt ja schon recht lange in der Schwebe). Nehme ich für das nächste Blacklist-Release mit auf die Liste

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify Filter] IP Blacklist für Subnetze?
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    6 years, 1 month ago

    Mir haben die beiden Möglichkeiten (einzelne Adresse, CIDR Block) bislang immer genügt. Sollte die Notwendigkeit, unübliche Netzsegmente zu sperren (sowas wie .5-.13 ist so ja nicht direkt abbildbar), einfach entsprechendes Feedback geben, das ließe sich sicher nachpflegen.

    Forum: Plugins
    In reply to: [Statify Filter] IP Blacklist für Subnetze?
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    6 years, 1 month ago

    Hallo Rolf,

    aktuell ist nur CIDR Notation verfügbar, um Subnetze zu sperren. In deinem Beispiel also mit Maske 24: 111.222.333.0/24.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify Filter] Statify Blacklist Aufruf verlangsamt die Seite
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    6 years, 3 months ago

    Hallo Gerd,

    […] dass Statify Blacklist einen Aufruf macht

    Diese Aussage ist so nicht korrekt. Der Aufruf stammt von Statify selbst. Dabei handelt es sich um den JavaScript Aufruf, falls “JS Tracking” aktiviert ist. (aus diesem Skript-Schnipsel)

    Dieser wird asynchron nach dem Laden der Seite vom Browser ausgelöst, hat also keinen Einfluss auf die Ladezeit der Seite selbst.

    Der Aufruf umgeht ganz bewusst das Caching, daher wird ein normaler WordPress Zyklus mit Initialisierung und Verarbeitung aller relevanten Plugins durchlaufen (bis Statify dran ist, dann wird mit Code 204 abgebrochen), was je nach Umfang der Seite un Performance des Systems in der genannten Größenordnung liegen kann.

    Ohne JavaScript Tracking erfolgt die Verarbeitung synchron beim Aufbau der Seite, d.h. dieser Zusatz-Request fällt weg. Sobald ein Cache aktiv ist und das HTML Markup nich von WP neu generiert wird, funktioniert das Tracking aber nicht mehr.

    Möglicher Weise wird das Verhalten in einer der kommenden Versionen auf WP AJAX umgestellt und damit deutlich verschlankt (vgl. GitHub Issue #109). Aktuell gibt es aber keine Möglichkeit, diesen Aufruf “mal eben” zu beschleunigen, außer den Aufbau der Seite durch WP zu optimieren, also im Wesentlichen Plugins deaktivieren oder umsortieren.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify] Dashboard-Anzeige – Tage begrenzen
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years, 3 months ago

    Hallo Peer,

    der Wunsch kam mir gleich bekannt vor. Tatsächlich habe ich genau dieses Feature vor bald 2 Jahren schon einmal programmiert und es gab bereits Diskussion über den tatsächlichen Nutzen: https://github.com/pluginkollektiv/statify/pull/72

    Parallel dazu ist für v1.7 ebenfalls ein scrollbares Diagramm in Planung, um große Bereiche lesbar zu halten: https://github.com/pluginkollektiv/statify/pull/101

    Danke für das Auffrischen der Diskussion, beide Themen sind offenbar ein wenig eingeschlafen.

    Gruß,
    Stefan

    Forum: Reviews
    In reply to: [Statify Filter] Great + feature request
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    6 years, 4 months ago

    Hi!

    Thanks for the kind words and the feature suggestion.

    If we don’t wanna break with the “do-not-save-anything” poliycy, we have to do the IP processing during live request which hits on performance – OK, probably most sites use asynchronous JS tracking, so a couple of ms won’t hurt here.

    I think we cannot assume a PHP GeoIP extension set up on many sites and as the underlying GeoIP Legacy service is discontinued for almost a year now, it is most likely outdated…

    I’ve integrated MaxMind GeoIP2 in other projects which might be a viable solution here, too. I will investigate on an optimal way to include include this. Porbably in both directions, allow- and block-list.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Statify] wie statify in theme ohne wp_footer() verwenden
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    6 years, 5 months ago

    Hallo Peter,

    das ist prinzipiell möglich.

    Option A:
    Du rufst die Methode statische Methode Statify_Frontend::wp_footer() auf.

    Option B:
    Du bindest das Skript und das leere Tag mit der Home URL per Hand ein.
    So macht es das Plugin:
    https://github.com/pluginkollektiv/statify/blob/master/views/js-snippet.php

    Plugin URL musst natürlich fix angeben oder den Pfad zur statify.php mit übergeben, da plugins_url() dort sonst nichts sinnvolles tut. (fix: /wp-content/statify/js/snippet.js ).

    Gruß,
    Stefan

Viewing 15 replies - 106 through 120 (of 157 total)
1 2 3 … 7 8 9 10 11