✨ Introducing Deeplancer - The Best Freelancing Platform

Getting Started

Admin Panel

For Developers

Best Practices

Understanding Deeplancer's architecture and development patterns

Best Practices

Understanding how Deeplancer is structured helps you extend it effectively. This isn't a Laravel tutorial—we assume you know the framework. Here's how this project works.

Project Architecture

Component Organization

Deeplancer uses a strict namespace and directory structure:

Admin Components:

App\Livewire\Admin\{Feature}\{Feature}Component - List/index components
App\Livewire\Admin\{Feature}\Options\{Action}Component - CRUD operations (Create, Edit)
Views: resources/views/livewire/admin/{feature}/{feature}.blade.php

Main/Frontend Components:

App\Livewire\Main\{Feature}\{Feature}Component - Public-facing components
Seller components: App\Livewire\Main\Seller\{Feature}\{Feature}Component
Views: resources/views/livewire/main/{feature}/{feature}.blade.php

Pattern:

Component class names end with Component
View files are lowercase, no hyphens (e.g., productlist.blade.php)
CRUD operations go in Options subdirectory
Each feature is self-contained

Deep UI Component System

All UI uses custom Deep UI components in resources/views/components/deep/. These are Blade components, not Livewire.

Usage:

<x-deep.button variant="primary">Save</x-deep.button>
<x-deep.input wire:model="name" />
<x-deep.modal wire:model="showModal">Content</x-deep.modal>

Why:

Consistent styling across admin and frontend
Centralized theming via Tailwind CSS variables
Single source of truth for UI patterns
Easy to override per-installation

Icons:

<x-deep.icon name="user" />

Icons use Heroicons but without the heroicon- prefix. The component handles the mapping.

Deep Facade & Toast System

App\Deep\Deep facade handles toast notifications:

use App\Deep\Deep;
 
Deep::toast(
    text: __('admin.item_created'),
    variant: 'success'
);

Variants: success, danger, warning, info

Why not session flash:

Real-time feedback without page refresh
Better UX for Livewire interactions
Consistent notification system
No redirect needed

Media Library Pattern

All file uploads use Spatie Media Library. Never use Laravel's store() or storeAs().

Model Setup:

use Spatie\MediaLibrary\HasMedia;
use Spatie\MediaLibrary\InteractsWithMedia;
 
class Gig extends Model implements HasMedia
{
    use InteractsWithMedia;
 
    public function registerMediaCollections(): void
    {
        $this->addMediaCollection('cover')->singleFile();
        $this->addMediaCollection('gallery');
    }
}

Upload Pattern:

use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
 
if ($file instanceof TemporaryUploadedFile) {
    $extension = $file->getClientOriginalExtension();
    $fileName = strtoupper(Str::random(32)) . '.' . $extension;
 
    $model
        ->addMedia($file->getRealPath())
        ->usingFileName($fileName)
        ->withCustomProperties(['path_prefix' => 'collection-name/'])
        ->toMediaCollection('collection-name');
}

Retrieval:

$model->getFirstMediaUrl('collection-name');
$model->getMedia('collection-name');

Important: Always eager load media:

Gig::with('media')->get();

Permission System

Uses Spatie Permission. Permissions are checked in component mount() methods:

public function mount(): void
{
    if (!auth()->user()->can('gigs.view_any')) {
        abort(403);
    }
}

Permission Naming:

{resource}.view_any - List/index
{resource}.view - Show single
{resource}.create - Create
{resource}.update - Update
{resource}.delete - Delete

Permissions are seeded in database/seeders/PermissionSeeder.php and translated in lang/en/permissions.php.

Localization Strategy

Never hardcode text. Everything uses translation keys:

__('admin.gigs_title')
__('messages.welcome')

File Organization:

lang/en/admin.php - Admin panel only
lang/en/messages.php - Frontend/public pages
lang/en/permissions.php - Permission names

Why separate:

Clear context separation
Easier to maintain
Better organization
No mixing of contexts

SEO Meta Tags

All components set SEO meta in render():

use Artesaos\SEOTools\Facades\SEOMeta;
 
public function render()
{
    SEOMeta::setTitle(seo_title(__('admin.gigs_title')));
    SEOMeta::setDescription(__('admin.gigs_subtitle'));
    SEOMeta::setCanonical(route('admin.gigs.index'));
    
    return view('livewire.admin.gigs.gigs', [
        'gigs' => $this->gigs,
    ]);
}

