DEV Community: Benyamin Khalife

Make Your Buttons Dodge the Cursor with a Wrium Plugin

Benyamin Khalife — Sat, 03 Oct 2026 11:57:53 +0000

Most buttons just sit there and wait to be clicked. This one doesn't.

Wrium Evasive Button is a small plugin for Wrium that makes a button (or any interactive element) smoothly dodge the cursor when you get close. It's silly on purpose, but it turns out to be surprisingly useful.

Why would you want this?

Smart form validation: the submit button stays out of reach until the required fields are valid
Gamified forms and playful login screens
Interactive confirmations where the "wrong" choice is hard to click

What you get

Smooth, physics-style gliding along walls, with no teleporting or sticking at edges
Movement limited to the parent, the viewport, or any element you choose
Limits via maxRadius, duration, and maxAttempts, so the button eventually gives up and settles
Reactive toggling: v-evade="{ active: !isFormValid }"
State classes and attributes for styling: .is-evading, .is-settled, data-state
@evade, @settle, and @giveup events
Respects prefers-reduced-motion and keeps keyboard navigation working (Tab + Enter/Space)
Zero dependencies

Install

npm install @wrium/evasive-button

@wrium/wrium is a peer dependency, so install it too if you haven't already.

Basic usage

<div id="app">
    <button v-evade>Try to Click Me!</button>
</div>

<script type="module">
    import { createApp } from '@wrium/wrium';
    import { EvasiveButtonPlugin } from '@wrium/evasive-button';

    createApp(() => ({}))
        .use(EvasiveButtonPlugin)
        .mount('#app');
</script>

That's it. The button now runs away from your mouse.

The practical version: form validation

Bind active to your form state. While the form is invalid the button dodges, and once it's valid the button glides back home, ready to be clicked:

<div id="button-arena">
    <button
        v-evade="{ active: !isFormValid, bounds: '#button-arena', maxRadius: 150 }"
    >
        {{ isFormValid ? 'Log In' : 'Fill fields first!' }}
    </button>
</div>

You can also style it based on its state:

