DEV Community: Hamada Habib

Building Better Scheduling Forms in Filament with Date & Time Slots

Hamada Habib — Mon, 07 Sep 2026 04:09:01 +0000

Scheduling looks simple until you actually have to build it.

At first, the requirement usually sounds straightforward:

“Let the user choose a date and time.”

A standard date-time picker handles that perfectly.

But real scheduling workflows rarely stop there.

What if users should only book during working hours?

What if appointments are available every 30 minutes?

What if some slots are already booked?

What if a reservation must be made at least two hours in advance?

What if availability comes dynamically from your database or an external API?

And what happens when your users and your application operate in different timezones?

At that point, choosing a date and time is no longer just a date-picker problem. It becomes a time-slot scheduling problem.

That is the problem I wanted to solve with Filament Date Time Slots.

A scheduling field, not another booking system

Filament Date Time Slots is an open-source form field for Filament designed specifically around date and time-slot selection.

The goal is intentionally simple:

Provide the scheduling UI and rules without forcing a booking architecture on your application.

The package doesn't require an appointments table, a reservation model, or a specific database schema.

At the end of the interaction, your Filament form still receives a normal datetime value.

That makes the field useful in many different workflows:

Appointments
Reservations
Meetings
Tasks
CRM follow-ups
Consultations
Service bookings
Delivery windows
Any workflow where users need to choose an available time

Installation

Install the package through Composer:

composer require wooserv/filament-date-time-slots

Then use the field in your Filament schema:

use WooServ\FilamentDateTimeSlots\Forms\Components\DateTimeSlotPicker;

DateTimeSlotPicker::make('scheduled_at')

That's enough to get started.

The package ships with its compiled frontend assets, so applications using it don't need to install its JavaScript dependencies or run a separate frontend build process.

Defining working hours

One of the most common scheduling requirements is limiting availability to specific hours.

Instead of letting users choose arbitrary times, you can define the working schedule and let the field generate the available slots.

For example:

DateTimeSlotPicker::make('scheduled_at')
    ->workingHours([
        'monday' => ['09:00', '17:00'],
        'tuesday' => ['09:00', '17:00'],
        'wednesday' => ['09:00', '17:00'],
        'thursday' => ['09:00', '17:00'],
        'friday' => ['09:00', '17:00'],
    ])
    ->slotInterval(30);

Now the UI can present 30-minute slots within the configured working hours instead of exposing every possible time.

This is much closer to how scheduling works in real applications.

When availability comes from your application

Generating slots from working hours is useful, but sometimes your backend already knows exactly which slots are available.

Maybe availability depends on:

A doctor's calendar
An employee's schedule
Existing reservations
A resource or room
Business rules
An external scheduling service

In those cases, you can provide available slots directly:

DateTimeSlotPicker::make('scheduled_at')
    ->availableSlots([
        '2026-09-08' => ['09:00', '09:30', '11:00', '14:30'],
        '2026-09-09' => ['10:00', '10:30', '13:00'],
    ]);

More importantly, scheduling data doesn't have to be static.

The package supports dynamic configuration, allowing availability to be calculated from your application's own data and logic.

That was an important design decision for me.

A scheduling component shouldn't try to own your availability logic. Your application should.

The field should simply provide a clean way to represent that availability to the user.

Handling booked or unavailable slots

Available times are only half of the problem.

Real systems also need to represent times that can no longer be selected.

For that, the field supports blocked slots:

DateTimeSlotPicker::make('scheduled_at')
    ->blockedSlots([
        '2026-09-08' => ['10:00', '10:30', '15:00'],
        '2026-09-09' => ['11:30'],
    ]);

This can be useful when existing bookings already occupy part of the schedule.

Depending on the experience you want, blocked slots can either disappear from the available choices or remain visible as disabled slots.

Keeping them visible can be especially useful in appointment systems because users can understand that a time exists but is no longer available.

Booking constraints

Scheduling usually includes rules beyond availability.

For example, imagine a consultation that cannot be booked less than two hours before it starts.

The field supports a minimum lead time:

DateTimeSlotPicker::make('scheduled_at')
    ->minimumLeadTime(120)

You can also control the allowed date range and disable specific dates.

These constraints let the form communicate the same rules that your scheduling workflow expects instead of relying on users to choose a valid datetime manually.

Preventing past dates and times

A surprisingly common issue with generic date-time fields is dealing with the current day.

Disabling yesterday is easy.

But if today is selectable, the application also needs to make sure that time slots that have already passed are no longer available.

A scheduling-focused field needs to understand both sides of that problem:

the selected date and the available time slots for that date.

This is one of the reasons I preferred building a dedicated scheduling field rather than adding more configuration around a generic datetime input.

Timezones matter

Timezone handling is another area where scheduling interfaces can become complicated quickly.

The package supports configuring the timezone used by the picker while allowing the application to keep its own storage timezone.

For example:

DateTimeSlotPicker::make('scheduled_at')
    ->timezone('Asia/Riyadh')

