DEV Community: Maniruzzaman Akash

Livewire Admin UX vs Classic WordPress Admin for Power Users

Maniruzzaman Akash — Thu, 01 Oct 2026 04:10:02 +0000

You live in the admin. Lists, filters, bulk edits, keyboard shortcuts, and muscle memory matter more than marketing screenshots. This piece compares Livewire admin UX (including Livewire-based admin kits and Filament-style Livewire UIs) with classic WordPress admin for power users who ship content and ops work every day.

It is an admin workflow comparison, not a general Laravel vs WordPress redo. Here we stay on screens, menus, AJAX habits, reactivity, and migration friction for WP power users.

Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you want a ready Laravel admin shell with Spatie-backed roles and product modules. Much of the Livewire side below also applies to Filament and custom Livewire panels. We say so when a claim is about LaraDashboard specifically.

The short answer

Classic wp-admin is a full-page admin with deep plugin UI, admin AJAX patterns, and decades of power-user muscle memory. You navigate menus, submit forms, wait for reloads, and stitch workflows across plugin screens.

Livewire admin UX keeps you in Laravel Blade (or kit pages) while components re-render after server round-trips without a full page reload. Filament-style resources, custom Livewire forms, and LaraDashboard admin screens share that feel: filters update, tables refresh, and modals open without leaving the Laravel app for a separate SPA stack.

Neither is "done" by default. wp-admin power comes from plugins and custom admin code. Livewire power comes from components you own, kit conventions you accept, and policies you actually wire. Pick based on how your operators work, not on blog hype.

Classic WordPress admin: strengths for power users

wp-admin still wins in places power users care about:

Ubiquity. Contractors already know Posts, Pages, Media, and Users. Training cost is low for content shops.
Plugin UI density. Need SEO fields, redirects, forms, CRM lite, and membership gates? There is a screen for each, often yesterday.
Admin AJAX culture. Heartbeat, meta box saves, and admin-ajax actions let parts of a screen update without a full reload when authors invest in it.
Bulk tools. Quick Edit, bulk edit, and media library workflows are mature for editorial teams.
Escape hatches. Hooks and add_menu_page let you inject almost anything into the left rail.

Those strengths come with friction: full page loads as the default, growing menus, uneven plugin UI, and workflows that depend on memorizing which plugin owns which field.

If your power users are WordPress natives and your product is content ops on WP, staying can be rational. If your power users are product operators who need one coherent app, the plugin menu model starts to tax every sprint.

Livewire admin UX: what feels different

Livewire (and Filament-style Livewire UIs) change the day-to-day feel:

Reactivity without a separate SPA. You stay in Laravel. Components call server methods. The DOM updates. You do not maintain a React admin unless you want one.
Forms that validate in place. Failed rules re-render the same screen with errors next to fields. No "return to form with old input" dance you hand-roll on every controller.
Tables that filter without navigation. Search, sort, and pagination can update the list region while the shell stays put.
Modals and slides for create/edit. Power users keep list context. That alone reduces lost filters after "open edit in new tab."
Shared auth and policies. The same Gate, Policy, or Spatie permission that protects a route protects the Livewire action if you wire it.

Filament leans hard into this model with resources, form builders, and table builders on Livewire. Custom Livewire admin pages give you the same primitives with more layout freedom. LaraDashboard gives you an admin shell and module screens in a Laravel CMS context. The interaction pattern is the shared idea: server-driven UI with SPA-ish feedback.

Cheat sheet: Livewire admin vs classic wp-admin

Compare along the axes power users feel:

Default navigation: Livewire kit shell + resource pages vs wp-admin left menu + plugin submenus.
Form submit feel: Component re-render / wire submit vs full postback or plugin AJAX of uneven quality.
List filtering: Livewire table state vs admin list tables + plugin columns.
Related records: Relation managers / nested components vs meta boxes + linked CPT screens.
Extensibility unit: Livewire components and kit plugins vs WP hooks and admin pages.
Consistency across features: High if you stay in one kit vs variable per plugin author.
Training curve for WP veterans: New mental model (components, resources) vs familiar chrome with plugin surprises.
Best fit: Product ops inside Laravel vs content ops inside the WP ecosystem.

Use this sheet in stakeholder talks. Do not pretend every Filament screen beats every WP plugin screen. A polished WP admin for a newspaper can outpace a neglected Livewire prototype. Ownership and polish decide the winner.

What breaks for WordPress power users who migrate

Expect friction. Name it early so stakeholders do not call the new admin "broken" when it is only unfamiliar.

Common breaks:

Quick Edit nostalgia. Inline edit of five fields from the list may need a Livewire modal or row action you must build.
Plugin field maps. SEO, redirects, and membership fields lived on the post screen. In Laravel they become model attributes, related models, or module settings. Operators must learn new homes.
Media library habits. WP media modal workflows are unique. Laravel media disks and pickers feel different. Plan a media story before cutover.
Role names and caps. WP capabilities do not map 1:1 to Spatie permissions. Rebuild the matrix on purpose.
Admin CSS muscle memory. Spacing, notices, and "where is the Publish box?" all change. Provide a one-page cheat sheet for editors.
Cron and background jobs. WP cron plus plugin crons become Laravel queues and schedulers. Ops runbooks must change.
Permalink and preview mental models. Preview and draft flows are app-specific. Rehearse them with real editors.

None of these mean Livewire is worse. They mean migration is a UX project, not only a data project.

When Livewire admin UX is the better power-user fit

Lean Livewire (Filament-style or custom) when:

The admin is the product UI for ops, not a side CMS
You want one auth, one validation style, and one deploy train with the Laravel app
You are tired of plugin UI drift and need coherent tables/forms
You already run Laravel for the API or customer app and do not want a second admin stack
Module packaging and Spatie roles matter more than WP plugin directories

LaraDashboard fits when you want that Laravel admin/CMS shell with modules and roles, not when you only need a Filament resource for one model. Filament fits when the admin kit should own UI conventions. Custom Livewire fits when neither kit should dictate layout.

FAQ

Is Livewire the same as a React admin SPA?

No. Livewire keeps rendering logic on the server and patches HTML. A React SPA keeps more UI state in the browser and talks to APIs. Livewire can feel SPA-like for forms and tables without a separate frontend build for every admin screen. Heavy client-only interactions may still need Alpine, JS, or a true SPA.

Can Filament replace wp-admin for editors?

For many ops and internal tools, yes. For editorial teams who depend on the WP block editor and a specific plugin stack, not as a drop-in. Plan content editing separately from ops CRUD. Match LaraDashboard (or any Laravel CMS) to your editor workflow before promising parity.

Will my WP keyboard shortcuts carry over?

Almost never 1:1. Budget a short training doc. Focus on list filters, save, and bulk actions first. Shortcuts are secondary to clear primary actions.

Does Livewire remove the need for admin AJAX skills?

It replaces many custom AJAX endpoints with component actions. You still need to authorize every action, validate input, and keep queries fast. The skill shifts from "write admin-ajax handlers" to "design Livewire components responsibly."

How does LaraDashboard relate to Livewire and Filament?

LaraDashboard is our Laravel admin and CMS product shell with modules and Spatie roles. Filament is a popular admin kit built on Livewire. You typically choose a primary admin approach rather than stacking every kit. We disclose our product interest and still recommend Filament when a Filament-centered panel is the better ownership model for your team.

Final verdict

Livewire admin UX gives power users reactivity, in-place validation, and coherent table/form patterns without leaving Laravel for a second SPA. Classic WordPress admin still wins on ecosystem familiarity, plugin density, and editorial muscle memory when your product lives in that world.

The deciding question is not "which is modern?" It is "which admin model matches how our operators work, and who owns the screens after launch?" If plugin menus and uneven AJAX define your pain, Livewire-based admin kits or a LaraDashboard-style Laravel shell are worth a serious prototype. If WP power users are your scarce resource and the plugin stack is under control, invest in wp-admin clarity before rewriting.

If you want a Laravel admin and CMS path with modules and Spatie-backed roles, try LaraDashboard. Prototype your top three operator tasks on a Livewire screen, and only then commit a migration checklist for content and media.

Wire Cursor and Claude to Your Laravel CMS with MCP (Skip the Paste Loop)

Maniruzzaman Akash — Mon, 28 Sep 2026 04:13:42 +0000

You already draft in Cursor or Claude. Then you open the CMS admin, paste HTML, hunt for the right status, and hope the featured image path is right. The agent wrote the words. You still did the busywork.

This guide is about connecting AI coding agents (Cursor, Claude Desktop, and similar MCP clients) to a real Laravel CMS through named tools. Here we stay on content ops: create and update posts, list tickets, work contacts, and keep a human gate on publish.

Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We ship an MCP server with tools for posts, media, tickets, CRM, forms, and ops. We recommend it when you want agents talking to your CMS through named tools and permissions, not through brittle copy-paste.

The short answer

MCP (Model Context Protocol) lets an agent discover tools with schemas and call them. Cursor and Claude act as clients. Your LaraDashboard instance exposes a server. The agent can draft a post into pending status, list open tickets, or pull a daily briefing without you leaving the editor.

Safer ops mean the agent prepares. You approve anything that goes live: publish, send email, delete, or attach media you have not checked. Token abilities and Laravel permissions still apply. An agent is not a superuser because it talks MCP.

Vs ChatGPT paste workflows: paste is fine for a one-off rewrite. It fails when you need post IDs, term IDs, ticket threads, or a consistent status flow. MCP keeps the agent on the same records your admin uses.