.login-btn.is-evading { background: #e11d48; }

A note on UX and accessibility

An evasive button is a fun UX trick, so use it with care. The plugin helps by respecting reduced-motion preferences, letting keyboard users submit normally, and giving up after a duration or number of attempts if you set those options. I'd still keep it for playful or low-stakes moments rather than critical flows.

Try it

Repo: github.com/wrium/evasive-button
Wrium: wrium.dev

It's MIT licensed, and the repo includes unit tests (Vitest) and end-to-end tests (Playwright). Issues and PRs are welcome. I'd love to see the creative ways you use it!

Real-Time Password Strength Checking for Wrium

Benyamin Khalife — Fri, 02 Oct 2026 10:57:02 +0000

We've all seen it: a signup form that happily accepts password123 and only complains after the server says no. Or worse, it doesn't complain at all.

I wanted a tiny, drop-in way to give users feedback while they type, so I built Wrium Password Strength, a plugin for Wrium.

What it does

It adds a single directive, v-password-strength, that checks a password on every input and tells you whether it's good enough. Under the hood it:

Blocks exact or substring matches against a common-password list
Flags sequential runs (abc, 123) and repeated characters (aaaa)
Scores character variety: lowercase, uppercase, digits, symbols

The plugin itself has zero dependencies. It only needs Wrium as a peer dependency.

Install

npm install @wrium/password-strength

@wrium/wrium is a peer dependency, so install it too if you haven't already.

Usage

import { createApp, ref } from '@wrium/wrium';
import { PasswordStrengthPlugin } from '@wrium/password-strength';

createApp(() => ({
    password: ref(''),
    strength: ref(null)
}))
    .use(PasswordStrengthPlugin, { minLength: 10, minScore: 'good' })
    .mount('#app');

Then use the directive in your template:

<input type="password" v-model="password" v-password-strength="strength" />
<p>Strength: {{ strength?.label }}</p>
<button :disabled="!strength?.valid">Submit</button>

On every keystroke the directive writes { label, valid, reasons } into your ref, so you can show a label, list hints, or disable the submit button.

Not using the directive?

The same logic is exported as a pure function with no DOM and no reactivity, handy for validating before a request:

import { assessPassword } from '@wrium/password-strength';

assessPassword('correcthorsebatterystaple');
// => { label: 'fair', valid: true, reasons: ['Mix letters, numbers, and symbols'] }

An honest note

The built-in blocklist is short. It catches the obvious offenders, but it's not a breach-database lookup. For high-stakes apps, pair it with a server-side check such as the Have I Been Pwned API. Think of this plugin as a fast, friendly first line of feedback, not your only line of defense.

Try it

Repo: github.com/wrium/password-strength
Wrium: wrium.dev

It's MIT licensed. Feedback, issues, and PRs are very welcome. If you try it, I'd love to hear how it goes!

Wrium: A Tiny Reactive JavaScript Library With No Build Step

Benyamin Khalife — Wed, 30 Sep 2026 11:56:43 +0000

Have you ever wanted a button that updates some text on a page, and ended up setting up a bundler, a compiler, and a folder full of config files?

I felt that way too. So I built Wrium, a small JavaScript library for making reactive user interfaces. You write normal HTML, add a few special attributes, and the page updates itself when your data changes.

Website: wrium.dev
GitHub: github.com/wrium/wrium
npm: @wrium/wrium

What is "reactive" anyway?

"Reactive" means one simple thing: when your data changes, the screen updates automatically.

Without reactivity, you write code like this:

count++;
document.querySelector('#count').textContent = count;

You have to change the data and update the page by hand. With a reactive library, you only change the data. The library updates the page for you.

Meet Wrium

Wrium is inspired by Vue. If you know Vue's ref, computed, v-if, or v-for, you will feel at home. But Wrium is much smaller and simpler:

Zero dependencies
No build step. Add a script tag and go.
About 10.9 KB for the whole core (minified)
TypeScript declarations included
MIT license

It is not trying to replace big frameworks. It is for the times when a big framework is too much.

Your first app in 20 lines

Here is a working counter. Save it as an HTML file and open it in a browser (use a local server, because ES modules need one).

<div id="app">
  <h1>{{ title }}</h1>
  <p>Current count: {{ count }}</p>
  <button @click="increment">+</button>
  <button @click="decrement">-</button>
</div>

<script type="module">
  import { createApp, ref } from '@wrium/wrium';

  createApp(() => {
    const title = ref('Counter App');
    const count = ref(0);

    const increment = () => count.value++;
    const decrement = () => count.value--;

    return { title, count, increment, decrement };
  }).mount('#app');
</script>

Here is what happens:

ref(0) creates a reactive box that holds the number 0.
{{ count }} in the HTML shows the value of that box.
When you click a button, count.value changes and the text on the page updates by itself.

There was no compiler and no bundler. It is just HTML and JavaScript.

The four building blocks

Wrium's reactivity is built on four functions.

ref holds a single value, such as a number, a string, or even an object.

const name = ref('John');
name.value = 'Jane'; // the page updates

reactive makes a whole object or array reactive, including nested properties.

const state = reactive({ user: { name: 'John' }, todos: [] });
state.user.name = 'Jane';   // reactive
state.todos.push('Learn');  // also reactive

computed creates a value that is calculated from other values. It only recalculates when something it depends on changes.

const first = ref('John');
const last = ref('Doe');
const fullName = computed(() => `${first.value} ${last.value}`);

watchEffect runs a function right away, then runs it again whenever the reactive values it uses change. You never have to list dependencies by hand.

watchEffect(() => {
  console.log('Count is:', count.value);
});

Templates: HTML that reacts

Wrium reads your HTML directly and understands the directives you already know from Vue:

<!-- Show or hide -->
<p v-if="score >= 90">Excellent!</p>
<p v-else>Keep trying!</p>

<!-- Repeat -->
<li v-for="item in items" :key="item.id">{{ item.name }}</li>

<!-- Two-way binding for inputs -->
<input v-model="username" />

<!-- Events, with modifiers -->
<form @submit.prevent="save">...</form>
<input @keyup.enter="submit" />

<!-- Bind attributes and classes -->
<button :disabled="isLoading" :class="{ active: isActive }">Save</button>

Supported directives include v-if, v-else-if, v-else, v-for, v-model, v-show, v-text, v-bind (:), and v-on (@).

A real example: a Todo list

Every framework needs a Todo list example, so here is Wrium's:

<div id="app">
  <input v-model="newTodo" @keyup.enter="addTodo" placeholder="Add todo" />
  <button @click="addTodo">Add</button>

  <ul>
    <li v-for="todo in todos" :key="todo.id">
      <span :class="{ done: todo.done }">{{ todo.text }}</span>
      <button @click="removeTodo(todo.id)">×</button>
    </li>
  </ul>

  <p>{{ remaining }} of {{ todos.length }} remaining</p>
</div>

<script type="module">
  import { createApp, ref, reactive, computed } from '@wrium/wrium';

  createApp(() => {
    const newTodo = ref('');
    const todos = reactive([]);
    const remaining = computed(() => todos.filter(t => !t.done).length);

    function addTodo() {
      if (!newTodo.value.trim()) return;
      todos.push({ id: Date.now(), text: newTodo.value, done: false });
      newTodo.value = '';
    }

    function removeTodo(id) {
      const i = todos.findIndex(t => t.id === id);
      if (i > -1) todos.splice(i, 1);
    }

    return { newTodo, todos, remaining, addTodo, removeTodo };
  }).mount('#app');
</script>

State, list rendering, a computed counter, and event handling, all in one small file.

Components

You can reuse markup with app.component():

app.component('todo-item', {
  template: '<li :class="{ done }">{{ text }}</li>'
});

<todo-item v-for="t in todos" :key="t.id" :text="t.text" :done="t.done"></todo-item>

Every attribute on the tag becomes a prop, and props stay in sync with the parent when you bind them with :.

Plugins: add your own directives

Wrium's built-in directives are registered the same way plugins register theirs. Built-ins get no special treatment. Here is a tiny plugin that adds a v-focus directive:

const FocusPlugin = {
  install(api) {
    api.directive('focus', (el) => {
      setTimeout(() => el.focus(), 0);
    });
  }
};

createApp(() => ({})).use(FocusPlugin).mount('#app');

Some features ship as optional plugins instead of core. For example, v-html is opt-in because inserting raw HTML can cause XSS problems if you use untrusted content. Wrium makes you choose it on purpose. There are also plugins for password strength checking and for draggable elements.

Honest limitations

Wrium is young, and I would rather tell you now than surprise you later:

Directives, components, and hooks are global, not scoped per app instance.
There are no slots and no dedicated emit. A function passed as a prop does that job.
reactive() does not handle Map and Set specially yet.
It needs Proxy support, so there is no Internet Explorer.

When should you use Wrium?

A good fit:

Small interactive widgets on an existing page
Prototypes and demos
Learning how reactivity works, since the library is small enough to read
Projects where you really do not want a build step

Probably not the best fit:

Large apps that need routing, state management, SSR, and a big ecosystem. Use Vue, React, or Svelte there.

Try it

npm install @wrium/wrium

Or read the docs at wrium.dev.

Wrium started as an experiment called Zog.js, and it just reached v1.0.0. If you try it, I would love to hear your feedback. Open an issue, send a PR, or drop a star on GitHub. And tell me in the comments: what is the smallest thing you would build with it?

What Is Vibe Coding? The Real Pros and Cons

Benyamin Khalife — Thu, 17 Sep 2026 13:08:08 +0000

Thanks to the rise of AI coding tools, vibe coding has become one of the most talked-about ideas in software development. The basic idea is simple: describe what you want in natural language, let an AI generate the code, and iterate based on the result.

That can feel almost magical. You can build a website, a prototype, or even a small application without writing every line of code yourself.

But there is an important distinction: using AI to write code is not automatically vibe coding.

The term was introduced by Andrej Karpathy in February 2025 to describe a much more hands-off approach, where the developer relies heavily on AI-generated code, often without reading or fully understanding what was produced.

That distinction matters because AI-assisted development can be extremely useful. The real question is what happens when you rely on the same approach for a product that has real users, real money, and real consequences.

Where Vibe Coding Actually Works

Vibe coding isn't inherently bad. In the right context, it can be extremely effective.

It works particularly well for:

Building a quick prototype to test an idea
Creating a proof of concept before committing serious resources
Small personal tools with no sensitive data and few users
Experimenting with unfamiliar technologies
Learning basic programming concepts and software development workflows

For these use cases, speed is often more important than long-term maintainability.

If a weekend project breaks six months later, that may not matter.

The problem begins when the same approach is used to build the actual product a business depends on.

Why It Becomes Risky for Startups and Business Sites

A production application has requirements that go far beyond "does the page work?"

It needs proper authentication and authorization, secure handling of secrets, database access controls, input validation, error handling, logging, testing, backups, monitoring, and a codebase that someone can maintain six months from now.

AI coding tools can generate functional implementations very quickly, but functional code is not the same thing as secure or maintainable software.

An AI-generated application may work perfectly during a demo while still containing problems that only appear with real users: authorization mistakes, exposed credentials, unsafe assumptions, missing edge cases, weak database rules, or fragile integrations.

The bigger issue is often not the AI itself. It's the lack of technical understanding behind the person deploying the result.

When the person building the product doesn't understand the architecture, debugging becomes difficult. Fixing one problem can also introduce another because nobody has a clear mental model of how the system actually works.

That creates a dangerous maintenance cycle: the application grows, the code becomes harder to understand, and every new change becomes more dependent on the AI that created it.

Two Real-World Examples

1. Enrichlead

One widely discussed example involved Enrichlead, a SaaS product built by its founder using Cursor with no handwritten code.

Shortly after launch, the founder reported that the application was being abused: API usage was being consumed, users were bypassing the subscription system, and unwanted data was being created in the database. He also explained that he wasn't technical, which made diagnosing the problems much harder.

The important lesson isn't that AI "failed."

The system did what it was asked to do: it produced something that worked.

The missing part was the engineering judgment required to answer questions such as:

Is authentication enforced on the server?
Can a user modify client-side values to unlock paid functionality?
Where are API keys stored?
What happens when someone deliberately abuses the application?
What protections exist around database writes?

These are software engineering and security questions, not just coding questions.

2. A CMS That Was Never Actually Connected

A quieter example comes from developer Dominik Gronkiewicz, who described taking over a project built by a previous team.

The website looked finished: clean design, smooth animations, and all the expected pages.

But under the hood, a Sanity CMS subscription had been paid for months without actually being connected to the website. Headlines, team biographies, and other content were hardcoded directly inside JSX components, leaving the client unable to edit even a single sentence without a developer.

This is a different kind of failure.

Nothing was necessarily "broken" from a visual perspective. The site worked.

But the architecture did not match the business requirement.

A CMS exists so non-developers can manage content. Paying for a CMS and then hardcoding all the content defeats its purpose.

This is exactly the kind of problem that can be missed when the goal is simply to make the application look finished.

The Maintenance Problem Is Often Bigger Than the Initial Build

One of the biggest advantages of vibe coding is also one of its biggest weaknesses: you can create a lot of software before you fully understand what you created.

That is fine for experimentation.

It becomes expensive when the application needs continuous development.

Eventually, someone has to answer questions like:

Why is this request slow?
Why can this user access that data?
Why did this deployment break another feature?
Which package is responsible for this behavior?
Where is this secret being used?
How should this database change be migrated safely?
What happens when traffic increases tenfold?

At that point, the question is no longer "Can AI build this?"

The question becomes "Does someone understand the system well enough to operate and evolve it?"

Why Experienced Developers Still Matter

A professional developer does much more than write syntax.

They make architectural decisions, think about security, understand trade-offs, design for maintainability, test failure scenarios, review dependencies, debug production problems, and plan for the future.

That doesn't mean experienced developers should avoid AI.

Quite the opposite.

AI can be a powerful development tool when it is used as an accelerator rather than as a replacement for engineering judgment.

There is a major difference between:

"AI wrote the code, so I trust it."

and:

"AI wrote most of the code, and I understand, test, review, and take responsibility for what ships."

The second approach is much closer to modern AI-assisted software development than pure vibe coding.

The Bottom Line

Vibe coding is excellent for exploring ideas, building prototypes, and creating small projects quickly.

For production systems, the risks increase significantly when nobody involved fully understands the generated code and architecture.

The real issue isn't whether AI wrote the code.

The real issue is who is responsible for understanding the system, securing it, maintaining it, and fixing it when something goes wrong.

For a startup or business website, AI can absolutely be part of that process. But it shouldn't be the only engineer in the room.

At Webrium, we use modern development tools, including AI, to speed up development while keeping architecture, security, maintainability, and human review at the center of the process.

If you're building something real and want a second pair of experienced eyes on it, feel free to reach out — benjamindev365@gmail.com. (I'm also the developer behind webrium.dev, if you want to see what I build.)

