Every site I build starts the same way. A field plugin, a form plugin, an SEO plugin, and then four or five one-trick utilities for the things WordPress does not do by itself. Four admin menus, four sets of conventions, four things to keep updated.

So I wrote one plugin that does those four. It is free on wordpress.org and it is called Ultivo Toolkit.

What is in the free version:

• Custom fields. Visual builder, location rules, 33 field types including repeater. Stores data in exactly the same meta pattern as ACF, so existing field data keeps working and there is a migration tool for field groups and acf-json.
• Forms. Drag and drop builder, entries in the admin, notifications, file uploads outside the media library, optional spam protection.
• SEO. Title and description templates, Open Graph, sitemap. It prints nothing at all while Yoast, Rank Math or AIOSEO is active, so you can install it next to what you already run.
• Seventeen switches for the usual chores: duplicate posts, SVG and AVIF uploads, a custom login URL, manual content ordering, limit login attempts, redirects with a 404 log, SMTP, admin menu organiser. All off by default.

It needs WordPress 6.0 and PHP 7.4, so it should install on just about anything you still maintain.

Three things I would want to know if someone posted this at me:

Is it heavy? Each of the four parts can be switched off, and when it is off it registers nothing: no menus, no screens, no hooks, no queries. Measured on a stock install, the whole thing adds eight queries to a front end page.

What if I uninstall it? Your content stays. Field values go into ordinary post meta, the same shape ACF uses: client holds the value, _client remembers which field it came from. Delete the plugin and those rows are still on your posts, and get_post_meta() still returns them. Nothing is kept in a table of its own, and nothing is cleaned up on uninstall. You lose the builder, not the content. That is also why you can leave ACF switched on while you try this: it never switches off a plugin from someone else, it just points out where the two overlap and lets you decide.

Where is the catch? There is a paid version. Pro adds Blueprints (export your post types, taxonomies, field groups and forms to a file and import them on another site), Flexible Content and the Clone field, and it starts at $49 a year for one site. Everything I listed above is in the free version and stays there, including repeater, options pages and the ACF migration. Nothing is sent to us, ever. Two features do reach an outside service: spam protection if you switch it on, and the map preview in the admin.

It went into the directory five weeks ago and has had six releases since, so it is new and barely used, but it is not parked. That is exactly why I am posting. If you build sites for a living I would rather hear what is missing than get a download: what would stop you switching?

https://wordpress.org/plugins/ultivo/

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.