Admin titles use seo_title() helper:

Format: "Page Title | Dashboard"
Separator from config
Dashboard label from translations

Layout System

Two main layouts:

components.layouts.admin - Admin panel
components.layouts.app - Frontend

Set via attribute:

#[Layout('components.layouts.admin')]
class GigsComponent extends Component

Query Patterns

Always eager load:

Gig::with(['category', 'user', 'media'])->get();

Pagination path:

$gigs = Gig::paginate(15);
$gigs->setPath(route('admin.gigs.index'));

Search pattern:

if ($this->search) {
    $query->where('title', 'like', '%' . $this->search . '%');
}

Filter pattern:

if ($this->statusFilter) {
    $query->where('status', $this->statusFilter);
}

Settings Models

Settings are stored in dedicated models:

SettingsGeneral - General settings
SettingsTheme - Theme settings
SettingsHome - Homepage settings
SettingsGig - Gig settings
SettingsMail - Mail settings
SettingsCurrency - Currency settings

Pattern:

$settings = SettingsGeneral::first();
if ($settings) {
    $this->logo_light = $settings->logo_light ?? '';
}

Settings are singleton—one record per setting type.

Payment Gateway Structure

Payment gateways are components in App\Livewire\Admin\Payments\Gateways\{Gateway}\{Gateway}Component:

Stripe: StripeComponent
PayPal: PayPalComponent
Wallet: WalletComponent

Each gateway has its own configuration form and processing logic.

Category Hierarchy

Three-level category system:

Categories (top level)
Sub Categories (second level)
Child Categories (third level)

Each level is a separate model with relationships:

Category -> hasMany(SubCategory)
SubCategory -> belongsTo(Category) -> hasMany(ChildCategory)
ChildCategory -> belongsTo(SubCategory)

Common Patterns

Component Lifecycle

public function mount(): void
{
    // Permission check
    // Initial data loading
}
 
public function updatedSearch(): void
{
    // Reset pagination on search
    $this->resetPage();
}
 
public function clearFilters(): void
{
    // Reset all filters
    $this->reset(['search', 'statusFilter']);
    $this->resetPage();
}
 
public function render()
{
    // Build query
    // Set SEO
    // Return view
}

Form Handling

public function save(): void
{
    $validated = $this->validate([
        'name' => ['required', 'string', 'max:255'],
    ]);
 
    $model = Model::create($validated);
 
    Deep::toast(
        text: __('admin.item_created'),
        variant: 'success'
    );
 
    // No redirect needed - toast handles feedback
}

Delete Pattern

public function delete(int $id): void
{
    $item = Model::findOrFail($id);
    $item->delete();
 
    Deep::toast(
        text: __('admin.item_deleted'),
        variant: 'success'
    );
 
    $this->dispatch('item-deleted'); // For Livewire updates
}

Key Decisions

Why Livewire over API:

Full-stack simplicity
Server-side rendering
Real-time updates
Less JavaScript complexity

Why Deep UI components:

Consistency
Centralized theming
Easy customization
No external dependencies

Why Spatie packages:

Battle-tested
Well-maintained
Laravel-native
Feature-rich

Why translation keys everywhere:

Multi-language ready
Maintainable
Consistent
No hardcoded strings

Extending Safely

Do:

Follow existing patterns
Use Deep UI components
Add permissions for new features
Use migrations for schema changes
Eager load relationships
Set SEO meta tags
Use translation keys

Don't:

Modify core Deep UI components directly (copy and override)
Use Laravel storage for uploads (use Spatie)
Hardcode text
Skip permission checks
Forget eager loading
Use session flash (use Deep::toast)

A Note from deep42

Don't Panic.

We've structured Deeplancer to be extensible. The codebase follows Laravel and Livewire conventions, so if you know the framework, you'll feel at home.

The architecture is modular—admin components, main components, services, and models are clearly separated. When extending, follow the existing patterns. Don't fight the framework.

We use Spatie packages for media and permissions. Deep UI components handle the frontend. Everything is namespaced and organized. If something feels off, there's probably a reason—check the existing implementations first.

Customize freely, but keep it maintainable. Use migrations for schema changes. Eager load relationships. Validate inputs. Check permissions. The usual stuff.