xZeroProtect: A Free WordPress Firewall That Also Tells You Who Your Real Visitors Are

Benyamin Khalife — Mon, 13 Jul 2026 08:07:39 +0000

If you run a WordPress site, your access logs are probably full of noise: scanners poking at wp-login.php, bots requesting .env files that don't exist, and crawlers with fake user-agents pretending to be Googlebot. Most security plugins block some of this, but very few use that same detection layer to give you cleaner analytics.

That's the idea behind xZeroProtect, a free, open-source WordPress plugin I just released.

🔗 Plugin: https://wordpress.org/plugins/xzeroprotect/
🔗 Firewall library: https://github.com/webrium/xzeroprotect
🔗 Plugin source: https://github.com/webrium/xzeroprotect-wp

The idea

I started by building a standalone, dependency-free PHP firewall library (xzeroprotect) — no Redis, no external services, everything file-based. Once it could reliably tell a real visitor from a bot, it made sense to go one step further: use that same signal to power visitor analytics that are already clean, instead of bolting a stats plugin on top of unfiltered traffic.

So the WordPress plugin does two jobs with one pass:

Firewall — blocks the request if it looks malicious.
Analytics — if the request passes every check, it gets recorded as a real visit.

Nothing that looks like a bot ever makes it into your stats.

What it actually blocks

SQL injection, XSS, path traversal, LFI/RFI, and command injection patterns in GET/POST/cookies
Known scanner and exploit-tool user-agents (sqlmap, nikto, nmap, masscan, and more)
Requests to sensitive paths (.env, .git, phpmyadmin, wp-config, common webshell names, etc.)
Repeat offenders, via a sliding-window rate limiter with automatic (and escalating) IP bans

One detail I'm fairly happy with is crawler verification: instead of trusting the User-Agent header (which anyone can fake), Googlebot/Bingbot/etc. are verified with double-DNS lookup — reverse-resolve the visitor's IP, check the hostname matches the expected suffix (e.g. .googlebot.com), then forward-resolve that hostname again and confirm it matches the original IP. This is the method Google and Bing themselves recommend, and it means legitimate crawlers are never accidentally rate-limited or banned.

There's also an optional Apache integration: permanently banned IPs get synced into .htaccess, so Apache rejects them before PHP even starts.

The dashboard

Once it's running, the plugin gives you:

A traffic chart (visits / unique visitors / blocked requests) over 7, 14, or 30 days
Top pages by hits and unique visitors
Device breakdown (desktop / mobile / tablet)
A breakdown of why things got blocked
A real-visitor log with browser, OS, and device detail
A blocked-request log with attack type and reason

Visitor uniqueness is tracked with a daily-resetting SHA-256 fingerprint (IP + user-agent + date), so raw IPs aren't stored in the fingerprint itself.

Getting started

Plugins → Add New → search "xZeroProtect" → Install → Activate

By default it runs in Production mode (block + log), but there's also a Learning mode that only logs what would be blocked — useful for a few days of tuning before you flip it live. WordPress core paths (/wp-admin, /wp-login.php, /wp-json) are always whitelisted, so there's no risk of locking yourself out.

Requirements: WordPress 6.0+, PHP 8.0+, MySQL 5.7+ / MariaDB 10.3+. No Redis, no external API calls, no cloud dependency — everything runs on your own server and database.

Why I'm sharing it

It's brand new, completely free, and MIT-licensed — both the plugin and the underlying PHP library are open source, so you can read exactly what it's doing or reuse the firewall library in any PHP 8 project, WordPress or not.

If you try it, I'd genuinely appreciate feedback, bug reports, or feature ideas — either on the WordPress.org support forum or as a GitHub issue.

Built by Webrium. MIT licensed.

Building Lightweight PHP Microservices with webrium/core — No Framework Bloat Required

Benyamin Khalife — Mon, 15 Jun 2026 09:56:01 +0000

Do you really need a full framework to handle a few API endpoints or webhooks?

Laravel and Symfony are excellent tools — for large applications. But when you're building a focused microservice, a webhook receiver, or a lightweight REST API, bootstrapping a full-stack framework means carrying hundreds of files, a massive autoloader, and a dependency tree you'll never fully use.

That's the problem webrium/core was built to solve: a minimalist, zero-dependency PHP micro-framework written entirely from scratch, designed to stay out of your way.

Installation

composer require webrium/core

That's it. No configuration files to publish, no service providers to register.

The Entry Point

Every webrium application starts with the same three lines:

<?php
require_once __DIR__ . '/vendor/autoload.php';

use Webrium\App;
use Webrium\Route;

App::initialize(__DIR__);

// ... your routes here

App::run();

App::initialize() sets the root path and loads the global helper functions. App::run() initializes error handling and dispatches the current request through the router.

Routing

The router supports all standard HTTP methods. Route handlers can be closures, a Controller@method string, or an [Controller::class, 'method'] array.

Basic routes:

Route::get('/status', fn() => ['status' => 'alive']);

Route::post('/items', fn() => ['created' => true]);

Route::put('/items/{id}', fn($id) => ['updated' => $id]);

Route::patch('/items/{id}', fn($id) => ['patched' => $id]);

Route::delete('/items/{id}', fn($id) => ['deleted' => $id]);

Route handlers return an array — the framework automatically encodes it as JSON and sends the correct Content-Type header.

Dynamic parameters:

Route::get('/users/{id}/posts/{postId}', function($id, $postId) {
    return [
        'user_id' => $id,
        'post_id' => $postId,
    ];
});

Named routes:

Route::get('/users/{id}', fn($id) => ['id' => $id])->name('users.show');

// Generate the URL elsewhere:
$url = route('users.show', ['id' => 42]); // /users/42

Route groups let you share a prefix and/or middleware across multiple routes:

