Henry Wright

A 404? When I try doing this on the back-end end it would silly ignore the change and display this old content

It does this when editing an existing post.

Try creating a new post via the back-end with a blank title and no content. An empty post gets created! Then when you try to view that post you get a 404.

OK that’s confused me.

Take, for example, creating a new post. This is what you can do via the back-end without any problems:

Title (Yes) Content (Yes)
Title (Yes) Content (No)
Title (No) Content (Yes)

You’re allowed to do the following but when visiting the post that is created you get a 404:

Title (No) Content (No)

I assumed WP displayed an error or warning message when doing this but testing again today I can see it doesn’t.

This doesn’t seem to be specific to the front-end editor. Do you think it is worth raising a WP Trac ticket for this?

Just to add, I can output the ‘report comment’ link using

global $safe_report_comments;
echo $safe_report_comments->get_flagging_link( $entry_id, '', 'Report comment' );

This allows users to flag the comment for moderation.

Once a comment is flagged enough times it disappears from the front end and goes into the moderation queue.

The problem happens when the comment is approved. It doesn’t appear back on the site.

I’d be grateful for your help on this.

That could work but thinking about it again – doing anything at all to the background of the edit page deviates from what makes the plugin so powerful – that being the edit-post-page and the post-page being identical to the user so they can see exactly what their blog post will look like once published.

I think your original idea could be best – display a warning if the user tries to navigate away from the edit page before saving.

I just did a mock up of both scenarios (black over white and white over back) and yes, you’re right! Both scenarios look V ugly ??

but it’s difficult to match the theme’s colour scheme.

Perhaps an overlay using CSS opacity would solve that issue. Something like opacity: 0.5; on all uneditable and inaccessible areas of the page and opacity: 1; on the editable regions and admin bar.

Alternatively, perhaps grey-out uneditable areas – making it explicit to the user what they can and can’t do on the page whilst in edit mode.

Just throwing out some suggestions.

Right, I see!

I suppose it is better to have inaccessible links than a user loosing the changes they’ve made after navigating away from the page. Perhaps this is where autosave (I noticed it’s on the roadmap) comes in?

Hi Janneke,

I’d probably be good to show a message or something.

Not sure I follow?

Brill ??

Yes, i’ll keep that in mind. Many thanks for clarifying.

Oh yes, of course. Forgot about save_post – that does the job. Thanks!

My aim was to redirect the user to the post after successful post update. I was thinking there is little need for them to remain on the /edit/ page after they’ve clicked on ‘save’. This may not be to everybody’s taste so hooking in sounded like a good option as oppose to being the default behaviour of the plugin.

I just upgraded from version 0.4.4 to 0.4.5 and this is now fixed. Thanks!

Of course, that explains it! Thanks for letting me know.

I can confirm this is happening for me too.

The problem seems to be with the popup which captures the user’s email address. Disabling the popup ensures that the user is registered. Enabling the popup results in nothing happening. The popup simply remains on screen even after the user has clicked on the button to submit their email address.