DEV Community: Abiodun Paul Ogunnaike

A practical walkthrough of real-world WordPress performance optimizations

Abiodun Paul Ogunnaike — Thu, 24 Sep 2026 08:49:02 +0000

When running a Google PageSpeed Insights or Lighthouse audit on a custom WordPress website, seeing a low mobile / desktop score (such as 30–40) alongside warnings like "Eliminate render-blocking resources", "Reduce unused JavaScript", and "Serve static assets with an efficient cache policy" is frustratingly common.

Many developers assume the only remedy is installing another heavyweight caching plugin. However, true long-term performance gains come from fixing fundamental bottlenecks in the theme itself: eliminating script bloat, optimizing font delivery, utilizing modern script loading strategies, and conditionally loading assets.

In this article, we'll walk through the exact steps we implemented on your-website to trim megabytes of unnecessary scripts, eliminate render-blocking delays, and streamline WordPress asset delivery.

The Initial Audit: What Went Wrong?

Our initial Lighthouse speed test revealed several common anti-patterns:

Gutenberg Editor Dependencies Leaking to the Frontend: Public-facing custom blocks were pulling in entire WordPress admin and React libraries.
Cache Busting via time(): Styles and scripts had dynamic timestamps, entirely defeating browser and CDN caching.
Render-Blocking Web Fonts via CSS @import: Google Fonts were being pulled synchronously inside multiple stylesheets.
Synchronous jQuery & jquery-migrate: Core jQuery was blocking the critical rendering path.
Redundant & Global Plugin Overhead: Heavy plugin assets were loading globally across 100% of pages, even where completely unused.

Here is how we addressed each issue step by step.

Step 1: Strip Gutenberg Admin Dependencies from Frontend Block Scripts

WordPress custom blocks created with the Block API often share registration logic between the editor and the frontend. A common oversight is passing editor packages into the frontend dependency array:

The Problem

// Bad: Loading editor runtime on public pages
wp_enqueue_script(
    'your-website-banner-block',
    get_template_directory_uri() . '/assets/scripts/banner.js',
    ['wp-blocks', 'wp-element', 'wp-editor', 'wp-components', 'jquery'], // 🛑 Heavy bloat!
    YOUR_THEME_VERSION,
    true
);

When you specify 'wp-blocks', 'wp-element', or 'wp-editor' as dependencies:

WordPress automatically enqueues React, react-dom, lodash, and the complete Gutenberg block parser runtime.
It injects API fetch handlers and triggers blocking background requests (/wp-json/wp/v2/users/me and rest-nonce).
The payload sent to visitors increases by over 1.5–2.0 MB of unneeded JavaScript.

The Solution

Audit your frontend scripts. If a script only handles DOM manipulation, sliders, or UI toggles on the frontend, it does not need WordPress editor packages.

// Good: Only declare what the frontend script actually uses
wp_enqueue_script(
    'your-website-banner-block',
    get_template_directory_uri() . '/assets/scripts/banner.js',
    ['jquery'], // or [] if refactored to vanilla JavaScript
    YOUR_THEME_VERSION,
    [
        'strategy'  => 'defer',
        'in_footer' => true,
    ]
);

Key Takeaway: Reserve 'wp-blocks', 'wp-element', and 'wp-editor' exclusively for enqueue_block_editor_assets (the admin editor screen). Keep frontend enqueues lean.

Step 2: Stop Using `time()` for Asset Versioning

During development, it’s tempting to pass time() as the version argument to avoid caching while making frequent changes. However, leaving it in production is detrimental to performance.

The Problem

// Bad: Generates a new query string on every single request
wp_enqueue_style('your-website-style', get_stylesheet_uri(), array(), time());

This generates URLs like style.css?ver=1726312489. Because the version changes every second:

Browsers never cache your CSS or JS files.
Edge caches (Cloudflare, Fastly, etc.) treat every visit as a cache miss.
Repeat visitors must re-download the entire stylesheet and script bundle on every page view.

The Solution

Use a centralized, static theme version constant (or file modification time if strictly needed during staging):

// In functions.php
if (!defined('YOUR_THEME_VERSION')) {
    define('YOUR_THEME_VERSION', '1.0.4');
}

// In your enqueue functions
wp_enqueue_style('your-website-style', get_stylesheet_uri(), array(), YOUR_THEME_VERSION);

Whenever you deploy an update, increment YOUR_THEME_VERSION once. Browsers will cache assets indefinitely and only re-fetch them when you release a new version.

Step 3: Eliminate CSS `@import` & Modernize Font Loading

Loading web fonts via CSS @import declarations is one of the biggest contributors to slow Largest Contentful Paint (LCP) and First Contentful Paint (FCP).

The Problem

// In SCSS or CSS
@import url("https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap");

When a browser encounters @import:

It pauses CSS parsing.
It makes a blocking network roundtrip to fetch Google's CSS stylesheet.
Only then does it discover the actual font files (.woff2) and begin downloading them.
If multiple stylesheets include @import, this blocking waterfall repeats.

The Solution

Remove all @import url(...) rules from your stylesheets and SCSS files.
Add preconnect hints in your theme's functions.php to resolve the DNS and TLS handshake early:

add_filter('wp_resource_hints', function ($hints, $relation_type) {
    if ('preconnect' === $relation_type) {
        $hints[] = [
            'href'        => 'https://fonts.googleapis.com',
            'crossorigin' => 'anonymous',
        ];
        $hints[] = [
            'href'        => 'https://fonts.gstatic.com',
            'crossorigin' => 'anonymous',
        ];
    }
    return $hints;
}, 10, 2);

Enqueue the font centrally in <head> with display=swap:

wp_enqueue_style(
    'your-website-google-fonts',
    'https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap',
    array(),
    null
);

display=swap instructs the browser to immediately render text using a system fallback font, seamlessly swapping in the custom web font once loaded. This eliminates Flash of Invisible Text (FOIT).

Step 4: Defer jQuery and Strip `jquery-migrate`

Historically, WordPress loaded jQuery synchronously in the <head> to support legacy plugins that inject inline jQuery calls in the body. In modern setups, this severely delays page rendering.

1. Remove `jquery-migrate` on Frontend

jquery-migrate is only required for legacy plugins using deprecated jQuery 1.x APIs. Removing it saves unnecessary HTTP requests and ~10 KB of blocking script execution:

add_action('wp_default_scripts', function ($scripts) {
    if (!is_admin() && !empty($scripts->registered['jquery'])) {
        $scripts->registered['jquery']->deps = array_diff(
            $scripts->registered['jquery']->deps,
            ['jquery-migrate']
        );
    }
});

2. Defer Core jQuery (WordPress 6.3+)