What you connect: client, server, token

Three pieces matter in practice.

MCP client. Cursor, Claude Desktop, or another host that speaks MCP.
MCP server. LaraDashboard exposes tools grouped by Content, CRM, Forms, Email, Operations, and Discovery. Each tool has a name, description, and parameter schema.
Auth. You create an MCP token with abilities (for example mcp:posts.read, mcp:posts.write). Laravel permissions on the user still gate actions like post.create or ticket.edit.

If a tool is missing, check installed modules and token abilities with list-mcp-tools, list-modules, and get-site-health. Do not assume every demo screenshot matches your install.

Agent CMS vs paste chat

Compare the job shapes teams actually run:

Draft a blog post: Agent calls create-post with title, HTML content, excerpt, and status=pending vs you paste by hand.
Revise before publish: Agent calls update-post on a known post_id vs you hunt the draft in the admin list.
Assign category: Agent calls assign-post-terms with term IDs from list-terms vs you click category checkboxes.
Triage support: Agent calls list-tickets / get-ticket / reply-ticket vs you retype context into chat.
CRM follow-up: Agent lists contacts or deals, then drafts a note via activity tools vs you copy CRM fields into a chat window.
Ops pulse: Agent calls get-daily-briefing or get-site-health vs you open five admin menus before standup.

Paste chat has no post ID. MCP does.

Content tools agents use every week

These Content tools show up in real editorial loops:

list-posts and get-post for inventory and QA
create-post for draft or pending posts
update-post for content, excerpt, title, status, and publish date
assign-post-terms after list-terms so categories and tags stay consistent
generate-seo-meta when you want a suggested meta title and description (still review soft marketing language)
Media tools (list-media, upload-media, attach-featured-image). Treat media attach as a human-gated step when storage is flaky.

A practical pattern:

Agent drafts Markdown locally.
You convert to clean HTML (or the agent does under review).
Agent creates the post as pending or draft with include_images=false when you do not want AI header images.
SEO pass and human review happen on the pending post.
Only after approval does someone set status=published.

The agent speeds the boring parts. You keep the publish button.

Tickets, CRM, and forms without tab chaos

When the same CMS holds support and CRM modules, the agent can stay in Cursor while you triage:

Tickets: list-tickets, get-ticket, reply-ticket, assign-ticket, update-ticket
Contacts and deals: list-contacts, get-contact, create-contact, list-deals, update-deal
Forms: list-form-submissions, mark-form-submission-viewed
Email: list/get templates; send-email only when you mean to send

Keep write actions behind confirmation. Draft a public ticket reply in the agent. Send only after you read it. Same rule for CRM stage moves and outbound email.

Safe defaults and hard stops

Safe when tools and tokens are scoped:

Read lists and single records
Create pending or draft posts
Update draft content before publish
Draft ticket replies as internal notes first
Pull get-daily-briefing for standup
Discover tools with list-mcp-tools before guessing names

Team rules that help:

Never publish without a human "yes" in the thread.
Never delete posts or media unless named and confirmed.
Never send email or public ticket replies without a quoted preview.
Prefer include_images=false unless you want generated headers.
Log post_id, slug, and status so QA can check the live URL.

Do not let an unsupervised agent flip many posts to published, invent metrics or customer quotes, bypass Spatie roles with a god-token, or treat MCP as a substitute for a public REST API. Scope tokens like you scope deploy keys.

Cursor versus Claude for CMS work

Both can be MCP clients. The useful differences are workflow habits.

Cursor fits when the draft lives next to code: article Markdown in a repo, editorial notes, PR review. The agent edits files, then calls MCP to create the pending post.

Claude Desktop fits when the operator lives in conversation: "list open high-priority tickets," "draft a reply for ticket 42," "create a pending post from this outline."

The LaraDashboard tool surface is the same either way. Pick the client your team will actually leave open.

A concrete day with and without MCP

Without MCP:

Outline in chat
Paste draft into Docs or the CMS
Fix formatting that broke on paste
Open admin to set category and excerpt
Open tickets in another tab
Forget which draft was the latest

With LaraDashboard MCP:

Outline and draft in the agent with your style rules open
Agent creates pending post via create-post
You review in admin or via get-post
Agent assigns your category via assign-post-terms
Agent lists related tickets if the post answers support themes
You publish after review

You still write. You still judge tone. You skip the scavenger hunt.

Setup checklist

Install and enable the MCP-related modules on your LaraDashboard site.
Create a dedicated MCP token with least privilege for the job.
Connect Cursor or Claude as a client using your host's MCP config.
Call list-mcp-tools and get-site-health before the first write.
Run a dry run: create-post with status=pending and a throwaway title.
Add team rules: publish only on approval; media attach policy; no silent deletes.

Prefer official Cursor or Claude MCP docs for connection JSON. Do not paste secrets into public repos.

Failure cases to expect

Payload size limits. Very large HTML bodies may fail on create/update. Keep a full Markdown source.
Soft SEO copy. generate-seo-meta can return marketing-heavy titles. Prefer a manual meta title when that happens.
Missing tools. Disabled modules hide CRM or forms tools. Check list-modules.
Permission errors. Token ability present but user permission missing (or the reverse).
Media storage flakes. If featured-image attach fails, upload manually.

FAQ

Is LaraDashboard MCP the same as a public REST API? No. MCP is for assistant clients with tool schemas. A public product API still wants Sanctum, versioning, and docs. Use MCP for operator agents. Use REST for apps that are not chat clients.

Can the agent publish without me? Only if your token allows it and you allow the call. Prefer pending first, human review, then publish.

Will agents replace our editors? No. Agents draft, list, and prep. Editors own voice, accuracy, disclosure, and publish.

Final verdict

If your team already writes in Cursor or Claude, connecting those agents to LaraDashboard MCP is a practical next step. You get pending posts, ticket context, and CRM reads without turning ChatGPT into a copy-paste modem. You keep humans on publish, send, and delete.

Skip MCP if you publish once a month and paste is fine. Adopt it when content and support share one Laravel CMS and tab-hopping is the tax you pay every day.

If you want that path with MCP tools for agents, try LaraDashboard. Connect a least-privilege token, create one pending post on purpose, and only then wire publish into your editorial checklist.

Role-Based Access for Laravel Client Portals (Spatie + Policies)

Maniruzzaman Akash — Thu, 24 Sep 2026 04:25:41 +0000

You ship a client portal next to your admin panel. Staff need CMS and CRM tools. Clients need their projects, invoices, tickets, and files.

Someone copies the staff role matrix into the portal. A client hits /admin, or changes an ID and reads another account's ticket.

This guide is about portal RBAC in Laravel: how to separate portal users from staff, how Spatie laravel-permission fits that split, and where policies still own "this invoice belongs to that account." It is not a generic Spatie tutorial. For staff-admin UI, middleware, and impersonation, use the companion staff guide on LaraDashboard. Here we stay on the portal surface.

Disclosure up front: we build LaraDashboard, an open-source Laravel admin and CMS. We recommend it for the staff half when you want Spatie-backed roles, modules, and activity logging in one admin. You still own portal routes, membership, and account-scoped policies. The same patterns apply if you use Filament, Nova, or a custom admin.

Staff RBAC is not portal RBAC

Staff admin RBAC answers which internal users can manage content, settings, users, and modules.

Client portal RBAC answers which external users can view or act on their resources, and never on staff-only surfaces.

Spatie gives you roles, permissions, middleware, Blade directives, and optional multiple guards. Laravel policies still decide resource ownership. "Logged in" is not "trusted like staff."

If the portal is a thin "view my invoices" page, a few permissions plus policies may be enough. If you have client admins, viewers, partners, and staff impersonation, write the portal role map before you invent another is_admin flag.

Portal users are not staff with fewer checkboxes

The common shortcut is one users table and one role list: Super Admin, Admin, Editor, Client. You hide admin nav with @can and hope clients never hit /admin.

That fails in three predictable ways:

Route leakage. A guessed admin URL still runs if middleware only checks auth.
Permission name collisions. projects.view means "all projects" for staff and "mine" for clients unless policies enforce ownership.
Role assignment mistakes. Support grants a temporary staff role during debugging and forgets to revoke it.

Same Eloquent model is fine. Same permission namespace for staff-only actions is not. Treat portal actors as a different audience.

Two surfaces, one Laravel app

Most products end up with:

Staff surface: /admin, session auth, Spatie roles for CMS/CRM, activity log, maybe impersonation.
Portal surface: /portal or a subdomain, session or Sanctum auth, portal roles (client-admin, client-member, client-billing), policies filtered by account_id / organization_id.

You can implement both in one codebase. Do not reuse staff permission strings as the only line of defense for portal writes.

Cheat sheet:

Staff goal: operate the product. Portal goal: consume and update own account data.
Staff default deny: no module permission. Portal default deny: no membership on the account.
Staff failure mode: over-privileged editor. Portal failure mode: IDOR across accounts.

RBAC and tenancy are related. They are not the same layer.

What to name in Spatie

Prefer permission names that encode the portal audience:

Good: portal.projects.view, portal.projects.update, portal.invoices.pay, portal.users.invite
Risky: bare projects.view for both staff "all" and client "mine"

Roles group those permissions:

client-admin: invite members, manage billing contacts, view all account projects
client-member: view and update assigned projects only
client-billing: invoices and payment methods
client-viewer: read-only across the account

