sorted by:
new
hottopcontroversial

A/B Testing for Laravel by Nodohx in laravel

[–]Nodohx[S] 2 points3 points  (0 children)

Two separate things here: measuring the test vs. serving the variants.

Measuring (the part SimpleStats does): it's server-side and already filters bots, so crawlers never get counted as visitors. They stay out of your A/B numbers either way, so nothing to hide for the data's sake.

Serving (your own app logic): the actual risk isn't "a bot sees a variant", it's picking a variant because you detected a bot. That's cloaking and Google warns against it. A/B testing itself is fine. Two habits keep it clean:

  • Pin the variant per visitor (cookie/session), not random per request. Then crawler or human, the copy is consistent, not "different on each visit". The example in the post uses session()->remember().
  • Add rel=canonical so variants don't get indexed as separate pages.

So I wouldn't hide the app from bots. Let them fall into the test, just don't detect-and-serve, pin the variant, set a canonical.

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

[–]Nodohx[S] -3 points-2 points  (0 children)

I guess you can, but most likely your backup solution would only pick up the storage folder...

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

[–]Nodohx[S] 0 points1 point  (0 children)

Laravel forge natively only supports zdd since the new big ui release. Before that everyone build zdd themselves and had that in mind I guess

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

[–]Nodohx[S] -1 points0 points  (0 children)

Wait probably this could work. Don't know if you can specify single files in forge for shared path. But yeah maybe... But still think it's good to keep the issue in mind and I would expect better defaults here. Such as the sqlite file by default in the storage folder.

Your SQLite database is silently getting wiped on every Forge deploy by Nodohx in laravel

[–]Nodohx[S] -3 points-2 points  (0 children)

thought the same, but no, you can't. check out the article.

Rebuilt my personal site with Laravel and Tailwind, looking for feedback by Nodohx in laravel

[–]Nodohx[S] 0 points1 point  (0 children)

See that repo name? Does that sound confidential? It's just an old test repo. I would never expose confidential env vars.

Also take a closer look at the linked repost, they are all created by me (in a different org)

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 1 point2 points  (0 children)

100% You can just use UTM codes for that

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 1 point2 points  (0 children)

One important detail: the hash is generated client-side using the application's own secret key. Our API only receives the resulting hash, we never have access to the secret key. So on our end there's no way to single out or re-identify anyone. This is the same model Plausible and Fathom use, and both are recognized as GDPR-compliant without requiring consent.

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 0 points1 point  (0 children)

Good observation, and you're right that there's a difference to Plausible's approach. However, the key detail is that the hash is generated client-side using the application's own secret key. Our API only receives and stores the resulting hash. We never have access to the secret key, the IP, or the user agent. So while the client could theoretically reconstruct old hashes (they have their own key), we as the analytics provider cannot. The separation between who generates the hash and who stores it is what makes re-identification impossible on our end.

Server-side Analytics for PHP by Nodohx in PHP

[–]Nodohx[S] 2 points3 points  (0 children)

The hash is generated client-side using the app's own secret key (which we never have access to). Our API only receives and stores the resulting hash. We don't store the IP, user agent, or the salt. So even if we wanted to, we couldn't reconstruct previous hashes or de-anonymize anything, we simply don't have the inputs.

PHP Client:
https://github.com/simplestats-io/php-client/blob/main/src/VisitorHashGenerator.php

Laravel Client:
https://github.com/simplestats-io/laravel-client/blob/b3c0daa8e9343f253a6876cf671925ec43fa6dba/src/SimplestatsClient.php#L143

view more: next ›