DEV Community: abdelali Selouani

How I got my first client and got myself banned on WordPress.org in the same week.

abdelali Selouani — Wed, 01 Apr 2026 23:57:21 +0000

one week ago I mass-dm'd people telling them about an AI plugin I built for WordPress.
‎ ‎
Zero replies. Fair.
‎ ‎
So I thought, what if I actually help people first?
‎ ‎
I started browsing WordPress.org support forums, finding questions I genuinely knew the answers to. WooCommerce template overrides, REST API issues, Elementor CSS quirks. Stuff I'd spent months deep in while building my plugin.
‎ ‎
I'd answer the question properly, and at the end I'd mention that I built a tool that handles some of this stuff through natural language.
‎ ‎
It worked. Sort of.
‎ ‎
Someone reached out, tried the plugin, liked it, and became my first paying subscriber. $19/month.
‎ ‎
I stared at that Freemius notification for like five minutes. If you've ever built something alone and someone hands you money for it, you know the feeling. It's not about $19. It's proof that the thing in your head is real to someone else too.
‎ ‎
Then two days later I got an email from WordPress.org.
‎ ‎
My account was banned. Turns out a mod flagged my posts as self-promotion, linked my new forum account to my main one, and disabled both. And the plugin submission I'd been preparing? Rejected before it was even reviewed.
‎ ‎
In one week I got the highest high and the lowest low of this entire project.
‎ ‎
Here's what I learned the hard way: WordPress.org forums are not a marketing channel. The mods are right to enforce that. I was genuinely helping people, but I was also promoting my product, and those two things don't mix on that platform.
‎ ‎
I thought I was being clever. I was being the exact person I'd find annoying if I was on the other side.
‎ ‎
So now I'm in this weird spot. I have a product that works, one customer who actually loves it, a full landing page, a payment system running. And zero presence on the platform where most WordPress users discover plugins.
‎ ‎
I've emailed their team to own up to it and ask if there's a path back. Maybe there is, maybe there isn't.
‎ ‎
In the meantime I'm not stopping. I spent too many late nights on this thing to let one mistake kill it.
‎ ‎
But I wanted to share this because every "how I grew my plugin" post is a highlight reel. Nobody talks about the part where you shoot yourself in the foot three steps into the race.
‎ ‎
If you've ever built something for WordPress or WooCommerce and hit a wall that was entirely your own fault, I'd love to hear how you got past it.

WordPress 7.0 Ships a Built-In AI Client — Here's How We're Already Using It

abdelali Selouani — Sat, 28 Mar 2026 19:00:50 +0000

WordPress 7.0 drops on April 9, 2026, and for the first time ever, WordPress Core ships with a built-in AI Client. Not a plugin. Not a SaaS bolt-on. A provider-agnostic PHP API baked into Core that lets any plugin talk to any AI model through one unified interface.

We've been building PressArk — an AI co-pilot that lives inside your wp-admin dashboard — for the past year. When we saw the WordPress 7.0 AI Client proposal land, we immediately started thinking about what it means for plugins like ours, and for the WordPress AI ecosystem in general.

Here's what's actually changing, and what we learned adapting to it.

What the WordPress 7.0 AI Client Actually Is

The new wp_ai_client_prompt() function is the single entry point. It returns a WP_AI_Client_Prompt_Builder instance — WordPress-flavored with snake_case methods, WP_Error returns, and integration with the Connectors API.

The key design decision: WordPress Core ships zero AI providers. Instead, providers (OpenAI, Anthropic, Google) are installed as connector plugins via the new Settings > Connectors screen in wp-admin. Site owners add their API keys once, and every AI-powered plugin on the site can use them.

This is a big deal for plugin developers. Before 7.0, every AI plugin had to:

Bundle its own API key management UI
Handle its own credential storage
Pick a provider and lock users into it
Maintain its own HTTP transport layer

After 7.0, you write against wp_ai_client_prompt() and the site's configured provider handles the rest. Your plugin works whether the site uses Claude, GPT, Gemini, or a local Ollama instance.

Where PressArk Fits In