Route::group(['prefix' => 'api/v1', 'middleware' => 'AuthMiddleware'], function() {
    Route::get('/profile',  fn() => ['user' => 'James Carter']);
    Route::post('/profile', fn() => ['updated' => true]);
});

Custom 404 handler:

Route::setNotFoundHandler(fn() => ['error' => 'Route not found', 'code' => 404]);

Reading Request Input

The global input() helper reads from $_GET on GET requests and from the request body on POST, PUT, PATCH, and DELETE. It handles both application/json and application/x-www-form-urlencoded automatically.

Route::post('/search', function() {
    $query  = input('q', '');
    $limit  = input('limit', 20);

    return ['query' => $query, 'limit' => $limit];
});

Pass null (or call input() with no arguments) to get the full input array:

Route::post('/echo', fn() => input());

Validation

The Validator class uses a fluent interface. Pass the input array to its constructor, chain your rules, then call isValid(), passes(), or fails().

use Webrium\Validator;

Route::post('/register', function() {
    $v = new Validator(input());

    $v->field('name', 'Full Name')->required()->string()->min(2)->max(50);
    $v->field('email', 'Email')->required()->email();
    $v->field('password', 'Password')->required()->min(8);
    $v->field('password_confirmation')->required()->confirmed('password');

    if ($v->fails()) {
        return respond(['errors' => $v->getErrors()], 422);
    }

    // proceed with registration...
    return ['success' => true, 'message' => 'Account created.'];
});

Available rules include: required, string, integer, numeric, boolean, email, min, max, confirmed, different, in, notIn, regex, date, json, array, nullable, and sometimes.

JWT Authentication

The Jwt class handles token generation and verification with HS256, HS384, and HS512. Signature verification uses hash_equals internally to prevent timing attacks.

use Webrium\Jwt;

$jwt = new Jwt('your-secret-key', 'HS256');

// Generate a token
$token = $jwt->generateToken([
    'sub'  => 42,
    'role' => 'admin',
    'exp'  => time() + 3600,
]);

// Verify and decode
$payload = $jwt->verifyToken($token);

if ($payload === null) {
    return respond(['error' => 'Invalid or expired token.'], 401);
}

return ['user_id' => $payload['sub']];

You can also read the payload without verification (useful for debugging):

$payload = Jwt::getPayload($token);

Password Hashing

The Hash class wraps PHP's password_hash and password_verify with sensible defaults and supports bcrypt, Argon2i, and Argon2id.

use Webrium\Hash;

// Hash a password (bcrypt by default)
$hashed = Hash::make('secret-password');

// Verify
$isValid = Hash::check('secret-password', $hashed); // true

// Argon2id
$hashed = Hash::argon2id('secret-password');

// Generate a secure random token
$token = Hash::token(64);

// Generate a UUID v4
$uuid = Hash::uuid();

Middleware

Middleware can be a closure, a global function, a Class@method string, or a class with a handle() method that returns a boolean. A falsy return blocks the request with a 403.

// Closure middleware
$authCheck = function() {
    $header = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
    return str_starts_with($header, 'Bearer ');
};

Route::group(['prefix' => 'api/v1', 'middleware' => $authCheck], function() {
    Route::get('/me', fn() => ['user' => 'James Carter']);
});

Class-based middleware:

class AuthMiddleware
{
    public function handle(): bool
    {
        $jwt     = new Webrium\Jwt('your-secret-key');
        $header  = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
        $token   = str_replace('Bearer ', '', $header);

        return $jwt->verifyToken($token) !== null;
    }
}

Route::group(['middleware' => 'AuthMiddleware'], function() {
    Route::get('/dashboard', fn() => ['data' => '...']);
});

CORS

CORS is handled at the application level with a single call before App::run().

App::enableCors(['https://app.example.com', 'https://admin.example.com']);

App::run();

For stricter control:

App::configureCors([
    'allowed_origins'   => ['https://app.example.com'],
    'allowed_methods'   => ['GET', 'POST', 'PUT', 'DELETE'],
    'allow_credentials' => true,
]);

Putting It All Together

Here is a minimal but complete authenticated REST API — health check, public registration, and a protected profile endpoint — in a single file:

<?php
require_once __DIR__ . '/vendor/autoload.php';

use Webrium\App;
use Webrium\Route;
use Webrium\Validator;
use Webrium\Hash;
use Webrium\Jwt;

App::initialize(__DIR__);
App::enableCors(['https://app.example.com']);

$jwt = new Jwt('super-secret-key');

// Health check
Route::get('/', fn() => ['status' => 'alive']);

// Public: register
Route::post('/register', function() {
    $v = new Validator(input());
    $v->field('email')->required()->email();
    $v->field('password')->required()->min(8);

    if ($v->fails()) {
        return respond(['errors' => $v->getErrors()], 422);
    }

    $hashed = Hash::make(input('password'));

    // save user to DB...

    return respond(['message' => 'Account created.'], 201);
});

// Public: login
Route::post('/login', function() use ($jwt) {
    $email    = input('email', '');
    $password = input('password', '');

    // fetch user from DB and verify password...
    $user         = ['id' => 1, 'email' => $email, 'hashed' => Hash::make('demo')];
    $passwordValid = Hash::check($password, $user['hashed']);

    if (!$passwordValid) {
        return respond(['error' => 'Invalid credentials.'], 401);
    }

    $token = $jwt->generateToken(['sub' => $user['id'], 'exp' => time() + 3600]);

    return ['token' => $token];
});

// Protected routes
$authMiddleware = function() use ($jwt) {
    $header = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
    $token  = str_replace('Bearer ', '', $header);
    return $jwt->verifyToken($token) !== null;
};

Route::group(['prefix' => 'api', 'middleware' => $authMiddleware], function() use ($jwt) {
    Route::get('/profile', function() use ($jwt) {
        $token   = str_replace('Bearer ', '', $_SERVER['HTTP_AUTHORIZATION'] ?? '');
        $payload = $jwt->verifyToken($token);
        return ['user_id' => $payload['sub']];
    });
});

App::run();

A complete, production-ready authenticated API service. No generated boilerplate, no hidden magic — just PHP.

webrium/core is a good fit when:

You're building a webhook receiver or a focused REST API
You need minimal cold-start time (serverless, edge environments)
You want zero third-party runtime dependencies
You're prototyping quickly and don't want framework overhead

It is not a replacement for a full-stack framework when you need an ORM,
a template engine, queue workers, or a large ecosystem of packages.

If you need all of that — but still want to stay in the Webrium ecosystem —
webrium/webrium is the full-stack
version, built on top of this same core. It ships with
FoxDB as its ORM and includes a
dedicated template engine. Same philosophy, full feature set.

Source Code

The project is open source and available on GitHub:

github.com/webrium/core

Contributions, issues, and feedback are welcome.

How I Stopped Counting Bots as Visitors

Benyamin Khalife — Mon, 08 Jun 2026 17:22:08 +0000

A few months ago I was looking at the analytics on one of my projects. The numbers looked decent — hundreds of daily visits, decent traffic from search. But something felt off. The server logs told a completely different story.

Half of those "visitors" were scanners probing for .env files. A quarter were bots hammering /wp-login.php. Maybe ten percent were actual humans.

Google Analytics had no idea. It was counting everything.

That's the problem I wanted to fix.

The gap nobody talks about

Every analytics tool I know of works the same way: a JavaScript snippet fires when a page loads, and the visit gets counted. The problem is that bots, scrapers, and scanners don't run JavaScript — but they still hit your server, and your server-side analytics still records them.

Some tools try to filter bot traffic after the fact, using lists of known bot user-agents or behavioral heuristics. But these lists are always behind, always incomplete, and never aware of the specific threats targeting your application.