WordPress 6.3 introduced native script loading strategies (defer and async). You can instruct WordPress to defer jQuery on non-admin pages:

add_action('wp_enqueue_scripts', function () {
    if (!is_admin()) {
        wp_script_add_data('jquery', 'strategy', 'defer');
        wp_script_add_data('jquery-core', 'strategy', 'defer');
    }

    // Defer your theme's custom scripts as well
    wp_enqueue_script(
        'your-website-global',
        get_template_directory_uri() . '/assets/scripts/global.js',
        ['jquery'],
        YOUR_THEME_VERSION,
        [
            'strategy'  => 'defer',
            'in_footer' => true,
        ]
    );
});

3. Safeguard Inline Event Handlers

If your theme renders inline scripts (such as reCAPTCHA or tracking handlers in wp_footer), avoid calling jQuery(document).ready(...) directly in raw <script> tags, because deferred jQuery will not have executed yet when the HTML parser hits that inline tag.

Instead, use standard Vanilla JavaScript:

// Instead of jQuery(document).on('submit', 'form', handler):
document.addEventListener('submit', function (event) {
    if (event.target && event.target.tagName === 'FORM') {
        // Execute form logic safely
    }
});

Step 5: Dequeue Redundant Third-Party Plugin Assets

As custom themes evolve, features originally handled by plugins (such as back-to-top buttons, social sharing buttons, or mobile drawers) are frequently rewritten as native, lightweight theme components.

However, inactive or redundant plugins often remain installed and continue injecting styles and scripts into every page.

add_action('wp_enqueue_scripts', function () {
    // Dequeue redundant general plugin assets handled natively by your-website
    wp_dequeue_style('redundant-plugin-style');
    wp_dequeue_style('redundant-plugin-fonts');
    wp_dequeue_script('redundant-plugin-script');
}, 100);

By auditing active plugins and dequeuing obsolete stylesheets and scripts, you remove duplicate network payloads without affecting user experience.

Step 6: Conditionally Load Heavy Plugin Assets (Forms & Anti-Spam)

Popular plugins like contact form managers and security/spam verifiers often enqueue their JavaScript and CSS across 100% of your website's pages, even on simple text articles and archive pages where no forms exist.

The Problem

A visitor reading a blog post or an about page is forced to download form validation scripts, styling bundles, and reCAPTCHA libraries that will never be used on that page.

The Solution: Smart Conditional Dequeuing

Instead of loading form assets globally, only keep them active on pages where forms are actually present.

add_action('wp_enqueue_scripts', function () {
    global $post;

    // Check if the current page actually has a form
    // (Be sure to check for custom popup banners or modals that embed forms!)
    $has_form = is_front_page() || is_home() || (
        is_a($post, 'WP_Post') && (
            has_shortcode($post->post_content, 'contact-form-7') ||
            has_block('contact-form-7/form', $post) ||
            has_block('your-website/notification-bar-block', $post) ||
            stripos($post->post_content, 'contact-form-7') !== false
        )
    );

    // If no form is present, dequeue the form assets
    if (!$has_form) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
        wp_dequeue_script('form-anti-spam');
        wp_dequeue_style('form-anti-spam-css');
    }
}, 99);

Important Pro Tip: If your homepage or header contains an interactive popup banner or modal with an embedded registration form, ensure your condition explicitly includes is_front_page() or checks for your banner block. Otherwise, selective dequeuing might strip the AJAX handlers from your popup form!

The Results

Applying these optimizations produced immediate, measurable improvements:

Payload Reduction: Over 1.5 MB of unnecessary JavaScript (React & Gutenberg editor dependencies) was eliminated from the public frontend.
Render-Blocking Clearance: Removing @import fonts, dequeuing jquery-migrate, and deferring core jQuery reduced initial render blocking by hundreds of milliseconds.
Effective Caching: Replacing time() with static versioning enabled proper browser caching and CDN hit ratios for all repeat visitors.
Zero Lost Functionality: Interactive blocks, form popups, and native animations continue to work seamlessly.

Conclusion

Optimizing WordPress performance doesn't require stripping away interactive features or relying solely on complex caching plugins. By auditing asset dependencies, modernizing script loading strategies, and delivering assets only where they are genuinely needed, you can deliver an ultra-fast experience to your visitors.

Have you audited your custom Gutenberg blocks and plugin enqueues recently? Let us know in the comments below!

Why I Added Tailscale to My VPS: Secure Access Without Relying on a Static IP

Abiodun Paul Ogunnaike — Tue, 08 Sep 2026 15:29:20 +0000

Managing a VPS from a home or office network sounds straightforward until your internet provider starts changing your public IP address.

That was one of the problems I ran into recently.

I had a VPS with some administrative resources restricted to specific IP addresses. The idea was simple: only my trusted IP should be able to access certain services.

The problem?

My ISP uses dynamic public IP addresses.

Every time my public IP changed, I potentially lost access to those IP-restricted resources.

Instead of continuously updating firewall rules whenever my IP changed, I decided to introduce Tailscale.

This article explains what Tailscale is, why it can be useful for VPS administration, and how to set it up on a Linux VPS and a Mac.

What is Tailscale?

Tailscale is a networking platform built around WireGuard that allows your devices and servers to communicate over a private network.

Tailscale calls this private network a tailnet.

Instead of relying on the public IP address of your VPS, devices connected to your tailnet can communicate using private Tailscale addresses, typically in the 100.x.x.x range.

For example:

Mac
  |
  | Tailscale
  |
  v
Private Tailnet
  |
  v
VPS
100.x.x.x

Tailscale describes itself as a zero-trust, identity-based connectivity platform, and it uses WireGuard for encrypted point-to-point connections.

The important part for me wasn't just encryption.

It was stable private connectivity between my devices and my VPS.

Why Would You Use Tailscale?

There are several reasons Tailscale can be useful.

1. Your ISP Uses Dynamic IP Addresses

This was my main reason.

Imagine you configure a firewall rule like:

Allow SSH
Source: 102.143.20.123/32

That means only that specific IP address can connect.

This is useful from a security perspective.

But if your ISP changes your public IP:

Yesterday:
102.143.20.123

Today:
105.131.95.49

your firewall rule is now outdated.

You have to manually update it.

With Tailscale, your Mac and VPS can communicate over your tailnet regardless of your ISP's current public IP.

Instead of depending on:

My ISP public IP
        ↓
      VPS

you have:

My Mac
   ↓
Tailscale
   ↓
Private tailnet
   ↓
VPS

This means I can maintain stable private access without constantly updating IP allowlists because my ISP changed my public IP.

2. Secure Access to Your VPS

SSH is already encrypted, but exposing SSH to the public internet means your server is continuously reachable by internet scanners and automated login attempts.

Tailscale provides another way to access your server over your private tailnet.

