Veyra Custom Content Manager documentation.
A practical starting point for understanding the plugin, planning a content model and keeping structural decisions separate from presentation.
What Veyra CCM is responsible for.
Veyra Custom Content Manager is designed to give custom WordPress content architecture a dedicated plugin layer. Its role is structural: defining and managing the custom content types and classifications a project needs.
The active theme remains responsible for presentation. WordPress remains responsible for storing the content. Keeping those concerns separate makes future redesigns, maintenance and project handoff easier to reason about.
This is not a page builder. CCM describes the content model. Templates, blocks and frontend code decide how that content is displayed.
Structure
The reusable types and classifications that organise information inside WordPress.
Content
The individual entries editors create after the structural model exists.
Presentation
The archive, single template, block or application interface that renders the content.
Maintenance
The responsibility to protect existing routes, data relationships and editorial workflows.
Install the official package in WordPress.
The final public download route will be listed on the product page. Use only the package distributed through the official Veyra or WordPress.org channel when it becomes available.
Exact WordPress and PHP requirements will be published from the audited release package. Check the product page before installing the first public version.
Model the information before creating structures.
A clear content model begins with the project, not with a list of settings. Before registering anything, define what editors need to create repeatedly and how visitors will browse it.
- Identify the entity. A project, event, location, team member or another repeatable kind of content.
- Decide whether it needs a public view. Some structures need archives and singles; others may exist only for internal organisation.
- Define useful classifications. Add a taxonomy only when editors or visitors need a meaningful way to group or filter entries.
- Plan the frontend separately. Know which theme templates, blocks or application views will present the model.
Use a custom content type for a repeatable entity.
A custom content type gives a distinct kind of information its own editing and retrieval model in WordPress. It is appropriate when ordinary posts or pages no longer communicate the role of the content clearly.
Good candidates
- Portfolio projects or case studies.
- Events, venues or locations.
- Team members, speakers or contributors.
- Products or services not managed as WooCommerce products.
- Documentation, resources or another specialised editorial collection.
Choose slugs carefully
A slug can affect internal identifiers and public routes. Treat it as a structural decision rather than display copy. Use concise lowercase names, avoid unnecessary changes and document any route that must remain stable.
Changing or removing a live content type can make existing entries disappear from the WordPress interface without deleting the underlying rows. Plan a migration and backup before structural changes.
Classify content only when the relationship has meaning.
A taxonomy describes a reusable classification system. Project type, destination, topic or service area can help editors organise entries and visitors browse related information.
Hierarchical
Useful when terms need parent and child relationships, similar to WordPress categories.
Non-hierarchical
Useful for flatter labels, similar to WordPress tags, when parent-child structure adds no value.
Do not create a taxonomy merely because a field has several possible values. Use it when the terms should be shared, browsed, queried or managed independently across multiple entries.
Build the visitor experience in the presentation layer.
After the content model exists, the theme or application layer can create archive pages, single templates, query loops, filters and reusable blocks around it.
- Use the theme for markup, layout and visual hierarchy.
- Use WordPress queries to retrieve the registered content and terms.
- Keep business logic, external services and account systems outside the theme.
- Test archive, single and taxonomy routes before making the project public.
Treat the content model as production infrastructure.
Once editors have created content, structural changes can affect admin screens, queries, public routes and templates. Apply the same discipline used for database and deployment changes.
Start with the structural layer, then check presentation.
The structure does not appear in WordPress admin
Confirm that Veyra CCM is active and that the structure remains enabled in the plugin. Then test for administrator capability restrictions or a conflicting plugin.
A public archive or single URL returns 404
Verify that the intended public route is enabled, save Settings → Permalinks once and check whether a page or another content type already uses the same slug.
The content exists but the frontend is empty
CCM manages the structure, not the final page layout. Confirm that the active theme contains the required template or query and that published entries match its conditions.
A taxonomy is not available for the expected content
Review which content structures the taxonomy is connected to, then confirm that the editor screen and frontend query use the intended relationship.
When reporting a defect, include WordPress and PHP versions, the CCM version, reproduction steps, the expected result and the actual result.
Use the route that matches the problem.
The public documentation covers stable concepts and common workflows. Use the existing Support system when the answer depends on a specific installation or when the product may be behaving incorrectly.
Veyra support routes
Contact Support for a product question, Bug Report for a reproducible defect and Feature Request for a focused improvement proposal.