DEV Community: Ali Karbasi

The "AI" Label Is Losing Its Meaning, and Companies Are the Ones Diluting It

Ali Karbasi — Tue, 26 May 2026 18:22:06 +0000

Posted on May 24, 2026
5 min read

🤖 AI summary: This article examines how the term "artificial intelligence" has been co-opted by companies as a marketing buzzword, often attached to products that have little to no genuine AI capability. Using Apple Intelligence and its $250 million false advertising settlement as a case study, the piece argues that this trend of "AI washing" is eroding public trust, confusing ordinary users, and making it harder to recognize the technology when it actually delivers real value.

Every product in 2026 is "AI-powered." Your toothbrush is AI-powered. Your coffee maker is AI-powered. The spreadsheet app you have been using for ten years just got a rebrand, and now it is "AI-powered" too. Nothing changed except the logo and a press release.

I have been watching this happen for two years now, and I think we have reached a tipping point. The word "AI" has been stretched so thin by marketing departments that it is starting to mean absolutely nothing to the average person.

And the companies doing the stretching are not scrappy startups trying to get attention. They are some of the biggest names in tech.

The Apple Intelligence Fiasco

Let us talk about the elephant in the room. Apple.

In September 2024, Apple launched the iPhone 16 series with a massive marketing push around "Apple Intelligence." The keynote was slick. The ads were everywhere. The message was clear: this phone is smart, and it is smart because of AI.

There was just one small problem. The AI features were not ready.

When people bought their shiny new iPhone 16, they discovered that most of the flagship "Apple Intelligence" features were either delayed, incomplete, or straight-up missing. The notification summaries hallucinated. Siri was still Siri. The "intelligent" features that were supposed to justify the upgrade were nowhere to be found at launch.

Apple had sold a promise, not a product.

In 2025, a class-action lawsuit was filed alleging false advertising. The plaintiffs argued that Apple had used AI capabilities as a primary selling point for the iPhone 16 lineup, knowing full well that those capabilities were not available at the time of purchase. And they had a point. If you watch those launch ads again, Apple Intelligence was not presented as a "coming soon" feature. It was presented as a reason to buy the phone right now.

Apple settled for $250 million. The settlement covers anyone who bought an iPhone 16 (any model) or an iPhone 15 Pro/Pro Max between June 2024 and March 2025. Eligible buyers could receive between $25 and $95 per device. The final approval hearing is scheduled for June 2026.

Let that sink in. A quarter of a billion dollars. Because a company slapped the word "Intelligence" on features that did not exist yet.

AI Washing Is the New Greenwashing

Apple is not alone. What happened with Apple Intelligence is just the most visible example of a much bigger trend that the industry is now calling "AI washing."

If you were around in the 2010s, you remember greenwashing. That is when companies would slap a green leaf on their packaging and call themselves "eco-friendly" without actually changing anything about their manufacturing process. The label was meaningless, but it sold products.

AI washing is the exact same playbook. And it is everywhere.

Presto Automation was charged by the SEC in early 2025 for claiming it used proprietary AI technology in its drive-through automation system. In reality, it was using third-party tools and heavy human intervention behind the scenes. The "AI" was basically people in a call center.
Companies laying off workers have started citing "AI efficiency" as the reason for the cuts, even when the layoffs are clearly driven by financial restructuring or overhiring corrections. AI becomes the convenient scapegoat. "We are not firing people because we made bad decisions. We are firing people because the robots are just that good." Even Sam Altman has called this out.
The FTC has taken enforcement actions against multiple companies, including Growth Cave, Air AI, and Cox Media Group, for misrepresenting what their so-called AI products actually do.

The pattern is always the same. Take an existing product. Add the letters "AI" to the name. Watch the stock price go up or the customers flood in. Hope nobody looks under the hood.

Why This Hurts Everyone

Here is why I care about this as a developer, and why you should too.

When every company calls everything "AI," the word loses its signal. The average person, your mom, your client, your neighbor, can no longer tell the difference between a genuine AI system and a glorified if-else statement with a chatbot skin.

I see this constantly in my web design work. Clients come to me and say, "We need AI on our website." When I ask what they mean, they usually describe something that is not AI at all. They want a FAQ section. They want a contact form that auto-responds. They want a product filter that remembers preferences. These are useful features, but they are not artificial intelligence. They are just good UX.

But because every SaaS tool they use has told them it is "AI-powered," they now think any moderately smart feature qualifies. The bar has been lowered so far that "AI" now means "it does something automatically."

This creates two real problems:

Trust erosion: When people buy an "AI-powered" product and it does not feel intelligent at all, they stop trusting the label entirely. And then when something genuinely impressive comes along, like actual real-time language translation or meaningful code generation, they are already skeptical. "Sure, they say it is AI. The last thing that said it was AI was my toaster."
Budget misallocation: Businesses are spending real money on "AI solutions" that are just repackaged automation. I have seen small e-commerce clients drop thousands on an "AI marketing platform" that turned out to be a basic email scheduler with a fancy dashboard. That money could have gone toward actual improvements to their site speed, their UX, or their conversion funnel.

The "Intelligence" Bar Is on the Floor

Part of the problem is that nobody has agreed on what "AI" actually means in a consumer context.

In academia, artificial intelligence refers to systems that can learn, reason, adapt, and make decisions in novel situations. That is a high bar. GPT-4, Claude, Gemini, these models genuinely clear that bar in meaningful ways. They can synthesize information, generate creative output, and handle tasks they were never explicitly trained for.

But in marketing? "AI" just means "we added an algorithm." A spam filter is AI. A recommendation engine is AI. Auto-brightness on your phone is AI. Predictive text is AI.

When you define AI that broadly, the word becomes meaningless. It is like calling every vehicle a "spaceship." A bicycle technically transports you through space, but nobody is going to be impressed when you tell them you arrived on a spaceship and they see a bicycle parked outside.

Apple calling Siri "intelligent" is a bit like parking a bicycle and calling it a spaceship. The word is doing a lot of heavy lifting that the product cannot support.

What Real AI Looks Like (And Why It Matters)

I want to be clear about something. I am not anti-AI. I have written extensively about AI on this blog. I think AI coding tools are powerful when used correctly. I think AI agents are going to transform how we manage websites. I have seen firsthand what AI agents can do in a WordPress environment, and it is genuinely impressive.

But those tools work because they are backed by actual large language models with billions of parameters, trained on massive datasets, capable of reasoning about novel problems. That is real AI. That is the thing worth getting excited about.

The problem is not AI itself. The problem is the label being used as a costume. When a company puts "AI" on a product that is really just a rules engine or a basic automation script, it cheapens the actual breakthroughs. It makes people tired of the word before they ever get to experience the real thing.

A Developer's Responsibility

As developers and designers, I think we have a small but important role here.

When a client asks for "AI features," we should be honest about what they actually need. If they need a chatbot, give them a chatbot and call it a chatbot. If they need a recommendation engine, build one and explain how it works. Do not call it "AI-powered" if it is just filtering products by purchase history.

And when we use actual AI in our workflows, like using language models to generate content or code, we should be transparent about what the AI is doing and what its limitations are. I wrote about this in my piece on the Vibe Tax. The tool is powerful, but it is not magic. Calling it magic is how you end up with $250 million lawsuits.

The Verdict

The word "AI" used to mean something. It used to carry weight. It used to make you lean forward and pay attention.

Now it is on toothbrush packaging.