Keep staff roles (super-admin, editor, support) in a separate naming family. Do not invent a "client-super-admin" that maps to staff middleware.

Seed portal roles in code so production permission strings are not casually renamed in a UI. Optionally expose a subset of portal role management to trusted support users.

Guards: when multiples help

Spatie supports multiple guards as namespaces. Creating edit articles for web does not create it for admin. Assignments must match the user's guard or you get GuardDoesNotMatch errors.

Separate portal guard helps when: portal users are a different authenticatable model, you want hard isolation so staff roles cannot land on portal sessions, or session cookies are already split.

One guard is enough when: one User model with membership, you force a single $guard_name, and route middleware plus policies do the isolation.

Multiple guards add ceremony. Single guard is simpler but demands ironclad middleware on /admin and /portal. Pick one strategy and document it. Mixing "sometimes check guard, sometimes check role name" is how incidents start.

Policies still own account scope

Roles answer capability classes. Policies answer resource instances.

Put rules like these in policies (or FormRequest authorize()), not only in Blade:

User may view Invoice $invoice only if they belong to that account and have portal.invoices.view
User may update Project $project only if they are client-admin or the project is assigned to them
User may never delete staff users, even with a mis-assigned permission string

A permission without a membership check is classic IDOR: change the ID in the URL, read another tenant's ticket. Hide UI with @can, but never trust UI hiding as security.

Six failure cases

Guard mixups. PermissionDoesNotExist after adding a portal guard, or checks use the wrong permission set. Set guard_name explicitly. Pass the guard on checks when you use multiples.
Super-admin leak. A Gate::before that returns true for super-admin also runs on portal routes. Scope god-mode bypass to staff middleware groups only.
Missing policies (IDOR). middleware('permission:portal.projects.view') then Project::findOrFail($id) with no account scope. Prefer forAccount($accountId)->findOrFail($id) plus $this->authorize('view', $project). Add feature tests that swap account IDs.
Staff permission reuse. Client role includes users.manage because a seeder reused the staff matrix. Separate catalogs. Code-review seeders.
Session fixation across surfaces. One session guard serves both route groups. Separate login endpoints, regenerate sessions, reject the wrong audience in middleware. Pair with 2FA for staff.
API tokens without portal abilities. Sanctum token with * or staff permission names. Map abilities to portal permissions only. Revoke on offboarding.

Where LaraDashboard fits

Disclosure again: LaraDashboard ships staff-facing RBAC on Spatie: role UI, permission groups (including module-scoped permissions), middleware, policies, Blade directives, activity logging, and guarded impersonation. That is the foundation for the admin half of a client-portal product.

What you still build for the portal half:

Portal route group and views
portal.* role/permission seeders
Account membership model
Policies that enforce account scope
Optional separate guard if authenticatable models differ
Tests for IDOR and role escalation

LaraDashboard does not replace your portal UX or tenancy rules. It reduces the cost of running a secure staff admin next to that portal.

Suggested build order

Write the role map on paper. Staff vs portal. No shared "admin" name for both.
Seed portal.* permissions. Attach to portal roles only.
Lock staff routes with staff middleware (and/or admin guard). Confirm clients get 403 on /admin.
Add membership + policies before fancy portal UI.
Add UI that only shows actions the policy allows.
Log role changes.
Test cross-account access, guard mismatch, and super-admin bypass.

Skip step 3 and you debug clients inside settings. Skip step 4 and you debug silent data leaks.

Ending note

Client portal security fails when you treat portal users as "staff with fewer boxes ticked." Separate the audiences in naming, middleware, and policies. Use Spatie for role storage. Use Laravel policies for account-scoped resources. Use LaraDashboard for the staff admin with auditable RBAC while you keep portal rules in your app code.

For the full walkthrough with FAQ and deeper guard tradeoffs, read the canonical post:

https://laradashboard.com/blog/role-based-access-for-client-portals-with-spatie-and-laradashboard

If you want a Laravel admin that already speaks Spatie roles for the staff side, try the demo or docs on laradashboard.com.

Layered Abuse Control for Self-Hosted Laravel Admins

Maniruzzaman Akash — Mon, 21 Sep 2026 04:20:41 +0000

You locked HTTPS. You hardened login. Backups are on a calendar.

Bots still hammer admin login and public forms all day.

Credential stuffing does not need a clever zero-day. It needs an open port and a patient script. A host firewall, a reverse proxy with sane headers, a WAF layer, fail2ban, and Laravel rate limits close that abuse gate. Without them, auth and patches only slow the noise.

This is a practical layering guide for self-hosted Laravel CMS admins. It focuses on login, contact forms, and API abuse. Disclosure up front: we build LaraDashboard, an open-source Laravel admin and CMS. The patterns apply to any Laravel app you own. Use LaraDashboard when you want routes and forms you can throttle on purpose instead of waiting on a pile of plugins.

Why layers beat a single shield

Many teams enable HTTPS and hope. Others put Cloudflare in front and skip app-level throttles. Both leave gaps.

Your origin IP can still get hit. Laravel still pays for every request that reaches PHP. Edge rules will not catch every bypass path.

Aim for layered controls:

Block what should never reach the box (host firewall).
Terminate TLS and add headers at the reverse proxy.
Filter hostile shapes at a WAF before PHP runs.
Ban repeat offenders with fail2ban.
Cap what the app accepts per IP and per user with Laravel RateLimiter.

Auth without traffic controls still leaves you open to stuffing and spam.

Host firewall: deny by default

Start on the OS. If SSH, HTTP, and HTTPS are the only public services, close everything else.

On Ubuntu/Debian with ufw:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Confirm SSH still works before you close the laptop. Prefer allowlisting SSH from stable admin egress when you can.

Do not expose MySQL, Redis, Elasticsearch, phpMyAdmin, or queue dashboards on public ports. Bind them to localhost or a private network. Cloud security groups should match the host rules so the next operator is not confused by a wide cloud rule and a tight ufw.

Reverse proxy: nginx or Caddy

Laravel should sit behind nginx or Caddy in production. The proxy terminates TLS, sets headers, and forwards to PHP-FPM or your container.

Serve HTTPS only. Redirect HTTP to HTTPS. Set TrustProxies so X-Forwarded-For and X-Forwarded-Proto come from your proxy only. Wrong trust settings break HTTPS detection and rate-limit IP keys.

Add headers you can maintain: HSTS (once HTTPS is solid), X-Content-Type-Options: nosniff, a sane Referrer-Policy, and frame controls. Start CSP in report-only if a Livewire admin breaks.

Point the document root at public/ only. Hide /.env and /vendor. Cap client_max_body_size on public forms. Prefer limit_req zones on login and form locations when you want edge throttling before PHP.

One proxy config in git beats tribal knowledge on the box.

WAF: buy time, not a substitute for patches

A WAF inspects HTTP for known attack shapes: SQLi probes, XSS payloads, path traversal, noisy bots. It is not a substitute for patching. It reduces noise.

ModSecurity + OWASP CRS works on nginx/Apache. Run DetectionOnly first. Whitelist narrow paths that break (uploads, some Livewire endpoints). Paranoia mode will fight a rich CMS editor if you skip tuning.

CDN WAF (Cloudflare and similar) gives managed rules without maintaining CRS yourself. Lock the origin so only the CDN can reach app ports. If the origin IP is public and open, attackers bypass the WAF entirely.

Small VPS with one CMS: CDN WAF plus host firewall is often enough. Air-gapped hosts: ModSecurity on the proxy. High traffic APIs: combine edge WAF with precise Laravel throttles so good API keys are not painted like scrapers.

fail2ban as a backstop

fail2ban watches logs and turns abuse into firewall drops.

Enable the sshd jail. Prefer key-only SSH. For the web, filter nginx/Caddy logs for repeated POST /login failures or contact endpoint floods. If Laravel logs auth failures, point a jail there.

Whitelist office and VPN egress. After you adopt a CDN, ban the real client IP, not the CDN edge. That means correct forwarded headers in both the proxy and the jail filters.

Laravel rate limits that actually share state

Edge controls reduce volume. App rate limits decide how many attempts a client may make against login, password reset, forms, and APIs.

Define named limiters:

RateLimiter::for('login', function (Request $request) {
    return Limit::perMinute(5)->by($request->ip());
});

Attach throttle:login on the login POST. Use stricter limits on password reset and 2FA challenge routes. Attackers often pivot there after login is locked.

Public APIs need separate budgets from browser forms. Authenticated tokens can be keyed by user or token. Return proper 429 with Retry-After.

Cache driver matters. Counters live in cache. Use Redis (or another shared store) with multiple app nodes. The file driver gives each node its own generous budget.

If you customized Fortify/Breeze login, verify built-in login rate limiting is still wired. Custom controllers often forget it.

Login and forms are the loud endpoints

Treat admin login and public forms as high-value.

Combine strong passwords, 2FA, throttle middleware, fail2ban on repeated failures, and optional VPN or allowlist for /admin when team size allows. Use generic login errors to reduce account enumeration.

On public forms: honeypot, time-based checks, throttle, optional CAPTCHA when spam stays high, server-side validation always, upload caps at the proxy.

During a stuffing run, occasional 429s for real users beat an open login. Document how to unban an IP and how to raise a limiter temporarily during a launch.

A short checklist

