I submitted my first plugin to the wordpress.org directory at the end of August and it was approved on 8 September, after five rounds. Almost none of the delay was code quality. Writing it down because most of what held me up is the kind of thing you only find out when it happens to you.

1. The name was rejected twice, and that cost the most

The first submission was auto-rejected within a second: a display name or permalink cannot begin with "wp". Fine, I renamed.

The second attempt cleared the automated scan and then a human turned it down. "Toolkit" is a generic description, and "Ultimate" is a promotional modifier rather than a distinctive identifier. Two lines in that reply were worth the whole round:

• "The absence of an exact match in the directory does not make the name distinctive." Checking that your name is free is not the test.
• "Other published plugins do not set a precedent for this submission; some were accepted under earlier standards." I had a list of near-identical names approved as recently as last year. It does not count.

What passes is a coined word or a personal/brand identifier, and it has to be at the front, not the back. I ended up inventing one. Remember that the slug is permanent while the display name is not, so keep the slug short and brandable and put the descriptive part in the name.

2. Your prefix has to be more than four characters

Mine was three. That meant renaming namespaces, constants, option names, post type slugs, hooks, script handles and every public template function. Do it before you submit. If your plugin is already out there, this is a breaking change for everyone who uses it.

A trap I hit doing that rename, and this one applies whether or not you ever submit anything: WordPress builds a submenu page's screen ID from the menu title, not the slug — sanitize_title( $menu_title ) . '_page_' . $submenu_slug. I had that prefix hardcoded in 31 comparisons. After the rename not one of them matched, so every admin screen of the plugin lost its CSS and JS. No error, no warning, php -l clean. It just looked like the styling had evaporated.

3. You can no longer ship an editor for arbitrary CSS, JavaScript or PHP

I had a code snippets feature. The reply was blunt: plugins that let users save arbitrary custom CSS, JS or PHP are not accepted, please remove it.

I asked whether a CSS-only version would be acceptable, since that is narrower than what the Customizer already offers. No, and they named the Customizer as exactly the reason CSS is covered too.

If you have that feature, plan for it not existing in your free version at all.

4. Escaping happens at the point of output, and nothing goes inline

52 notices, two patterns behind them.

Escape where you echo, not where you build. A helper that escapes attributes earlier in the chain does not count, even when it is provably safe. I annotated 105 of those in one directory and proved the rendered HTML was byte-identical before and after, which is a good way to convince yourself you did not break anything while touching a hundred files.

Every <style> and <script> goes through the enqueue chain. I argued for one exception, an engine that printed CSS on wp_head at priority 99 so user CSS would land after the theme, and I was wrong: enqueuing at priority 999 keeps exactly the same order.

Two exceptions I explained in my reply and that survived: a block render callback returning HTML the theme developer wrote themselves, and a standalone page that builds a whole document and exits, the way core's wp_die() does.

Two things I broke myself while fixing the above

• **sanitize_text_field() strips percent-encoded characters.** /caf%C3%A9/ comes back as /caf/. Harmless on REMOTE_ADDR, fatal on a URL path: a redirect or a route with a non-ASCII slug silently stops matching, and nothing errors. Use esc_url_raw() for anything that is a URL. I introduced this by following the review instruction literally instead of choosing the function that fits the value.
• Core owns the id {metabox-id}-title. It gives every metabox heading that id. My box was ultivo-seo and my own title input was ultivo-seo-title, so two elements shared an id and getElementById returned the <h2>. The character counter sat at 0/60 with text in the field, and the live preview never followed that input. It went unnoticed for months because the field right below it had no collision.

One more, if your URIs point at your own domain

If the Author URI or Plugin URI is a domain that is not obviously connected to the email you registered with, they will ask you to prove you own it. A TXT record on the root is enough. Add it next to your SPF record: a root domain can hold several TXT records, and replacing the SPF one instead of adding to it breaks your mail.

