v2.7.0 (Flarum 2.x)

Your forum loads faster: the Analytics window is now only downloaded when someone opens it.

Improvements

• Lighter forum pages. The Analytics window, opened from the user menu by members allowed to see statistics, used to be part of the code every forum page downloads, even for visitors who never see it. It now loads the moment someone opens Analytics, so every other page downloads about 6 KB less (compressed), which helps most on phones. The dashboard and the admin page work exactly as before.

After updating

Run php flarum cache:clear so your forum serves the rebuilt files instead of the copies it already has cached.

v2.6.0 (Flarum 2.x)

Birdseye now tells you when your statistics have stopped updating, and why.

Birdseye adds up each finished day in an hourly job on Flarum's scheduler. If that job never runs, today's numbers keep moving while every chart quietly stops at the last day it added, which looks like Birdseye losing your data.

• A notice at the top of the dashboard says which day the statistics stop at. It shows on the admin page and in the forum's Analytics window.
• If Flarum's scheduler isn't running, the notice says so and links to Flarum's guide to setting it up. This is the usual cause: the scheduler needs a cron job on your server.
• If the scheduler is running but the statistics still stopped, the notice says that instead, so you know to look in storage/logs for an error.

Birdseye keeps raw visits for 3 days. Once the scheduler is set up, run php flarum birdseye:sync to catch up on the days it missed.

After updating

Run php flarum cache:clear so your forum serves the rebuilt files instead of the copies it already has cached.

v2.5.0 (Flarum 2.x)

Visitor countries now work out of the box, with no database to download or set up yourself.

If you haven't set a country database file, Birdseye now downloads the free country database from DB-IP by itself and refreshes it once a month. Only the database file is downloaded: no visitor data leaves your server, and every country lookup still happens on your own forum.

• Nothing to configure. The world map and Countries card fill in from the next day processed, as long as Flarum's scheduler is running (Birdseye already needs it for its stats). To fetch the database right away instead of waiting for the next hourly check, run php flarum birdseye:country-database.
• Your own database still wins. If you've already set a MaxMind database file, Birdseye keeps using it and downloads nothing.
• You can turn it off with the new "Download a country database automatically" setting.
• If the download fails (some hosts block outgoing connections), the world map says so and shows the error, and Birdseye keeps whatever copy it already has. It tries again every few hours.
• If it hasn't run yet, the map tells you to check that the scheduler is running.
• The map shows a small "IP Geolocation by DB-IP" credit when DB-IP's database is in use, as its free licence requires.

After updating

Run php flarum cache:clear so your forum serves the rebuilt files instead of the copies it already has cached.

v2.4.1 (Flarum 2.x)

When country lookup isn't working, the world map now tells you why, instead of always saying "not configured".

Until now the map said "not configured" whenever no visitor countries could be found, even when a country database file was set but couldn't be used. That sent admins looking for a setting they had already filled in.

If the country database file is set but can't be used, the map now names the problem and how to fix it:

• The path isn't a full path. It needs to start with a slash, such as /home/you/geoip/GeoLite2-Country.mmdb.
• The path points at a folder, not the file inside it.
• There is no file at that path, or your host doesn't let PHP open files in that folder.
• PHP can't read the file. Permissions of 644 usually work.
• The file is still compressed. MaxMind's download is a .tar.gz archive; extract it and use the GeoLite2-Country.mmdb file inside.
• The file isn't a MaxMind database.

It also tells you when the database is fine but "Country lookup via anonymized IP prefix" is turned off, which means the database is never used.

The help text for the country database setting now gives an example path, and recommends keeping the file outside your public web folder (such as public_html) so it can't be downloaded from your site. The extension's page has a new step-by-step guide to setting up visitor countries.

Thanks to Tutrix for the report and SpikeNit for the suggestion.

After updating

Run php flarum cache:clear so your forum serves the rebuilt files instead of the copies it already has cached.

v2.4.0 (Flarum 2.x)

The world map and the Countries card now tell you when no visitor countries are being recorded, instead of drawing an empty map that looks exactly like a forum nobody has visited.

Birdseye reads a visitor's country from a trusted proxy header such as CF-IPCountry, or failing that from a local MaxMind country database. A forum with neither collects no country at all. That has been true for any forum not behind such a proxy since version 2.3.0 moved all processing onto your own server, and until now nothing on screen said so. Two admins reported the blank map as a bug, which was fair, because it was indistinguishable from one.