Layer	Check
Host	Deny-by-default; only SSH/80/443 (or VPN) public
Host	DB/Redis/queue ports not public
Proxy	TLS + headers; docroot `public/`; TrustProxies correct
WAF	CDN WAF or tuned ModSecurity; origin locked
fail2ban	sshd + login/form jails; office IPs whitelisted
Laravel	Named limiters on login, reset, forms, API; Redis cache
Forms	Honeypot/CAPTCHA as needed; upload caps
Ops	Alert on ban spikes and 429 floods; unban runbook

Common failure cases

Open origin behind CDN: attackers skip the WAF. Firewall origin to CDN ranges or a tunnel.
Wrong client IP: every visitor shares one proxy address. Fix TrustProxies and real_ip.
Throttle only in nginx: internal routes still see abuse. Keep Laravel limits too.
Untuned CRS: blocks editors. DetectionOnly, then narrow allowlists.
file cache on many nodes: limits reset per box.
fail2ban on CDN IPs: you ban infrastructure, not bots.

Where LaraDashboard fits

Disclosure again: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you want a self-hosted CMS you own, with content, media, roles, and forms in one Laravel-native back office.

You still own the firewall, proxy, WAF, and rate-limit wiring. That is the point versus a shared host you cannot tune. Standard Laravel middleware and your reverse proxy apply. LaraDashboard does not replace ufw, fail2ban, or a CDN WAF. It gives you routes and forms you can throttle on purpose.

Ending note

Firewall, WAF, and rate limiting close the abuse gate on a self-hosted Laravel CMS. Deny unused ports, terminate TLS at nginx or Caddy, filter at a WAF, ban repeat offenders with fail2ban, and throttle login and forms in Laravel.

Keep this next to your HTTPS, auth, and backup checklists. For the full walkthrough with FAQ and the living checklist table, read the canonical post on LaraDashboard:

https://laradashboard.com/blog/firewall-waf-and-rate-limiting-for-self-hosted-laradashboard

If you want a Laravel-native CMS you can harden on your own terms, try the demo or docs on laradashboard.com.

Stop Being the Copy-Paste Bridge — MCP for Everyday CMS Work

Maniruzzaman Akash — Fri, 18 Sep 2026 19:25:20 +0000

You open the admin. Then chat. Then email. Then the form inbox. Then the CRM.

By mid-morning you have ten tabs and three half-finished tasks. Nothing is hard. Everything is slow. You are the integration layer.

That is the part most "AI for CMS" demos skip. They rewrite a paragraph in a chat window. Your real work still lives in drafts, tickets, media uploads, and publish buttons.

MCP (Model Context Protocol) is the boring fix for that gap.

What MCP actually is

MCP is an open standard for connecting AI clients to apps and data. A server describes tools with schemas. The assistant discovers them and calls them. It does not guess your API shape.

A chatbot that only talks ends at text. You still own every paste.

An MCP-connected assistant can list tickets, draft a post, search docs, or prepare an email inside your real systems. The win is not "smarter prose." The win is structured access.

You still write. You still decide. You stop acting as the only bridge between chat and the admin UI.

Where the day goes without it

Task	Manual today	With MCP + a small approval loop
Publish a blog draft	Find draft, edit, set status, save	Assistant updates draft; you confirm publish
Triage tickets	Scan list, open threads, assign	Assistant lists open items; you approve assigns
Form inbox	Open each submission, mark viewed	Assistant lists unviewed; you approve marks
Daily "what needs me?"	Hop across modules	Assistant returns one briefing list
Attach a featured image	Upload, open post, attach	Assistant uploads or finds media; you confirm
Clear cache after a change	Ops screen or SSH	Assistant calls clear after you confirm

Notice what stays manual on the right: confirmation, tone, judgment. Busywork moves. Responsibility does not vanish.

The pattern that keeps production safe

Full autopilot fails for boring reasons. Wrong IDs. Tone misfires. Deletes that stick. Secrets in the wrong place.

Use three defaults:

1. Read, then propose

List first. Propose the next action in plain language. Fix the plan before any write runs.

2. Draft, then approve

Create posts as draft. Draft the public reply. Prepare the email fields. Humans confirm publish, send, and delete.

3. Dry-run, then apply

Prefer tools that show what would change. Apply only after a human yes.

Map your tools to those stages so the team shares a vocabulary:

Read: list posts, list tickets, list form submissions, search docs, daily briefing, site health
Draft: create-post as draft, draft reply text, prepare send fields
Approve write: publish, reply, send email, clear cache, delete

Security is part of the product, not a footnote

Treat an MCP connection like any other privileged integration.

Scoped tokens. One token per agent or host. Not one forever token shared across laptops and CI. Rotate when people leave.

Least privilege. Start read-only. Add write abilities when you have an approval habit and an audit path. Separate read from write when the host allows it.

Skip MCP when:

You do not trust the system yet
There is no staging twin and no audit log for a production database
The flow is highly regulated and legal has not reviewed write tools
The job is an angry public customer reply (draft is fine; send still needs a human)
Personal mail with broad send rights on day one

If you cannot explain who may call a tool and how you will audit it, do not expose that tool yet.

Failure modes that bite teams

Vague tools. doStuff helps no one. list-form-submissions with filters for form and unviewed state helps immediately. Fix the catalog before you blame the model.

Over-permission. A token with every ability turns a prompt mistake into a wide outage. Expand with intent, not "just make it work."

Silent success. A tool that returns success while doing nothing is worse than a loud error. Prefer clear failures. Watch partial success: post created, image attach failed.

Confused identity. Shared tokens blur audit trails. Give people their own tokens tied to their permissions when you can. Shared robots for CI are fine. Shared robots for human editors are not.

A starter set (week one)

Three tools beat thirty.

Content teams

Daily briefing
Create post as draft
Update post (publish only after review)

Support teams

List open tickets
Summarize a thread
Draft a reply (do not send until confirmed)

Measure progress without fake ROI charts. Count tab switches during a publish. Count minutes from "please draft this" to a reviewable draft. If those fall across two weeks, the setup is working. If not, fix the catalog or the approval habit.

How this looks on LaraDashboard (disclosure)

Disclosure: I work on LaraDashboard, an open-source Laravel CMS and admin with an optional built-in MCP server. Steal the workflow even if you wire your own server.

On LaraDashboard, MCP lives under Settings → MCP. You create agent tokens and attach abilities. Tools cover posts, media, daily briefing, email templates, CRM/tickets, forms, docs, cache, and logs — filtered by token abilities and the linked user's permissions.

A practical getting-started checklist:

Enable MCP
Create a dedicated agent token (do not reuse a browser session)
Grant least-privilege abilities (start read-only)
Connect Cursor, Claude Desktop, or another MCP client
Call list-mcp-tools and verify the catalog
Run a read-only test (list-posts or daily briefing)
Run a draft write test (create-post as draft)
Practice an approval loop on publish or send
Add media upload only when needed
Document who approves which writes; expand abilities only after the first workflow feels stable

Most "MCP is broken" reports are scope issues: token abilities, module status, or site health — not the protocol itself.

What "done" looks like for a pilot

One read workflow used daily for two weeks
One write workflow with confirmations and zero surprise publishes
Tokens named, scoped, and stored outside chat
A short internal doc with house rules and starter tools
A known owner for catalog changes
A rollback plan: revoke token, disable MCP, continue in the admin UI

Ending note

You do not need a larger chatbot. You need fewer tab hops between intent and a reviewable action.

MCP gives assistants a clear door into your systems. A small human loop keeps publish, send, and delete under your control.

Start narrow. Read first. Add one write workflow. Keep confirmations on the actions you would hate to undo.

The longer original (with more LaraDashboard-specific tool mapping) lives here — this Dev.to version is adapted from it, and that URL is the canonical source:

How MCP Makes Everyday Work Easier (With a Small Human in the Loop)

Try the product at laradashboard.com if you want that door inside a Laravel CMS you can own.

Stop Building Laravel Admin Panels From Scratch — Meet Lara Dashboard

Maniruzzaman Akash — Sat, 14 Feb 2026 07:12:39 +0000

Hey there, fellow Laravel developer!

Are you still spending weeks building the same boring admin panel features for every client project? User management, role management, permissions, blog systems, media libraries... the list goes on.

What if I told you there's a 100% free, open-source solution that gives you all of this — and more — out of the box?

Let me introduce you to https://laradashboard.com — your all-in-one marketplace CMS solution for Laravel.

The Pain We All Know Too Well

Every Laravel project starts the same way:

"I need user authentication with role-based access control"
"I need a beautiful admin dashboard with charts"
"I need content management — posts, pages, categories, tags"
"I need a media library for file uploads"
"I need email templates and notification management"
"I need multi-language support"
"I need activity logging for audit trails"
"I need REST APIs for mobile apps"
"Oh, and I need AI-powered content generation because it's 2026"

Sound familiar? You've probably built these features dozens of times. Each time reinventing the wheel, each time spending precious hours on boilerplate instead of your client's actual business logic.

What if you could skip all that and focus on what actually matters?

What is Lara Dashboard?

Lara Dashboard is a complete, production-ready Laravel admin panel and CMS that comes with everything you need to kickstart any Laravel project.

Built on the latest tech stack:

Laravel 12.x with PHP 8.3/8.4
Livewire 3 for reactive components
Tailwind CSS 4 for beautiful, responsive UI
Alpine.js for lightweight interactivity
Laravel Pulse for real-time monitoring
Laravel Sanctum for API authentication
Pest for modern testing

It's not just another admin template. It's a fully functional application with business logic, services, tests, and a modular architecture that lets you extend it infinitely.