I already had a firewall — xZeroProtect — running on my projects. It was blocking scanners, rate-limiting aggressive IPs, and verifying crawlers via double-DNS. It knew, with high confidence, which requests were real humans.

The insight was simple: if the firewall already knows who's a real visitor, why not record that?

How it works

In xZeroProtect, every request passes through a chain of checks before it reaches your application:

Incoming request
       │
  Whitelisted? ──────────────────────────► Pass through
  Verified crawler (Googlebot etc.)? ────► Pass through  
  Banned IP? ────────────────────────────► Block
  Rate limit exceeded? ──────────────────► Block
  Suspicious path? ──────────────────────► Block
  Bad User-Agent? ────────────────────────► Block
  Payload attack (SQLi, XSS...)? ─────────► Block
       │
  All checks passed ─────────────────────► Real visit ✓

Any request that reaches the bottom has survived every check. That's the right moment to record a visit — not before, not after.

The API is intentionally simple. You pass a closure to enableTracking(), and it fires for every verified real visit:

use Webrium\XZeroProtect\XZeroProtect;
use Webrium\XZeroProtect\VisitInfo;

$firewall = XZeroProtect::init();

$firewall->enableTracking(function (VisitInfo $visit) {
    // store however you like — the library doesn't care
    $pdo->prepare("INSERT INTO visits ...")
        ->execute($visit->toArray());
});

$firewall->run();

The library never touches your database. It hands you a VisitInfo object and gets out of the way.

What VisitInfo gives you

The $visit object carries everything you need, parsed and ready:

$visit->ip              // '94.182.11.42'
$visit->path            // '/blog/my-post'
$visit->method          // 'GET'
$visit->referer         // 'https://google.com'
$visit->timestamp       // 1749388800
$visit->date()          // '2026-06-08 14:30:00'

// Device info — parsed from User-Agent, no external service
$visit->device->browser         // 'Chrome'
$visit->device->browserVersion  // '124.0'
$visit->device->os              // 'Windows'
$visit->device->osVersion       // '10/11'
$visit->device->type            // 'desktop' | 'mobile' | 'tablet'
$visit->device->isMobile        // false

// Unique visitor fingerprint
$visit->fingerprint     // 'a3f8c2...' (64-char SHA-256 hash)

// Flat array — ready for a direct DB insert
$visit->toArray()

The device detection is built in — no third-party service, no API call, just a User-Agent parser that covers Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, IE, and all major operating systems.

The fingerprint

This is the part I'm most happy with.

Traditional unique visitor tracking either uses cookies (which require consent banners and get cleared) or stores raw IPs (which is a privacy problem). I wanted something in between.

The fingerprint is a SHA-256 hash of three things: the visitor's IP address, their User-Agent string, and today's date.

$raw = implode('|', [
    $request->ip,
    $request->userAgent,
    date('Y-m-d'),   // resets daily
]);

$fingerprint = hash('sha256', $raw);

This means:

The same person visiting twice today gets the same fingerprint — you can deduplicate
Tomorrow their fingerprint is different — no persistent cross-session tracking
The raw IP is not stored in the fingerprint — it cannot be reversed
No cookies, no JavaScript, no consent required

It's not perfect — two people on the same NAT with the same browser will collide — but for the purpose of counting unique daily visitors it's good enough, and it respects privacy by design.

Counting unique visitors becomes a simple query:

$firewall->enableTracking(function (VisitInfo $visit) use ($pdo) {
    // Only record the first visit of the day for each fingerprint
    $seen = $pdo->prepare(
        "SELECT 1 FROM visits 
         WHERE fingerprint = ? AND DATE(visited_at) = CURDATE()"
    )->execute([$visit->fingerprint])->fetchColumn();

    if (!$seen) {
        $pdo->prepare("INSERT INTO visits ...")
            ->execute($visit->toArray());
    }
});

Why opt-in, and why a closure?

Two deliberate design decisions worth explaining.

Opt-in: Tracking is disabled by default. You call enableTracking() to turn it on. This keeps the library's core purpose — protecting your application — separate from the analytics concern. If you don't need tracking, you pay zero cost for it.

Closure instead of configuration: I could have designed this as a config option with a built-in storage backend. But that would mean the library needs to know about your database, your schema, your connection. Instead, you own the storage completely. Want to write to MySQL? Redis? A log file? A third-party analytics API? The library doesn't care.

// Write to database
$firewall->enableTracking(fn(VisitInfo $v) => $db->insert('visits', $v->toArray()));

// Write to a log file
$firewall->enableTracking(fn(VisitInfo $v) => 
    file_put_contents('/var/log/visits.log', json_encode($v->toArray()) . "\n", FILE_APPEND)
);

// Send to an external service
$firewall->enableTracking(fn(VisitInfo $v) => 
    Http::post('https://my-analytics.example.com/ingest', $v->toArray())
);

Same API, any storage.

Errors never reach your visitors

One more thing: the callback runs inside a try/catch.

private function recordVisit(Request $request): void
{
    if (!$this->trackingEnabled || $this->visitorCallback === null) {
        return;
    }

    try {
        ($this->visitorCallback)(new VisitInfo($request));
    } catch (\Throwable) {
        // Tracking must never crash the application
    }
}

If your database is down, if your callback throws, if anything goes wrong — the visitor still sees your page. Tracking is infrastructure, and infrastructure fails. The firewall's job is to protect your application; it shouldn't become a new point of failure.

The result

After running this for a while, the difference is striking. My "real" visitor count is about 40% of what Google Analytics was reporting. The other 60% was noise — bots, scanners, crawlers, and monitoring tools that JavaScript analytics was happily counting as humans.

The data is smaller, but it's accurate. And because the firewall is already running, there's no extra overhead — the tracking happens as a side effect of protection that was already in place.

If you want to try it:

composer require webrium/xzeroprotect

The full API reference and configuration docs are on GitHub. There's also a WordPress plugin if you want the dashboard out of the box.

xZeroProtect 1.1.1 — Smarter Defaults, Cleaner Rules, Real Visitor Tracking

Benyamin Khalife — Sun, 07 Jun 2026 19:11:25 +0000

After using xZeroProtect across several projects, I kept running into the same friction points — default rules that blocked legitimate API clients, a .php extension rule that silently broke non-routed apps, and an auto-ban threshold that was a little too eager. Version 1.1.1 fixes all of that, and adds something new.

What is xZeroProtect?

A lightweight, file-based PHP 8 firewall library. No database, no Redis, no external service. Drop it into any PHP project, call run(), and it handles the rest — rate limiting, IP banning, payload scanning, bot detection, and crawler verification.

composer require webrium/xzeroprotect

use Webrium\XZeroProtect\XZeroProtect;

$firewall = XZeroProtect::init();
$firewall->run();

That's the whole setup for most projects.

What changed in 1.1.1

Smarter default blocked agents

The previous release blocked curl/, wget/, python-requests, and go-http-client out of the box. That made sense for public-facing websites, but caused real problems for anyone exposing an API — every legitimate client using those libraries got blocked on install.

These four are no longer in the default list. If your site doesn't serve an API and you want to block them, it's one line:

$firewall->patterns->addAgent('curl/');
$firewall->patterns->addAgent('wget/');
$firewall->patterns->addAgent('python-requests');
$firewall->patterns->addAgent('go-http-client');

libwww-perl and lwp-trivial are still blocked by default — there's no modern legitimate use case for those.

`.php` extension no longer blocked by default

The old default blocked any URL containing .php. The intention was good — modern routed applications (Laravel, Symfony, Slim) have no public .php files, so blocking the extension stops a lot of scanner noise.

