Contents
A WordPress name generator has two jobs: store name-building blocks in a way editors can maintain, and turn user filters into fresh results without a page reload. The main design choice is whether those blocks live as custom post types with fields and taxonomies, as JSON or PHP arrays, or as a hybrid of both. That choice affects admin workflow, query shape, caching needs, and how quickly you can add new generators.
This guide maps a practical build for mygenify.cloud. It compares storage models, outlines admin and import workflows, shows how to filter blocks with WP_Query, and describes an AJAX flow with nonce checks and sanitized inputs. It also covers local save lists, clipboard copy, and plugin shortcuts. Where the available material does not establish a fact, the guide flags the gap instead of inventing a universal rule.
Data Modeling: CPT vs. JSON vs. Arrays
Start with the decision that will shape everything else: where the name-building blocks live. There are three practical options for mygenify.cloud.
Custom post type plus fields and taxonomies. A CPT such as name_block can provide a structured admin editing workflow. Revisions and admin search are not automatic guarantees: revisions require explicit post-type support, and admin/search behavior depends on registration settings such as public, show_in_rest, and the admin UI configuration. Store the literal block in the post title or a dedicated field, then add fields for position (prefix, root, suffix), syllable count, rarity, theme, and any other filterable attribute. Use a taxonomy such as generator_type to separate fantasy, business, baby, or other generator families. This is the strongest fit when non-developers will curate data.
JSON or PHP arrays. A static file can be loaded into memory and filtered in PHP, which avoids per-request database reads for the block set. The trade-off is that updates require code or a custom import path, and the WordPress admin is no longer the source of truth. This can work for a fixed corpus or for algorithmic data that rarely changes.
Hybrid. Keep editable vocabulary and metadata in a CPT, and keep structural rules or large static lookup tables in code. The general model in the available material is useful here: a generator turns source columns into target outputs through configured methods, parts, and conditions. In WordPress terms, columns become fields or taxonomy terms, and methods become generation rules in PHP or JavaScript.
For a growing utility site, start with one CPT and one taxonomy rather than a separate post type per generator. Measure query performance on your own dataset before committing to a large architectural change; the available material does not establish a universal size cutoff.
WordPress Backend: Admin Management and Import
Plan the admin around the people who will maintain the data. Register name_block with title and custom fields enabled, then create field groups for block text, position, syllable count, theme, rarity, and status. Use a taxonomy for generator type and any shared categories. Keep required fields small at first; every filterable attribute adds query and editorial overhead.
For bulk import, use a CSV mapper such as WP All Import or a custom WP-CLI/import script. Map columns to fields and taxonomy terms, validate values before import, and test with a small sample. If you expect a large initial corpus, treat import as a must-have rather than a later enhancement.
Code-generation shortcuts can help with registration. Zelvigo Dev Studio Lite produces custom post type code and stores generated output on the local installation; it does not register the post type for you and does not call an outside API. Treat that output as a starting point, then add your own fields, validation, and import workflow. That tool is a code-generation shortcut, not evidence that it supplies a complete field-builder or import workflow. If you evaluate other CPT plugins, compare their advertised features individually.
Blue Studio positions its generators for fantasy and lifestyle naming and emphasizes responsive support. In the available material, that is a support-positioning claim; it does not establish admin, import, or frontend behavior, so verify those directly if you use it as a benchmark.
Query Strategies: Filtering Names by Attributes
Use WP_Query for filtered block selection, but keep the query shape deliberate. A typical request combines a taxonomy filter with one or more meta filters. For example:
$args = [
'post_type' => 'name_block',
'post_status' => 'publish',
'posts_per_page' => 50,
'tax_query' => [[
'taxonomy' => 'generator_type',
'field' => 'slug',
'terms' => $generator_type,
]],
'meta_query' => [[
'key' => 'syllable_count',
'value' => 2,
'compare' => '<=',
'type' => 'NUMERIC',
]],
];
$query = new WP_Query($args);
Sanitize every incoming value and whitelist allowed taxonomy terms and meta keys. The shortcode pattern in the available material exposes category filters plus result count, sort field, and direction controls; mirror that idea in your AJAX request, but build a custom query server-side rather than trusting client-supplied query arguments.
Meta queries can become expensive as data grows. Cache filtered block sets with transients or object caching when the same combinations repeat, limit result sets, and avoid orderby => 'rand' on large unfiltered sets without testing. If you need random output, fetch a bounded candidate set and randomize in PHP. Benchmark with your real data, hosting, and cache configuration; the available material does not provide a universal performance threshold.
Frontend AJAX: Instant Generation Without Page Reload
Expose one AJAX action for generation and register it for both logged-in and logged-out users. Check a nonce, sanitize inputs, build the query, assemble names, and return JSON. Keep the generation logic in a service function so the AJAX handler stays thin.
add_action('wp_ajax_mygen_generate', 'mygen_generate');
add_action('wp_ajax_nopriv_mygen_generate', 'mygen_generate');
function mygen_generate() {
check_ajax_referer('mygen_generate', 'nonce');
$type = isset($_POST['type']) ? sanitize_key($_POST['type']) : '';
$names = mygen_build_names($type);
wp_send_json_success(['names' => $names]);
}
On the front end, localize the AJAX URL and nonce, gather the selected filters, disable the button while the request is in flight, and render the returned names into a results container. Use fetch() or jQuery.ajax(); the key is that the page does not reload. Provide an empty state and an error state.
If the endpoint is public and traffic is high, add rate limiting or a lightweight challenge; the right level depends on your expected concurrency, which the available material cannot determine for you. Blue Studio’s support positioning does not define this implementation, so treat any public generator as a product reference to verify directly rather than as a code pattern.
Retention: Save Lists and One-Click Copy
Retention can be lightweight. For saved names, store an array in localStorage under a namespaced key. Add a save button next to each result, deduplicate by exact string, and render a saved-list panel on page load. This keeps the feature account-free, but it does not sync across devices or browsers.
function saveName(name) {
const key = 'mygenify_saved_names';
const saved = JSON.parse(localStorage.getItem(key) || '[]');
if (!saved.includes(name)) {
saved.push(name);
localStorage.setItem(key, JSON.stringify(saved));
}
}
For one-click copy, use navigator.clipboard.writeText(name) with a fallback for older browsers. Show a short ‘Copied’ state and keep the interaction accessible with a real button and visible focus. Use event delegation on the results container so newly rendered names work without rebinding.
If cross-device sync becomes a requirement, add user accounts and store saved names in user meta or a custom table. Do not pretend local storage is a synced account feature; it is a same-browser convenience.
Context: How Existing Generators Structure Word Lists
The available material includes a generator description that uses a Markov-chain approach and syllable matrices built around consonant-vowel patterns such as CVC and CCV. That is evidence that some generators encode structural rules, not proof that every naming corpus uses the same grammar. Use it as a design prompt rather than a universal schema.
In WordPress, represent each block with text and a position field: prefix, root, or suffix. Add syllable count and generator type as filters. If combinations are constrained, store allowed pairings in a rules table, a JSON file, or a custom taxonomy; keep the first version simple. The uniqueness-check pattern checks a candidate against chosen fields and then tries fallback options in a defined order if a duplicate appears. You can implement that by keeping a short-lived set of generated names per request and retrying with the next candidate.
The gap: the available material does not provide a complete, production-ready schema for a WordPress name generator. It describes generation concepts and one plugin shortcut, not a full data contract. Your schema should be validated against real editorial workflows, query performance, and the number of attributes you actually need.
Plugin and Code Generation Shortcuts
CPT generator plugins can reduce the boilerplate for register_post_type(). Zelvigo Dev Studio Lite produces custom post type code and keeps generated output on the local site; it does not automatically register the type and does not depend on an external API. That makes it a reasonable starting point for a quick admin prototype, but not a complete generator architecture.
Before adopting any shortcut, check maintenance status, WordPress compatibility, license, and whether the generated code follows your coding standards. Do not generalize from one Lite tool to every CPT generator: feature sets differ, and each plugin’s current documentation should be checked for field builders, import tools, and other claims. Likewise, do not assume a plugin handles CSV import, AJAX generation, nonce checks, or rate limiting unless its documentation says so.
Blue Studio’s positioning for fantasy and lifestyle naming with responsive support is a product reference only; the available material does not establish its code, query, or import architecture. For mygenify.cloud, use shortcuts only for the admin layer, then own the query, generation, and front-end logic. Review any generated PHP for escaping, sanitization, and capability checks before it reaches production.
Open Decisions to Validate Before Build
Before implementation, settle these decisions because they change the schema and query design:
- How many blocks will you manage, and how many generators will share them? Use that estimate to choose one CPT or separate types.
- Which attributes are truly filterable? Every meta field adds query and editorial cost.
- Is CSV import required for launch? If yes, build and test it before content entry.
- Will saved names remain local, or must they sync through accounts?
- Do you need exact-match deduplication only, or near-match checks with an edit-distance rule?
- Is AJAX sufficient, or do you need a REST endpoint for integrations?
- Who curates data: your team or a submission workflow?
- What response time is acceptable, and what caching can you operate?
- How will you handle trademark risk and user-facing disclaimers?
- Do you need non-Latin character sets or multiple languages?
The available material does not answer these product questions. Treat them as requirements to validate with stakeholders and load tests, not as facts to infer from a plugin listing.