Features That'll Make You Say "Finally!"

User & Access Management

Complete user CRUD with profile management
Role-based access control (RBAC) using Spatie Permissions
Granular permission system with grouped permissions
Admin impersonation — log in as any user for debugging
Beautiful user detail pages with activity history

Content Management System (CMS)

Posts and Pages with visual drag-and-drop builder
Categories and Tags with hierarchical structure
SEO-friendly URLs and meta management
Media library with image optimization
Content scheduling and drafts

AI-Powered Content Generation

Built-in AI Agent for content creation
Support for OpenAI, Anthropic, and other providers
Inline AI editor for posts and pages
Fine-tuning options for tone and style

Email Management

Visual email template builder (drag-and-drop blocks)
Multiple email connections (SMTP, Mailgun, etc.)
Inbound and outbound email management
Notification system with customizable triggers

Translation & Localization

21+ languages supported out of the box
Easy translation management UI
Add any new language in seconds
RTL support ready

Monitoring & Security

Activity logging for every action
Laravel Pulse integration for real-time metrics
Laravel Telescope for debugging
reCAPTCHA integration
Customizable login page settings

Developer Experience

Modular architecture — add/remove features as modules
CRUD Generator — scaffold complete CRUD in one command
WordPress-like hooks — action/filter system for extensibility
REST API with auto-generated Scramble documentation
Comprehensive test suite — Pest, PHPStan, Rector, Pint

The Module System — This Changes Everything

Here's where Lara Dashboard really shines. It uses a modular architecture powered by https://laravelmodules.com/.

This means:

Install only what you need — Don't need a blog? Don't enable the module.
Add features via marketplace — Browse and install modules with one click.
Build your own modules — Create custom functionality that plugs right in.
Share or sell your modules — Build once, monetize forever.

CRUD Generator — Your New Best Friend

Need to add a new entity to your project? One command does it all:

# Create migration
php artisan module:make-migration create_products_table Shop

# Run migration
php artisan migrate

# Generate complete CRUD
php artisan module:make-crud Shop --migration=create_products_table

What you get:

Model with fillable fields and casts
Datatable with sorting, searching, pagination
Index, Show, Create, Edit Livewire components
Blade views with breadcrumb navigation
Routes and sidebar menu item

From zero to fully functional CRUD in under 60 seconds. No joke.

Is It Really Free?

Yes, 100% free and open source.

The core is completely free under the MIT license. You can use it for personal projects, client work, SaaS products — whatever you want.

There are also premium modules available at https://laradashboard.com if you need advanced features like:

CRM (Customer Relationship Management)
HRM (Human Resource Management)
Course Management
E-commerce
And more coming...

But the core? Completely free. Forever.

Getting Started in 5 Minutes

# Clone the repo
git clone git@github.com:laradashboard/laradashboard.git
cd laradashboard

# Setup environment
cp .env.example .env

# Install dependencies
composer install
npm install

# Generate key and link storage
php artisan key:generate
php artisan storage:link

# Run migrations with seed data
php artisan migrate:fresh --seed

# Start the server
composer run dev

Open http://localhost:8000 and log in:

Email: superadmin@example.com
Password: 12345678

That's it. You now have a fully functional admin panel.

Try Before You Clone

Want to see it in action first?

Live Demo: https://demo.laradashboard.com?source=dev.to

Email: superadmin@example.com
Password: 12345678

Play around. Break things. The demo resets automatically.

Documentation That Actually Helps

We've invested heavily in documentation because we know how frustrating bad docs can be.

Full documentation: https://laradashboard.com/docs

Covers everything from:

Installation and configuration
User and role management
Module development
CRUD generator usage
API integration
Deployment guides
And much more...

The Tech Stack You'll Love

| Technology | Version | Purpose |
|-------------------|---------|-------------------------|
| Laravel | 12.x | Backend framework |
| PHP | 8.3+ | Server-side language |
| Livewire | 3.x | Reactive components |
| Tailwind CSS | 4.x | Styling |
| Alpine.js | 3.x | Frontend interactivity |
| Laravel Pulse | 1.5 | Real-time monitoring |
| Laravel Sanctum | 4.3 | API authentication |
| Laravel Telescope | 5.17 | Debugging |
| Pest | 4.x | Testing |
| React | 18.x | Page builder components |

All the modern tools. All working together. All tested.

Deployment Made Easy

Lara Dashboard works everywhere:

VPS/Dedicated servers — Standard Laravel deployment
Shared hosting (cPanel) — Root index.php included, no document root changes needed
Docker — Laravel Sail support built-in
Cloud platforms — Works with Forge, Vapor, DigitalOcean, AWS, etc.

We even have a distribution package builder that creates production-ready ZIP files with vendor dependencies included — perfect for clients who can't run Composer.

Join the Community

Lara Dashboard is built by developers, for developers. We'd love to have you:

GitHub: https://github.com/laradashboard/laradashboard
Facebook Group: https://www.facebook.com/groups/laradashboard
LinkedIn: https://www.linkedin.com/groups/14690156
YouTube: https://www.youtube.com/@laradashboard (tutorials coming!)

Contributing

Found a bug? Have a feature idea? PRs are always welcome!

The codebase follows strict standards:

Pint for code formatting
PHPStan/Larastan for static analysis
Rector for automated refactoring
Pest for testing

Run composer run test and everything is checked automatically.

Why Choose Lara Dashboard?

| Feature | Building from Scratch | Lara Dashboard |
|--------------------|-----------------------|----------------|
| User Management | Hours/Days | Included |
| Role & Permissions | Hours | Included |
| CMS (Posts, Pages) | Days | Included |
| Media Library | Hours | Included |
| Email Management | Hours | Included |
| AI Integration | Days | Included |
| Multi-language | Hours | Included |
| Activity Logging | Hours | Included |
| REST API | Days | Included |
| Monitoring | Hours | Included |
| Beautiful UI | Days | Included |
| Tests | Days | Included |
| Total | Weeks | Minutes |

The math speaks for itself.

Final Thoughts

Stop reinventing the wheel. Stop building the same features over and over. Stop wasting time on boilerplate.

Lara Dashboard gives you a 6-month head start on every Laravel project.

Clone it. Customize it. Ship it.

Your clients will thank you. Your deadline will thank you. Your sanity will thank you.

Ready to try it?

Demo: https://demo.laradashboard.com?source=dev.to
GitHub: https://github.com/laradashboard/laradashboard
Docs: https://laradashboard.com/docs

Drop a star on GitHub if you find it useful. And let me know in the comments what features you'd love to see next!

Happy coding!

Built with love by the Laravel community. Powered by Lara Dashboard.

Next Generation Admin Template with Laravel for Best Coding practice

Maniruzzaman Akash — Tue, 26 Aug 2025 20:10:16 +0000

I'm talking today with a Real Admin Dashboard / Laravel based admin template solution, which really matters. Its not some simple CRUD interfaces. Its an architecture for your laravel project, its a standard to build a Laravel based application.
Its a CMS for your Laravel App, Introducing Lara Dashboard - https://github.com/laradashboard/laradashboard

Why it matters most:

Its UI - Its UI is clean, minimal, rich for any Laravel starter application.

All of the core features what you planning to add on your project is already being added.
In build unit tests with Pest Unit test with Feature, Unit, Browser tests included.
UI's are clean, minimal and researched.
Well architectured code.
Modular and highly extendible, They are planning to add Module marketplace soon and already they have core modules built in, which are rich too.
Dark mode supported under the hood.
Beautiful responsive supported.
Every action is tracked inside Monitoring.
Role permission management system added.
Media library added.
Beautiful blade component library with documentation.
Easy settings page.

See some demos before more talking.

Dashboard

User Profile

And here are some little demos -

Media library

Sign In Page

Module List

For more, please visit to https://laradashboard.com/try-demo/

Demo

Try Live Demo - https://laradashboard.com/try-demo/
Github Repo - https://github.com/laradashboard/laradashboard

Feature Request

Any more feature request, please add it here - https://feedback.laradashboard.com/

Best Admin Template with Laravel for 2025: Lara Dashboard

Maniruzzaman Akash — Mon, 23 Jun 2025 08:12:53 +0000

In the ever-evolving web development landscape, Laravel continues to dominate as a favorite PHP framework due to its elegant syntax, robust features, and growing ecosystem. For developers seeking to build sophisticated, scalable web applications quickly, the right admin dashboard template can be a game-changer.

Download Now - https://github.com/laradashboard/laradashboard

As we step into 2025, one admin template stands out from the rest: Lara Dashboard. This article explores why Lara Dashboard is the best Laravel admin template for modern developers and agencies.

🚀 What is Lara Dashboard?
Lara Dashboard is a fully-featured, premium admin template built specifically for Laravel. It offers seamless integration with Laravel’s backend architecture, making it a perfect starter kit for building advanced web applications, CMSs, SaaS platforms, and admin interfaces.

It is developed with clean, modular code and modern design aesthetics, ensuring both ease of customization and a great user experience.

🎯 Key Features
✅ Laravel 10+ Compatibility
Lara Dashboard is fully compatible with the latest Laravel versions, ensuring developers benefit from the most current performance enhancements, security features, and syntax updates.

🧩 Blade + Livewire Integration
Designed with Laravel Blade components and Livewire integration out-of-the-box, Lara Dashboard enables reactive, dynamic interfaces without writing custom JavaScript.