If you see the new notice, either set the country database file in the extension's settings, or point the trusted country header at whatever your proxy sends. Countries then appear from the next day processed onwards. Days that have already been summarised cannot be filled in afterwards, because the raw events behind them are deleted once their totals are written.

Nothing changes for a forum whose country lookup is already working, and a forum with too little recent traffic to judge is left alone rather than warned.

Thanks to Tutrix and SpikeNit for the reports.

After updating

Run php flarum cache:clear so your forum serves the rebuilt files instead of the copies it already has cached.

v2.3.3 (Flarum 2.x)

v2.3.3 — Permission keys move from linkrobins-birdseye.* to lr-birdseye.*. A migration renames your existing grants in place, so there is nothing to do after updating: every group keeps exactly the permissions it had.

Why: fof/links reads a link id out of any granted permission whose name starts with "link" and contains "view". On MySQL and MariaDB the mismatch was silently ignored; on PostgreSQL it failed every page for forums running both extensions. The new prefix cannot collide.

v2.3.2 (Flarum 2.x)

Fixes the weekly digest occasionally arriving twice.

The digest remembered the last week it sent by reading a marker at the start of the run and writing it at the end. Two scheduler runs starting at the same moment could both read the old marker and both send, so some admins received two identical digest emails moments apart. The send is now also protected by a lock, so when two runs race, exactly one sends and the other stands down. The protection works with Flarum's default setup and needs nothing configured.

Also new: php flarum birdseye:digest --dry-run lists exactly who a digest would be emailed to without sending anything. If you ever see what looks like a duplicate, run this first: two admin accounts whose addresses reach the same inbox looks identical to a double send from the receiving end.

One more safeguard: if two admin accounts share the same email address, the digest now sends that address a single copy.

Thanks to SpikeNIT for the report.

v2.3.1 (Flarum 2.x)

Fixed

• Statistics no longer stall on busy days. On forums with large daily traffic, the nightly rollup could run out of memory on a big day — and because the sync always retries the oldest day first, every following run failed on the same day: the "today" numbers kept working while nothing new reached the statistics. Days are now processed in a streaming pass that uses the same small amount of memory no matter how busy the day was. Reported on the extension thread; thank you.

If your statistics stopped: update, then run this once on your server — it immediately processes everything still in the 72-hour buffer:

php flarum birdseye:sync

Days older than 72 hours at the time you update were already pruned and cannot be recovered.

https://github.com/linkrobins/birdseye/releases/tag/v2.3.1

v1.7.1 (Flarum 1.8)

Birdseye on Flarum 1.8 is now free and standalone

Same change the Flarum 2.x line got: the license key, the subscription and the hosted processing are gone. Everything the paid tier computed — bounce rate, session length, top pages and discussions, referrer sources, devices, countries and the world map — is now computed on your own server, for everyone, and nothing ever leaves your forum. If you had a key, the update ignores it and cleans it up.

Fixed

• Statistics no longer stall on busy days. A day with enough traffic could exhaust memory during processing, and every later run then failed on the same day: today's numbers kept working while nothing new reached the statistics. Days now stream through with the same small memory footprint no matter how busy they were.

If your statistics stopped: update, then run this once — it immediately processes everything still in the 72-hour buffer (older days were already pruned and cannot be recovered):

php flarum birdseye:sync

This release includes a migration, so the full update is:

composer update linkrobins/birdseye
php flarum migrate
php flarum cache:clear

https://github.com/linkrobins/birdseye/releases/tag/v1.7.1

(Version note: v1.7.0 was mis-tagged from the wrong branch and contains Flarum 2.x code; it installs nowhere and should be ignored. This release, v1.7.1, is the real Flarum 1.8 release.)

v1.7.0 — MIS-TAGGED, use v1.7.1 (1.8) or v2.3.1 (2.x)

This tag was cut from the wrong branch and points at Flarum 2.x code under a 1.x version number. It installs nowhere (its composer constraints match no line correctly). The real releases: Flarum 1.8 → v1.7.1. Flarum 2.x → v2.3.1. The tag is immutable under the repository ruleset, so it stays; ignore it.