Apple showed us what happens when a company over-promises on AI. A quarter-billion-dollar settlement and a wave of consumer distrust. But Apple is just the company that got caught. Hundreds of other companies are doing the same thing on a smaller scale, every single day.

If we want AI to keep meaning something, if we want people to actually trust the technology when it delivers real value, then we need to stop letting the marketing departments turn "artificial intelligence" into the new "all-natural" or "military-grade." Those phrases are meaningless now. "AI" is heading in the same direction.

The next time you see a product that claims to be AI-powered, ask yourself one question: "If I removed the AI label, would this product seem any different?"

If the answer is no, you have just spotted AI washing. And unfortunately, you are going to keep spotting it everywhere.

Speed Up Your WordPress Site in 30 Minutes: A No-Plugin Performance Guide

Ali Karbasi — Tue, 26 May 2026 18:14:05 +0000

Posted on May 3, 2026
6 min read

🤖 AI summary: This practical guide walks WordPress and WooCommerce site owners through a series of hands-on performance optimizations that can be completed in 30 minutes, without installing a single caching or optimization plugin. It covers converting images to modern formats like WebP and AVIF, implementing native lazy loading, optimizing web font delivery, inlining critical CSS, cleaning up the database, and removing render-blocking resources. Each step includes real code snippets that can be dropped into a child theme's functions.php file, making this a copy-paste-and-go resource for store owners who want faster load times today.

I am going to say something that might upset a few people: your WordPress site does not need fifteen plugins to be fast.

I have lost count of the number of WooCommerce stores I have audited where the client installed a caching plugin, an image optimization plugin, a lazy loading plugin, a minification plugin, a database optimization plugin, and a CDN plugin, and the site was still slow. In some cases, the plugins were actually fighting each other and making things worse.

The truth is that WordPress, out of the box, is not as slow as people think. What makes it slow is what we pile on top of it. And the irony of installing more plugins to fix a problem caused by too many plugins is something that should keep us all up at night.

So here is my challenge: set a 30-minute timer and follow this guide. No plugins. Just code, configuration, and common sense. By the time you are done, your site will be measurably faster.

Let's go.

Minute 0-5: Convert Your Images to WebP or AVIF

This is the single biggest performance win for most WordPress sites, and it is not even close.

If your product images and blog thumbnails are still in JPEG or PNG format, you are serving files that are two to five times larger than they need to be. WebP delivers the same visual quality at roughly 30% smaller file sizes than JPEG. AVIF goes even further, often 50% smaller.

Here is the thing: WordPress has supported WebP uploads natively since version 5.8 (2021). And as of WordPress 6.5, AVIF is also supported out of the box. You do not need a plugin for this.

What to do:

Use a free tool like Squoosh (by Google) to batch convert your existing images to WebP.
For new uploads, simply save your images as .webp before uploading them to the Media Library.
If you want WordPress to serve AVIF to browsers that support it and WebP as a fallback, you can add this to your .htaccess file:

# Serve AVIF/WebP images if browser supports them
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/avif
  RewriteCond %{REQUEST_FILENAME}.avif -f
  RewriteRule ^(.+)\.(jpe?g|png|gif)$ $1.$2.avif [T=image/avif,L]

  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^(.+)\.(jpe?g|png|gif)$ $1.$2.webp [T=image/webp,L]
</IfModule>

On a WooCommerce store with 500 products, I have seen this single change cut total page weight by 60%. That translates directly into faster load times, especially for customers on mobile networks.

Minute 5-10: Enable Native Lazy Loading

Lazy loading means images below the fold (the ones you cannot see without scrolling) are not loaded until the user scrolls down to them. This dramatically reduces initial page load time.

The good news: WordPress has included native lazy loading since version 5.5. It automatically adds loading="lazy" to images. But there are two problems with the default behavior.

First, WordPress also lazy-loads images above the fold, including your hero banner and first visible product images. This actually hurts your Largest Contentful Paint (LCP) score because the browser waits to load the most important image on the page.

Second, iframes (like embedded YouTube videos) are not lazy-loaded by default.

Add this to your child theme's functions.php to fix both issues:

/**
 * Skip lazy loading for the first image (above the fold)
 * and add lazy loading to iframes
 */
// Skip lazy loading on hero/banner images
add_filter('wp_img_tag_add_loading_attr', function($value, $image, $context) {
    static $count = 0;
    $count++;
    // Don't lazy load the first 2 images (likely above the fold)
    if ($count <= 2) {
        return false;
    }
    return 'lazy';
}, 10, 3);

// Add lazy loading to iframes (YouTube embeds, maps, etc.)
add_filter('the_content', function($content) {
    $content = str_replace('<iframe ', '<iframe loading="lazy" ', $content);
    return $content;
});

This is one of those changes that costs you nothing but gives you an immediate improvement in Core Web Vitals, specifically LCP and the overall page load waterfall.

Minute 10-15: Optimize Your Web Fonts

Fonts are a silent performance killer. Most WordPress themes load Google Fonts by making a round-trip request to fonts.googleapis.com, then another to fonts.gstatic.com, then downloading the actual font files. That is three network hops before your text even renders.

Here is how to fix it in three steps:

Step 1: Add preconnect hints. This tells the browser to start the connection to the font server early. Add this to your theme's <head>:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

Step 2: Use font-display: swap. This tells the browser to show the text immediately using a system font, then swap in the custom font once it has loaded. No more invisible text while fonts download. When loading Google Fonts, append &display=swap to the URL:

https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap

Step 3: Self-host your fonts. This is the biggest win. Instead of loading fonts from Google's servers, download them and serve them from your own domain. This eliminates the DNS lookup and connection overhead entirely.

Download your fonts from Google Webfonts Helper, place them in your theme's /fonts/ directory, and add a @font-face declaration to your CSS:

@font-face {
    font-family: 'Inter';
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: url('/wp-content/themes/your-child-theme/fonts/inter-v18-latin-regular.woff2')
         format('woff2');
}

Then remove the Google Fonts stylesheet from your theme. If your parent theme enqueues it, dequeue it in your child theme:

add_action('wp_enqueue_scripts', function() {
    wp_dequeue_style('google-fonts');
    wp_deregister_style('google-fonts');
}, 20);

On one WooCommerce store I optimized, self-hosting fonts alone shaved 400ms off the initial render time. That is almost half a second just from eliminating external font requests.

Minute 15-20: Inline Critical CSS and Defer the Rest

By default, WordPress loads your entire stylesheet as a render-blocking resource. This means the browser has to download and parse your complete CSS file before it can paint anything on screen, even if 90% of that CSS is for pages the user has not visited yet.

The fix is to inline the critical CSS (the styles needed for the above-the-fold content) directly in the <head>, and load the rest asynchronously.

Here is a practical approach without a plugin:

Step 1: Use a tool like CSS Minifier to minify your stylesheet.

Step 2: Extract your critical CSS. You can use the free Critical CSS Generator to identify which styles are needed for the initial viewport. This typically includes your header, navigation, hero section, and first row of products.

Step 3: Inline that critical CSS and defer the full stylesheet. Add this to your functions.php:

add_action('wp_head', function() {
    // Inline critical CSS
    echo '<style id="critical-css">';
    // Paste your minified critical CSS here
    include get_stylesheet_directory() . '/critical.css';
    echo '</style>';
}, 1);