🎨 Modern UI & UX
Built using modern UI trends and responsive design, it delivers a polished, intuitive interface across all devices. It uses Bootstrap 5 and is compatible with Tailwind for custom styling needs.

🔐 Authentication & User Management
Comes pre-configured with Laravel Breeze/Fortify-based authentication and user roles & permissions. This saves hours of initial setup for developers.

📊 Ready-to-Use Components
Lara Dashboard includes:

Charts and graphs (via Chart.js & ApexCharts)

Dynamic data tables

Calendar integration

Forms with validation

File uploads

Modals, notifications, tabs, and more.

🧪 Modular & Scalable Code
Code is clean, well-commented, and modularized for scalability. It follows PSR-12 coding standards and Laravel best practices.

🛠️ Developer Experience
⚙️ Easy Installation
The template comes with a CLI-based installer and complete documentation. Simply run a few artisan commands, and you’re ready to go.

📦 RESTful API Ready
API scaffolding is built-in, allowing seamless integration with frontend frameworks like Vue.js, React, or mobile apps.

💼 Perfect for Agencies & Freelancers
Whether you're building a CRM, project management tool, or dashboard for a SaaS app, Lara Dashboard provides the building blocks to launch faster and with confidence.

📈 Why Lara Dashboard is Best in 2025
Performance First: Optimized asset loading, lazy loading, and minimal dependencies ensure speed and efficiency.

Ongoing Updates: Frequent updates aligned with Laravel's release cycle ensure stability and future-proofing.

Community & Support: Active support community and documentation make it easy to troubleshoot and extend functionality.

Customization: Extensive layout and theme options let developers tweak UI easily for client-specific branding.

💬 What Developers Are Saying
“Lara Dashboard helped us cut project delivery time by 40%. It’s like Laravel and design thinking had a baby.”
— Adeel K., Software Engineer

“The Livewire integration was buttery smooth. Zero JavaScript headache.”
— Maria V., Freelance Laravel Developer

🔗 Get Lara Dashboard
You can get started with Lara Dashboard by visiting the official page (replace with actual URL) or exploring its GitHub repo (if open-source).

🏁 Final Thoughts
Lara Dashboard sets the gold standard for Laravel admin templates in 2025. With its modern UI, feature-rich components, and deep Laravel integration, it empowers developers to build robust applications faster than ever before.

If you're planning your next Laravel-based project, Lara Dashboard is not just an option — it's the best choice.

Download Now - https://github.com/laradashboard/laradashboard

Advanced Laravel Dashboard for your application in 2025

Maniruzzaman Akash — Thu, 24 Apr 2025 07:19:35 +0000

🚀 Lara Dashboard – A Complete Role & Permission System for Laravel (with Dark Mode, Settings, Modules & More)

Hey Laravel Devs 👋

Tired of rewriting the same Role & Permission logic in every project? Let me introduce you to Lara Dashboard – a powerful Laravel starter kit packed with features to speed up your backend development. It's modular, beautiful, and 100% open-source.

✅ Live Demo: https://demo.laradashboard.com

🔐 Login:

Email: superadmin@example.com

Password: 12345678

⭐ GitHub Repo: github.com/laradashboard/laradashboard

🎯 What is Lara Dashboard?

Lara Dashboard is a modern admin panel built with Laravel, Tailwind CSS, and a fully modular structure. It’s designed to give you:

A ready-to-use Role-Based Access Control system
Clean UI with dark/light modes
Advanced user, role, and permission management
Modular architecture to scale your app easily
Action logs, charts, forms, and even Laravel Pulse integration

Whether you’re building a SaaS platform, admin interface, or internal tool — this dashboard gives you a solid base so you can focus on building features, not scaffolding.

🧰 Core Features

✅ Role & Permission System (using Spatie/Permission)

🌗 Tailwind UI with Dark/Light Mode

👥 Multi-role User Management

🧩 Modular Development Support

🕵️‍♂️ Admin Impersonation

📈 Dashboard with Charts

📋 Action Logs & Laravel Pulse Monitoring

⚙️ Full Settings Panel (Appearance, Integrations, etc.)

📧 Email Ready (supports Mailtrap, SMTP, etc.)

🔥 Custom Error Pages

🧪 PHPUnit Ready

✨ Visual Sneak Peek

Light Mode Dashboard

Dark Mode Dashboard

More demos

Settings

Users

Roles

Action Logs

Laravel Pulse

Forget password

Modules

🛠️ Quick Installation Guide

git clone git@github.com:laradashboard/laradashboard.git
cd laradashboard
composer install
npm install
cp .env.example .env
php artisan key:generate
php artisan storage:link
php artisan migrate:fresh --seed && php artisan module:seed
php artisan serve
npm run dev

Visit: http://localhost:8000

Login with the demo credentials and you’re in 🚪

💡 Why Developers Love It

Time Saver: Avoid rebuilding roles, permissions, and dashboards for every project.
Modular: Easily extend with modules like CRM, HRM, Course Management.
Production Ready: Includes settings panel, password reset, profile management, etc.
Clean & Scalable: Separation of concerns using services, helpers, and modules.

🔌 Mail Setup (Optional)

Testing email flows? Use Mailtrap with this config:

MAIL_MAILER=smtp
MAIL_HOST=sandbox.smtp.mailtrap.io
MAIL_PORT=587
MAIL_USERNAME=your-username
MAIL_PASSWORD=your-password
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=you@example.com
MAIL_FROM_NAME="${APP_NAME}"

🌟 Contribute & Support

Lara Dashboard is fully open-source and made with ❤️ by Maniruzzaman Akash.

If it helps you:

Give it a ⭐ on GitHub
Submit a PR
Buy a coffee ☕ on Patreon

🔮 What’s Coming Next?

Premium modules are on the way at laradashboard.com, including:

CRM
HRM
Course Management
...and more!

🗣 Final Words

If you’re working on a Laravel project and want a ready-made admin panel with role management, modularity, and gorgeous UI — Lara Dashboard will save you hours of work.

Check it out, clone it, star it, and let’s build amazing things together! 🚀

👉 https://github.com/laradashboard/laradashboard

Let me know if you'd like a preview thumbnail, meta description, or social share banner to go with your Dev.to post — I can create those too!

How to Build a Beautiful Todo Application Using React JS and Custom CSS

Maniruzzaman Akash — Sun, 01 Dec 2024 11:57:41 +0000

In this post, we'll walk through building a fully functional Todo application using React JS, custom CSS, and the SimpleCRUD API to handle backend operations like data fetching, pagination, creation, updates, and deletions.
The SimpleCRUD API simplifies backend complexities, letting us focus on building the UI and handling interactions effectively. Let's dive into the components of the application.

Setting Up the Environment

Required Libraries
Ensure you have the following libraries installed in your React project. These are already mentioned in your package.json:

React & React-DOM: For building the UI.
Axios: For making HTTP requests to the SimpleCRUD API.
React Icons: For icons to improve user experience.
date-fns: For formatting dates.

Project Structure

Here's how the project is structured - its using create-react-app.

/public
  /index.html
/src
  api.js
  App.js
  styles.css
  index.js
package.json

Backend API Integration

The src/api.js file handles all the interactions with the SimpleCRUD API.

Simple CRUD API Docs for Todos - https://simplecrudapi.com/docs/todos

import axios from "axios";

const API_URL = "https://simplecrudapi.com/api/todos";

export const getTodos = async (params) => {
  let apiUrl = `${API_URL}?orderBy=id&orderDirection=desc`;
  const response = await axios.get(apiUrl, { params });
  const { data, meta } = response.data;
  return { data, meta };
};

export const createTodo = async (todo) => {
  todo.user_id = null;
  const response = await axios.post(API_URL, todo);
  return response.data.data;
};

export const updateTodo = async (id, todo) => {
  todo.user_id = null;
  const response = await axios.put(`${API_URL}/${id}`, todo);
  return response.data.data;
};

export const deleteTodo = async (id) => {
  const response = await axios.delete(`${API_URL}/${id}`);
  return response.data.data;
};

getTodos: Fetches a paginated list of todos.
createTodo: Creates a new todo.
updateTodo: Updates an existing todo.
deleteTodo: Deletes a todo by its ID.

Application Logic File: App.js This file contains the main application logic: State management for todos, form data, pagination, and editing. CRUD operations: Fetch, add, edit, and delete todos. Pagination controls: Navigate through pages of todos.

Walkthrough
Initial Setup
Use useState to manage the app's state, including todos and pagination details.
Use useEffect to fetch todos when the page loads or pagination state changes.

Todo Operations
Add a new todo or update an existing one using handleSubmit.
Delete a todo with handleDelete.
Edit a todo by populating the form fields with the selected todo's data.

Pagination
Handle pagination using changePage to navigate between pages.

Key Code Snippets

Fetching Todos

const fetchTodos = async (page = 1) => {
  try {
    const { data, meta } = await getTodos({ page });
    setTodos(data);
        setPagination((prev) => ({
          ...prev,
          currentPage: meta?.current_page || 1,
          lastPage: meta?.last_page || 1,
          total: meta?.total || 0,
        }));
      } catch (error) {
        console.error("Failed to fetch todos:", error);
        setTodos([]);
        setPagination((prev) => ({
          ...prev,
          currentPage: 1,
          lastPage: 1,
          total: 0,
        }));
      }
    };

Handling Submit

const handleSubmit = async (e) => {
  e.preventDefault();
  if (editingId) {
    await updateTodo(editingId, form);
    setEditingId(null);
  } else {
    await createTodo(form);
  }

  setForm({ title: "", description: "", completed: false });
  fetchTodos(pagination.currentPage);
};