PressArk predates the WordPress 7.0 AI Client — we've been shipping our own AI integration layer since v1.0. Our plugin adds a chat panel to every wp-admin page where you describe what you want in plain English, and the AI agent figures out which tools to call, shows you a preview, and executes only after you approve.

Currently, PressArk handles its own model routing:

Free tier: DeepSeek V3.2 (bundled credits, no API key needed)
Pro tier: Claude Sonnet 4.6 via our token relay
BYOK: Bring your own OpenRouter key for any model

With the WordPress 7.0 AI Client landing in Core, we're evaluating how to integrate with the Connectors API alongside our existing routing. The interesting challenge: PressArk isn't just sending simple prompts — we run a full agentic loop with 200+ AI-callable tools, spin detection, token budgeting, and structured checkpoints. The WP AI Client is designed for request-response patterns, but agentic workflows need:

Multi-turn conversations with tool call results fed back into context
Token budget awareness (we track usage across a 258K context window with three-stage degradation)
Spin detection (if the agent makes 3 consecutive no-progress rounds, we kill the loop)
Structured memory that survives message compaction

We'll likely use the Connectors API for credential management while keeping our own orchestration layer for the agentic parts.

What This Means for WordPress AI Plugin Developers

If you're building AI features for WordPress, the 7.0 AI Client changes your development model:

1. Stop building credential UIs. The Connectors API handles API key storage, validation, and the admin settings page. Your plugin just calls wp_ai_client_prompt().

2. Go provider-agnostic from day one. Don't hardcode OpenAI or Anthropic. The AI Client automatically selects a suitable model based on prompt requirements (text vs. image, etc.) and whatever the site owner has configured.

3. Plan for the provider ecosystem. WordPress 7.1 (August 2026) will open up the Connectors page to third-party providers. If you're building a connector plugin for a niche model provider, start now.

4. Think beyond simple prompts. The AI Client handles request-response well, but if you're building agents, planners, or multi-step workflows, you'll need your own orchestration layer on top. The AI Client gives you the transport; you build the brain.

The Bigger Picture

WordPress powers 40%+ of the web. Having a standard AI interface in Core means:

Site owners configure AI credentials once instead of per-plugin
Plugin developers can add AI features without reinventing infrastructure
The WordPress ecosystem gets a shared foundation instead of fragmented approaches
Users aren't locked into a single AI provider

This is infrastructure, not features — and that's exactly the right call for something going into Core.

Try PressArk

If you want to see what a full AI agent looks like inside WordPress (not just prompt-response, but a complete agentic co-pilot with tool execution, previews, and safety guardrails), check out PressArk:

Website: pressark.com
WordPress.org: Plugin submitted and pending approval — search "PressArk" (it may be live by the time you read this)
Free tier available: Bundled AI credits, no API key required to start

We're genuinely excited about the WordPress 7.0 AI Client. It validates the direction we've been building toward, and it means we can focus more on what makes PressArk unique — the agentic layer — instead of infrastructure plumbing.

What are you building with the WordPress 7.0 AI Client? Drop your ideas in the comments — curious to see what the community comes up with.

Show DEV: PressArk - Talk to Your WordPress Site Instead of Clicking Through It

abdelali Selouani — Sat, 28 Mar 2026 18:50:26 +0000

Hey DEV! I built an AI co-pilot that lives inside your WordPress admin dashboard. Instead of clicking through menus, you just chat with it.

Website: pressark.com
WordPress.org: wordpress.org/plugins/pressark
Free tier: Yes - bundled AI credits, no API key needed

What it does

PressArk adds a chat panel to every wp-admin page. You describe what you want in plain English, it figures out the tools, shows you a preview, and executes only after you approve.

Examples of real commands:

"Edit the intro on my latest post to mention the spring sale"

"Create a 20% off coupon for WooCommerce that expires Friday"

"Audit the SEO on my homepage and fix the meta description"

"Scan my site for security vulnerabilities"

"Every Monday at 9am, run an SEO check on my top 5 pages"

What makes it different from other WP AI plugins

Most WordPress AI plugins do one thing: generate content. PressArk manages your entire site through conversation:

Content & Pages: Edit posts, pages, blocks, custom post types, media, excerpts, metadata
WooCommerce: Products, orders, customers, coupons, shipping, taxes, analytics
SEO: Full audit with scores (A-F), meta optimization, crawlability checks, one-click fixes
Security: WordPress version, PHP, SSL, plugin vulnerabilities, file permissions, user enumeration
Elementor: Edit widgets, layouts, containers, global styles, forms, popups via chat
Automations: Schedule recurring AI tasks with cron (daily SEO checks, weekly content audits)

Total: 200+ AI-callable tools across all categories.

The safety model

Nothing writes without your approval. Every tool is classified:

Level	Action	Example
Read	Auto-executes	Search content, check SEO score
Preview	Shows diff first	Edit post, update meta
Confirm	Explicit approval card	Publish, delete, process refund

This Preview > Approve > Execute pipeline is non-negotiable. The AI can't go rogue on your production site.

Tech details for the curious

Pure PHP WordPress plugin, no external frameworks
AI model routing: Free tier = DeepSeek V3.2, Pro = Claude Sonnet 4.6, or BYOK with OpenRouter/OpenAI/Anthropic
Content indexing via MySQL FULLTEXT (800-char chunks, 100-char overlap) - no vector DB needed
Site profiling: auto-analyzes your tone, brand voice, content patterns, and theme.json design tokens
Structured checkpoints for conversation memory that survives context compression
Spin detection: exits after 3 consecutive no-progress agent rounds
Token budget with three-stage degradation (prime at 65%, compact at 86%, pause at ceiling)
Real-time streaming via SSE
Wall-clock timeout: 120s hard ceiling per execution

I wrote a deep-dive on the agent safety architecture here: How We Stop AI Agents from Going Rogue Inside WordPress

Try it

Install from WordPress.org (still pending approval, may be approved by the time you read this) or visit pressark.com. The free tier is fully functional - not a limited trial.

Would love feedback from the DEV community. What features would you want from an AI co-pilot for WordPress? What am I missing?

I Got Tired of Clicking Through wp-admin, So I Built an AI That Does It for Me

abdelali Selouani — Sat, 28 Mar 2026 18:46:24 +0000

Here's a WordPress admin workflow I used to do three times a week:

Log into wp-admin
Navigate to Posts > All Posts
Find the post I need to update
Click Edit
Scroll to the paragraph that needs changing
Make the edit
Update the SEO meta title and description
Check the featured image is still right
Click Update
Go back to the post list
Repeat for the next 4 posts

Total time: 45 minutes of clicking through menus, waiting for pages to load, and context-switching between the editor, Yoast, and the media library.

I've been building WordPress sites for years. The platform is incredible — it powers 43% of the web for a reason. But the admin experience hasn't fundamentally changed in a decade. It's still a series of forms, buttons, and page loads. You still navigate to the thing, click the thing, fill in the thing, save the thing.

One day I was doing this for the tenth time that week and thought: what if I could just tell WordPress what I want and have it do all the clicking for me?

That's the moment PressArk was born.

The Idea: A Chat Panel in Every Admin Page

The concept was simple. Add a chat panel to the bottom-right of every wp-admin page. Type what you want. The AI figures out which tools to use, shows you a preview of the changes, and applies them only after you approve.

Instead of that 11-step workflow above:

You: "Update the intro paragraph on the running shoes post to mention 
      the spring sale, and update the SEO title to include 'Spring 2026'"

PressArk: [reads the post] [finds the intro paragraph] [drafts the edit] 
          [updates the meta title] [shows preview] [waits for your OK]

One message. Same result. Thirty seconds instead of fifteen minutes.

But "simple concept" and "simple to build" are very different things.

The Hard Parts Nobody Warns You About

Your AI doesn't know your site

The first version of PressArk was basically a GPT wrapper with WordPress API access. It could edit posts, sure. But every edit sounded like it was written by a different person. The tone was wrong. The CTAs didn't match our style. It used "utilize" when the site always says "use."

The fix was what we call Site Profiling. When you activate PressArk, it crawls your existing content and builds a profile:

Tone analysis: Are you a "we" brand or a "you" brand? Formal or casual? Do you use contractions?
Content DNA: Average word count, heading patterns, how often you use lists vs paragraphs, CTA placement
Brand terms: Words and phrases unique to your site that should always appear
Design tokens: Colors and spacing from your theme.json

This profile gets compressed to about 100-200 tokens and injected into every prompt. The AI doesn't just edit your content — it edits it like you would.

WordPress data is messy

If you've ever worked with wp_postmeta, you know what I'm talking about. Custom fields from five different plugins. Serialized arrays stored as strings. Elementor storing entire page layouts as nested JSON in post meta. Yoast and Rank Math both hooking into the same SEO fields with different conventions.

We had to build a resolution layer that understands all of this. When the AI says "update the SEO title," PressArk detects whether you're using Yoast, Rank Math, or core WordPress meta, and routes the update to the right place. When you say "change the hero section," it knows whether you're using Gutenberg blocks, Elementor widgets, or a theme template.

Users don't trust AI with their live site (and they shouldn't)

The single most important design decision we made: nothing writes without explicit approval.

Every action the AI takes falls into one of three categories:

Reads happen automatically — checking your content, scanning SEO, looking at site structure. These can't hurt anything.
Edits generate a live preview — you see exactly what will change, side by side, before anything touches the database.
Dangerous actions (publish, delete, WooCommerce order changes) require an explicit confirmation card with full details.

This Preview > Approve > Execute pipeline is the reason people actually use PressArk on production sites. They can see what the AI wants to do before it does it. Trust isn't given — it's earned through transparency.

What People Actually Use It For

I built PressArk to solve my own content editing problem. Turns out people use it for a lot more:

Content teams use it for bulk operations — "update the CTA on all blog posts from 2024 to link to the new pricing page." One message instead of editing 50 posts manually.

WooCommerce store owners use it for product management — "create a 15% coupon for the spring collection that expires next Friday." Done in 10 seconds instead of navigating through 4 WooCommerce screens.

Freelancers use the SEO scanner — "audit the SEO on my top 10 pages and tell me what to fix." It checks meta titles, descriptions, heading structure, canonical URLs, schema markup, and gives actionable recommendations with one-click fixes.

Security-conscious site owners run the security scanner — "scan my site for vulnerabilities." It checks WordPress version, PHP version, SSL, plugin updates, file permissions, user enumeration, and rates each issue by severity.

Agencies use the automation system — "every Monday at 9am, run an SEO audit on my homepage and email me the results." Cron-based automations with full audit trails.

The Technical Stack (For the Curious)

PressArk is a WordPress plugin — pure PHP, no external frameworks:

AI routing: Routes to the best model per task automatically. Free tier uses DeepSeek V3.2. Pro tier uses Claude Sonnet 4.6. BYOK (Bring Your Own Key) lets you connect OpenRouter, OpenAI, Anthropic, or DeepSeek directly.
200+ tools: Content editing, SEO, security, WooCommerce, Elementor, blocks, custom fields, media management — all exposed as AI-callable functions.
Content indexing: Posts chunked into 800-char segments with 100-char overlap, indexed via MySQL FULLTEXT. No vector DB dependency — works on any WordPress host.
Streaming: Real-time token delivery via SSE. You see the AI thinking in real-time, not waiting for a complete response.
Checkpoints: Structured conversation memory that survives context window compression. The AI remembers what it was doing even when old messages get dropped.

Where We Are Now

WordPress.org (still pending approval, may be approved by the time you read this) and running on thousands of sites. The free tier includes bundled AI credits — no API key needed to start.

The thing I'm most proud of isn't the technology. It's that people who spend hours in wp-admin every day are getting that time back. A freelancer in our community told me PressArk saves her about 6 hours a week on content management alone. That's 6 hours she spends on actual creative work instead of clicking through menus.

WordPress is the backbone of the web. It deserves an interface that matches what AI makes possible in 2026 — not more buttons and forms, but a conversation.

If you manage a WordPress site, give PressArk a try. The free tier is genuinely useful, not a teaser.

And if you're building something similar for a different platform — I'd love to hear about the problems you're solving. The agent safety stuff alone could fill a whole series of posts (and actually, I wrote one about that too).