The problem: anyone running a traditional PHP app, or a CMS like WordPress, would have all their pages blocked immediately after installation.

.php is now opt-in:

// Only add this if your app uses modern routing
// and no public .php files exist
$firewall->patterns->addPath('.php');

Auto-ban threshold raised from 5 to 10

The previous threshold of 5 violations before a ban was aggressive. A real user hitting a few 404s, a misconfigured uptime monitor, or a developer testing locally could end up banned for 24 hours.

The new default is 10 — still firm enough to catch actual scanners and brute-force attempts, but with enough room to avoid false positives on legitimate traffic.

New: `VisitInfo` and real visitor tracking

This release introduces opt-in visitor tracking. After all firewall checks pass, you can record the visit — and since the firewall has already filtered out bots and scanners, what gets recorded is real human traffic.

use Webrium\XZeroProtect\VisitInfo;

$firewall->enableTracking(function (VisitInfo $visit) {
    // Store however you like — the library doesn't care
    $db->insert('visits', $visit->toArray());
});

$firewall->run();

The VisitInfo object gives you everything you need:

$visit->ip
$visit->path
$visit->method
$visit->fingerprint      // daily SHA-256 hash — for unique visitor counting
$visit->device->browser  // 'Chrome', 'Firefox', 'Safari' ...
$visit->device->os       // 'Windows', 'macOS', 'Android', 'iOS' ...
$visit->device->type     // 'desktop' | 'mobile' | 'tablet'
$visit->date()           // formatted timestamp
$visit->toArray()        // flat array ready for DB insert

Tracking is disabled by default — you enable it explicitly. The library stays zero-dependency; how and where you store data is entirely up to you.

I'll be writing a dedicated post covering the full tracking API, unique visitor fingerprinting, and some practical analytics patterns. This is just the introduction.

What didn't change

The core API is identical. No breaking changes. If you were on 1.0.x, updating is safe:

composer update webrium/xzeroprotect

All existing configuration, custom rules, IP bans, and rate limit data carry over.

Why You Should Stop Using Laravel for Commercial Projects (The Hidden Risks)

Benyamin Khalife — Tue, 26 May 2026 13:57:50 +0000

Every framework has its honeymoon phase. For PHP developers, Laravel has been that reliable, feature-rich partner for years. It’s elegant, it has an amazing community, and it gets things done fast.

But fast development doesn't always mean a sustainable commercial product.

With the recent wave of supply chain attacks targeting popular Laravel ecosystem dependencies (like localization/lang packages and ignition RCEs), it’s time to take off the rose-colored glasses. Here is why choosing Laravel for your next enterprise or high-scale commercial project might be a massive technical debt in disguise.

1. The "Bloatware" Dilemma: Heavy, Slow, and Resource-Hungry

Laravel is undeniably bloated. Out of the box, it boots up a massive container, hundreds of classes, and an abstraction layer for almost everything.

The Cost: While this makes writing code easy, it consumes significant memory and CPU cycles per request compared to modern micro-frameworks or compiled languages like Go and Rust.

Commercial Impact: In a production environment, higher resource consumption directly translates to bloated cloud infrastructure bills. When scaling to millions of requests, Laravel requires expensive horizontal scaling setups far sooner than it should.

2. The Dependency Hell & Supply Chain Vulnerabilities

Laravel doesn't live in a vacuum; it heavily relies on Symfony components and a massive tree of third-party packages.

The Risk: You aren't just trusting Taylor Otwell; you are trusting hundreds of anonymous open-source maintainers. As we recently witnessed, hackers are actively exploiting this by poisoning the ecosystem (e.g., embedding backdoors in language and helper packages).

The Control Problem: Managing, auditing, and securing a giant vendor folder in Laravel is a logistical nightmare. One compromised sub-dependency can instantly introduce a Remote Code Execution (RCE) vulnerability into your commercial app.

3. The "Mass Popularity" Target

Being the king of PHP frameworks comes with a massive bullseye on your back.

The Target: Hackers love popular frameworks. Why waste time finding a zero-day vulnerability for a custom or niche framework when finding one exploit in Laravel or its core dependencies grants you access to hundreds of thousands of live websites?

Automated Exploitation: Shodan and automated botnets constantly scan the web for Laravel specific patterns (like exposed .env files or older Ignition pages). The moment an exploit is published, your site is targeted within minutes.

4. Architectural Magic That Breaks at Scale

Laravel relies heavily on "magic" methods, Facades, and Eloquent ORM. While great for rapid prototyping, this magic obfuscates what is actually happening under the hood.

As your data grows, Eloquent can easily introduce N+1 query problems and hidden memory leaks if not meticulously optimized.

Deeply nesting your business logic inside Laravel's heavily opinionated structure makes migrating or rewriting microservices incredibly difficult later on.

Conclusion: Is Laravel Dead?

No. It’s still fantastic for MVPs, SaaS internal tools, or small-to-medium business apps.

However, if you are building an enterprise-grade, high-performance, and security-critical commercial system, the heavy architectural footprint and the massive attack surface of its ecosystem should make you think twice. Sometimes, going lighter, stricter, and more compiled is the only way to scale safely.

What’s your take? Have you migrated away from Laravel for performance or security reasons? Let's discuss below!

Stop Scanners from Hammering Your PHP App — Without a Database or External Services

Benyamin Khalife — Sat, 16 May 2026 12:46:35 +0000

Every day, automated bots are scanning your website. Not just yours — everyone's. They probe for exposed .env files, old WordPress admin panels, SQL injection points, and known CVEs. Some of them send thousands of requests per minute, not because they're targeting you specifically, but because scanning the entire internet is cheap and easy.

This article is about what's actually happening out there, why it matters even for small projects, and how a lightweight PHP library can help you deal with it.

What Are These Scanners, Exactly?

Web scanners are automated programs that crawl the internet looking for security vulnerabilities. Some are legitimate security tools — like Shodan or Censys — that map the internet for research purposes. But many others are operated by attackers who are looking for:

Exposed configuration files — .env, web.config, .git/config
Unprotected admin panels — /wp-admin, /phpmyadmin, /adminer
Known vulnerable endpoints — like xmlrpc.php in WordPress or setup.php left behind after an install
SQL injection and XSS vectors — via query strings, POST bodies, and cookies
Path traversal attacks — trying ../../etc/passwd variations

The tools they use are well-known: sqlmap, nikto, nmap, dirbuster, gobuster, masscan, and many more. These aren't obscure hacking tools — they're freely available, widely documented, and actively maintained.

Even if your app has no actual vulnerabilities, these scanners generate noise, consume server resources, pollute your logs, and can slow down real users during a burst of requests.

Why Server-Level Solutions Aren't Always Enough

You might wonder: "Can't Nginx or Apache handle this?"

Sort of. You can write firewall rules, block known bad IPs, or configure rate limiting in your server config. But these approaches have limitations:

They require system-level access (not always available on shared hosting)
They need manual maintenance as attack patterns evolve
They can't easily inspect request payloads for things like SQL injection signatures
They don't integrate naturally with your application logic

A PHP-level firewall runs inside your application, which means it can inspect everything: headers, query strings, POST bodies, cookies, request paths, and user agents — and react accordingly.

Introducing xZeroProtect

xZeroProtect is a lightweight, file-based PHP 8 firewall with zero external dependencies. No Redis, no MySQL, no external services — everything is stored on disk.

Install it via Composer:

composer require webrium/xzeroprotect

The simplest possible integration — two lines at the top of your index.php:

<?php
require 'vendor/autoload.php';

use Webrium\XZeroProtect\XZeroProtect;

XZeroProtect::init()->run();

That's it. Default rules activate immediately.

