Stefan Kalscheuer

since last update to version 1.4.0 I get virus alert every day. […] When checking manually everything is shown as OK.

Seems to be an issue with the manual scan. I can reproduce it by provoking a virus warning (add risky code to a theme file) which is detected correctly in the cron execution, but not in the manual scan. (https://github.com/pluginkollektiv/antivirus/issues/88)

edit: should be fixed in the upcoming release (https://github.com/pluginkollektiv/antivirus/issues/89)

– files in child theme with same file name as in parent are not scanned
– files in child theme with different names (self created files) are scanned

Confirmed and – hopefully – fixed in the upcoming release (https://github.com/pluginkollektiv/antivirus/pull/86)

– files in child theme subfolders are scanned, but not all files and not all subfolders

That’s by design. The plugin collects theme files with a maximum depth of 1.

Please don’t ask me for the actual reason as I can only guess (at least since 1.3 (2015) and not documented). I’d be fine with raising the maximum depth to a more reasonable value.

Cheers,
Stefan

• This reply was modified 4 years, 2 months ago by Stefan Kalscheuer.

Thanks for your input and the possible solution!

Sounds like a reasonable change, so I’ll try to integrate with an upcoming release (https://github.com/stklcode/wp-liveticker/issues/14).

Cheers,
Stefan

Hallo Lorenz,

eine pauschale Antwort auf die Frage gibt es nicht. Da Statify Aufrufe protokolliert, h?ngt die Gr??e direkt von der Nutzerzahl ab.

Die Gr??e je Datensatz betr?gt 16-526 Byte (Target und Referrer URL variabel). Gerade einmal geschaut, im Schnitt 40 Byte reine Daten auf einer meiner Seiten oder total (mit Indizes, etc.) rund 500 KiB für 3000 Eintr?ge.

Daten skalieren linear, Index nicht, aber als Sch?tzwert denke ich gut genug.

Die Ladezeit für Besucher wird dadurch praktisch nicht beeinflusst. Die des Dashboard Widgets schon. Ob 300MB bei Komplettanzeige (ist ja separat anpassbar da spürbar ins Gewicht fallen h?ngt vom Server ab.

Gru?,
Stefan

Hi,

I hadn’t planned a dedicated update, because 1.5.1 seems to work fine with WP 5.5. Apparently I forgot about raising the compatibility tag, sorry for that.

Nevertheless, I’ve released v1.5.2 a few seconds ago with some minor internal corrections and explicit 5.5 compatibility.

The wording – starting from the plugin’s name “Statify Blacklist” – is not perfect, as the term “blacklist” is more or less replaced by more descriptive phrases in 5.5, but I’ll take care of that in near future. Functionality is given.

Cheers,
Stefan

Hi,

ich nehme an, dass JavaScript Tracking aktiviert ist.

Dann kann auf eurer Seite tats?chlich keine Spuren eines aktiven Statify Plugins erkennen. Installiert ist es wohl, die Skripte sind da, aber nicht eingebunden.

Ich habe den Verdacht, dass euer neues Theme keinen Aufruf von wp_footer() beinhaltet, kann das sein? In dieser Phase binden wir für JS-Tracking die notwendigen Ressourcen ein.

Falls ich damit richtig liege und das Einbinden keine Option ist, müsste die entsprechende Methode für Statify im Frontend (nicht Admin, AJAX, Cron, XML-RPC – um die übrigen Randf?lle kümmern wir uns selbst) manuell getriggert werden. Der Originalaufruf ist der folgende:
add_action( 'wp_footer', array( 'Statify_Frontend', 'wp_footer' ) );

Also entweder den Hook in eine ad?quate Phase h?ngen oder manuell Statify_Frontend::wp_footer() aufrufen.

Gru?,
Stefan

Hi,

@zodiac1978 is right, it only a UI issue here, functionality is given.

Statify only registers the actual cron action during cron execution. This has been the case since at least 1.4.0 when the project was ported to GitHub, so I can only guess the reason.

When you access the WP Control interface, you’re in a backend/admin request-cycle, not in a cron-cycle, so no action is registered and WP Control can’t see it. As soon as you click “run now” or whenever the a real cron task is running, Statify registers the action method and it gets executed when necessary.

Cheers,
Stefan

• This reply was modified 4 years, 6 months ago by Stefan Kalscheuer.

Hi,

zum einen k?nntest du den Speicher-Zeitraum in den Einstellungen (seit 1.7 unabh?ngig vom Anzeigezeitraum) auf eine entsprechende Anzahl Tage stellen, für den 01.08.2020 Stand heute (27.08.2020) also 27. Beim n?chsten Cron Aufruf (warten oder manuell ../wp-cron.php triggern) werden ?ltere Daten gel?scht. Danach kannst du die Zahl wieder beliebig hoch setzen.

Alternativ kannst du auch per SQL rangehen, wenn dir das zusagt:
DELETE FROM wp_statify WHERE created < '2020-08-01'
(Pr?fix und Datum nach Bedarf ersetzen)

Gru?,
Stefan

You’re welcome.

I personally wasn’t aware of these files or at least it wasn’t really on my mind until yesterday. I like the idea and opened a corresponding issue to maybe remove or allow disabling GZ-generation in future releases: https://github.com/pluginkollektiv/cachify/issues/197

Cheers,
Stefan

Hi,

actually the generation of gzipped files for HDD caching is not optional and hard-coded. Usage is optional though, as you can simply ignore these files and don’t have to do anything with them. So there is no option to control that feature. Only way to get around is removing line 166 from inc/cachify_hdd.class.php…

What is configurable is minification (remove empty lines and comments from HTML).

But you got a good point here. With native on-the-fly compression support in most Webservers the additional generation should be optional to reduce unnecessary overhead.

Cheers,
Stefan

Hallo Dieter,

darüber, wie diese URLs in den Suchindex geraten sind, l?sst sich leider nur mutma?en.

Bis Statify 1.6 wurden solche URLs tats?chlich zum Tracking genutzt, allerdings sollten diese auf die Home-URL der Seite zeigen, nicht auf eine Unterseite (also i.d.R. /?statify_referrer=...&statify_target=...) und liefern dann auch keine gültige Seite, sondern eine leere Antwort.
Bis 1.5 wurde dazu ein Pseudo-Element <script> eingebunden, danach erfolgte der Aufruf direkt aus dem JavaScript heraus. Aber eigentlich nie direkt durch einen Link oder Benutzeraufruf.

Seit 1.7 werden solche Aufrufe nicht mehr verarbeitet, entsprechend l?uft der ganz normale WordPress Zyklus durch (Ergebnis s.u.)

Vermutlich kamen hier diverse Punkte zusammen. Eine m?gliche Erkl?rung w?re, dass eine Seite, die vor dem Statify 1.7 Update bereits im Cache lag, solche (nicht mehr funktionierenden) Tracking-Aufrufe abgesetzt hat, die dann eine normale HTML Seite liefern. Eines der eingebunden Google Skripte k?nnte diesen Aufruf als gültig interpretiert haben (ist er ja auch) und entsprechend hat der Suchindex diese URL gelernt.
Ggf. kam noch ein Theme-Wechsel oder eine Umkonfiguration dazu, was die Seite 4 erkl?ren würde. Den Punkt finde ich aber hier eher zweitrangig.

Ich finde das sehr merkwürdig, da die URLs aufrufbar sind und eine Blogübersicht zeigen.

Dieser Teil ist tats?chlich das einzig nicht merkwürdige.
/page/<Nummer> ist ein Standardmechanismus von WordPress, der auf die entsprechende Seite der Blog-übersicht verweist. Bei vielen Themes, die die Standardmethodik zum Bl?ttern nicht nutzen – so wie deines – wird der zus?tzliche Parameter einfach ignoriert. Du kannst auch /page/99999 aufrufen. Statify hat hiermit nichts zu tun, der Parameter am Ende tut nichts.

Nach flüchtiger übersicht deiner Seite sieht das ganze eigentlich soweit gut aus und es sind keine Hinweise auf eine derartige URL oder ?hnliche überreste alter Statify-Verhalten auffindbar.

Gru?,
Stefan

You can fill the database yourself and migrate data from the other system. The model is quite simple, one row per visit.

Sample SQL (replace “wp“ if changed):
INSERT INTO wp_statify(created, referrer, target) VALUES ('2020-07-17', 'https://www.pluginkollektiv.org', '/some/page');

or if you prefer PHP with WP logic:

$wpdb->insert(
  $wpdb->statify,
  array(
    'created'  => '2020-07-17',
    'referrer' => 'https://www.pluginkollektiv.org',
    'target'   => '/some/page',
  )
);

Referrer and target optional, if only daily counts are of interest. If you have aggregates like date => count, you have to add that much entries.

Remember configuring an adequately long storage time, otherwise the data is cleaned up automatically ??

Cheers,
Stefan

Hi,

currently this is possible using a filter hook statify__user_can_see_stats (https://statify.pluginkollektiv.org/documentation/hooks/#user_can_see_stats)

You case would be something like the example from the docs:

add_filter(
    'statify__user_can_see_stats',
    current_user_can('edit_others_pages' )
);

A more convenient configuration is planned for next point release 1.8, however no ETA yet. (https://github.com/pluginkollektiv/statify/issues/106)

Cheers,
Stefan

Sch?n zu h?ren.
Das sieht soweit korrekt aus. Status 204 (“No Content”) ist beabsichtigt, da der Aufruf keinerlei Inhalt zurück übermittelt.
Die Information, ob der Aufruf gez?hlt oder gefiltert wurde wird nicht zurück gespiegelt, lediglich die Erkenntnis dass die Verarbeitung erfolgreich war. Im Fehlerfall gibt es entsprechende 4xx/5xx Status.

Joah… Ich zitiere aus dem WP Core Code: “This is the best attempt to reverse that operation into a local time to use.”

Der übergebene Zeitpunkt wird als UTC gesehen und der Offset (erneut) herausgerechnet. Meine Vermutung hier w?re, dass es von der System und/oder PHP-Zeitzone abh?ngt, was die Rechnung hier tut. Auf meinem lokalen Testsystem (alle Zeitzonen einheitlich Europe/Berlin) passt es. Im Container (System+PHP auf UTC, WP Berlin) verschiebt es sich nach vorne, was unkritisch ist. Aber eben so kann ein negativer Offset reinkommen, dann sind wir bei Uhrzeit 00:00:00 (wir speichern ja nur das Datum) eben einen Tag zurück.

Wir speichern hier bereits “lokale” Zeitstempel, d.h. die Zone interessiert uns bei der Ausgabe gar nicht mehr. Wir sollten also entweder alles als “UTC” ansehen oder Konversion g?nzlich ignorieren (z.B. gem?? Thorstens Vorschlag).

Gru?,
Stefan

Hi Peer,

you’re talking about the date shown in the tooltip of the rightmost chart entry, right?

Obvious question in advance: Is there data for “today” that could be shown?
If Statify didn’t count anything (correctly or by error), nothing can be displayed, as we do not fill gaps yet.

also after the 1.7.2 update […]

1.7.2 fixed the number days evaluated for the top lists, not the chart. However the fix only affected the oldest entry (e.g. with 14 days configured, “today – 14” had been evaluated, so 15 days in total).

The definition of “today” has changed in 1.7.0 though. Statify now only relies on the PHP server date where the database server date had been evaluated for the dashboard output before. Both times obviously don’t need to match for several reasons.

I cannot reproduce your issue on several test and live sites, all of them show 03.07.2020 (which is correct now at 09:50 CEST).

Is your WP date and time(zone) correct? (can easily be verified on the general settings page, all examples there are generated from current timestamp)

Cheers,
Stefan