How We Stop AI Agents from Going Rogue Inside WordPress (Spin Detection, Token Budgets, and Checkpoints)

abdelali Selouani — Sat, 28 Mar 2026 18:43:50 +0000

If you've ever built an AI agent that interacts with a real system — not a chatbot, an agent that reads data, makes decisions, and executes actions — you know the terrifying moment when it starts looping.

It reads a post. Tries to edit it. Gets an unexpected response. Reads the same post again. Tries the same edit. Gets the same response. Burns through $4 of API tokens in 30 seconds doing absolutely nothing useful.

We hit this problem building PressArk, an AI co-pilot that lives inside the WordPress admin dashboard. Users chat with it to manage their entire site: edit content, run SEO audits, manage WooCommerce products, scan for security issues — all through natural language.

The agent has access to 200+ tools across content, SEO, security, WooCommerce, and Elementor. It runs inside a real production WordPress environment with real user data. Getting safety right isn't optional — it's existential.

Here's what we built to keep the agent under control.

Problem 1: The Spin Cycle

AI agents love to get stuck. Especially in WordPress, where API responses can be... surprising. A wp_update_post() that silently fails. A WooCommerce endpoint that returns a different schema than expected. An Elementor page where the JSON structure doesn't match what the model predicted.

The agent sees an unexpected result, retries the same approach, gets the same unexpected result, and loops forever.

Our solution: Tool Signature Tracking

Every round, we hash the tool calls the agent makes. If the signature matches the previous round — same tools, same arguments, same pattern — we increment an idle counter.

// Spin detection - tracks consecutive rounds with no real progress.
private int    $idle_rounds         = 0;
private string $last_tool_signature = '';

const MAX_IDLE_ROUNDS = 3;

After 3 consecutive no-progress rounds, we force-exit the loop. No exceptions. The agent gets a structured error message explaining what happened, and the user sees a clear "I got stuck, here's what I was trying to do" message instead of a mysterious timeout.

Simple heuristic. Saved us thousands in runaway API costs during development.

Problem 2: The Context Window is a Ticking Clock

WordPress conversations get long fast. A user asks "audit the SEO on my homepage." The agent needs to:

Read the page content (big HTML blob)
Check meta tags
Analyze heading structure
Check canonical URLs
Look at internal links
Generate recommendations

Each step adds to the conversation history. By step 4, we're already burning through the context window. By the time the agent tries to generate a coherent summary, it's forgotten what it found in step 1.

Our solution: Three-Stage Token Budget

We track total tokens consumed across all rounds and apply pressure at three thresholds:

const MAX_REQUEST_TOKENS          = 258000;
const SOFT_PRIME_TOKEN_RATIO      = 0.65;  // ~167K: start checkpoint priming
const SOFT_COMPACTION_TOKEN_RATIO = 0.86;  // ~222K: live message compaction
const PAUSE_HEADROOM_TOKENS       = 8000;  // Pause within 8K of ceiling

Stage 1 — Checkpoint Priming (65%): The agent starts building a structured checkpoint that captures what it's learned so far. Not a summary — a structured state object with specific fields:

private string $goal        = '';
private array  $entities    = []; // posts, pages, products with IDs
private array  $facts       = []; // key-value pairs discovered
private array  $pending     = []; // actions still queued
private string $workflow_stage = ''; // discover|gather|plan|preview|apply|verify

Stage 2 — Live Compaction (86%): Old messages get dropped from the conversation, but the checkpoint persists. The agent loses the raw conversation but keeps the operational state. It knows what it was doing and what it found without carrying 200K tokens of chat history.

Stage 3 — Hard Pause (within 8K of ceiling): We pause the loop entirely. The checkpoint becomes a "context capsule" that can be used to continue in a follow-up request if needed.

This means the agent degrades gracefully instead of hitting a wall. At 65%, it's still fully functional but preparing for compression. At 86%, it's working from structured memory. At the ceiling, it hands off cleanly.

Problem 3: Not All Tools Are Equal

The agent has 200+ tools. Some are harmless reads. Some modify content. Some delete things permanently. Some charge the user money (WooCommerce refunds, for example).

Treating them all the same is asking for trouble.