For example:

ssh root@100.89.121.90

instead of:

ssh root@your-public-ip

The 100.82.128.80 address is a Tailscale address in this example.

Tailscale's documentation specifically supports using Tailscale to SSH into Linux machines over the tailnet.

3. You Don't Need to Know Your Current Public IP

Before using Tailscale, I might need to check my current public IP before accessing an IP-restricted service.

With Tailscale, my devices have stable identities on the tailnet.

That makes remote administration much more predictable.

4. Access Services That Shouldn't Be Public

Not every service running on a VPS needs to be accessible from the entire internet.

For example, you might have:

Public
├── HTTP :80
└── HTTPS :443

Private
├── Admin dashboard
├── Database administration
├── Internal monitoring
├── Development tools
└── SSH administration

Tailscale can be useful for the private portion.

Instead of exposing every administrative service publicly, you can make certain services reachable only through your tailnet.

5. You Can Connect More Than Just Your Laptop

Tailscale isn't limited to:

Mac → VPS

You can connect:

Mac
Laptop
Phone
VPS
Home server
Cloud server
Development machine

and control which devices can communicate with which resources.

Tailscale's access-control system is designed around identity and least-privilege access, allowing policies to define which users and devices can access specific resources.

Setting Up Tailscale on a Linux VPS

Let's walk through a basic setup.

I'm using an Ubuntu-based VPS for this example.

Step 1: Install Tailscale

On the VPS:

curl -fsSL https://tailscale.com/install.sh | sh

This is the installation method documented by Tailscale for mainstream Linux distributions.

After installation:

tailscale version

You should see the installed version.

For example:

1.102.3

Step 2: Authenticate the VPS

Run:

sudo tailscale up

Tailscale will provide an authentication URL.

Open the URL in your browser and authenticate with your Tailscale account.

Once completed, the VPS becomes part of your tailnet.

Step 3: Check the Tailscale Connection

Run:

tailscale status

You should see your VPS and other devices connected to your tailnet.

You can also retrieve the VPS's Tailscale IPv4 address:

tailscale ip -4

For example:

100.89.121.90

That address is what you can use for private communication with the VPS.

Step 4: Install Tailscale on Your Mac

Install Tailscale on your Mac and sign in using the same Tailscale account.

After both devices are connected, you should have something similar to:

Mac
100.x.x.x
   |
   | Tailscale
   |
   v
VPS
100.89.121.90

Step 5: Test SSH Through Tailscale

From your Mac:

ssh root@100.89.121.90

You can also explicitly specify an SSH key:

ssh -i ~/.ssh/your-key \
    -o IdentitiesOnly=yes \
    root@100.89.121.90

The important part is that the connection is going through the VPS's Tailscale address rather than its public IP.

Tailscale's documentation also supports using MagicDNS, allowing you to connect using a machine hostname instead of remembering the 100.x.x.x address.

Making SSH Easier with ~/.ssh/config

Typing the entire SSH command every time isn't necessary.

On your Mac:

nano ~/.ssh/config

Add:

Host my-vps
    HostName 100.89.121.90
    User root
    IdentityFile ~/.ssh/your-key
    IdentitiesOnly yes

Now you can simply run:

ssh my-vps

This becomes particularly useful when you have multiple servers and multiple SSH keys.

Tailscale vs a Traditional VPN

Tailscale is often described as a VPN, but the experience is different from configuring a traditional VPN server yourself.

With a traditional VPN setup, you might have to manage:

VPN server
Certificates
Routing
Firewall rules
NAT
Client configuration
Key management

Tailscale handles much of the networking complexity for you.

It uses WireGuard underneath and provides identity and access-control features around the network.

That's one reason it is attractive for developers and infrastructure administrators who don't want to manually build and maintain a VPN infrastructure.

Tailscale and Firewalls

One important thing to understand is that Tailscale does not automatically replace your firewall.

You can still use:

Contabo Firewall
        ↓
UFW
        ↓
Tailscale
        ↓
Application

Tailscale is designed to work alongside existing firewalls, and its networking can often work without additional firewall configuration because of NAT traversal.

Your firewall should still be configured according to what your server actually needs.

Should You Close Port 22?

This depends on your architecture.

If you use Tailscale exclusively for SSH, you can potentially remove public SSH access and use Tailscale SSH or SSH over the Tailscale network.

Tailscale's documentation even recommends closing the public SSH port after verifying Tailscale SSH access when appropriate.

However, this isn't always practical.

For example, if you have a CI/CD system using GitHub-hosted runners that connects to your VPS over public SSH, closing port 22 would break that deployment workflow unless you redesign the deployment architecture.

In that situation, you can keep port 22 publicly reachable while still using Tailscale for your own administrative access.

Tailscale SSH

Tailscale also has a feature called Tailscale SSH.

Instead of relying on traditional SSH key management, Tailscale can manage SSH authentication and authorization using your tailnet identity and access policies.

You can enable it with:

tailscale set --ssh

However, I recommend understanding your existing SSH setup before switching to Tailscale SSH on a production server.

You don't necessarily need Tailscale SSH just to benefit from Tailscale networking.

You can simply use:

Tailscale networking
+
Traditional SSH

which is the approach I used for my VPS.

A Practical VPS Security Architecture

A setup I like is:

                    Internet
                       |
              +--------+--------+
              |                 |
           HTTPS             SSH :22
              |                 |
              v                 v
        Public Services      VPS Firewall
                                |
                                v
                              SSH
                                ^
                                |
                         Tailscale network
                                ^
                                |
                              My Mac

Then I can keep public services public while using Tailscale for private administration.

For example:

Public
├── 80/tcp
└── 443/tcp

Restricted / Administrative
├── SSH
├── Admin interfaces
├── Internal tools
└── Monitoring

What Tailscale Doesn't Solve

Tailscale isn't a replacement for general server security.

You should still consider:

SSH keys instead of passwords
Disabling SSH password authentication
Avoiding root for automated deployments
Using dedicated deployment users
Keeping the operating system updated
Configuring a firewall
Using least-privilege access
Monitoring authentication attempts
Using Fail2ban where appropriate
Protecting application credentials
Backups

Tailscale gives you a better networking and access layer; it doesn't magically make an insecure server secure.

My Main Takeaway

The biggest reason I added Tailscale to my VPS wasn't simply:

"I need a VPN."

It was:

"I need reliable private access to my infrastructure without depending on my ISP's changing public IP address."

That distinction matters.

If your ISP gives you a dynamic IP and you've built firewall rules around your current address, eventually you'll probably run into the same problem:

ISP changes IP
      ↓
Firewall rule becomes outdated
      ↓
Access breaks
      ↓
Update firewall
      ↓
ISP changes IP again