None of this is a complaint. The reviewers were right on every point except the one where I pushed back and lost, and the plugin is better for it. But if I had known the name rule and the prefix rule before submitting, I would have saved about two weeks.

The plugin was Ultivo Toolkit, if anyone wants to see what came out the other end. Not linking it, that is not what this post is for.

I wanted to share my application for WordPress on macOS. I worked on a 1.x version for a long time but decided the app should have full Gutenberg compatibility and a native macOS feel. I also decided to make the GitHub repo public if anyone had questions about the architecture/privacy. I just wanted a free, no-frills Mac app that I wanted to use for WordPress. Keep in mind the app only supports self-hosted WordPress.

https://quill.siolon.com

I kept running into the same problem with small-business software like zoho and pipedrive:

- The CRM ends when the deal is won.

- Then invoicing happens somewhere else.

- Purchasing turns into spreadsheets, email threads, approvals, and a lot of “where are we on this?”

So I built PipelineIQ.eu around one continuous workflow logic of win the deal → send the invoice → manage what the business needs to buy

Right now it includes:

- CRM, deals, follow-ups, and revenue forecasting

- Invoice drafts and Stripe payments

- Automation when a deal is won

- Purchase requests, approvals, supplier quotes, purchase orders, and supplier tracking

- A pipeline assistant that flags stale deals, missing close dates, and missing next steps

The revenue forcasting i built has a margin of error of 1-2% which I have tested numerous time and I am open to others proving me wrong

I’m at the point where I’d rather have people actually use it than keep building more features. So I’m looking for a few small businesses, agencies, consultancies, and service companies willing to try it and tell me: Its called pipelineiq.eu. So tell me, what feels confusing or what breaks and what actually saves time and eventually what you’d never use.

Wordpress is impossible to wor wit .I have contacted their"customer service AI" over and over again for the last month. My payment is up to date, but I cannot edit or change anything on my website! Is there a human being out there who can help me? It is really hurting my business.

I've been thinking about how much information a small business actually needs from a CRM on a daily basis.

For me, the essentials seem to be:

Who is the lead?

Where did they come from?

What stage are they in?

What's the next action?

When should I follow up?

Everything beyond that feels secondary until these are clear.

Curious how other people approach this: what information do you personally check most often in your CRM?

Hello. I need some help. I use wpml the latest version (5.0.2) and i try to change some settings as it shows on the screenshot. For some reason it can't be updated after clicking on save button even though the rest of settings work normally.

I find it harder than quoting a project with a detailed brief.

Sometimes a client knows they need a new website, but once you start asking about what he actually needs, there are still a lot of unanswered questions.

providing a fixed quote too early can backfire, but asking technical questions before giving any indication of cost can also lose the client.

How do you approach pricing when the scope is unclear?

A company decides it needs a CRM. The first meeting is about tools: HubSpot vs Salesforce vs Dynamics vs Zoho vs Pipedrive. Demos get booked, comparison sheets get built, and someone says "Salesforce is the industry standard, let's just go with that."

Six months later, the CRM is live and nobody really uses it. Reps keep their real pipeline in Excel. Managers still ask for reports by email. The company blames the software and starts looking at a different one.

In most of these cases the tool wasn't the problem. Nobody had agreed on what the CRM was supposed to do.

Before I talk about software with anyone, I ask questions like these:

1. How do leads actually reach you today? Web form, email, phone, events, referrals? Where do they land first?
2. What happens after a lead is qualified? Who takes it, and by when? What does "qualified" actually mean?
3. How do you track opportunities? What are your real stages, not the ones from a template?
4. What do managers need to see every Monday morning? If you can't name the reports, you can't design the CRM.
5. What eats the most manual time? That's usually where automation pays off first.
6. Who owns the customer data? Who can edit it, and who's responsible when it's wrong?

Once you have answers, the decision gets much clearer, and it's not always "pick a big brand":