Our solution: Three-Tier Capability Classification

Every tool in our catalog gets classified:

Read (auto-execute): site_overview, search_content, get_seo_score — these run automatically, no user interaction needed.
Preview (live preview): edit_post, update_seo_meta, modify_elementor_widget — these generate a visual diff showing exactly what will change, and wait for approval.
Confirm (explicit card): publish_post, delete_content, process_refund, apply_security_fix — these show a confirmation card with full details. Nothing executes without a click.

The classification lives in the tool catalog, not in the agent loop. This means adding a new tool automatically inherits the right safety level based on its category:

Every write action goes through:
Preview -> Approve -> Execute

Nothing changes on your site without your explicit OK.

This isn't just about preventing accidents — it's about trust. When a user sees the agent propose a change, review it, and then apply only what was approved, they start trusting it with bigger tasks. Trust compounds.

Problem 4: The 120-Second Ceiling

Token limits and spin detection handle most runaway scenarios. But there's an edge case: cheap read-only tool calls that don't burn many tokens but run forever.

Imagine the agent deciding to "scan all 500 pages for broken links" one by one. Each read call is cheap. Token budget isn't triggered. Spin detection doesn't catch it because each call is different. But 500 sequential API calls take... a while.

Our solution: Wall-Clock Timeout

const LOOP_TIMEOUT_SECONDS = 120;

Hard two-minute ceiling on any single agent execution. Combined with per-tier round limits (free tier gets fewer rounds than paid), this creates a bounded execution envelope: you know exactly how much time and money any single request can consume, regardless of what the agent decides to do.

Problem 5: Tool Discovery Loops

Our agent doesn't load all 200+ tools upfront. It starts with a small core set and can discover/load more tools as needed via meta-tools (discover_tools and load_tools).

This is great for efficiency but creates a new failure mode: the agent discovers tools, doesn't find what it needs, discovers again, loads the wrong group, discovers again...

Our solution: Meta-Tool Budgets

const MAX_DISCOVER_CALLS = 5;
const MAX_LOAD_CALLS     = 5;

Five discovery calls and five load calls per session. After that, guided degradation — the agent works with what it has instead of searching for the perfect tool. This prevents the discovery loop without restricting the agent's ability to find the right tools for most tasks.

The Execution Envelope

All of these mechanisms work together to create what we call the "bounded execution kernel":

Constraint	Limit	Purpose
Max idle rounds	3	Stop spin cycles
Soft checkpoint priming	65% of token budget	Prepare structured memory
Live compaction	86% of token budget	Drop old messages, keep state
Hard token ceiling	258K tokens	Absolute budget limit
Wall-clock timeout	120 seconds	Catch cheap-but-slow loops
Meta-tool budget	5 discover + 5 load	Prevent discovery loops
Tool result ceiling	10K tokens per call	Prevent single-tool context flooding

No single mechanism is sufficient. A spin cycle that uses cheap tools bypasses the token budget but hits the wall-clock timeout. A context-heavy task that doesn't loop hits the compaction thresholds. A discovery loop hits the meta-tool budget. The envelope is the intersection of all constraints.

What We Learned

Simple heuristics beat complex classifiers. Our spin detection is just "did the tool signature change?" Not fancy, but it catches 95% of loops. The remaining 5% hit the wall-clock timeout.

Structured checkpoints beat summaries. When you compress conversation history into a summary, you lose precision. When you compress it into a structured state object with specific entities, facts, and pending actions, the agent can pick up exactly where it left off.

Classify tools at the catalog level, not the agent level. The agent doesn't need to decide whether a tool is dangerous. The catalog already knows. This separation means new tools get safety for free.

Bounded execution is a feature, not a limitation. Users trust an agent more when they know it can't run away. "This will take at most 2 minutes and cost at most X tokens" is a better UX than "let me think about that..." followed by silence.

(still pending approval, may be approved by the time you read this) WordPress.org with a free tier if you want to try the agent yourself. The bounded execution kernel is the same one running in production across thousands of sites.

If you're building AI agents that interact with real systems — not just chatbots — I'd love to hear what safety mechanisms you've found essential. What failure modes did you discover that you didn't anticipate?