add_action('wp_enqueue_scripts', function() {
    // Change main stylesheet to load asynchronously
    wp_dequeue_style('theme-style');
    wp_enqueue_style('theme-style',
        get_stylesheet_uri(),
        array(),
        null,
        'print' // Load as print, then swap to all
    );
    // Add onload handler to swap media to "all"
    add_filter('style_loader_tag', function($html, $handle) {
        if ($handle === 'theme-style') {
            $html = str_replace(
                "media='print'",
                "media='print' onload=\"this.media='all'\"",
                $html
            );
        }
        return $html;
    }, 10, 2);
}, 20);

This technique makes your page visually complete in a fraction of the time because the browser does not have to wait for the full stylesheet. Users see content immediately, and the rest of the styles load quietly in the background.

Minute 20-25: Clean Up Your Database

This one is especially important for WooCommerce stores. Over time, your WordPress database accumulates a shocking amount of junk:

Post revisions: WordPress saves every single draft of every post and page. A store with 500 products might have 5,000+ revision entries doing absolutely nothing.
Transients: Temporary cached data that often outlives its usefulness. Expired transients just sit in the database taking up space.
Spam and trashed comments: Self-explanatory.
Orphaned post meta: Metadata left behind by plugins you uninstalled months ago.
WooCommerce sessions: Expired customer session data that can grow to thousands of rows.

You can clean all of this up with a few SQL queries. Connect to your database via phpMyAdmin or a MySQL client and run these:

-- Delete all post revisions
DELETE FROM wp_posts WHERE post_type = 'revision';

-- Delete expired transients
DELETE FROM wp_options WHERE option_name
    LIKE '%\_transient\_%'
    AND option_name NOT LIKE '%\_transient\_timeout\_%';

-- Delete spam and trashed comments
DELETE FROM wp_comments WHERE comment_approved = 'spam'
    OR comment_approved = 'trash';

-- Optimize all tables
-- (run this after the cleanup queries above)

Important: Always back up your database before running any SQL queries. Always. I do not care how confident you are. Back it up.

To prevent revision bloat from coming back, add this line to your wp-config.php file:

// Limit post revisions to 3
define('WP_POST_REVISIONS', 3);

This keeps the safety net of revisions while preventing the database from growing endlessly. On a WooCommerce store I worked on last year, cleaning up revisions and expired transients alone reduced the database size from 800MB to 120MB. The difference in query speed was immediately noticeable.

Minute 25-30: Remove Render-Blocking Resources

The final step is to audit what WordPress is injecting into your <head> that you do not actually need. By default, WordPress adds quite a bit of extra weight:

The emoji script (yes, WordPress loads a JavaScript file just for emojis)
The embed script for oEmbed
jQuery Migrate (a compatibility layer for old plugins that most modern themes do not need)
The RSS feed links
The Windows Live Writer manifest
The WordPress version number (which is also a security risk)

Add this to your functions.php to clean it all up:

/**
 * Remove unnecessary head resources
 */
// Remove emoji scripts and styles
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
remove_action('admin_print_scripts', 'print_emoji_detection_script');
remove_action('admin_print_styles', 'print_emoji_styles');

// Remove embed script
wp_deregister_script('wp-embed');

// Remove WordPress version number
remove_action('wp_head', 'wp_generator');

// Remove Windows Live Writer manifest
remove_action('wp_head', 'wlwmanifest_link');

// Remove RSS feed links (if you don't use RSS)
remove_action('wp_head', 'feed_links', 2);
remove_action('wp_head', 'feed_links_extra', 3);

// Remove REST API link
remove_action('wp_head', 'rest_output_link_wp_head');

// Remove oEmbed discovery links
remove_action('wp_head', 'wp_oembed_add_discovery_links');

// Remove shortlink
remove_action('wp_head', 'wp_shortlink_wp_head');

For jQuery Migrate, be careful. Test your site after removing it, because some older plugins still depend on it. If everything works fine without it, add this:

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

The Results

If you followed all six steps, here is what you have done in 30 minutes:

Reduced image sizes by 30-50% (WebP/AVIF conversion)
Eliminated unnecessary image loading on initial page load (smart lazy loading)
Removed external font requests and eliminated invisible text flash (font optimization)
Made the above-the-fold content render without waiting for the full stylesheet (critical CSS)
Shrunk your database and sped up queries (database cleanup)
Removed 6+ unnecessary scripts and meta tags from your <head> (resource cleanup)

On the last WooCommerce store where I applied all of these changes together, the results were:

LCP (Largest Contentful Paint): from 4.2s to 1.8s
Total page weight: from 3.8MB to 1.1MB
Number of HTTP requests: from 47 to 22
PageSpeed Insights score: from 38 to 91

No caching plugin. No optimization plugin. No CDN (though you should use one too). Just fundamentals.

One Last Thing

I want to be clear: I am not saying plugins are bad. There are excellent caching plugins and CDN integrations that absolutely have their place. What I am saying is that installing plugins before fixing the basics is like putting a turbocharger on a car with flat tires.

Fix the tires first. Then add the turbo.

The steps in this guide are the tires. They are the foundational performance wins that every WordPress and WooCommerce site should have, regardless of what plugins you add on top. And the best part is that these changes are permanent. They do not depend on a plugin being maintained, updated, or compatible with your next theme.

Your code, your performance, your control.

Happy coding :D

AI Agents Are Coming for Your WordPress Admin Panel, and That's Not a Bad Thing

Ali Karbasi — Tue, 26 May 2026 17:52:25 +0000

Posted on Apr 25, 2026
5 min read

🤖 AI summary: This article explores the rise of AI agents in the WordPress ecosystem and what it means for web developers. While autonomous AI is beginning to handle routine admin tasks like inventory management, SEO optimization, and customer support, the author argues this shift creates more opportunities for skilled developers, not fewer. The piece draws on real-world examples to show that AI agents still need human architects to configure, supervise, and rescue them when they inevitably break, making the WordPress developer's role more strategic than ever.

I have been building WordPress sites since the days when "responsive design" meant adding a single media query and hoping for the best. Over that time, I have watched the platform survive every existential threat thrown at it. Squarespace was going to kill it. Wix was going to kill it. Headless CMS was going to kill it. Webflow was definitely going to kill it.

WordPress is still here, powering over 40% of the web.

But this time, the threat feels different. Because the thing coming for WordPress isn't another website builder. It is something that doesn't build websites at all. It is something that runs them.

I am talking about AI agents.

What Are AI Agents, and Why Should You Care?

If you have been paying attention to the tech world in 2026, you have heard the term "AI agents" roughly nine thousand times. But let me cut through the hype and explain what they actually are in practical terms.

An AI agent is not a chatbot. A chatbot waits for you to ask it something, gives you an answer, and stops. An AI agent is autonomous. You give it a goal, and it figures out the steps, executes them, and keeps going until the job is done. It can use tools, make decisions, and chain multiple actions together.

Think of it this way: ChatGPT is like texting a smart friend for advice. An AI agent is like hiring an employee who shows up, reads the manual, and starts working without being told every single step.

Now imagine that employee has access to your WordPress admin panel.

What Agents Are Already Doing in WordPress

This is not hypothetical. It is happening right now. Here is what AI agents are starting to handle in the WordPress and WooCommerce ecosystem:

Inventory management: Agents that monitor stock levels, automatically reorder from suppliers, and update product statuses. Remember my post about hiding out-of-stock products? An agent doesn't just hide them; it restocks them before they even run out.
SEO optimization: Agents that crawl your pages, rewrite meta descriptions, optimize image alt text, fix internal linking, and submit updated sitemaps to Google. All while you sleep.
Customer support: Agents that handle order inquiries, process refunds, and update shipping information. Not canned responses, actual contextual understanding of the customer's order history.
Content scheduling and updates: Agents that audit your blog posts, update outdated information, flag broken links, and even draft new posts based on trending keywords in your niche.
Security monitoring: Agents that watch your access logs, detect suspicious login attempts, patch vulnerable plugins, and alert you only when something genuinely needs human attention.