This is useful when your application's stored datetime and the timezone shown to the person making the booking aren't necessarily the same.

Timezone support is part of the field's datetime lifecycle rather than simply changing a label in the interface.

Localization, RTL, and time formats

Scheduling interfaces are user-facing components, so localization matters.

The picker supports locale configuration, RTL layouts, and both 12-hour and 24-hour time display.

For example:

DateTimeSlotPicker::make('scheduled_at')
    ->locale('ar')
    ->timezone('Africa/Cairo');

This was particularly important for applications that need to work well across both Arabic and English interfaces.

Dark mode is supported as well, so the field can fit naturally into Filament panels using either theme.

Why return a normal datetime?

One of the design choices I like most about this approach is what the package doesn't do.

It doesn't introduce its own booking model.

It doesn't create scheduling tables.

It doesn't dictate how appointments should be stored.

It doesn't try to become a calendar platform.

Instead:

DateTimeSlotPicker::make('scheduled_at')

still represents a normal field in your form.

Your application remains responsible for its business model.

That means the same component can be used in a CRM today and an appointment system tomorrow without changing the architecture around it.

For reusable packages, I think that separation is valuable.

Compatibility

The package is designed to work across the current Filament ecosystem, including:

Filament 3, 4, and 5
Laravel 11, 12, and 13
PHP 8.2+

Compatibility is continuously tested through GitHub Actions across representative supported combinations.

That was important because supporting several framework generations shouldn't just mean adding broad Composer constraints.

The combinations should actually be tested.

Open source

Filament Date Time Slots is open source and released under the MIT license.

You can find the source code, documentation, examples, and issue tracker on GitHub:

GitHub:

https://github.com/wooserv/filament-date-time-slots

Live demo:
https://booking.wooserv.com

Filament Marketplace:
https://filamentphp.com/plugins/wooserv-date-time-slots

Packagist:

https://packagist.org/packages/wooserv/filament-date-time-slots

Install it with:

composer require wooserv/filament-date-time-slots

If you're building scheduling workflows with Filament, I'd love to hear what kinds of availability rules you're dealing with.

Issues, feedback, and contributions are welcome.

Turning WordPress Into an Open Knowledge Graph with OKF

Hamada Habib — Tue, 16 Jun 2026 17:29:28 +0000

For years, content management systems have been optimized for people and search engines.

Pages, posts, taxonomies, custom post types, categories, tags, and internal links all work well for publishing content on the web.

But modern AI systems need something different.

They need structure.

They need relationships.

They need knowledge.

This is where the Open Knowledge Format (OKF) becomes interesting.

The Problem

Most WordPress websites contain valuable knowledge.

A real estate website may contain:

Projects
Developers
Cities
Properties

A SaaS website may contain:

Features
Documentation
Guides
Integrations
FAQs

A university website may contain:

Courses
Departments
Professors
Research papers

The information exists.

The relationships exist.

But the knowledge is trapped inside HTML pages.

For humans, that is fine.

For AI systems, it is not ideal.

What Is OKF?

Open Knowledge Format (OKF) is an open specification introduced by Google Cloud as a lightweight way to represent knowledge using Markdown files.

Instead of storing knowledge in a graph database or a proprietary format, OKF uses:

Directories
Markdown documents
Metadata
Links

Every document becomes a concept.

Every link becomes a relationship.

The result is a portable and AI-friendly knowledge graph.

Why WordPress?

WordPress powers a large portion of the web.

Yet most WordPress content is still distributed as HTML.

If we can transform WordPress content into OKF documents, we gain:

Structured knowledge representation
Better AI ingestion
Portable knowledge graphs
Vendor independence
Human-readable storage
Git-friendly versioning

Building Knowledge Layer

To explore this idea, I built Knowledge Layer:

https://github.com/wooserv/wp-knowledge-layer

Knowledge Layer is a WordPress plugin that synchronizes WordPress content into Open Knowledge Format documents.

The goal is simple:

Transform WordPress content into a persistent Markdown-based knowledge graph.

The plugin supports:

Pages
Posts
Custom Post Types
Taxonomies
Internal links
Incremental synchronization

Instead of rebuilding everything repeatedly, content is synchronized as it changes.

How It Works

When content is published:

WordPress content is discovered.
HTML is converted into Markdown.
Metadata is extracted.
Internal links are rewritten.
OKF documents are generated.
The knowledge graph is updated.

The resulting files remain readable by both humans and AI systems.

Why Markdown?

Markdown provides several advantages:

Human-readable
Version controllable
Portable
AI-friendly
Easy to inspect
Easy to archive

Most importantly, Markdown does not require specialized infrastructure.

The Future

As AI systems increasingly consume structured knowledge, websites need more than pages and posts.

They need a way to expose their knowledge in an open and portable format.

OKF provides a promising foundation.

WordPress already contains the knowledge.

The next step is making that knowledge accessible.

Knowledge Layer is one attempt to bridge that gap.

References

Google Cloud:
https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing

Open Knowledge Format Specification:
https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md