A friendly heads-up: We'll release updates, and when we do, you'll need to adapt your customizations. That's just how software works—things evolve. Extending helps, but it's not a magic shield. You can stay on your current version if it works for you, or roll up your sleeves when updates arrive. Either way, you're in control.

The answer is 42. The code is clean. Build something great.

— deep42

Deep UI Components

Best Practices

Understanding Deeplancer's architecture and development patterns

Best Practices

Understanding how Deeplancer is structured helps you extend it effectively. This isn't a Laravel tutorial—we assume you know the framework. Here's how this project works.

Project Architecture

Component Organization

Deeplancer uses a strict namespace and directory structure:

Admin Components:

App\Livewire\Admin\{Feature}\{Feature}Component - List/index components
App\Livewire\Admin\{Feature}\Options\{Action}Component - CRUD operations (Create, Edit)
Views: resources/views/livewire/admin/{feature}/{feature}.blade.php

Main/Frontend Components:

App\Livewire\Main\{Feature}\{Feature}Component - Public-facing components
Seller components: App\Livewire\Main\Seller\{Feature}\{Feature}Component
Views: resources/views/livewire/main/{feature}/{feature}.blade.php

Pattern:

Component class names end with Component
View files are lowercase, no hyphens (e.g., productlist.blade.php)
CRUD operations go in Options subdirectory
Each feature is self-contained

Deep UI Component System

All UI uses custom Deep UI components in resources/views/components/deep/. These are Blade components, not Livewire.

Usage:

<x-deep.button variant="primary">Save</x-deep.button>
<x-deep.input wire:model="name" />
<x-deep.modal wire:model="showModal">Content</x-deep.modal>

Why:

Consistent styling across admin and frontend
Centralized theming via Tailwind CSS variables
Single source of truth for UI patterns
Easy to override per-installation

Icons:

<x-deep.icon name="user" />

Icons use Heroicons but without the heroicon- prefix. The component handles the mapping.

Deep Facade & Toast System

App\Deep\Deep facade handles toast notifications:

use App\Deep\Deep;
 
Deep::toast(
    text: __('admin.item_created'),
    variant: 'success'
);

Variants: success, danger, warning, info

Why not session flash:

Real-time feedback without page refresh
Better UX for Livewire interactions
Consistent notification system
No redirect needed

Media Library Pattern

All file uploads use Spatie Media Library. Never use Laravel's store() or storeAs().

Model Setup:

use Spatie\MediaLibrary\HasMedia;
use Spatie\MediaLibrary\InteractsWithMedia;
 
class Gig extends Model implements HasMedia
{
    use InteractsWithMedia;
 
    public function registerMediaCollections(): void
    {
        $this->addMediaCollection('cover')->singleFile();
        $this->addMediaCollection('gallery');
    }
}

Upload Pattern:

use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
 
if ($file instanceof TemporaryUploadedFile) {
    $extension = $file->getClientOriginalExtension();
    $fileName = strtoupper(Str::random(32)) . '.' . $extension;
 
    $model
        ->addMedia($file->getRealPath())
        ->usingFileName($fileName)
        ->withCustomProperties(['path_prefix' => 'collection-name/'])
        ->toMediaCollection('collection-name');
}

Retrieval:

$model->getFirstMediaUrl('collection-name');
$model->getMedia('collection-name');

Important: Always eager load media:

Gig::with('media')->get();

Permission System

Uses Spatie Permission. Permissions are checked in component mount() methods:

public function mount(): void
{
    if (!auth()->user()->can('gigs.view_any')) {
        abort(403);
    }
}

Permission Naming:

{resource}.view_any - List/index
{resource}.view - Show single
{resource}.create - Create
{resource}.update - Update
{resource}.delete - Delete

Permissions are seeded in database/seeders/PermissionSeeder.php and translated in lang/en/permissions.php.

Localization Strategy

Never hardcode text. Everything uses translation keys:

__('admin.gigs_title')
__('messages.welcome')

File Organization:

lang/en/admin.php - Admin panel only
lang/en/messages.php - Frontend/public pages
lang/en/permissions.php - Permission names

Why separate:

Clear context separation
Easier to maintain
Better organization
No mixing of contexts

SEO Meta Tags

All components set SEO meta in render():

use Artesaos\SEOTools\Facades\SEOMeta;
 