A year ago, each of these tasks required either a dedicated plugin (or three), a virtual assistant, or you doing it yourself at midnight. Now, a single AI agent with the right permissions can handle all of them.

The "But It Will Replace Us" Panic

I know what you are thinking, because I thought it too.

"If an AI agent can manage a WordPress site, why would anyone hire me to do it?"

This is the same fear I wrote about in my junior developer article. And the answer is the same: the tool is not the job. The job is knowing when and how to use the tool.

Let me give you a real example.

A client I work with runs a WooCommerce store with about 2,000 products. They set up an AI agent to manage their product descriptions. The agent was supposed to optimize them for SEO. And it did. Beautifully. Every product description was rewritten with keywords, proper structure, and compelling copy.

There was just one problem.

The agent changed the product descriptions for items that had legal compliance requirements. Supplement labels, safety warnings, certifications. The agent didn't know those descriptions were legally mandated. It just saw "poorly optimized text" and "fixed" it.

The store was flagged by their payment processor within a week.

Who fixed it? Not the agent. A developer who understood the business context, rolled back the changes, and set up guardrails so the agent couldn't touch compliance-sensitive fields.

The New WordPress Developer Role

This is where I think our profession is heading. And honestly, I think it is a more interesting job than what we had before.

The old WordPress developer role was roughly this:

Install WordPress
Pick a theme
Install 47 plugins
Customize CSS until the client is happy
Pray nothing breaks on update day

The new WordPress developer role is becoming this:

Agent Architect: Deciding which tasks should be automated and which need human oversight. Setting up the agent's permissions, scope, and boundaries.
Integration Engineer: Connecting AI agents to WooCommerce APIs, payment gateways, CRMs, and third-party services. This requires understanding both the WordPress ecosystem and the new agent protocols like MCP (Model Context Protocol).
Guardrail Designer: Building the safety nets. What can the agent change? What requires approval? What is completely off-limits? This is the compliance and risk layer that no AI can design for itself.
Rescue Squad: When the agent breaks something (and it will), you are the one who understands the system well enough to fix it. This is the same argument I made in my Vibe Coding vs. System Architecture post: the market pays you for what you do when things go wrong, not when things go right.

The Plugin Graveyard

Here is a prediction I feel fairly confident about: AI agents are going to kill a significant number of WordPress plugins.

Think about it. Why would you install a dedicated SEO plugin, a caching plugin, an image optimization plugin, a broken link checker, a redirect manager, and a security scanner when a single AI agent can handle all of those tasks dynamically?

The plugin model is fundamentally static. You install it, configure it once, and it does the same thing forever until you update it. An agent is dynamic. It adapts. It learns your site's patterns. It doesn't need a settings page because it figures out the optimal settings itself.

This does not mean all plugins are dead. Complex functionality like WooCommerce itself, page builders, and specialized tools will survive. But the "utility" plugins, the ones that do one simple thing, are going to be absorbed by agents.

And here is the twist: this is good for WordPress performance. One of the biggest complaints about WordPress has always been plugin bloat. If agents replace twenty plugins with a single intelligent process, sites get faster, more secure, and easier to maintain.

What You Should Do Right Now

If you are a WordPress developer reading this, here is my honest advice:

Learn how AI agents work: Not at a PhD level. Just understand the basics: what an agent is, how it chains actions, what MCP and tool-use patterns look like. You do not need to build an agent from scratch; you need to know how to configure and supervise one.
Get comfortable with APIs: The WordPress REST API is about to become the most important part of your skill set. Agents interact with WordPress through APIs, not through the admin panel. If you have been avoiding the REST API, now is the time to learn it.
Think in permissions, not features: The old question was "What plugin should I install?" The new question is "What should this agent be allowed to do?" Start thinking about WordPress management as an access control problem.
Keep your WooCommerce knowledge sharp: E-commerce is the area where AI agents will have the biggest impact first, because there is the most repetitive work to automate. Your WooCommerce expertise is about to become more valuable, not less.
Document everything: Agents need context to work well. The better you document a client's business rules, content guidelines, and compliance requirements, the better the agent will perform, and the more the client will need you to maintain that documentation.

The Verdict

AI agents are not coming to replace WordPress developers. They are coming to replace the most boring parts of the WordPress developer's job.

The manual updates. The repetitive SEO tweaks. The "can you change this button color" tickets. The midnight stock-level checks. Those are agent territory now.

What is left for us? The interesting stuff. The architecture. The strategy. The "your agent just deleted all your product reviews and I need to fix it" emergencies.

The developers who treat AI agents as a threat will be competing against a tool they refuse to understand. The developers who treat AI agents as a power tool will be the ones building, configuring, and supervising the systems that run the next generation of WordPress sites.

The admin panel is getting a new operator. Your job is to make sure that operator doesn't burn the house down.

And trust me, that job is not going anywhere.

The Death of the Junior Developer Is Greatly Exaggerated

Ali Karbasi — Tue, 26 May 2026 17:34:06 +0000

Posted on Feb 13, 2026
4 min read

🤖 AI summary: This article pushes back on the popular narrative that AI coding tools will eliminate the need for junior developers. It argues that while AI has changed the entry point into software engineering, juniors who learn alongside AI are developing a hybrid skill set that makes them more capable, not less relevant. The piece warns that companies cutting junior roles to rely on AI are sabotaging their own talent pipelines, creating a "missing generation" of mid-level engineers that will haunt them within three to five years.

Every week, I see a new LinkedIn post from a tech CEO declaring that junior developers are finished. "Why would I hire someone with zero experience when I can just use AI?" they say, usually accompanied by a screenshot of ChatGPT writing a React component in twelve seconds.

And honestly, I get the logic. On paper, it makes sense. If the machine can write the code, why pay someone to learn how to write it?

But this take is so shortsighted it makes my eyes hurt.

The "Just Use AI" Fallacy

Here is what the "replace juniors with AI" crowd doesn't understand: you are not hiring a junior developer to write code. You are hiring them to become the senior developer you will desperately need in three years.

Junior roles have never been about immediate output. They are an investment in your future engineering bench. It is like a football club saying, "Why do we need an academy? We can just buy finished players." Sure, until the transfer market dries up and you have no pipeline.

And that is exactly what is happening. The companies slashing junior positions today are going to be in a bidding war for senior talent in 2029, wondering where all the mid-level engineers went.

They didn't go anywhere. They were never created.

The Junior + AI = Something New

Here is the part that actually excites me.

The juniors who are entering the industry right now, in 2026, are not the same juniors we had in 2019. They are growing up with AI as a native tool. They don't see it as a crutch or a threat. They see it as a power tool, like a drill versus a screwdriver.

I have been watching junior developers on my team use AI, and something interesting happens. They don't just blindly paste the output. The good ones are doing something I rarely saw before:

They ask the AI to explain its reasoning. Not just "give me the code" but "why did you use a Map instead of an Object here?"
They cross-reference the output. They check the docs. They test edge cases. They are skeptical.
They learn faster. What used to take six months of Stack Overflow rabbit holes now takes six weeks of targeted AI-assisted exploration.

