Patrick Robrecht

Hallo,

wer die Statistiken sehen kann, kannst du mit einem Hook ?ndern: siehe https://de.www.ads-software.com/plugins/statify/#wie%20%C3%A4ndere%20ich%2C%20wer%20das%20dashboard%20widget%20sehen%20darf%3F

Viele Grü?e
Patrick

Hi axmann,

to count views per role, you’ll have to implement a filter similar to this one:

add_filter(
    'statify_skip_tracking',
    function() {
        if (in_array('administrator', wp_get_current_user()->roles)) {
            return true;
        }

        return false;
    }
);

You can put this in your theme’s functions.php or write a small plugin containing just the filter (recommended as theme updates won’t destroy your changes in this case).

In this example only non-administrator would be logged (as the view is not logged if the skip filter returns true). Note that the code is untested.

Regarding tracking private posts/pages: I think we don’t make a difference here. But by default, views by logged in users are not tracked – that’s why private posts/pages shouldn’t be tracked with the default settings. If you change the default tracking behavior, you can modify this.

Kind regards
Patrick

Hello Tobias,

when typing the beginning of a post title into the input field for the URL, you should see some suggestions. However, I created an issue at GitHub, such that improvements may be implemented in a future release.

Cheers,
Patrick

Hi Matthias,

sorry for the late reply. The problem with the missing source maps is fixed in version 2.6.0 released today.

SearchWP is closed source, so I cannot debug the conflict with that plugin. I assume that it also loads the chartist library which leads to the conflict. You may check in the source code of the pages provided by Statify – Extended Evaluation whether the chartist library is loaded twice.

Statify – Extended Evaluation only loads its assets on the Statify pages. If SearchWP did the same, the two plugins should be compatible.

Best regards
Patrick

Hi lkf_tanzt,

the plugin Statify – Extended Evaluation does not store any data. It uses the data from the Statify table and calculates the views for the charts.

If the Statify data is deleted (because it’s older than the storage period defined in Statify), it won’t be included in the stats anymore. The plugin offers a CSV export to store data permanently.

Cheers
Patrick

Hi,

generell ist Statify kompatibel mit Caching-Plugins, sofern das Tracking über JavaScript erfolgt. Enthalten die gecachten Dateien den JavaScript-Code von Statify?

Wenn nein, musst du dein Caching-Plugin entsprechend konfigurieren. Dabei kann dir ggf. die Dokumentation von Borlabs Cache helfen.

Viele Grü?e
Patrick

Just for the case someone has not noticed yet: The plugin is available on www.ads-software.com again.

Hi Matthias,

I can’t reproduce this behavior on my sites.

Could you add some additional details (WordPress version, Statify version, other plugins installed)?

Kind regards
Patrick

Hallo,

wenn die Option für JavaScript-Tracking nicht aktiv ist, ist im Quelltext nicht erkennbar, dass Statify installiert ist.

Trotzdem kann man natürlich https://example.com/wp-content/plugins/statify/js/snippet.js aufrufen – wenn es die URL gibt, ist Statify installiert. Dasselbe funktioniert bei fast allen Plugins, die JavaScript- oder CSS-Dateien mitliefern.

Hi Steve,

Statify stores its data in a table wp_statify (prefix may be different). If you delete all entries in this table, the stats are reset. The dashboard is cached for some minutes, after that you’ll see 0 views again.

Note that Statify has an option for deleting entries after some time (default: 14 days, this period can be changed in the dashboard).

Hi,

Statify stores one entry per page view. A cron job regularly deletes all entries older than the data saving period (default: 14 days, can be changed to any number of days in the configuration).

So the size of the database table wp_statify depends upon the number of page views and the period of data saving. However, 90 MB sounds quite much. You may check whether the cron job is running correctly:

a) Compare the oldest entry (found via a query on the database) with the period of data saving.

b) WP Crontrol helps to check registered cron jobs. There should be an cron event statify_cleanup executed once daily.

Cheers
Patrick

Hallo Thomas,

ich habe einmal geprüft, dass das JavaScript von Statify auf der o.g. Website richtig eingebunden ist. In der Netzwerkanalyse kann ich auch nachvollziehn, dass der Request füür das Tracking des Seitenaufrufs abgesendet wird (Statuscode der Antwort: 204) – sprich alles von au?en erkennbare funktioniert genauso wie es sein soll.

Die Statistiken im Dashboard werden für eine kurze Zeit gecacht. Du kannst aber auch in der Datenbank (Tabelle wp_statify, wobei du wp_ durch das Tabellenpr?fix deiner WordPress-Installation ersetzen musst) nachschauen, ob hier neue Eintr?ge hinzugefügt wurden.

Hello Fernanda,

if you haven’t changed the default behavior (using the hook statify__skip_tracking), Statify will not track views by logged in users (cp. Statify, FAQ section, 1st question).

Cheers
Patrick

Hi,
Statify l?scht die Daten nach ein x Tagen (den Aufbewahrungszeitraum kannst du in den Einstellungen ?ndern, Standard ist 14 Tage).

An die gel?schten Daten kommst du in dem du die entsprechenden Zeilen in Tabelle wp_statify (bzw. anderes Pr?fix als wp) aus einem Backup, das du ja sicherlich regelm??ig anfertigst, wieder hinzugefügst.

Viele Grü?e
Patrick

Hi Mandy,

you’ve enabled JavaScript tracking as I found

<div id="statify-js-snippet" style="display:none" data-home-url="/">

in the source code. This seems to lead to a conflict with the plugin optimizing the source code.

Just after the line above there should be something like

<script type="text/javascript"
        src="https:/yourdomain.de/wp-content/plugins/statify/js/snippet.js">
</script>

– that missing at most pages such that the tracking script is not executed.

On categories I found the script correctly installed such those views are counted correctly.

Cheers
Patrick