Also works with custom post types – helpful plugin

Hi @alamea,

Thank you for taking the time to try FrontEdit and explain what disappointed you. I value feedback like this, especially when it identifies a gap between what I intended to communicate and what a new user actually experiences.

You were right that the additional Pro preview pages could make the free plugin appear much more limited than it is. The free version includes the full FrontEdit editing experience for currently supported blocks, including editing multiple blocks during the same session. Pro does not unlock additional editing capabilities for those blocks; it adds advanced workflows such as drafts and approvals, per-user permissions, request management, a content catalog, and edit history.

However, I understand that presenting those Pro features as separate menu pages created the impression that much of the plugin was unavailable. Based directly on your feedback, I have removed those preview pages, added a more useful Getting Started section, and revised the plugin’s messaging to explain more clearly what is included in the free version. Those changes will be available in the next update which will be live soon.

Regarding custom post types, FrontEdit is currently designed to edit supported Gutenberg blocks stored in standard WordPress post content. It does not edit Meta Box fields, custom metadata, or content created through third-party page builders. Every supported block is implemented and tested individually because preserving valid Gutenberg serialization and avoiding corrupted content or invalid blocks is one of my highest priorities.

That said, your review highlighted that FrontEdit currently excludes custom post types even when they use the normal block editor and contain blocks that FrontEdit already supports. I am now actively investigating how to add safe support for those block-based custom post types. This would not mean attempting to edit arbitrary custom fields, but it could allow FrontEdit to work with supported Gutenberg blocks wherever WordPress stores and manages them through its normal block-content workflow.

I am committed to continuing to improve FrontEdit when user feedback identifies something that fits its purpose and can be implemented safely. Your review has already resulted in concrete changes, and it has also helped shape an important area I am now working to expand.

I hope the revised onboarding makes it easier to evaluate FrontEdit for its intended use: editing supported Gutenberg blocks directly on a post or page. If you have a chance to revisit that core workflow, I would genuinely welcome any further feedback. Either way, thank you again for pointing out where the experience and expectations did not match.

@alamea,

Thank you very much for reconsidering your rating and for taking the time to explain your perspective further. I sincerely appreciate both.

Your criticism of the Pro menu pages was fair. I was probably being naively optimistic when I added them. From my perspective, the frontend editor in the free plugin was already the complete core product, and I saw the Pro workflows as extra features layered on top of it. I assumed users would see the pages as previews of those additions after experiencing what FrontEdit could already do.

I understand now that this was not how the admin area came across. Instead, it could make the free plugin look like a collection of locked features. As I mentioned, I have already removed those separate Pro preview pages and replaced them with a Getting Started page that better explains how to use FrontEdit and what it supports. That change is live in the latest update.

I also agree that custom post types using the Gutenberg editor are important, particularly for agencies building client sites with Meta Box, ACF, or similar tools. After your initial message, I started investigating it. This week I’ll begin working on support for CPTs that store their main content using the standard WordPress block editor and contain blocks already supported by FrontEdit. This would remain separate from editing arbitrary custom fields, but supported Gutenberg blocks within those post types should be a realistic fit for FrontEdit’s existing architecture.

My priority will be making sure CPT edits go through the same safe parsing, serialization, permission, and save process as standard posts and pages. Once I have it working reliably, I will release the update and follow up. I would be very interested to know whether it works the way you expected or whether you think the implementation should behave differently.

FrontEdit is an active project, and the current version is not intended to be its final form. Feedback like yours is exactly what I am looking for. When something is missing that fits the plugin’s purpose and can be added safely, I want to address it rather than simply explain why it’s not there.

Thank you again for giving FrontEdit another consideration and for changing your rating. More importantly, thank you for identifying areas where the plugin could be made better for other users.