These AI-native juniors are developing at an accelerated pace. They still make mistakes, obviously. But they are making different mistakes. More interesting ones. Higher-level ones. They are skipping the "how do I center a div?" phase and getting to the "should this be server-rendered or client-rendered?" phase much sooner.

The "Missing Generation" Problem

Let me paint you a picture of what happens if the industry actually follows through on cutting junior roles.

Right now, a healthy engineering team looks like a pyramid. A few seniors at the top, a solid layer of mid-levels in the middle, and a wide base of juniors at the bottom. The juniors learn from the mids, the mids learn from the seniors, and the whole thing flows upward over time.

Now remove the bottom layer.

In three years, those mid-levels become your seniors. But who replaces them? There is nobody. You skipped a generation. You now have a top-heavy team of expensive seniors with no one beneath them to delegate to, mentor, or promote.

So what do you do? You post a job listing for a "mid-level developer with 3-5 years experience." But the candidates don't exist because nobody hired them when they were juniors. The talent pool has a hole in it, and it is a hole you created.

What Actually Changed (And What Didn't)

Let me be clear about what AI did change for juniors:

The bar for "entry-level output" is higher. A junior today is expected to ship more, faster, than a junior five years ago. AI raised the floor.
Syntax memorization is worthless. Nobody cares if you can write a for loop from memory. AI can do that. What matters is knowing when to use a for loop versus a .map() versus a recursive call.
The interview process needs to change. If you are still asking juniors to reverse a linked list on a whiteboard, you are testing the wrong skills. Test their ability to evaluate AI output. Give them broken AI-generated code and ask them to find the bugs.

But here is what did NOT change:

You still need people who understand systems. AI doesn't understand your business logic. It doesn't know that the discount code feature your last developer built has a race condition that triggers double coupons. A human does.
You still need people who can communicate. Half of engineering is translating what the product manager wants into what the code should do. AI cannot sit in a meeting and say, "That feature scope is too big for this sprint."
You still need people who grow. AI doesn't get promoted. It doesn't become your tech lead. It doesn't mentor the next batch of juniors. People do.

A Message to Junior Devs

If you are a junior reading this and feeling anxious about your future, let me be blunt: you are fine.

But you need to adapt. The junior role of 2020 is gone. The new junior role is not "person who writes boilerplate code." The new junior role is "person who can leverage AI to solve problems while understanding why the solution works."

Learn to read code more than you write it. Learn to ask "what could go wrong?" before you ask "does it work?" Learn to treat AI like a very fast, very confident coworker who sometimes lies to your face.

If you can do that, you are not replaceable. You are invaluable.

The Verdict

The death of the junior developer has been greatly exaggerated. What is actually dying is the old definition of what a junior developer does.

The companies that understand this will invest in AI-augmented junior programs and have a stacked engineering bench in five years. The companies that don't will be posting desperate LinkedIn job ads for "senior engineers, URGENT" while wondering why nobody applies.

The future doesn't belong to AI alone. It belongs to the humans who know how to work with it. And the best time to start learning that skill is when you are junior.

The Vibe Tax: How Unvalidated AI Code Is Flooding the Market and Driving Up Technical Debt

Ali Karbasi — Tue, 26 May 2026 17:19:40 +0000

Posted on Nov 29, 2025
3 min read

🤖 AI summary: This article explores "The Vibe Tax," a hidden cost associated with relying on unvalidated AI-generated code that appears correct on the surface but lacks structural integrity. While AI tools drastically increase coding speed, they often lack context and optimization, leading to bloated dependencies and disjointed "Frankenstein" codebases that are difficult to maintain. The piece argues that this accumulation of technical debt ultimately makes senior engineers more valuable than ever, as they are needed to audit AI outputs and ensure sustainable software architecture rather than just rapid delivery.

We need to talk about the bill.

Right now, the tech industry is enjoying an all-you-can-eat buffet of free code. You want a landing page? Here is the HTML. You want a Python script to scrape emails? Done in seconds. It feels like we have unlocked a cheat code for productivity.

But as any senior developer will tell you, there is no such thing as free code.

I have started noticing a pattern in recent code reviews and freelance audits. I call it "The Vibe Tax." It is the hidden cost of pasting code that you do not fully understand, and it is about to become the most expensive line item in software development.

The "Frankenstein" Codebase

The problem with AI generation isn't that the code is wrong. Often, it is technically correct. The problem is that AI has zero sense of context.

If you ask ChatGPT to write a function to format a date in three different parts of your app, it might give you three completely different solutions.

One uses moment.js (which is huge and outdated).
One uses a custom regex (which is fragile).
One uses the native Date object (which is quirky).

They all work. The "vibe" is consistent. But your codebase is now a Frankenstein monster of conflicting styles and unnecessary dependencies.

The tax comes due six months later. That is when a developer has to update the date format across the app. Instead of changing it in one place, they have to hunt down three different implementation methods. What should be a five-minute task turns into a two-hour headache.

Bloat is the New Normal

I recently looked at a simple "To-Do" app built by a founder using AI tools. It worked great. But the bundle size was massive.

Why? Because every time the founder got stuck, they asked the AI for a fix, and the AI suggested installing a new library. Need a button? Install a UI kit. Need an icon? Install an icon pack. Need to center a div? Install a layout engine.

The AI optimized for "getting it working now" rather than "keeping it lightweight." The result was a simple app carrying 50MB of dead weight. That is the Vibe Tax. You pay for it in server costs, slow load times, and frustrated users on mobile connections.

The Market Impact: The "MVP" Trap

This is where it affects the market. We are seeing a flood of MVPs (Minimum Viable Products) built entirely via vibe coding.

Investors love them because they are built fast and cheap. But these products often have a technical lifespan of about three months.

When these startups try to hire their first real engineering team to build "Version 2," the engineers take one look at the code and realize it is unsalvageable. There is no architecture. There is no security logic. It is just a loose pile of scripts held together by hope.

The company then has to pause all feature development for months just to rewrite the entire thing. That is a massive tax.

Experience is the Only Audit

This is why I believe the demand for senior engineers is actually going to go up, not down.

Junior developers and non-coders can now generate volume. They can flood a repo with commits. But volume is not value.

Companies are going to realize that while they can get features built for "free" with AI, the cost of maintaining that code is skyrocketing. They will need experienced eyes to look at a generated solution and say, "No, do not use that library," or "That database schema will fail at 1,000 users."

The Vibe Tax is real. And the only way to avoid paying it is to stop treating AI as a magic wand and start treating it like what it actually is: a really fast, really confident intern who needs supervision.

The New Digital Divide: Will "Vibe Coding" Really Make Everyone a Developer?

Ali Karbasi — Tue, 26 May 2026 16:56:00 +0000

Posted on Nov 23, 2025
4 min read

🤖 AI summary: This post challenges the popular narrative that AI tools are making traditional coding skills obsolete by allowing anyone to become a software engineer. It argues that while "vibe coding" enables non-technical users to generate code quickly, it creates a new "digital divide" where these users become helpless "passengers" the moment they encounter complex errors or dependency conflicts. The article concludes that the market value of a developer is shifting from writing syntax to "logic verification," as the true cost of engineering lies in fixing systems when they break, not just generating them when they work.

My LinkedIn feed is currently drowning in posts from "ex-non-technical" founders. You know the ones. They claim they built a SaaS in a weekend using nothing but Cursor and a dream. They say, "Coding is dead. English is the new programming language." And for a split second, I believe them.

Then I look at the actual code they are shipping.

We are being sold a story that AI is the great equalizer. The narrative is that the barrier to entry has dropped to zero, and now anyone with a keyboard is a software engineer. But I actually think the opposite is happening.

Vibe coding isn't closing the digital divide. It is creating a much scarier one.

The "Hello World" Mirage

Here is the thing about coding that tutorials never tell you: writing the code is actually the easy part.

If you ask an LLM to "build me a To-Do list app in React," it will do it. It will give you the component. It will give you the CSS. It looks great. The non-developer feels like a wizard.

But then they try to run npm install.

Suddenly, they see a wall of red text. Something about peer dependency conflicts or a deprecated warning from a library the AI chose because its training data is six months old.

This is the new divide.

On one side, you have people who know how to read that error message, update the package.json, and move on. On the other side, you have the "Vibe Coders" who are now completely stuck. They paste the error back into the AI. The AI apologizes and gives them a different wrong solution. They go in circles for four hours.

Access to code generation is not the same thing as access to engineering.

The "Passenger" Problem

I like to think of it like self-driving cars.

Vibe coding puts you in the driver's seat of a Tesla on Autopilot. It feels amazing. You are going 70 mph on the highway, listening to a podcast, barely touching the wheel. You feel like a driver.

But what happens when the car suddenly swerves because it saw a ghost cone? Or when a tire blows out?

If you don't know how to drive manually, you aren't a driver. You are a passenger who happens to be sitting in the front seat.

The danger for these new "AI developers" is that they are building complex systems they do not understand. They are passengers in their own products. When a customer reports a bug, the Vibe Coder is helpless. They can't fix it because they never built it. They just asked for it.

The New Skill: Developing a "Lie Detector" for Code

So, does this mean "normal people" can't become developers via AI?

No, they absolutely can. But the path isn't just "typing prompts." The path is learning to audit what comes back.

The most valuable skill for a junior developer right now isn't memorizing syntax. It is Logic Verification.

I watched a junior dev use AI to write a regex for validating emails last week. The AI gave him a regex. It looked fancy. He pasted it in.

I asked him, "Does that regex allow a plus sign for email aliases? Like name+tag@gmail.com?"

He didn't know. He hadn't checked. He trusted the vibe!

Real development is now about looking at the AI's output and saying, "Nice try, but that is going to cause a memory leak." It is about having the foundational knowledge to know when the AI is hallucinating.

The Verdict

Vibe coding is an incredible entry point. It is like training wheels. It lets you feel the wind in your hair before you know how to balance.

But if we tell people that the training wheels are the bike, we are setting them up for a nasty crash.

The market doesn't pay you for the code you write when everything is going right. The market pays you for the code you fix when everything goes wrong. And unfortunately for the vibe coders, you can't prompt your way out of a system outage.

Vibe Coding vs. System Architecture: Why "It Works" is Not the Same as "It Scales"

Ali Karbasi — Tue, 26 May 2026 16:41:50 +0000

Posted on Nov 18, 2025
2 min read

🤖 AI summary: This piece distinguishes between the immediate gratification of "vibe coding" and the necessity of robust system architecture. It argues that while AI successfully handles the "happy path" for demos, it consistently overlooks critical factors like scalability, security, and edge cases, such as database connection limits or race conditions. Consequently, the role of the developer is evolving into that of an auditor who must validate AI outputs, ultimately ensuring job security as experts are required to stabilize fragile, AI-generated prototypes.

I saw a tweet the other day. Maybe you saw it too. Someone "vibe coded" a Flappy Bird clone in like, forty-five seconds. They just typed "Make me a game with a bird that jumps," and boom. Python script. Working game.

And honestly? It was impressive. I felt that familiar little pang of insecurity.

Is this it? Am I done? Do I just retire to a goat farm now?

But then I remembered the file my old boss sent me (the empty one I mentioned in my LinkedIn post). And I remembered what happens when you actually try to put that "forty-five second" code into a real production environment.

The problem with Vibe Coding isn't that it doesn't work. It’s that "working" is the lowest bar in software engineering.

The "Works on My Machine" Trap, AI Edition

We’ve all been there. You write a quick script to parse a CSV. It runs fine on your laptop with 50 rows of data. Then you push it to prod, the client uploads a 4GB file, and the server melts because you loaded the whole thing into memory.

AI is the king of the "happy path."

When you tell an LLM, "Write me a React component that fetches user data" it will give you exactly that. A useEffect, a fetch call, maybe a loading state if it’s feeling generous. It works. You can click the button, and data appears. The vibe is good.

But here is what the AI didn't ask you:

What happens when the API is down? (The AI usually just lets the app crash).
What about race conditions? If I click that button five times fast, do I trigger five parallel requests that return out of order?
Where are the secrets stored? (I’ve seen AI hardcode API keys into frontend code more times than I can count).

Vibe coding gets you from A to B. System architecture is asking, "What happens if 10,000 people try to go from A to B at the same time, and the road is on fire?"

Architecture is Invisible

The reason "Vibe Coding" feels so magical to non-developers (and let's be real, to us too sometimes) is that code looks flat. To an LLM, a for loop is just text. It predicts the next token. It doesn't "know" that a nested loop over a million records is a bad idea; it just knows that nested loops often appear in codebases.

Architecture is the invisible structure that holds the code up. It's the decisions you make before you type.

I recently reviewed some AI-generated backend code that "worked perfectly" for a single user. It opened a database connection, queried the data, and closed the connection. Great.

Except it opened a new connection for every single API request.

In a "vibe check," that passes. The app loads. The demo looks slick. But if you launched that? Your database runs out of connections in ten minutes, your site 504s, and you’re waking up at 3 AM wondering why the vibe has turned so hostile.

The Developer as the Auditor

This is where I think our role is actually going. We aren't just writers anymore; we’re auditors.

When I use ChatGPT now, I don't treat it like a junior developer. I treat it like a talented but reckless contractor who lies on their resume.

"Okay, you wrote the SQL query. Nice. Did you index that column?"
"You added an image upload feature. Cool. Did you restrict the file types, or can someone upload a .exe and hack the server?"

The "Vibe" is fast, but it’s shallow. It prioritizes immediate gratification over long-term survival.

So, Are We Doomed?

Nah.

If anything, "Vibe Coding" is going to create more work for us, not less. We are about to see a tsunami of "It Works!" prototypes hitting the market. These will be apps built entirely by prompt engineering that function beautifully until they hit their first edge case.

Someone has to come in and untangle that spaghetti. Someone has to look at the "working" code and say, "Okay, this is cute, but it’s not scalable."

That’s not vibe. That’s engineering.

How to Grayscale Images of Out-of-Stock Products in WooCommerce Using CSS

Ali Karbasi — Tue, 26 May 2026 16:39:28 +0000

Posted on Aug 27, 2024
2 min read

🤖 AI summary: This article provides a guide on how to enhance WooCommerce store navigation by automatically grayscaling images of out-of-stock products using CSS. By targeting the .outofstock class that WooCommerce automatically assigns to unavailable items, store owners can apply a filter: grayscale(1); rule to visually mute these specific images. This visual cue helps customers quickly identify stock availability without relying on text labels, and the necessary code can be easily implemented through the WordPress Theme Editor or the Customizer's Additional CSS section.

WooCommerce is a powerful and flexible eCommerce plugin for WordPress, allowing you to create and manage an online store with ease. Making visual changes to your products, particularly those that are out of stock, using CSS is just one of the numerous ways you can personalize your WooCommerce store. This post will explain how to apply a simple CSS code snippet to grayscale product photos that are out of stock so that customers can notice that these items are not available.

Why Grayscale Out-of-Stock Product Images?

Grayscaling photos of out-of-stock products is a simple yet effective approach to notify shoppers that some things are now unavailable. This visual signal helps manage consumer expectations without requiring additional text or notifications. It also improves the customer experience by clearly indicating which products are in stock and which are not, decreasing frustration and improving the entire shopping experience.

The CSS Code

The CSS code required to grayscale the images of out-of-stock products in WooCommerce is simple and straightforward:

.outofstock img {
    filter: grayscale(1);
}

How This Code Works

Let's break down how this code works and why it integrates seamlessly with WooCommerce:

WooCommerce's Built-In Class for Out-of-Stock Products: WooCommerce automatically assigns the class outofstock to products that are out of stock. This class can be targeted with CSS to apply specific styles to out-of-stock items only.
Targeting the Product Image: The img selector within .outofstock ensures that only the images of the out-of-stock products are affected by this CSS rule. This means that the rest of the product details, such as the title and price, will remain unchanged.
Applying the Grayscale Filter: The filter property in CSS is used to apply visual effects to elements. In this case, grayscale(1) converts the image to black and white, with 1 indicating a full grayscale effect (as opposed to 0, which would leave the image in full color). This makes the product image appear muted, clearly signaling that the item is unavailable.

Implementing the Code in Your WooCommerce Store

To apply this CSS code to your WooCommerce online store, you can simply add it to your theme's stylesheet or use the built-in Additional CSS option in the WordPress Customizer:

Using the Theme's Stylesheet:

Go to your WordPress dashboard.
Navigate to Appearance > Theme Editor.
Locate the style.css file of your active theme.
Add the CSS code at the bottom of the file and save your changes.

Using the WordPress Customizer:

Go to your WordPress dashboard.
Navigate to Appearance > Customize.
Click on Additional CSS.
Paste the CSS code into the text area and publish your changes.

Conclusion

Customizing your WooCommerce store to display grayscale out-of-stock product photos is a simple yet effective method to improve the user experience. Using WooCommerce's built-in classes and the CSS filter function, you can visually distinguish unavailable products, allowing customers to explore your store more efficiently. This little change can have a significant impact on how people perceive your store, resulting in a more enjoyable shopping experience.

Feel free to play around with this CSS code and combine it with other styles to further customize your WooCommerce store!

Happy Coding :D

How to Boost Customer Loyalty with Automatic Discount Codes in WooCommerce

Ali Karbasi — Tue, 26 May 2026 16:32:21 +0000

Posted on Aug 11, 2024
2 min read

🤖 AI summary: This article outlines a technical method for increasing customer loyalty in WooCommerce by automatically generating unique discount codes for customers after they complete a purchase. By adding a specific PHP code snippet to the functions.php file of a child theme, store owners can programmatically create a 25% off coupon that is linked to the customer's order ID and email, set to expire in 90 days. The guide highlights that this strategy not only personalizes the shopping experience but also incentivizes repeat business by providing a tangible reward for previous orders, ultimately serving as a low effort, high impact tool for customer retention.

Customer retention is critical for long-term business growth, and one efficient strategy to encourage repeat purchases is to provide discount codes for future sales. This article will explore how to use automatic discount code generation in WooCommerce to enhance client loyalty and sales.

Implementing Automatic Discount Codes

Adding automatic discount codes to your WooCommerce online store is a straightforward process. By inserting the following code into your theme’s functions.php file, you can automatically generate a unique discount code when a customer completes a purchase. This code can then be used by the customer on their next order.

Here’s the code to achieve this:

/**
 * Automatic Discount Codes in WooCommerce
 * Visit alikarbasi.com/blog for more codes.
**/

add_action('woocommerce_order_status_processing', 'create_discount_code_with_order_id', 10, 1);

function create_discount_code_with_order_id($order_id) {
    $order = wc_get_order($order_id);
    $email = $order->get_billing_email();
    // Order number with "solo" prefix as discount code
    $coupon_code = 'solo' . $order_id;
    // Discount percentage
    $amount = '25';
    // Discount type
    $discount_type = 'percent';

    // Check if the discount code with this order number and prefix already exists
    if (get_page_by_title($coupon_code, OBJECT, 'shop_coupon')) {
        return;
    }

    $coupon = array(
        'post_title' => $coupon_code,
        'post_content' => '',
        'post_status' => 'publish',
        'post_author' => 1,
        'post_type' => 'shop_coupon'
    );

    $new_coupon_id = wp_insert_post($coupon);

    // Discount code settings
    update_post_meta($new_coupon_id, 'discount_type', $discount_type);
    update_post_meta($new_coupon_id, 'coupon_amount', $amount);
    update_post_meta($new_coupon_id, 'individual_use', 'yes');
    update_post_meta($new_coupon_id, 'usage_limit', '1');
    //Set discount code to expire after 3 months
    update_post_meta($new_coupon_id, 'expiry_date', date('Y-m-d', strtotime('+90 days')));
    update_post_meta($new_coupon_id, 'customer_email', array($email));
    update_post_meta($new_coupon_id, 'usage_limit_per_user', '1');
    update_post_meta($new_coupon_id, 'minimum_amount', '50');
    update_post_meta($new_coupon_id, 'product_ids', '');

    // Save the discount code as order meta data for future use
    update_post_meta($order_id, '_discount_coupon_code', $coupon_code);
}

Benefits of Automatic Discount Codes

Giving consumers a discount code for subsequent purchases encourages them to stay loyal to your business. This may be a crucial tactic in preserving enduring connections with your clients.

Having automatic discount codes makes buying more personalized for the individual. Consumers like the gesture of a discount since it makes them feel important and may improve their opinion of your brand.

Best Practices for Implementation

When implementing this feature, it is advisable to:

Use a Child Theme: Insert the code into your theme’s child theme rather than the main theme. This ensures that your changes are preserved even after theme updates.
Customize Messaging: Tailor the discount code message sent to customers to align with your brand’s tone and enhance their experience.

Conclusion

Using WooCommerce to automatically generate discount codes is a straightforward but powerful way to increase sales and foster client loyalty. You can quickly add this feature to your WordPress website and give your consumers an extra reason to come back and make more purchases by following the above-described procedures. This minor adjustment can have a big impact on customer retention and overall company expansion.

Happy coding :D

How to Hide Out-of-Stock Products on Your WordPress Website

Ali Karbasi — Tue, 26 May 2026 16:25:24 +0000

Posted on Aug 5, 2024
2 min read

🤖 AI summary: This article outlines a technical method to improve the shopping experience on WordPress websites by automatically hiding out-of-stock products from the main views. By adding a custom PHP code snippet to the theme's functions.php file, site administrators can utilize the pre_get_posts action hook to modify the main database query. This ensures that items with a "outofstock" status are excluded from the home page, shop page, and product category archives, keeping the storefront clutter-free and preventing customer frustration.

If you use WordPress to manage an online store, you must keep your product pages clean and clutter-free. One effective strategy is to hide out-of-stock items. This improves the general shopping experience and helps avoid confusion among customers. In this article, we'll walk you through a simple method to hide out-of-stock products using a custom code snippet added to your functions.php file.

The Code

Let's start by looking at the code that will make your product pages show only available products.

/**
 * Visit alikarbasi.com/blog for more codes.
**/
function custom_pre_get_posts_query( $q ) {
    if ( ! is_admin() && $q->is_main_query() ) {
        if ( is_home() || is_front_page() || is_shop() || is_product_category() ) {
            $meta_query = $q->get( 'meta_query' );
            $meta_query[] = array(
                'key'     => '_stock_status',
                'value'   => 'outofstock',
                'compare' => 'NOT IN',
            );
            $q->set( 'meta_query', $meta_query );
        }
    }
}
add_action( 'pre_get_posts', 'custom_pre_get_posts_query' );

How It Works

This code snippet leverages the pre_get_posts action hook to modify the main query before WordPress fetches posts from the database. Here's a breakdown of how it works:

Function Declaration: The function custom_pre_get_posts_query is declared to modify the query parameters.
Conditional Check: The function checks if the current request is not from the WordPress admin area (! is_admin()) and if it is the main query ($q->is_main_query()).
Home and Front Page Check: It further checks if the current page is the home page or the front page (is_home() or is_front_page()) or the current page is shop page (is_shop()) or product category page (is_product_category()).
Modify Meta Query: If all conditions are met, it retrieves the existing meta_query from the query object and appends a new condition to exclude posts with the meta key _stock_status set to outofstock.
Set Modified Meta Query: The modified meta_query is then set back to the query object, effectively excluding out-of-stock products from the results.

How to Use the Code

To apply this code to your WordPress site, take these steps:

Access Your Theme's functions.php File:

Log in to your WordPress admin dashboard.
Navigate to Appearance > Theme Editor.
In the Theme Files list, locate and click on functions.php.

Add the Code:

Copy the provided code snippet.
Paste it at the end of your functions.php file, just before the closing ?> tag if it exists.

Save Changes:

Click the Update File button to save your changes.

Conclusion

By adding this simple code snippet in your functions.php file, you can easily hide out-of-stock items from your product and main pages. This will assist maintain your website clean and guarantee that customers only see available products.

Happy coding :D

The Easiest Way to Add Dark Mode to Your Website

Ali Karbasi — Tue, 26 May 2026 16:23:17 +0000

Posted on Jul 28, 2024
3 min read

🤖 AI summary: This tutorial outlines a method for implementing dark mode on a website using HTML, CSS variables, and JavaScript. The process involves creating a basic HTML structure with a toggle button, defining specific color variables for both light and dark themes in CSS, and using JavaScript to switch the "dark-mode" class while saving the user's preference in local storage. By following these steps, developers can ensure a seamless transition between themes that persists across page reloads, ultimately improving user experience by reducing eye strain and conserving battery life.

The ability to use websites and applications in dark mode has grown in popularity in recent years. It relieves eye strain, prolongs battery life on OLED-screening devices, and offers an aesthetically pleasing substitute for the traditional light theme. This tutorial will show you how to use JavaScript to toggle themes and CSS variables to add dark mode to your website.

Step 1: Setting Up Your HTML

First, let's start with a basic HTML structure. Create an index.html file with the following content:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Dark Mode Example</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <header>
        <h1>Welcome to Dark Mode Tutorial</h1>
        <button id="theme-toggle">Toggle Dark Mode</button>
    </header>
    <main>
        <p>This is a sample website to demonstrate dark mode implementation.</p>
    </main>
    <script src="script.js"></script>
</body>
</html>

This HTML file includes a header with a title and a button to toggle dark mode, a main content area with some text, and links to our CSS and JavaScript files.

Step 2: Defining CSS Variables

Now let's define the variables in our CSS. Make a styles.css file with the following content:

:root {
    --background-color: #ffffff;
    --text-color: #000000;
    --header-background-color: #f1f1f1;
}

body {
    background-color: var(--background-color);
    color: var(--text-color);
    font-family: Arial, sans-serif;
    transition: background-color 0.3s, color 0.3s;
}

header {
    background-color: var(--header-background-color);
    padding: 20px;
    text-align: center;
}

button {
    padding: 10px 20px;
    margin-top: 20px;
    cursor: pointer;
}

.dark-mode {
    --background-color: #181818;
    --text-color: #ffffff;
    --header-background-color: #242424;
}

We use :root to define a group of CSS variables in this CSS file. For the light mode, these variables determine the background color, text color, and header background color. Additionally, a .dark-mode class is defined, and its settings take precedence over these variables. A seamless transition between themes is guaranteed by the body element's transition property.

Step 3: Adding JavaScript for Theme Toggling

Now, let's add the JavaScript to handle the theme toggling. Create a script.js file with the following content:

const themeToggle = document.getElementById('theme-toggle');
const body = document.body;

// Check for saved user preference
const savedTheme = localStorage.getItem('theme');
if (savedTheme) {
    body.classList.add(savedTheme);
}

// Toggle dark mode
themeToggle.addEventListener('click', () => {
    body.classList.toggle('dark-mode');

    // Save user preference
    if (body.classList.contains('dark-mode')) {
        localStorage.setItem('theme', 'dark-mode');
    } else {
        localStorage.removeItem('theme');
    }
});

This script selects the theme toggle button and the body element. When the button is clicked, it toggles the dark-mode class on the body. The script also saves the user's theme preference in localStorage, so the theme persists across page reloads.

Step 4: Testing the Implementation

Launch your web browser and open the index.html file to test the implementation. To switch between bright and dark themes, click the "Toggle Dark Mode" button. Remember that refreshing the page shouldn't affect the theme preference.

Conclusion

You can quickly add a dark mode toggle to your website by utilizing CSS variables and a little JavaScript. This methodology facilitates seamless theme transitions and offers an enhanced user experience. Please feel free to add more elements to your page and modify the styles in order to build upon this lesson.

Happy coding :D

Checking Internet Status in Basic4Android

Ali Karbasi — Tue, 26 May 2026 16:08:04 +0000

Posted on Jul 29, 2023
1 min read

🤖 AI summary: This article outlines a method for preventing default error messages in Basic4Android WebViews by verifying internet connectivity before loading content. By utilizing the Network library and initializing a ServerSocket on port 0, developers can implement a subroutine that checks the device's IP address. If the returned IP is "127.0.0.1", the device is considered offline, while any other IP indicates an active connection. This boolean check allows the application to gracefully handle offline states by displaying custom messages or hiding the WebView instead of showing standard browser errors.

Basic4Android lets you use WebView to load URLs in your application, but if your phone isn’t connected to the internet when the program runs, an error message will show up in the WebView itself, which doesn’t look nice.

By using this piece of code, you can check if the user’s phone is connected to the internet or not. Depending on the information you get, you can either hide the WebView or display an error message. Of course, this code can have other applications as well, but in this post, I’m using it for this purpose.

Required libraries: Network

First you need to define a ServerSocket variable in Process_Globals:

Sub Process_Globals
    Dim server As ServerSocket
End Sub

Then, check the phone’s IP address using the following Sub:

Sub GetIp As Boolean
    server.Initialize(0,"")
    If server.GetMyIP = "127.0.0.1" Then
      Return False
    Else
      Return True
    End If
End Sub

As you know, if we’re not connected to the internet, the default IP address of the device is 127.0.0.1. The If condition checks this IP and returns False if the phone’s IP matches 127.0.0.1 and if the IP address is not 127.0.0.1 (meaning we are connected to the internet), it returns True.

By the way, the number 0 in server.Initialize(0,"") represents the port number. More Info

Last but not least, you can use the True or False value to check if the internet connection is working:

If GetIp=True Then
  ToastMessageShow("Internet connection is established.", False)
Else
  ToastMessageShow("No internet connection!", False)
End If

That’s all!

Happy coding :D