Tailscale changes the model:

Mac
 ↓
Tailscale identity
 ↓
Private tailnet
 ↓
VPS

Now my access doesn't depend on whatever public IP my ISP happens to assign me that day.

For anyone managing a VPS from a dynamic residential or office connection, Tailscale is worth considering.

It is particularly useful when you need private access to infrastructure without wanting to build and maintain a traditional VPN yourself.

Useful Resources

Mastering Zero-Downtime Deployments with Laravel Deployer

Abiodun Paul Ogunnaike — Wed, 26 Aug 2026 11:06:16 +0000

How I achieved zero-downtime deployments using PHP Deployer for my Laravel app, and the critical caching and Horizon worker issues I had to solve.

Deploying a Laravel application shouldn't mean taking your site offline. For a long time, I used simple git pull scripts or basic FTP, which often resulted in momentary downtime or broken states if a user visited exactly while composer install was running.

To solve this for my platform, CelebrateMe, I migrated to Deployer a powerful, PHP-based deployment tool that makes zero-downtime deployments incredibly easy.

However, the journey wasn't entirely smooth. I ran into a couple of frustrating issues regarding Deployer's Git caching and Laravel Horizon worker memory that had me pulling my hair out.

Here is how I set it up alongside GitHub Actions to automate the process, the issues I faced, and exactly how I fixed them.

Triggering Deployments with GitHub Actions

To fully automate the CI/CD pipeline, I connected Deployer to GitHub Actions. Instead of manually running dep deploy from my local machine, I configured a GitHub Actions workflow that runs whenever I push to the main or beta branch.

The workflow handles building my frontend assets and then securely triggers Deployer (via an SSH key and secret tokens) to pull the latest code and deploy it to the server. This means every push automatically triggers a zero-downtime deployment without any manual intervention!

How Zero-Downtime Deployment Works

Deployer achieves zero-downtime by maintaining a specific directory structure on your server:

/www/wwwroot/my-app/
├── current -> /www/wwwroot/my-app/releases/21  (Symlink to the latest release)
├── releases/
│   ├── 19/
│   ├── 20/
│   └── 21/  (The active release)
└── shared/
    ├── .env
    └── storage/

When you run dep deploy, Deployer does not overwrite your live code. Instead, it:

Creates a brand new folder in releases/ (e.g., releases/22).
Clones your GitHub repository into that new folder.
Runs composer install, npm run build, and php artisan migrate entirely in the background inside releases/22.
Finally, it updates the current symlink to point to releases/22 in a fraction of a second.

Because the web server (Nginx/Apache) points to the current symlink, the transition is instantaneous. Zero downtime!

The Problem: Deployer's Git Cache (`.dep/repo`)

By default, to make deployments faster, Deployer tries to cache your Git repository on the server inside a hidden .dep/repo directory. Instead of doing a full git clone every time, it fetches the changes into this cached repo and then copies them to the new release folder.

The Issue I Faced

After a few successful deployments, my deployments suddenly started failing mysteriously. Deployer would get stuck during the deploy:update_code step, complaining about uncommitted changes, corrupted git indices, or simply failing to pull the latest commits from the main branch.

Because the cached repository in .dep/repo had gotten out of sync or corrupted by a previous interrupted deployment, Deployer was completely locked up.

The Solution: The Clone Strategy

I realized that for my scale, a fresh clone takes only a few seconds anyway, and the reliability of a fresh clone far outweighs the slight speed boost of the Git cache.

I bypassed the cache completely by explicitly telling Deployer to use the clone strategy instead of the default cache strategy.

In my deploy.php file, I added this single line of configuration:

// Force Deployer to freshly clone the repository every time
set('update_code_strategy', 'clone');

Once I added this, Deployer stopped relying on the .dep/repo cache. It simply ran a fresh git clone into the new release directory every time. The deployments became 100% reliable and I never saw a Git cache corruption error again.

The Second Gotcha: Laravel Horizon and "Ghost" Code

Even after my deployments were succeeding perfectly and the current symlink was pointing to my new code, I noticed something terrifying in my error logs.

My queue workers (Laravel Horizon) were crashing with errors referencing line numbers and logic from old code that I had completely removed in my latest commit!

Why did this happen?

When Deployer updates the current symlink, your web server (Nginx) immediately starts serving the new PHP files for incoming HTTP requests.

However, Laravel Horizon (and queue workers) are long-running PHP daemon processes. They are started once and kept alive in memory. When you deploy new code, those long-running processes do not automatically know that the files on the hard drive have changed. They continue executing the old classes that were loaded into memory when the worker first started (potentially days ago!).

The Solution: Graceful Termination

To fix this, you must tell Horizon to gracefully terminate itself after a deployment finishes. If you are using a process monitor like Supervisor, it will instantly restart the Horizon process, and when it boots back up, it will load the fresh code from the new current symlink.

To automate this, hook into Deployer's lifecycle. In deploy.php, define a task to restart Horizon and run it right after the symlink is updated:

task('horizon:terminate', function () {
    run('cd {{release_or_current_path}} && php artisan horizon:terminate');
});

// Run this task automatically after the new code is live
after('deploy:symlink', 'horizon:terminate');