What It Actually Does

1. Blocks Known Scanner User Agents

The library maintains a list of User-Agent signatures associated with scanning tools and attack frameworks: sqlmap, nikto, nessus, acunetix, masscan, dirbuster, gobuster, feroxbuster, wfuzz, ffuf, hydra, metasploit, and many others. Requests from these tools are blocked before they get anywhere near your application logic.

You can extend or trim this list:

$firewall->patterns->addAgent('custom-bad-bot');
$firewall->patterns->removeAgent('curl'); // if your API clients use curl legitimately

2. Blocks Sensitive Path Probes

Scanners routinely probe paths that don't exist in modern PHP apps — and shouldn't. xZeroProtect blocks requests targeting:

CMS admin panels: /wp-admin, /wp-login, /administrator
Config files: .env, .git, .htpasswd, web.config
Database tools: /phpmyadmin, /adminer, /dbadmin
Dangerous files: .sql, .bak, .backup, dump.sql
Web shells: shell.php, c99.php, r57.php
Path traversal: ../, ..%2f, %2e%2e

If you're running a fully-routed PHP app with no .php files in URLs, you can add that as a rule too:

$firewall->patterns->addPath('.php');

3. Scans Payloads for Attack Signatures

The payload scanner inspects GET parameters, POST body, raw input, and cookies using compiled regular expressions. It detects:

SQL injection variants: UNION SELECT, DROP TABLE, SLEEP(), BENCHMARK()
XSS: <script tags, inline event handlers, javascript: protocol
Path traversal: ../
PHP code injection: system(), exec(), eval(base64_decode(...))
LFI: /etc/passwd, /etc/shadow
Remote file inclusion
Command injection via shell metacharacters

4. Rate Limiting Without Redis

The rate limiter uses a sliding-window counter stored per-IP on disk. No Redis or Memcached required.

$firewall = XZeroProtect::init([
    'rate_limit' => [
        'max_requests' => 60,
        'per_seconds'  => 60,
    ],
]);

When a client exceeds the limit, they accumulate violations. After enough violations, they get temporarily banned. After enough bans, permanently.

5. Doesn't Block Legitimate Crawlers

This is important: Google, Bing, and other legitimate search engines should not get caught in your firewall. xZeroProtect handles this with double-DNS verification for major crawlers:

Resolve the visitor's IP to a hostname via reverse DNS
Confirm the hostname ends with the expected suffix (e.g. .googlebot.com)
Re-resolve that hostname back to an IP
Confirm the re-resolved IP matches the original

Anyone can fake a User-Agent string. DNS cannot be faked. This is the same verification method recommended by Google and Bing in their official documentation.

Learning Mode: Test Before You Block

Before switching to production, you can run in learning mode. All threats are detected and logged, but nothing is blocked. This lets you review what would have been caught and tune your configuration accordingly.

// During tuning
XZeroProtect::init(['mode' => 'learning'])->run();

// Once satisfied
XZeroProtect::init(['mode' => 'production'])->run();

This is genuinely useful. Running learning mode for a few days on a real server will show you the volume and variety of automated probes hitting your application — and help you avoid accidentally blocking legitimate traffic.

Apache Integration for Zero-PHP-Overhead Blocking

For permanently banned IPs, you can optionally write them into .htaccess so Apache rejects the connection before PHP even starts:

$firewall = XZeroProtect::init([
    'apache_blocking' => true,
    'htaccess_path'   => __DIR__ . '/.htaccess',
]);

This is particularly useful for confirmed attackers who you never want to reach your application layer again.

Custom Rules

If the built-in modules don't cover a specific case, you can register your own:

use Webrium\XZeroProtect\RuleResult;

$firewall->rules->add('no-php-extension', function ($request) {
    if (str_ends_with($request->path(), '.php')) {
        return RuleResult::block('PHP extension not valid on this server');
    }
    return RuleResult::pass();
});

Rules can block, log without blocking, or pass. They run in priority order and can be enabled, disabled, or removed at runtime.

What xZeroProtect Is Not

To be clear about expectations: this is not a commercial WAF. It won't stop a sophisticated, targeted attack from a determined adversary. It doesn't do deep packet inspection, it doesn't have a threat intelligence feed, and it doesn't update its rule set automatically.

What it does is significantly reduce the automated noise that hits most PHP applications — the opportunistic scanners, the script-kiddie tools, the mass-probing bots — with a setup that takes minutes and has no infrastructure dependencies.

For many projects, especially those on shared hosting or small VPS instances where you don't have the option to configure Nginx rate limiting or cloud WAF rules, this is a practical and useful layer of defense.

Getting Started

composer require webrium/xzeroprotect

Full documentation and source: github.com/webrium/xzeroprotect

Start in learning mode, review your logs, tune your configuration, then flip to production.

Have feedback or found an edge case? Issues and PRs are welcome on GitHub.

Building a Modular Ecosystem: How I’m Rethinking the CLI for My Personal

Benyamin Khalife — Fri, 15 May 2026 18:01:04 +0000

Every developer has that one project they pour their soul into. For me, it’s Webrium — my personal PHP framework. Recently, I’ve been focusing on its "brain" for command-line operations: the Webrium Console.

You can check out the progress here: https://github.com/webrium/console

The Vision: Beyond Simple Commands

While I’ve always admired how Laravel’s Artisan simplifies development, I wanted to build something that fits a specific architectural need I had: True Modularity.

The goal for the Webrium Console wasn't just to run migrations or seeders. I wanted a system where you can build a website normally, and then "export" or "modularize" specific parts of it as independent plugins or components.

Turning Features into Components

The most exciting part of this console library is how it handles site sections. Imagine you’ve built a robust Admin Panel or a Blog system. Instead of having them buried deep within your project’s monolith, Webrium Console allows you to treat them as portable components.
For example:

The Blog Component: It’s not just a set of files. It includes

everything—the management interface for the admin and the public-facing views for the client.
The Admin Portal: You can build it once and potentially plug it into different projects managed by the framework.

This "extract and reuse" approach is what I’m currently refining. It’s about being able to say: "I need a blog on this new site," and simply plugging in your pre-built, console-managed component.

I’d love to hear your thoughts on this:
Laravel is the industry standard for a reason, but sometimes we seek something different. What is the one thing that would make you look beyond established frameworks like Laravel and try something newer or custom-built for your projects?

Do you need a custom website or a specialized web solution?
Feel free to reach out! I’m available for new projects, or even just a free consultation to help you figure out the best tech stack for your needs.

Let’s connect:
Telegram: @benyaminir
Email: benkhalifedev@gmail.com

Generating Sitemaps is Easy

Benyamin Khalife — Thu, 14 May 2026 06:02:44 +0000

I've been building PHP projects for a while, and one of those annoying little tasks that keeps coming up is generating sitemaps. Not because it's technically hard — it's just tedious. You either roll your own XML string builder (and inevitably forget an edge case), or you pull in a heavy package that does ten things you don't need.
So I wrote a small library called webrium/sitemap to handle it cleanly. No bloat, just a focused tool that covers the real-world cases: images, videos, hreflang for multilingual sites, gzip, and automatic splitting for large sites.

Getting Started

composer require webrium/sitemap

That's it. PHP 8.1+ and the xmlwriter extension (which is almost always enabled by default).

The Basics

use Webrium\Sitemap\Sitemap;

$sitemap = new Sitemap('https://example.com');

$sitemap->addUrl('/',       changefreq: Sitemap::FREQ_DAILY,   priority: 1.0); // → https://example.com
$sitemap->addUrl('/about',  changefreq: Sitemap::FREQ_MONTHLY, priority: 0.8);
$sitemap->addUrl('/blog',   changefreq: Sitemap::FREQ_DAILY,   priority: 0.9);