Pagination

const changePage = (newPage) => {
  if (newPage > 0 && newPage <= pagination.lastPage) {
    setPagination((prev) => ({ ...prev, currentPage: newPage }));
  }
};

Styling the Application

File: styles.css
The CSS file defines a sleek and modern look for the Todo app:
Animations: Subtle fadeIn and slideIn animations enhance user experience.

Responsiveness: Styles adapt well to various screen sizes.
Visual hierarchy: Clear distinction between buttons, input fields, and todo items.

Running the Application

Install Dependencies

npx create-react-app my-todo
cd my-todo
npm start

Install Extra Dependencies

npm install axios react-icons date-fns

Interact with the App

Add new todos using the form.
Edit existing todos by clicking the edit button.
Delete todos by clicking the delete button.
Navigate through pages of todos using the pagination controls.

Complete Source code

The src/App.js file -

import React, { useEffect, useState } from "react";
import { format } from "date-fns"; // Importing date-fns
import { getTodos, createTodo, updateTodo, deleteTodo } from "./api";
import { AiOutlineDelete, AiOutlineEdit } from "react-icons/ai";
import "./styles.css";

function App() {
  const [todos, setTodos] = useState([]);
  const [form, setForm] = useState({
    title: "",
    description: "",
    completed: false,
  });
  const [editingId, setEditingId] = useState(null);
  const [pagination, setPagination] = useState({
    currentPage: 1,
    lastPage: 1,
    perPage: 10,
    total: 0,
  });

  useEffect(() => {
    fetchTodos(pagination.currentPage);
  }, [pagination.currentPage]);

  const fetchTodos = async (page = 1) => {
    try {
      const { data, meta } = await getTodos({ page });

      setTodos(data);
      setPagination((prev) => ({
        ...prev,
        currentPage: meta?.current_page || 1,
        lastPage: meta?.last_page || 1,
        total: meta?.total || 0,
      }));
    } catch (error) {
      console.error("Failed to fetch todos:", error);
      setTodos([]);
      setPagination((prev) => ({
        ...prev,
        currentPage: 1,
        lastPage: 1,
        total: 0,
      }));
    }
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    if (editingId) {
      await updateTodo(editingId, form);
      setEditingId(null);
    } else {
      await createTodo(form);
    }

    setForm({ title: "", description: "", completed: false });
    fetchTodos(pagination.currentPage);
  };

  const handleEdit = (todo) => {
    setEditingId(todo.id);
    setForm({
      title: todo.title,
      description: todo.description,
      completed: todo.completed,
    });
  };

  const handleDelete = async (id) => {
    await deleteTodo(id);
    fetchTodos(pagination.currentPage);
  };

  const changePage = (newPage) => {
    if (newPage > 0 && newPage <= pagination.lastPage) {
      setPagination((prev) => ({ ...prev, currentPage: newPage }));
    }
  };

  return (
    <div className="app-container">
      <div className="todo-wrapper">
        <h1 className="app-title">My Todos</h1>
        <p className="app-description">
          By Simple CRUD API →{" "}
          <a href="https://simplecrudapi.com/docs/todos">Todo API link</a>
        </p>

        {/* Form */}
        <form onSubmit={handleSubmit} className="todo-form">
          <input
            type="text"
            placeholder="Title"
            value={form.title}
            onChange={(e) => setForm({ ...form, title: e.target.value })}
            className="todo-input"
            required
          />
          <textarea
            placeholder="Description"
            value={form.description}
            onChange={(e) => setForm({ ...form, description: e.target.value })}
            className="todo-textarea"
            required
          ></textarea>
          <div className="todo-checkbox-wrapper">
            <input
              type="checkbox"
              checked={form.completed}
              onChange={(e) =>
                setForm({ ...form, completed: e.target.checked })
              }
              className="todo-checkbox"
            />
            <label>Completed</label>
          </div>
          <button type="submit" className="todo-button">
            {editingId ? "Update" : "Add"} Todo
          </button>
        </form>

        {/* Todo List */}
        <div className="todo-list">
          {todos.map((todo) => (
            <div key={todo.id} className="todo-item">
              <div>
                <h2
                  className={`todo-title ${todo.completed ? "completed" : ""}`}
                >
                  {todo.title}
                </h2>
                <p className="todo-description">{todo.description}</p>
                <p className="todo-updated-at">
                  Last updated:{" "}
                  {todo.updated_at
                    ? format(new Date(todo.updated_at), "MMM d, yyyy h:mm a")
                    : "N/A"}
                </p>
              </div>
              <div className="todo-actions">
                <button
                  onClick={() => handleEdit(todo)}
                  className="edit-button"
                >
                  <AiOutlineEdit />
                </button>
                <button
                  onClick={() => handleDelete(todo.id)}
                  className="delete-button"
                >
                  <AiOutlineDelete />
                </button>
              </div>
            </div>
          ))}
        </div>

        {/* Pagination */}
        <div className="pagination">
          <button
            className="pagination-button"
            onClick={() => changePage(pagination.currentPage - 1)}
            disabled={pagination.currentPage === 1}
          >
            &laquo; Previous
          </button>
          <span className="pagination-info">
            Page {pagination.currentPage} of {pagination.lastPage}
          </span>
          <button
            className="pagination-button"
            onClick={() => changePage(pagination.currentPage + 1)}
            disabled={pagination.currentPage === pagination.lastPage}
          >
            Next &raquo;
          </button>
        </div>
      </div>

      {/* Footer */}
      <footer className="app-footer">
        Powered by{" "}
        <a
          href="https://simplecrudapi.com"
          target="_blank"
          rel="noopener noreferrer"
        >
          simplecrudapi.com
        </a>
      </footer>
    </div>
  );
}

export default App;

The src/styles.css file -

/* General App Styles */
.app-container {
  font-family: "Roboto", Arial, sans-serif;
  background: linear-gradient(135deg, #f0f8ff, #e0e7ff);
  min-height: 100vh;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 20px;
  box-sizing: border-box;
}

.todo-wrapper {
  max-width: 650px;
  width: 100%;
  background: #fff;
  padding: 25px;
  border-radius: 12px;
  box-shadow: 0 8px 15px rgba(0, 0, 0, 0.1);
  animation: fadeIn 0.8s ease-in-out;
}

@keyframes fadeIn {
  from {
    opacity: 0;
    transform: scale(0.95);
  }
  to {
    opacity: 1;
    transform: scale(1);
  }
}

.app-title {
  font-size: 28px;
  font-weight: bold;
  text-align: center;
  color: #2c3e50;
  margin-bottom: 12px;
}

.app-description {
  text-align: center;
  font-size: 14px;
  margin-bottom: 25px;
  color: #34495e;
}

.app-description a {
  color: #3498db;
  text-decoration: none;
  font-weight: 500;
}

.app-description a:hover {
  text-decoration: underline;
}

/* Form Styles */
.todo-form {
  margin-bottom: 25px;
}

.todo-input,
.todo-textarea {
  width: 100%;
  padding: 12px;
  margin-bottom: 12px;
  border: 1px solid #dcdfe6;
  border-radius: 6px;
  font-size: 14px;
  box-sizing: border-box;
  transition: border-color 0.3s ease;
}

.todo-input:focus,
.todo-textarea:focus {
  outline: none;
  border-color: #007bff;
}

.todo-textarea {
  height: 90px;
  resize: none;
}

.todo-checkbox-wrapper {
  display: flex;
  align-items: center;
  margin-bottom: 12px;
}

.todo-checkbox {
  margin-right: 8px;
}

.todo-button {
  display: block;
  width: 100%;
  padding: 12px;
  background: #4caf50;
  color: white;
  border: none;
  border-radius: 6px;
  cursor: pointer;
  font-size: 16px;
  font-weight: bold;
  transition: all 0.3s ease;
}

.todo-button:hover {
  background: #45a049;
  transform: translateY(-2px);
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.15);
}

/* Todo List Styles */
.todo-list {
  margin-top: 20px;
}

.todo-item {
  display: flex;
  justify-content: space-between;
  align-items: center;
  background: #fdfdfd;
  padding: 15px 20px;
  border: 1px solid #ddd;
  border-radius: 8px;
  margin-bottom: 12px;
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.05);
  transition: all 0.3s ease;
  animation: slideIn 0.5s ease forwards;
  overflow-x: hidden;
  gap: 10px;
}

.todo-item:hover {
  transform: translateY(-2px);
  box-shadow: 0 6px 10px rgba(0, 0, 0, 0.1);
}

@keyframes slideIn {
  from {
    opacity: 0;
    transform: translateX(-20px);
  }
  to {
    opacity: 1;
    transform: translateX(0);
  }
}

.todo-title {
  font-size: 18px;
  font-weight: bold;
  margin: 0;
  color: #2c3e50;
  word-wrap: break-word;
  word-break: break-word;
  overflow-wrap: break-word;
}

.todo-title.completed {
  text-decoration: line-through;
  color: #7f8c8d;
}

.todo-description {
  font-size: 15px;
  color: #95a5a6;
  margin: 5px 0 0;
  word-wrap: break-word;
  word-break: break-word;
  overflow-wrap: break-word;
}

.todo-actions {
  display: flex;
  gap: 10px;
}

.edit-button,
.delete-button {
  background: none;
  border: none;
  cursor: pointer;
  font-size: 20px;
  transition: all 0.3s ease;
}