(Note: Don't use horizon:purge or queue:restart if you are specifically using Horizon. horizon:terminate is the official, safe way to instruct the master process to wrap up its current jobs and shut down).

Conclusion

Deployer is an absolute game-changer for deploying PHP applications, but understanding how it interacts with the server environment is crucial.

If you're setting up Deployer for a Laravel app, save yourself a headache and remember these two rules:

Use set('update_code_strategy', 'clone'); if you run into .dep cache corruption.
Always run php artisan horizon:terminate after your deploy:symlink step to ensure your background workers aren't running ghost code from memory!

Happy deploying!!!

How to Secure Your WordPress Dashboard and Prevent Clients from Breaking Their Sites

Abiodun Paul Ogunnaike — Mon, 10 Aug 2026 09:54:00 +0000

A guide on using Admin Extension Access Control to lock down WordPress plugins and prevent unauthorized changes.

How to Secure Your WordPress Dashboard and Prevent Clients from Breaking Their Sites

If you are a freelance web developer or run an agency, you have probably experienced the dread of a client accidentally bringing down their WordPress site. You spend weeks building a robust, performant website, only for an unauthorized user to log into the dashboard, start deactivating essential plugins, or install poorly coded extensions that break everything.

WordPress is fantastic because of its flexibility, but out of the box, any Administrator can touch everything.

To solve this problem, I want to introduce a lightweight solution: Admin Extension Access Control.

What is Admin Extension Access Control?

Admin Extension Access Control is a WordPress plugin designed to give you granular control over who can see, modify, install, or delete plugins on your site.

Built for modern environments (PHP 8.1+ and WordPress 6.0+), it allows you to configure strict role-based access rules without writing custom PHP functions in your functions.php file every time.

Key Features

Global Lockdown: Completely remove the plugins page for specific user roles.
Granular Permissions: Restrict the ability to add, delete, activate, deactivate, or install plugins on a per-role basis.
Exempt Users Whitelist: Designate trusted administrators (like yourself) who bypass all lockdown rules. Only exempt users can configure the access control settings.
Dashboard Cleanup: Hide the plugins menu item from unauthorized users to keep the dashboard less confusing for clients.

How It Works

Once installed and activated, the user who activates the plugin is automatically added to the Exempt Users list. This prevents you from accidentally locking yourself out.

From the settings panel, you can select which roles should be restricted from managing plugins. For example, you can give your client an "Administrator" role (so they feel in control of their site) but restrict their ability to install or delete plugins. If they try to access the restricted URLs directly, they will be safely redirected.

What's Next?

The plugin is currently actively developed, and there are some exciting advanced features on the roadmap:

Individual Plugin Selection: Hide specific plugins from users while leaving others visible.
Activity & Audit Logs: A timestamped log of all access attempts and plugin visibility events.(Coming soon)
Slack Notifications: Get instant alerts when someone attempts to breach a lockdown rule.(Coming soon)
Multisite Compatibility: Manage rules across a network of sites.(Coming soon)

Conclusion

Securing the WordPress admin area is a critical step in maintaining the longevity and stability of your client projects. By restricting plugin access, you save yourself hours of troubleshooting and protect your clients from their own curiosity.

Check out the repository on (https://wordpress.org/plugins/restrictify-extension-access-control/) to contribute, or download the latest release to try it out on your next project!

If you find it useful, let me know in the comments below!

Laravel Packages Every Developer Should Know (After Building a Real-World Product)

Abiodun Paul Ogunnaike — Thu, 30 Jul 2026 18:35:36 +0000

Laravel is one of my favorite frameworks because it allows you to move from idea to production incredibly fast. But after spending months building CelebrateMe a platform that helps people celebrate life's special moments through virtual gifts, wishlists, messages, and verified vendors—I realized something.

I wasn't just using Laravel.

I was relying heavily on the incredible ecosystem around it.

Some packages solved problems that would have taken days (or weeks) to build myself. Others helped me monitor, debug, and secure the application as it grew.

Here are the Laravel packages I now consider essential for almost every project.

1. Laravel Sanctum

Use it for: API Authentication

CelebrateMe has a Laravel API with a React frontend, so authentication needed to be secure without adding unnecessary complexity.

Laravel Sanctum was the perfect choice.

It provides:

Personal access tokens
SPA authentication
Mobile API authentication
Lightweight implementation

For most APIs, Sanctum is more than enough.

2. Laravel Horizon

Use it for: Queue Monitoring

As CelebrateMe grew, background jobs became increasingly important.

Things like:

Sending emails
Processing uploads
Notifications
Payment-related jobs

Instead of wondering whether jobs were running correctly, Horizon gave me a beautiful dashboard to monitor everything in real time.

If you're using queues and not using Horizon, you're missing out.

3. Laravel Telescope

Use it for: Debugging

Telescope quickly became one of my favorite development tools.

Instead of scattering dd() statements throughout my code, I could inspect:

Requests
SQL queries
Jobs
Exceptions
Cache operations
Notifications

It made debugging significantly easier.

4. Spatie Laravel Permission

Use it for: Roles & Permissions

CelebrateMe has multiple user types, each requiring different permissions.

Managing authorization manually would have become difficult very quickly.

Spatie's Permission package made it straightforward to assign roles and permissions while integrating cleanly with Laravel's authorization system.

5. Laravel Excel

Use it for: Importing and Exporting Data

Every business application eventually needs reporting.

Whether it's exporting users, vendors, or financial reports, Laravel Excel saves an enormous amount of development time.

6. Spatie Media Library

Use it for: File Management

Users upload profile pictures, event images, product photos, and other assets.

Media Library handles:

Multiple collections
Image conversions
Cloud storage
Responsive images

Instead of building a custom media management solution, I could focus on building product features.

7. Laravel Activity Log

Use it for: Audit Trails

As applications grow, knowing who changed what becomes increasingly valuable.

Whether it's an administrator updating information or users modifying their profiles, Activity Log creates a reliable audit trail with minimal effort.

8. Laravel Pint

Use it for: Code Formatting

This may seem like a small addition, but it improves team productivity.

Instead of discussing formatting during code reviews, Pint keeps everything consistent automatically.

One command:

./vendor/bin/pint

That's it.

9. Laravel Pulse

Use it for: Application Monitoring

Performance issues are much easier to solve when you can actually see what's happening.

Pulse provides visibility into:

Slow requests
Database performance
Cache usage
Queue health

It's a great addition once your application reaches production.

10. Laravel Socialite

Use it for: Social Authentication

If your application supports "Sign in with Google" or GitHub, don't build OAuth yourself.

Socialite makes authentication simple and integrates beautifully with Laravel.

My Biggest Lesson

One thing I learned while building CelebrateMe is that being productive isn't about writing the most code.

It's about writing the right code.

Laravel's ecosystem already solves many common problems with mature, well-maintained packages. Instead of reinventing those solutions, I could spend my time building features that actually made CelebrateMe better for its users.

That shift in mindset probably saved me weeks of development.

Honorable Mentions

Some excellent packages that are also worth exploring:

Laravel Reverb
Laravel Scout
Laravel Octane
Spatie Laravel Data
Spatie Query Builder
Barryvdh DomPDF
Intervention Image
Laravel Backup

Final Thoughts

These are the packages that have consistently made my development workflow faster and my applications more maintainable.

The Laravel ecosystem is one of the framework's biggest strengths, and learning which packages to trust is just as important as learning the framework itself.

I'm always looking for new tools.

What Laravel package do you install on every project?

I'd love to discover a few more.

# Using FlyEnv for Laravel and WordPress Development: My First Experience

Abiodun Paul Ogunnaike — Sun, 28 Jun 2026 00:43:29 +0000

As someone who works with both Laravel and WordPress projects often, one recurring challenge is managing local development environments efficiently. Switching between projects, maintaining configurations, and ensuring everything works consistently can sometimes take more effort than expected.

Recently, I decided to try FlyEnv and wanted to share my experience using it in my Laravel and WordPress workflow.

Why I Tried FlyEnv

I was looking for a simpler way to manage local development without spending too much time on setup and configuration.since upgrading XAMPP on mac was a hassle.

For my workflow, I wanted:

Easier environment management
Faster project setup
Less manual configuration
Ability to change from different versions of PHP
A smoother transition between Laravel and WordPress projects

My Experience Using FlyEnv

I tested FlyEnv with both Laravel and WordPress development projects.

The initial setup process was straightforward and did not take long. I was able to get started without spending excessive time trying to understand the interface or changing multiple settings.

For Laravel projects, I liked having a cleaner environment setup because it helped me focus more on building features rather than handling configuration issues.

For WordPress development, having a simpler local workflow also made things easier when working on themes, creating custom plugins and testing changes.

Since I regularly move between Laravel applications and WordPress projects, having a tool that helps reduce friction during development is valuable.

What I Liked

A few things stood out during my use:

Simple onboarding process
Cleaner development workflow
Less time spent on manual environment setup
Useful for handling different project types
Easy enough to start using quickly

Final Thoughts

Overall, my experience with FlyEnv for Laravel and WordPress development was positive.

I appreciate tools that reduce setup overhead and allow developers to spend more time writing code rather than troubleshooting environments.

I'll continue using it and testing additional workflows, but so far it has been a useful addition to my development setup.

Have you used FlyEnv in your projects? I'd be interested in hearing how others are using it in their workflows.

Building a Custom Home Casting App with Rust and React

Abiodun Paul Ogunnaike — Sat, 06 Jun 2026 13:26:17 +0000

Have you ever wanted a simple, lightweight way to cast videos from your phone to your smart TV without relying on third-party apps or dealing with complex Chromecast/DLNA setups? In this article, I am going to show you how I built "Home Cast" – a fully self-hosted video casting application using a Rust backend and a sleek React frontend.

The Architecture

The system consists of two main parts:

The Server (Rust/Axum): A fast, concurrent backend that handles video uploads via multipart forms and communicates with the TV using WebSockets.
The Client (React/Vite): A beautiful, modern interface that lets you upload videos and cast them with a single tap.

The magic relies on WebSockets. When you open the application on your TV's web browser, it connects to the Rust server's WebSocket endpoint and passively listens. When you upload a video from your phone, the Rust server saves it locally. Then, when you click "Cast to TV," the server broadcasts a message containing the new video URL to the TV. The TV receives the message, dynamically updates its HTML5 <video> player, and immediately begins playback.

Handling Browser Autoplay Policies

One major hurdle with web-based video players on TVs is the dreaded "Playback Blocked" error. Modern browsers restrict videos with audio from playing automatically unless the user interacts with the page first. I solved this by catching the rejected play promise and gracefully prompting the user to press the OK button on their TV remote (which simulates a click event). This bypasses the restriction and starts the stream seamlessly.

Why Rust?

Using Axum and Tokio made it incredibly easy to handle WebSocket connections and file uploads concurrently. Rust's memory safety guarantees mean we never have to worry about null pointer exceptions or memory leaks crashing our server right in the middle of movie night.

My Conclusion

Building your own casting app is a fun weekend project that teaches you a lot about WebSockets, multipart uploads, and HTML5 video APIs. Best of all, you get a custom media solution that works entirely on your local network, without any cloud dependencies!

I probably will be adding more features as time goes on, below is the github repo: https://github.com/abbeymaniak/cast-app

OAuth vs OAuth 2.0 Explained Simply for Beginners

Abiodun Paul Ogunnaike — Fri, 01 May 2026 18:34:00 +0000

If you’ve ever clicked "Continue with Google" or "Login with Facebook", then you’ve already used OAuth 2.0 even if you didn’t know it.

As developers, especially backend developers, understanding OAuth is important because it powers modern authentication and authorization systems across APIs, web apps, and mobile applications.

Let’s break it down in the simplest way possible.

What Problem Does OAuth Solve?

Imagine a third-party app wants access to your Google contacts or GitHub repositories.

Before OAuth existed, the only way to do this was to give the app your actual username and password.

That created huge security problems:

The app could store your password
Your credentials could be leaked if the app got hacked
You had no control over what the app could access OAuth solved this problem.

Instead of sharing your password, OAuth allows applications to access specific parts of your account using temporary tokens.

OAuth in Simple Terms

OAuth is an authorization framework that allows one application to access another application’s resources on behalf of a user without exposing the user’s password.

In simple English:

OAuth lets users give limited access to their data without sharing login credentials.

How OAuth 2.0 Works

Here’s the basic flow:

Step 1: User Clicks Login

A user clicks:

Continue with Google
Sign in with GitHub

Step 2: Redirect to Provider

The app redirects the user to the provider (Google, GitHub, Facebook).

Step 3: User Grants Permission

The provider asks:

Do you allow this app to access your profile/email?

Step 4: Token Issued

If approved, the provider generates an access token.

Step 5: Access Granted

The application uses that token to access allowed resources.

No password is shared with the third-party application.

OAuth vs OAuth 2.0

OAuth 2.0 is simply the modern version of OAuth.

It was designed to be:

Simpler
Faster
More flexible
Better for APIs and mobile apps Today, OAuth 2.0 is the industry standard.

Important OAuth 2.0 Terms

Access Token

A temporary token used to access resources.

Refresh Token

Used to generate a new access token when the old one expires.

Scope

Defines what the app can access:

email
profile
contacts
repositories

Authorization Server

The server responsible for issuing tokens.

Resource Server

The server that stores the protected data.

OAuth Is NOT Authentication

One of the biggest beginner mistakes is thinking OAuth is authentication.

OAuth handles:

Authorization -> What can this app access?

Authentication answers:

Who is this user?

This is why technologies like OpenID Connect exist on top of OAuth 2.0.

Why Backend Developers Should Learn OAuth

As a backend developer, OAuth 2.0 is everywhere:

API authentication
Social login systems
Microservices
SaaS integrations
Mobile app authentication

Frameworks like Laravel make implementation easier using tools like:

Laravel Passport
Laravel Sanctum

Understanding OAuth helps you build more secure systems and integrate with modern platforms confidently.

If you’re learning backend development, mastering OAuth 2.0 is one of the most valuable concepts you can add to your skill set.

Understanding and Fixing the N+1 Query Problem in Laravel

Abiodun Paul Ogunnaike — Wed, 22 Apr 2026 11:28:16 +0000

If you’ve ever built a Laravel app that felt fast locally but slow in production, there’s a good chance you’ve encountered the N+1 query problem.

It’s one of the most common performance issues in backend development and many developers don’t realize it’s happening.

What is the N+1 Query Problem?

The N+1 problem occurs when:

You run 1 query to fetch data
Then N additional queries to fetch related data

$users = User::all();

foreach ($users as $user) {
    echo $user->posts;
}

If you have 10 users, Laravel executes:

1 query for users
10 queries for posts

Total: 11 queries

Why This is Dangerous

At small scale, it looks harmless.

At scale:

100 users = 101 queries
1000 users = 1001 queries

This leads to:

Slow response times
High database load
Poor user experience

The Solution: Eager Loading

Laravel provides a simple fix using with():

$users = User::with('posts')->get();

Now Laravel executes:

1 query for users
1 query for posts

Total: 2 queries

Going Deeper: Nested Relationships

The problem becomes worse with nested relationships:

$users = User::all();

foreach ($users as $user) {
    foreach ($user->posts as $post) {
        echo $post->comments;
    }
}

The Fix:

$users = User::with('posts.comments')->get();

Quick Tips

Always inspect queries using Laravel Debugbar
Be cautious with API resources and transformers
Use eager loading by default when returning relationships

Conclusion

The N+1 query problem is easy to miss—but expensive to ignore.

If you’re serious about building scalable Laravel applications, mastering this concept is essential.

Built a Fully Offline AI Assistant on My Mac (Using Local LLMs)

Abiodun Paul Ogunnaike — Mon, 13 Apr 2026 18:31:50 +0000

Most AI apps today rely on APIs.

I wanted something different:

A fully offline AI assistant
Runs locally on my Mac
No API keys, no internet required

So I built one.

What I Built

A local AI assistant that:

Runs using a small language model (LLaMA / Mistral)
Works entirely offline
Supports chat + memory
Can be extended into a RAG system

Architecture

[CLI / Terminal] 
      ↓ 
[Node.js App] 
      ↓ 
[Ollama (Local AI Engine)] 
      ↓ 
[Local LLM]

Step 1 — Install Ollama on your local Machine

brew install ollama

Start the server:

ollama serve

Pull a model:

ollama run qwen2.5:latest

I choose qwen:2.5:latest because its just 4.7GB in size

Step 2 — Build CLI Assistant

mkdir local-ai-assistant 
cd local-ai-assistant 
npm init -y 
npm install axios readline-sync

Create a file in the local-ai-assistant folder

assistant.js

!/usr/bin/env node

const axios = require('axios');
const readline = require('readline-sync');

let history = [];

async function chat() {
    while (true) {
        const input = readline.question("You: ");

        history.push({ role: "user", content: input });

        const response = await axios.post('http://localhost:11434/api/chat', {
            model: 'qwen2.5:latest',
            messages: history,
            stream: false
        });

        const reply = response.data.message?.content || "No response";

        history.push({ role: "assistant", content: reply });

        console.log("AI:", reply);
    }
}

chat();

Step 3 — Make It a Global CLI Tool

Update package.json:

{
  "name": "local-ai",
  "bin": {
    "local-ai": "./assistant.js"
  }
}

Run:

npm link

Now you can run:

local-ai

What I Learned

Local LLMs are powerful enough for real use cases
You don’t need Python to start — Node works fine
The real value is in architecture, not just models

What i intend to build next

Add file-based memory (RAG)
Add tools (agent behavior)
Connect to Laravel API
Deploy via Docker + AWS

Final Thought

Running AI locally changes how you think about systems.

You’re no longer dependent on external APIs — you own the stack.

If you’re building something similar, I’d love to connect

https://github.com/abbeymaniak
https://linkedin.com/in/abiodun-paul-ogunnaike

Stateless vs. Stateful Systems in Software Architecture

Abiodun Paul Ogunnaike — Fri, 27 Mar 2026 19:58:22 +0000

TD;LR:

Stateless systems scale easily and recover quickly. (Scale with stateless.)
Stateful systems enable deeper, continuous user experiences. (Experience with stateful.)
Great architecture isn’t about choosing one it’s about placing state intentionally. (Win by controlling where state lives.)

Modern software architecture often comes down to one fundamental question: Should your system remember anything between requests? That single decision shapes scalability, complexity, performance, and even cost. Let’s break it down clearly and practically.

What Does “Remembering Between Requests” Really Mean?

When a system remembers, it retains information about a user or process across multiple interactions.

A stateful system keeps that memory internally (e.g., user session stored on a server).
A stateless system treats every request as independent no memory of the past.

Think of it like this:

Stateful = a waiter who remembers your order without asking again
Stateless = a waiter who asks you to repeat your order every time

Stateless Systems: Simple, Scalable, Cloud-Friendly

A stateless system does not store client context between requests. Each request must contain all the information needed to process it.

How it works

No session stored on the server State is passed via:
Tokens (e.g., JWT)
Query params / headers
External storage (DB, cache)

Advantages

1. Horizontal scalability (effortless scaling)
You can spin up multiple servers behind a load balancer without worrying about where a user’s data lives.

2. Fault tolerance
If one server dies, another can handle the next request seamlessly.

3. Simpler infrastructure
No need for session replication or sticky sessions.

Trade-offs

Larger request sizes (state sent every time)
More work pushed to clients or external systems
Can feel less intuitive for complex workflows

Real-world examples

REST APIs
Microservices architectures
Serverless functions (e.g., AWS Lambda)

Stateful Systems: Powerful but Complex

A stateful system stores data about a user/session on the server across multiple requests.

How it works

Server stores session data (memory, Redis, DB)
Client sends a session ID (cookie)
Server retrieves stored context

Advantages

1. Simpler client logic
The server “remembers,” so the client doesn’t have to send everything every time.

2. Efficient for long-lived interactions
Great for workflows like:

Shopping carts
Multiplayer games
Real-time collaboration

Trade-offs

1. Harder to scale
You need:

Sticky sessions, or
Shared session stores (e.g., Redis)

2. Reduced fault tolerance
If the server holding the session crashes, state may be lost.

3. Operational complexity
Session replication, synchronization, and consistency become real challenges.

The Hybrid Reality (What Most Systems Actually Do)

Here’s the truth: most modern systems are not purely stateless or stateful—they’re a mix.

A common pattern:

Keep application servers stateless Store state in external systems:
Databases
Caches (Redis)
Object storage

This gives you:

Stateless scalability
Stateful capability (via external persistence)

For Example in Celebrateme.co a digital platform focused on helping people to never miss important moments like birthdays and making those moments more meaningful with Physical and digital gifts currently in development:

The API is stateless
Authentication uses JWT (stateless)
User data lives in a database (stateful, but externalized)

The following Non-Function Requirements will determine which approach to take:

1. How much scale do you need?

Massive / unpredictable traffic → Stateless (JWT)
Controlled / predictable → Stateful can work (cookies)

2. How critical is resilience?

High uptime requirement → Stateless wins

3. How complex is the interaction?

Multi-step workflows → Stateful or hybrid
Simple request-response → Stateless

4. What’s your team’s operational maturity?

Small team → stateless reduces headaches
Experienced infra team → stateful is manageable

My advice: default to stateless, and introduce state only where it’s truly needed.

This keeps your system:

Easier to scale
Easier to debug
Easier to deploy

Stateless systems optimize for scale and resilience.
Stateful systems optimize for rich, continuous interactions.

The best architects don’t pick one blindly, they control where state lives.

10 REST API MISTAKES TO AVOID

Abiodun Paul Ogunnaike — Fri, 20 Mar 2026 15:47:55 +0000

If you're building APIs with Wordpress, Laravel or Node.js, this might hit a bit close to home

A lot of developers aren’t really designing APIs
they’re just returning JSON and calling it a day.

And that’s where things start to fall apart.

Because a solid API isn’t just something that “works.”
It should be consistent, scalable, predictable, and easy for other developers to use.

Let’s break down some of the most common mistakes and how to fix them 👇

❌ 1. Using Verbs in URLs

Wrong

GET /getBooks  
POST /createBook 
DELETE /deleteBook/1

Right

GET /books  
POST /books 
DELETE /books/1

👉 URLs should represent resources (nouns) — not actions.
HTTP methods already define the action.

❌ 2. Ignoring HTTP Status Codes

Wrong

200 OK
{ "status": "error", "message": "User not found" }

Right

200 → Success
201 → Created
400 → Bad Request
401 → Unauthorized
403 → Forbidden
404 → Not Found
422 → Validation Error
500 → Server Error

👉 Status codes are part of your API contract.

❌ 3. Inconsistent JSON Structure

Wrong

{ "userName": "Paul" }
{ "username": "Paul" }

Right

Pick one style: snake_case OR camelCase
Use it everywhere

👉 Consistency builds trust.

❌ 4. No API Versioning

Wrong

/books

Right

/api/v1/books
/api/v2/books

👉 Versioning prevents breaking existing clients.

❌ 5. No Pagination

Wrong

GET /books → returns 10,000 records

Right

GET /books?page=1&limit=10
{
  "data": [],
  "meta": {
    "current_page": 1,
    "total": 1000
  }
}

👉 Pagination improves performance, scalability, and UX.

❌ 6. Mixing Authentication & Authorization

Authentication = Who are you?
Authorization = What can you do?

👉 Use proper tools:

JWT / OAuth
Laravel Sanctum / Passport
Never trust frontend validation alone.

❌ 7. Poor Error Handling

Bad

"Something went wrong"

Good

{
  "error": {
    "code": 404,
    "message": "Book not found"
  }
}

👉 Errors should be predictable and structured.

❌ 8. Bad Filtering & Sorting

Wrong

GET /getActiveEventsSortedByName

Right

GET /events?status=active&sort=name

👉 Keep it clean, flexible, and scalable.

❌ 9. Ignoring Security

Common mistakes:

No rate limiting
No validation
No HTTPS
Exposing sensitive data

👉 Best practices:

Always use HTTPS
Validate all inputs
Add rate limiting
Hide sensitive/internal fields

❌ 10. Designing APIs Around Your Database

Bad mindset

“This is my table structure”

Good mindset

“This is what the client needs”

👉 Your API is a contract, not a database mirror.

What Good APIs Look Like

Versioned endpoints
Consistent naming
Proper status codes
Pagination
Filtering & sorting
Secure authentication
Structured errors
Resource-based URLs

REST API design isn’t about returning JSON.

It’s about:

Consistency
Scalability
Predictability
Security
Developer Experience

When your API is clean and predictable…
developers love working with it.

DEV Community: Abiodun Paul Ogunnaike

A practical walkthrough of real-world WordPress performance optimizations

The Initial Audit: What Went Wrong?

Step 1: Strip Gutenberg Admin Dependencies from Frontend Block Scripts

The Problem

The Solution

Step 2: Stop Using time() for Asset Versioning

The Problem

The Solution

Step 3: Eliminate CSS @import & Modernize Font Loading

The Problem

The Solution

Step 4: Defer jQuery and Strip jquery-migrate

1. Remove jquery-migrate on Frontend

2. Defer Core jQuery (WordPress 6.3+)

3. Safeguard Inline Event Handlers

Step 5: Dequeue Redundant Third-Party Plugin Assets

Step 6: Conditionally Load Heavy Plugin Assets (Forms & Anti-Spam)

The Problem

The Solution: Smart Conditional Dequeuing

The Results

Conclusion

Why I Added Tailscale to My VPS: Secure Access Without Relying on a Static IP

What is Tailscale?

Why Would You Use Tailscale?

1. Your ISP Uses Dynamic IP Addresses

2. Secure Access to Your VPS

3. You Don't Need to Know Your Current Public IP

4. Access Services That Shouldn't Be Public

5. You Can Connect More Than Just Your Laptop

Setting Up Tailscale on a Linux VPS

Step 1: Install Tailscale

Step 2: Authenticate the VPS

Step 3: Check the Tailscale Connection

Step 4: Install Tailscale on Your Mac

Step 5: Test SSH Through Tailscale

Making SSH Easier with ~/.ssh/config

Tailscale vs a Traditional VPN

Tailscale and Firewalls

Should You Close Port 22?

Tailscale SSH

A Practical VPS Security Architecture

What Tailscale Doesn't Solve

My Main Takeaway

Useful Resources

Mastering Zero-Downtime Deployments with Laravel Deployer

Triggering Deployments with GitHub Actions

How Zero-Downtime Deployment Works

The Problem: Deployer's Git Cache (.dep/repo)

The Issue I Faced

The Solution: The Clone Strategy

The Second Gotcha: Laravel Horizon and "Ghost" Code

Why did this happen?

The Solution: Graceful Termination

Conclusion

How to Secure Your WordPress Dashboard and Prevent Clients from Breaking Their Sites

How to Secure Your WordPress Dashboard and Prevent Clients from Breaking Their Sites

What is Admin Extension Access Control?

Key Features

How It Works

What's Next?

Conclusion

Laravel Packages Every Developer Should Know (After Building a Real-World Product)

1. Laravel Sanctum

2. Laravel Horizon

3. Laravel Telescope

4. Spatie Laravel Permission

5. Laravel Excel

6. Spatie Media Library

7. Laravel Activity Log

8. Laravel Pint

9. Laravel Pulse

10. Laravel Socialite

My Biggest Lesson

Honorable Mentions

Final Thoughts

# Using FlyEnv for Laravel and WordPress Development: My First Experience

Why I Tried FlyEnv

My Experience Using FlyEnv

What I Liked

Step 2: Stop Using `time()` for Asset Versioning

Step 3: Eliminate CSS `@import` & Modernize Font Loading

Step 4: Defer jQuery and Strip `jquery-migrate`

1. Remove `jquery-migrate` on Frontend

The Problem: Deployer's Git Cache (`.dep/repo`)