public function render()
{
    SEOMeta::setTitle(seo_title(__('admin.gigs_title')));
    SEOMeta::setDescription(__('admin.gigs_subtitle'));
    SEOMeta::setCanonical(route('admin.gigs.index'));
    
    return view('livewire.admin.gigs.gigs', [
        'gigs' => $this->gigs,
    ]);
}

Admin titles use seo_title() helper:

Format: "Page Title | Dashboard"
Separator from config
Dashboard label from translations

Layout System

Two main layouts:

components.layouts.admin - Admin panel
components.layouts.app - Frontend

Set via attribute:

#[Layout('components.layouts.admin')]
class GigsComponent extends Component

Query Patterns

Always eager load:

Gig::with(['category', 'user', 'media'])->get();

Pagination path:

$gigs = Gig::paginate(15);
$gigs->setPath(route('admin.gigs.index'));

Search pattern:

if ($this->search) {
    $query->where('title', 'like', '%' . $this->search . '%');
}

Filter pattern:

if ($this->statusFilter) {
    $query->where('status', $this->statusFilter);
}

Settings Models

Settings are stored in dedicated models:

SettingsGeneral - General settings
SettingsTheme - Theme settings
SettingsHome - Homepage settings
SettingsGig - Gig settings
SettingsMail - Mail settings
SettingsCurrency - Currency settings

Pattern:

$settings = SettingsGeneral::first();
if ($settings) {
    $this->logo_light = $settings->logo_light ?? '';
}

Settings are singleton—one record per setting type.

Payment Gateway Structure

Payment gateways are components in App\Livewire\Admin\Payments\Gateways\{Gateway}\{Gateway}Component:

Stripe: StripeComponent
PayPal: PayPalComponent
Wallet: WalletComponent

Each gateway has its own configuration form and processing logic.

Category Hierarchy

Three-level category system:

Categories (top level)
Sub Categories (second level)
Child Categories (third level)

Each level is a separate model with relationships:

Category -> hasMany(SubCategory)
SubCategory -> belongsTo(Category) -> hasMany(ChildCategory)
ChildCategory -> belongsTo(SubCategory)

Common Patterns

Component Lifecycle

public function mount(): void
{
    // Permission check
    // Initial data loading
}
 
public function updatedSearch(): void
{
    // Reset pagination on search
    $this->resetPage();
}
 
public function clearFilters(): void
{
    // Reset all filters
    $this->reset(['search', 'statusFilter']);
    $this->resetPage();
}
 
public function render()
{
    // Build query
    // Set SEO
    // Return view
}

Form Handling

public function save(): void
{
    $validated = $this->validate([
        'name' => ['required', 'string', 'max:255'],
    ]);
 
    $model = Model::create($validated);
 
    Deep::toast(
        text: __('admin.item_created'),
        variant: 'success'
    );
 
    // No redirect needed - toast handles feedback
}

Delete Pattern

public function delete(int $id): void
{
    $item = Model::findOrFail($id);
    $item->delete();
 
    Deep::toast(
        text: __('admin.item_deleted'),
        variant: 'success'
    );
 
    $this->dispatch('item-deleted'); // For Livewire updates
}

Key Decisions

Why Livewire over API:

Full-stack simplicity
Server-side rendering
Real-time updates
Less JavaScript complexity

Why Deep UI components:

Consistency
Centralized theming
Easy customization
No external dependencies

Why Spatie packages:

Battle-tested
Well-maintained
Laravel-native
Feature-rich

Why translation keys everywhere:

Multi-language ready
Maintainable
Consistent
No hardcoded strings

Extending Safely

Do:

Follow existing patterns
Use Deep UI components
Add permissions for new features
Use migrations for schema changes
Eager load relationships
Set SEO meta tags
Use translation keys

Don't:

Modify core Deep UI components directly (copy and override)
Use Laravel storage for uploads (use Spatie)
Hardcode text
Skip permission checks
Forget eager loading
Use session flash (use Deep::toast)

A Note from deep42

Don't Panic.

We've structured Deeplancer to be extensible. The codebase follows Laravel and Livewire conventions, so if you know the framework, you'll feel at home.

The architecture is modular—admin components, main components, services, and models are clearly separated. When extending, follow the existing patterns. Don't fight the framework.

Customize freely, but keep it maintainable. Use migrations for schema changes. Eager load relationships. Validate inputs. Check permissions. The usual stuff.

The answer is 42. The code is clean. Build something great.

— deep42

Deep UI Components