.edit-button {
  color: #3498db;
}

.edit-button:hover {
  color: #2980b9;
  transform: scale(1.1);
}

.delete-button {
  color: #e74c3c;
}

.delete-button:hover {
  color: #c0392b;
  transform: scale(1.1);
}

/* Pagination Styles */
.pagination {
  display: flex;
  justify-content: center;
  align-items: center;
  gap: 15px;
  margin-top: 20px;
}

.pagination-button {
  background: #3498db;
  color: white;
  padding: 10px 15px;
  border: none;
  border-radius: 6px;
  cursor: pointer;
  font-size: 14px;
  transition: all 0.3s ease;
}

.pagination-button:hover {
  background: #2980b9;
  transform: translateY(-2px);
}

.pagination-button:disabled {
  background: #95a5a6;
  cursor: not-allowed;
}

.pagination-info {
  font-size: 14px;
  color: #2c3e50;
}

/* Footer Styles */
.app-footer {
  margin-top: 30px;
  text-align: center;
  font-size: 14px;
  color: #555;
}

.app-footer a {
  color: #3498db;
  text-decoration: none;
}

.app-footer a:hover {
  text-decoration: underline;
}

.todo-updated-at {
  font-size: 12px;
  color: #7f8c8d;
  margin-top: 5px;
}

In package.json -

{
  "name": "react",
  "version": "1.0.0",
  "description": "",
  "keywords": [],
  "main": "src/index.tsx",
  "dependencies": {
    "react": "^18.0.0",
    "react-dom": "^18.0.0",
    "react-scripts": "^5.0.0",
    "axios": "1.7.7",
    "react-icons": "5.3.0",
    "date-fns": "4.1.0"
  },
  "devDependencies": {
    "@types/react": "18.2.38",
    "@types/react-dom": "18.2.15",
    "loader-utils": "3.2.1",
    "typescript": "4.4.4"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 11",
    "not op_mini all"
  ]
}

UI Demo

TODO App Demo8. Live Sandbox Demo Link
Live App Link - https://lyjxd2.csb.app/
Code Sandbox Code Editor - https://codesandbox.io/p/sandbox/lyjxd2
All Sandbox Demos of SimpleCRUD API - https://simplecrudapi.com/sandbox-demo

Summary

This Todo app demonstrates the seamless integration of React, custom CSS, and a backend API (SimpleCRUD API). The design is clean, and the functionality covers all essential aspects of a task management application, making it a perfect starter project for React enthusiasts.

For more information on the SimpleCRUD API, refer to their documentation - https://simplecrudapi.com/docs/todos

Queue Data Structure Detailed Examples

Maniruzzaman Akash — Thu, 22 Feb 2024 11:00:03 +0000

Queue Data Structure

A queue is a fundamental data structure in computer science that follows the First-In-First-Out (FIFO) principle. The element that enters the queue first is the first to be removed and the element enters last is the last to be removed.

Operations in Queue

Practical Queue Example in C Programming

#include <stdio.h>

#define MAX_SIZE 100

struct Queue {
    int arr[MAX_SIZE];
    int front, rear;
};

// Function to initialize the queue
void initQueue(struct Queue* q) {
    q->front = q->rear = -1;
}

// Enqueue Operation
void enqueue(struct Queue* q, int item) {
    if (q->rear == MAX_SIZE - 1) {
        printf("Queue Overflow: Cannot enqueue more elements.\n");
        return;
    }

    if (q->front == -1) {
        q->front = q->rear = 0;
    } else {
        q->rear++;
    }

    q->arr[q->rear] = item;
    printf("%d enqueued to the queue.\n", item);
}

// Dequeue Operation
void dequeue(struct Queue* q) {
    if (q->front == -1) {
        printf("Queue Underflow: Cannot dequeue from an empty queue.\n");
        return;
    }

    int dequeuedItem = q->arr[q->front];

    if (q->front == q->rear) {
        q->front = q->rear = -1; // Reset the queue when the last element is dequeued
    } else {
        q->front++;
    }

    printf("%d dequeued from the queue.\n", dequeuedItem);
}

// Peek (or Front) Operation
void peek(struct Queue* q) {
    if (q->front == -1) {
        printf("Queue is empty.\n");
    } else {
        printf("Front element: %d\n", q->arr[q->front]);
    }
}

// Size Operation
int size(struct Queue* q) {
    if (q->front == -1) {
        return 0;
    }
    return q->rear - q->front + 1;
}

// Search Operation
int search(struct Queue* q, int item) {
    for (int i = q->front; i <= q->rear; i++) {
        if (q->arr[i] == item) {
            printf("%d found in the queue.\n", item);
            return 1;
        }
    }
    printf("%d not found in the queue.\n", item);
    return 0;
}

// Check if the queue is empty
int isEmpty(struct Queue* q) {
    return q->front == -1;
}

int main() {
    struct Queue myQueue;
    initQueue(&myQueue);

    enqueue(&myQueue, 10);
    enqueue(&myQueue, 20);
    enqueue(&myQueue, 30);

    peek(&myQueue);

    dequeue(&myQueue);
    peek(&myQueue);

    printf("Queue Size: %d\n", size(&myQueue));

    search(&myQueue, 20);
    search(&myQueue, 40);

    return 0;
}

Get Queue examples with practical detail in depth knowledge - https://devsenv.com/tutorials/queue

Getting More About Linked List Data Structure

Maniruzzaman Akash — Thu, 22 Feb 2024 10:54:06 +0000

Why Linked list

When a program needs to smoothly handle dynamic operations like adding, updating, and removing data-linked lists with a good solution at that time. It provides a flexible way to manage information, making it easier to insert, update, or delete data elements in our program.

Structure of a Linked list

Components of Linked List

struct Node {
    int data;
    struct Node* next;
};

Insert in Linked List

// Create a new node
struct Node* newNode = malloc(sizeof(struct Node));
newNode->data = newData;
// Update pointers
newNode->next = head;
head = newNode;

Insert in the middle

// Create a new node
struct Node* newNode = malloc(sizeof(struct Node));
newNode->data = newData;
// Update pointers
newNode->next = temp->next;
temp->next = newNode;

Insert in the end

struct Node* newNode = malloc(sizeof(struct Node));
newNode->data = newData;
newNode->next = NULL;
// Update pointers
if (head == NULL) {
    head = newNode;
} else {
    struct Node* temp = head;
    while (temp->next != NULL) {
        temp = temp->next;
    }
    temp->next = newNode;
}

Linked List Traverse

struct Node* current = head;
while (current != NULL) {
        // Access data at the current node
        printf("%d -> ", current->data);
        // Move to the next node
        current = current->next;
}

Real life example of Linked list

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Node structure for the linked list
struct Task {
    int taskID;
    char description[100];
    struct Task* next;
};

// Function to add a new task to the to-do list
struct Task* insertTask(struct Task* head, int id, const char* desc) {
    // Allocate memory for the new task
    struct Task* newTask = (struct Task*)malloc(sizeof(struct Task));

    // Set the task details
    newTask->taskID = id;
    strncpy(newTask->description, desc, sizeof(newTask->description));
    newTask->next = NULL;

    // If the list is empty, make the new task the head
    if (head == NULL) {
        head = newTask;
    } else {
        // Otherwise, add the new task to the end of the list
        struct Task* current = head;
        while (current->next != NULL) {
            current = current->next;
        }
        current->next = newTask;
    }

    return head;
}

// Function to traverse and display the to-do list
void traverseToDoList(struct Task* head) {
    if (head == NULL) {
        printf("To-Do List is empty.\n");
        return;
    }

    // Initialize a pointer to the head of the list
    struct Task* current = head;

    // Iterate through the tasks
    while (current != NULL) {
        // Display task details
        printf("Task %d: %s\n", current->taskID, current->description);

        // Move to the next task
        current = current->next;
    }
}

// Function to remove a task from the to-do list
struct Task* deleteTask(struct Task* head, int id) {
    // If the list is empty, nothing to delete
    if (head == NULL) {
        printf("To-Do List is empty. Cannot delete.\n");
        return head;
    }

    // If the task to be deleted is the head
    if (head->taskID == id) {
        struct Task* newHead = head->next;
        free(head);
        return newHead;
    }

    // Search for the task to be deleted
    struct Task* current = head;
    struct Task* previous = NULL;

    while (current != NULL && current->taskID != id) {
        previous = current;
        current = current->next;
    }

    // If the task is not found
    if (current == NULL) {
        printf("Task %d not found. Cannot delete.\n", id);
        return head;
    }

    // Remove the task from the list
    previous->next = current->next;
    free(current);

    return head;
}

int main() {
    // Initialize an empty to-do list
    struct Task* toDoList = NULL;

    // Insert tasks
    toDoList = insertTask(toDoList, 1, "Complete assignment");
    toDoList = insertTask(toDoList, 2, "Buy groceries");
    toDoList = insertTask(toDoList, 3, "Attend meeting");

    // Display the to-do list
    printf("Initial To-Do List:\n");
    traverseToDoList(toDoList);

    // Delete a task
    toDoList = deleteTask(toDoList, 2);

    // Display the updated to-do list
    printf("\nUpdated To-Do List after deletion:\n");
    traverseToDoList(toDoList);

    return 0;
}

This is just the beginning of the Linked list.

If you need more examples and detailed learning, deleting, and many more Please go through this article with many practical examples and learning - https://devsenv.com/tutorials/linked-list