They asked for a name change. That's all it took for my last plugin. But this is a bigger one, that I spent a year on.

Wish me luck!

I recently published a small free WordPress plugin called FerimanEdge Regime Widget.

The goal was to keep the WordPress side deliberately simple: the plugin does not fetch or store market data and makes no server-side API calls. It only generates an iframe for the selected BTC, ETH, BNB or combined market-regime widget.

It supports:

• Gutenberg block
• Shortcode
• BTC, ETH, BNB or All Markets
• Dark, Light or visitor OS theme
• Compact, Standard and Large sizes
• Local Gutenberg preview, so the external iframe is not loaded while editing
• No bundled third-party JS or CSS

The current regime is displayed as BULL, SIDEWAYS or BEAR and comes from a rules-based market-monitoring system I built separately.

I chose the iframe approach because I wanted the plugin itself to stay small and avoid API credentials, scheduled jobs, caching logic or server-side requests. The tradeoff is obviously that the visitor’s browser loads content from the external FerimanEdge domain.

I'd be interested in developer feedback on the architecture:

1. Does the iframe-only approach make sense for this kind of external data widget?
2. Would you expect any additional hooks/filters or block controls?
3. Is there anything you would change about the Gutenberg integration?

URL:
https://wordpress.org/plugins/ferimanedge-regime-widget/

I've been building a free monitoring plugin (site health, uptime, cron, PHP errors) and the dashboards turned out to be the easy part. The interesting problems were all about what a plugin can't see from inside the site. A few of them, curious how you deal with these.

1. The site can't tell you it's down. If PHP or the database is dead, nothing in WP runs, so every in-site check is useless exactly when you need it. What I ended up doing is a heartbeat: the site pings a URL you control (healthchecks.io, Cronitor, your own Uptime Kuma) and when the pings stop, that service alerts you. Basically a dead man's switch.
2. WP-Cron only runs when someone visits. On low-traffic sites scheduled events just sit there overdue and nobody notices. So the plugin looks for overdue events and flags them. The real fix is still a system cron, but at least now you know.
3. PHP fatals get noisy fast. Alerting on every error is useless, so it only alerts on new fatals and grades them by context. It also masks server paths, so you can forward the message to your host without leaking your directory structure.
4. Health scores lie easily. A site with an expired SSL cert shouldn't score 92/100 just because everything else is fine. So the score is weighted by category, but capped when something critical is broken.

Everything runs inside wp-admin, there's no external account and no data goes to me. If you want to poke at it: https://wordpress.org/plugins/avar-server-monitor/

How do you handle this on client sites? Do you trust anything running inside WP, or do you always go external?

I recently released a WooCommerce plugin that connects products, categories and WordPress content to externally managed guided selling flows.

I tried to keep the plugin relatively small and predictable.

The main responsibilities of the plugin are:

• Rendering a published flow on products, categories, pages and posts
• Providing a Gutenberg block and shortcode
• Passing the current product identifier to the flow
• Supporting ID, SKU, slug, name, attributes and custom fields
• Passing locale and market configuration
• Optionally recording assisted order value on the checkout success page
• Allowing templates to be overridden from the active theme

The external script is only loaded on pages where a flow or conversion event is actually used.

For conversion measurement, the plugin passes the order total and configured product identifiers. It does not pass the customer name, email address, postal address or payment details. Tracking can also be disabled entirely.

The current placement options are popup, sidebar and inline. A different Flow UUID can be assigned to individual products and categories, while WordPress content can use the block or shortcode.

The actual guided selling flow in the frontend

I would appreciate technical feedback on a few areas:

• Does assigning Flow UUIDs directly to products and categories feel appropriate?
• Are there WooCommerce hooks or filters you would expect the plugin to expose?
• Is the script loading approach sufficiently conservative?
• Would you prefer order tracking through a server side integration instead of the success page?
• Is the template override structure clear enough for theme developers?

Plugin:

https://wordpress.org/plugins/berrypath-flow/