• Off-the-shelf works great when your process is fairly standard. You get a mature product, integrations, and a community. The trade-off is that you'll adapt your process to the tool, and per-seat licensing adds up as you grow.
• Heavily customized off-the-shelf is where a lot of projects get expensive. If you're paying for endless workarounds, custom fields, and add-ons just to force the tool to fit, you're often halfway to a custom build without the benefits.
• A custom CRM makes sense when your sales process is genuinely unusual, when the CRM has to plug deeply into your own product or internal systems, or when you'd otherwise pay for a hundred features to use ten. The trade-off is that you own the maintenance, and it's a bad idea if your requirements are still vague.

That last point is the catch. Custom is the most requirement-dependent option of all. If you can't describe your process clearly, you'll build the wrong thing, just with more code.

So the order matters: process first, requirements second, tool (or custom build) third. I always start with a discovery phase and only then decide whether an existing platform or a custom build fits.

Curious what others have experienced. If you've been through a CRM rollout, did you define requirements first or pick the tool and figure it out later? Has anyone gone custom and regretted it, or been glad they did?

Happy to answer questions in the comments if you're in the middle of an evaluation.

I’ve been thinking about how CRM problems usually don’t become obvious when a company first starts using one.

Things like duplicate customer data, missed follow-ups, poor pipeline visibility, disconnected sales and support data, or workflows that nobody actually uses can become much harder to fix later.

For people who have worked with CRM systems, what problem caused the biggest headache after the company had already grown?

Was it data quality, user adoption, automation, reporting, integrations, or something else?

Read online about how makers and takers. The problem is that many users of #Drupal don't want or aren't able to donate hundreds of dollars. Why don't we use micro-crowdfunding?

Weird thing happening with a very basic anchor link on jim-flannery.com/music

Clicking "Watch" doesn't bring you down to the appropriate position on a mobile device. Yet, if you then scroll back up and click it a second time, it is correct.

No idea why this is inconsistent, seems like the only anchor link on the site doing this and there's quite a few.

After opening an account with AppMySite, I experienced what I consider an extremely misleading and frustrating process, including constant stalling, lack of support, wasted time, and an arrogant attitude. After paying for the service, the level of support and service I received was completely unacceptable. This was an extremely disappointing and trust-destroying experience, and I absolutely do not recommend this company.

I write on my own blog and kept running into the same gap: a post would show 4,000 pageviews and I still had no idea whether anyone got past the intro. GA4 can track scroll, but by the time the number reaches me it has been through consent gating and sampling, and I wanted the raw rows somewhere I control.

So I wrote a small plugin for it. It's free on wp.org, GPL, no pro version, no account, no signup screen: https://wordpress.org/plugins/ango-scroll-analytics/

What it does: one script on single posts and pages. It records how far the page was scrolled per visit, and gives you visits, average, median and percentiles 5/10/25/50/75/90/100 on a wp-admin screen — phrased as "25% of visitors scrolled at least to X% of the page".

Three deliberate decisions, one of which will annoy somebody:

1. It measures depth through the scrollable height of the page, not the share of the article text. A short post that fits on one screen records 100%. That's why the numbers won't match your analytics tool.
2. A visit with zero scrolling still counts, as 0%. The percentiles describe everyone who arrived, not only the people who read to the end. There is a filter that drops "load-and-die" visits — page loads that never sent anything after the initial beacon, which on a live site are mostly bots and link previews — and it's on by default.
3. Your own logged-in visits aren't tracked. I added that after my own refreshing had quietly wrecked my first week of percentiles.

Everything sits in one table in your own database. The front-end script is ~2 KB gzipped, the endpoint is rate limited, no IPs are stored, Chart.js is bundled so wp-admin makes no external request, and deleting the plugin deletes its data.

Caveats, since you'd find them anyway: it went up on wp.org five days ago and I'm the only person who has used it in anger. It does no funnels, heatmaps or sessions and can't tell you why people leave. Stats are computed on the fly, so at hundreds of thousands of visits it would want caching — a normal blog won't notice.

Happy to answer anything about how the measurement works, including the parts that are my opinion rather than fact.