echo $sitemap->generate();

One thing worth noting: passing '/' for the homepage correctly produces https://example.com — no trailing slash appended. Clean URLs matter, especially when Google is reading them.

Full URL Options

Each URL can carry a lastmod, changefreq, and priority. Named arguments make this readable even when you're using all of them:

use DateTime;

$sitemap->addUrl(
    path:       '/blog/my-first-post',
    lastmod:    new DateTime('2025-04-15'),
    changefreq: Sitemap::FREQ_WEEKLY,
    priority:   0.7
);

changefreq tells crawlers how often the content changes. Available values:

changefreq tells crawlers how often the content changes. Available values:

Constant	Value
`Sitemap::FREQ_ALWAYS`	always
`Sitemap::FREQ_HOURLY`	hourly
`Sitemap::FREQ_DAILY`	daily
`Sitemap::FREQ_WEEKLY`	weekly
`Sitemap::FREQ_MONTHLY`	monthly
`Sitemap::FREQ_YEARLY`	yearly
`Sitemap::FREQ_NEVER`	never

priority is a float between 0.0 and 1.0. Your homepage is typically 1.0, blog posts somewhere around 0.6–0.8. Search engines don't treat this as a hard rule, but it's still worth setting thoughtfully.

lastmod accepts any DateTimeInterface, so you can pass a DateTime, DateTimeImmutable, or Carbon instance from your models directly.

Adding URLs in Bulk

If you're pulling pages from a database, addUrls() is cleaner than looping manually:

$sitemap->addUrls([
    ['path' => '/services',  'priority' => 0.9],
    ['path' => '/portfolio', 'changefreq' => Sitemap::FREQ_MONTHLY],
    ['path' => '/contact',   'lastmod' => new DateTime('2025-01-10'), 'priority' => 0.5],
]);

Duplicate URLs are silently ignored — you don't need to deduplicate before passing.

Images

Google's image sitemap extension lets you associate images with pages, which can improve image search visibility:

$sitemap->addUrl(
    path:   '/portfolio/project-alpha',
    images: [
        [
            'loc'     => 'https://example.com/images/project-alpha-hero.jpg',
            'title'   => 'Project Alpha — hero shot',
            'caption' => 'The main dashboard view of Project Alpha.',
        ],
        [
            'loc'   => 'https://example.com/images/project-alpha-mobile.jpg',
            'title' => 'Project Alpha — mobile view',
        ],
    ]
);

loc is required. title and caption are optional but recommended.

Videos

Same idea for videos, with a few more required fields:

$sitemap->addUrl(
    path:   '/tutorials/getting-started',
    videos: [
        [
            'thumbnail_loc' => 'https://example.com/thumbs/getting-started.jpg',
            'title'         => 'Getting Started in 5 Minutes',
            'description'   => 'A quick walkthrough of the core features.',
            'duration'      => 320, // seconds
        ],
    ]
);

thumbnail_loc, title, and description are required. duration is optional.

Multilingual Sites (Hreflang)

If your site serves content in multiple languages, you can attach hreflang alternates to each URL:

$sitemap->addUrl(
    path:      '/about',
    hreflangs: [
        ['lang' => 'en',        'url' => 'https://example.com/en/about'],
        ['lang' => 'fa',        'url' => 'https://example.com/fa/about'],
        ['lang' => 'x-default', 'url' => 'https://example.com/about'],
    ]
);

The x-default entry tells Google which version to show when no language preference matches.

Saving to File

// Plain XML
$sitemap->saveToFile('/var/www/public/sitemap.xml');

// Gzip compressed — just add .gz to the filename
$sitemap->saveToFile('/var/www/public/sitemap.xml.gz');

Gzip is worth enabling in production. The file ends up 5–10x smaller, and most crawlers handle it fine.

Large Sites — Auto Splitting

The sitemap protocol caps files at 50,000 URLs and 50 MB. For bigger sites, splitAndSave() handles the splitting automatically and generates a sitemap index:

$sitemap = new Sitemap('https://example.com');

foreach ($allPages as $page) {
    $sitemap->addUrl($page->path, $page->updatedAt);
}

$indexXml = $sitemap->splitAndSave(
    directory:   '/var/www/public/sitemaps',
    baseFileUrl: 'https://example.com/sitemaps',
    prefix:      'sitemap',
    gzip:        true
);

file_put_contents('/var/www/public/sitemap-index.xml', $indexXml);

This produces sitemap-1.xml.gz, sitemap-2.xml.gz, and so on — plus a sitemap index file that points to all of them. Submit the index URL to Google Search Console and you're done.

Namespace Cleanliness

One small detail I care about: the library only adds XML namespaces that are actually used. If your sitemap has no images or videos, the output won't carry xmlns:image or xmlns:video. It's a minor thing, but it keeps the XML clean and honest.

Wrapping Up

Nothing revolutionary here — it's a sitemap generator. But it handles the real cases correctly and gets out of your way. If you've been copy-pasting sitemap XML by hand or using a bloated package, give it a try.

GitHub / Packagist: composer require webrium/sitemap

DEV Community: Benyamin Khalife

Make Your Buttons Dodge the Cursor with a Wrium Plugin

Why would you want this?

What you get

Install

Basic usage

The practical version: form validation

A note on UX and accessibility

Try it

Real-Time Password Strength Checking for Wrium

What it does

Install

Usage

Not using the directive?

An honest note

Try it

Wrium: A Tiny Reactive JavaScript Library With No Build Step

What is "reactive" anyway?

Meet Wrium

Your first app in 20 lines

The four building blocks

Templates: HTML that reacts

A real example: a Todo list

Components

Plugins: add your own directives

Honest limitations

When should you use Wrium?

Try it

What Is Vibe Coding? The Real Pros and Cons

Where Vibe Coding Actually Works

Why It Becomes Risky for Startups and Business Sites

Two Real-World Examples

1. Enrichlead

2. A CMS That Was Never Actually Connected

The Maintenance Problem Is Often Bigger Than the Initial Build

Why Experienced Developers Still Matter

The Bottom Line

xZeroProtect: A Free WordPress Firewall That Also Tells You Who Your Real Visitors Are

The idea

What it actually blocks

The dashboard

Getting started

Why I'm sharing it

Building Lightweight PHP Microservices with webrium/core — No Framework Bloat Required

Installation

The Entry Point

Routing

Reading Request Input

Validation

JWT Authentication

Password Hashing

Middleware

CORS

Putting It All Together

Source Code

How I Stopped Counting Bots as Visitors

The gap nobody talks about

How it works

What VisitInfo gives you

The fingerprint

Why opt-in, and why a closure?

Errors never reach your visitors

The result

xZeroProtect 1.1.1 — Smarter Defaults, Cleaner Rules, Real Visitor Tracking

What is xZeroProtect?

What changed in 1.1.1

Smarter default blocked agents

.php extension no longer blocked by default

Auto-ban threshold raised from 5 to 10

New: VisitInfo and real visitor tracking

What didn't change

Links

Why You Should Stop Using Laravel for Commercial Projects (The Hidden Risks)

1. The "Bloatware" Dilemma: Heavy, Slow, and Resource-Hungry

2. The Dependency Hell & Supply Chain Vulnerabilities

3. The "Mass Popularity" Target

4. Architectural Magic That Breaks at Scale

Conclusion: Is Laravel Dead?

Stop Scanners from Hammering Your PHP App — Without a Database or External Services

What Are These Scanners, Exactly?

`.php` extension no longer blocked by default

New: `VisitInfo` and real visitor tracking