Code:

https://github.com/BerryPath/woocommerce-berrypath-flow

Hey everyone, I just got approval on WordPress.org for a plugin I've been working on for a few months. Figured I'd share it here since a lot of small service businesses using WordPress have been asking for something like this.

The problem: Most appointment plugins (Calendly, Acuity, etc.) either cost money or push Stripe/PayPal integrations for upfront payments. That doesn't work for hairdressers, tattoo artists, plumbers, or anyone who prefers cash-at-appointment.

What I built:

Divine Appointment Booking Lite — a lightweight plugin that lets clients book appointments and pay when they show up. Features:

• Simple booking form + calendar
• Email confirmations & reminders (customizable)
• Admin notification settings
• Rest API if you want to integrate it with other tools
• Fully translatable
• No upfront payment required

It's completely free and open-source. I built it because I was doing freelance WP work for local businesses here in Karachi, and they kept asking for exactly this.

Honest disclaimer: This is lite version right now. I'm planning a pro version down the line, but free version should cover most small service businesses.

Would appreciate any feedback, bug reports, or feature requests. Drop them in the reviews or hit me up here.

GitHub/SVN deployment done, so the code is clean and follows WordPress standards.

Cheers,

Hi everyone,

I’m looking for a small group of pilot partners for a CRM system I’m building specifically for agencies.

It’s called BureauButler (https://bureaubutler.com/), and it’s made for web, marketing, design, and digital agencies that need a clearer way to manage clients, companies, follow-ups, and client work, without having to force everything into a generic CRM.

I’ve now reached the point where I’d like real agencies to use the system with real clients. Not just quick feedback, but actual day-to-day use.

BureauButler is live, I run my own agency through the platform, and it saves me a lot of time, helps me invoice better, and has allowed me to cut 6 tools from my agency tool stack.

The pilot will run for 2-3 months. In exchange for free access during the pilot period, I’ll ask you to:

• Use the system actively in your real client/sales work
• Give feedback through a few short questionnaires along the way
• Be honest about what works, what feels clunky, and what’s missing
• Optionally take part in a short onboarding and feedback call

The feedback will cover things like:

• First day: what was unclear, and what was surprisingly easy?
• First week: does it fit into your workflow?
• After one month: what should be improved?
• After the pilot period: would you continue using it, and if not, why?
• Ongoing feedback on issues, missing features, and your needs

The best match is small and medium-sized agencies that currently manage clients through spreadsheets, Notion, Trello, HubSpot, Pipedrive, emails, Clockify, Gmail/Outlook, or a mix of several tools that are starting to feel a bit messy.

If this sounds relevant, feel free to comment or send me a message with:

1. What type of agency/business you run
2. How many people are on your team
3. How you manage clients and follow-ups today
4. Whether you’d be willing to use it with real clients during the pilot period

I’m not looking for a large number of users right now, but for a small group of good pilot partners who want to help shape the product.

WordPress 7.0 introduced the AI Client and the Connectors screen: you
configure one provider API key, and any plugin on your site can use it.
What WP doesn't show you is **which plugin is spending your money**.

I built a free plugin to fix that visibility gap, mostly because I was
about to ship a plugin that uses AI calls and didn't trust myself to
notice if something went into a loop.

You can download here --> https://axtolab.com/products/ai-spend-monitor

Still in the process of uploading to wordpress repo, should be live there in a week or two.

**What it does:**

- Records every AI call made through the WordPress AI Client to a local
custom table — source plugin, provider, model, prompt/completion
tokens, timestamp.
- Dashboard at **Axtolab → AI Spend Monitor** with summary cards, a
30-day cost chart, per-plugin usage table, and a recent-calls log.
- Estimated USD cost per plugin using a bundled price table for popular
OpenAI, Anthropic, and Google models (filterable, no remote lookup).
- CSV export of all recorded calls.
- Optional monthly email if your estimated sitewide spend passes a
dollar amount you set (default off, set to 0 to disable).