Community Resources:
https://suganthan.com/blog/open-knowledge-format/

GitHub:
https://github.com/wooserv/wp-knowledge-layer

🚀 Introducing Laravel ObjectId — The Fastest MongoDB-Style Identifier for Laravel Models

Hamada Habib — Sun, 09 Nov 2025 08:41:16 +0000

Works seamlessly with MySQL, MariaDB, and PostgreSQL — no MongoDB required.

Every Laravel developer has been there — you start a new project, define your migrations, and by default, your models use auto-incrementing IDs. It works fine... until your app grows, you need distributed systems, API integrations, or microservices. Suddenly, those integer IDs start to look like a limitation.

That’s where Laravel ObjectId comes in — a drop-in, ultra-fast, globally unique identifier system inspired by MongoDB’s ObjectIds, designed for MySQL, MariaDB, and PostgreSQL — no MongoDB required.

💡 Why ObjectId?

Unlike UUIDs or ULIDs, ObjectIds are compact 12-byte identifiers that encode timestamp, randomness, and a counter — making them sortable, lightweight, and unique across systems.

In numeric terms, they’re up to 3× faster to generate and smaller in size, which directly improves database performance and indexing.

✅ Works natively with MySQL, MariaDB, and PostgreSQL
🚫 No MongoDB driver or extension required

🧬 How ObjectId Works Internally

ObjectIds are 12-byte (96-bit) identifiers consisting of four key parts:

Segment	Size	Description
Timestamp	4 bytes	UNIX epoch seconds — makes IDs sortable by creation time
Machine Identifier	5 bytes	Randomly generated, unique per host
Process ID	2 bytes	Uniquely identifies the generating process
Counter	3 bytes	Incrementing counter initialized randomly per process

➡️ Total = 4 + 5 + 2 + 3 = 12 bytes = 24 hex characters

This design ensures uniqueness without any central generator and preserves chronological order, making it ideal for distributed systems.

For more details, check:

🧩 The Ecosystem

The Laravel package is built on top of our core PHP library:

🔹 wooserv/php-objectid: a pure PHP implementation of ObjectIds.
🔹 wooserv/laravel-objectid: Laravel integration with automatic model ID assignment and migration macros.

Both packages are open-source under the MIT license, created by WooServ Labs.

⚡ Installation

composer require wooserv/laravel-objectid

🧱 Usage

Model Example

use WooServ\LaravelObjectId\Concerns\HasObjectIds;
use Illuminate\Database\Eloquent\Model;

class Post extends Model
{
    use HasObjectIds;
}

Migration Example

Schema::create('posts', function (Blueprint $table) {
    $table->objectId(); // Creates a 24-char string primary key
    $table->string('title');
    $table->timestamps();
});

Generate IDs Anywhere

$id = objectid(); // e.g. 6730b6a0d8a28f890b7c9f40

🔬 Benchmark Results

Laravel ObjectId Performance (10,000 iterations)

----------------------------------------------------------
ObjectId             : 0.412 µs per ID
objectid() helper    : 0.417 µs per ID
UUID                 : 1.283 µs per ID
ULID                 : 1.147 µs per ID
----------------------------------------------------------
Fastest: ObjectId 🚀

Database Insert Benchmark (1,000 inserts)

----------------------------------------------------------
ObjectId   : 14.78 ms total (0.015 ms/insert)
UUID       : 15.48 ms total (0.015 ms/insert)
ULID       : 15.17 ms total (0.015 ms/insert)
----------------------------------------------------------

⚔️ ObjectId vs UUID vs ULID

Feature	ObjectId	UUID	ULID
Length	24 chars	36 chars	26 chars
Bytes	12	16	16
Sortable	✅ (timestamp prefix)	❌	✅
Randomness	✅	✅	✅
Readability	🟢 Compact	🔴 Long	🟢 Fair
Speed	🚀 Fastest	🐢 Slowest	⚡ Medium
Works with MySQL/MariaDB/PostgreSQL	✅	✅	✅
Requires MongoDB	❌	❌	❌

Verdict: ObjectId is the best balance between compactness, performance, and chronological order — and it’s fully compatible with standard SQL databases.

🧠 Why Developers Love It

✅ Automatic assignment — no need to manually generate IDs.
⚙️ Migration macro $table->objectId() — clean and intuitive.
🧩 Framework-agnostic core — works outside Laravel too.
📦 Compact storage — saves DB space compared to UUID.
🕒 Sortable by creation time — built-in timestamp encoding.
🧰 Database-compatible — works with MySQL, MariaDB, and PostgreSQL seamlessly.

🌍 Open Source Philosophy

Both packages are released under the MIT License and maintained by WooServ Labs, a collective of developers building open, high-performance PHP tooling for modern web apps.

We believe that open-source should be:

Simple to install.
Fun to use.
Fast by default.

If you share that philosophy — star the repo, contribute, or just spread the word 💫

📎 Resources

⭐ If you like it — give it a Star on GitHub and share it with your fellow Laravel devs!