Review Of Front End Editor Plugin

pluginoptionsA few days ago, I reported on a piece published by Andy Peatling regarding why BuddyPress themes were future proof and how the themes provided functions where you could perform most backend tasks on the frontend. This perked my interests because I’d love to see the same thing implemented on the WordPress side of things. After monitoring the WP Hackers List and doing a search on the plugin repository, I’ve come across a plugin developed by Scribu called Front End Editor.

Installation is simple and can be performed from the plugin section of the administration panel. Once installed, you’ll have a new option in your Settings menu called Front-end Editor. This is where you’ll find options for the plugin. From here you can enable/disable editing of the following:

  • Post/page title
  • Post/page content
  • Post/page excerpt
  • Post tags
  • Post/page custom fields
  • Comment text
  • Text widget content
  • Text widget title

The great thing about doing this from a plugin approach is that you don’t need to do anything special with your theme. This is great news for theme developers and end users alike however, as you’ll see in a little bit, not all themes play nice.

After you configure the plugin, checkout your front page. You’ll notice that nothing has changed but if you double click on post content, widget title headers, or anywhere else you configured the plugin, you’ll instantly see a real time editor show up around the content. If you’ve selected the WYSIWYG editor, a full blown TinyMCE editor will show up around the content which is great if you’ve ever wanted the ability to edit a text widget with one of these. However, here are a couple of screenshots which show the plugin not playing nice with my version of Hybrid News.

listitems topwidgetmessedup notwideenough

In the first screenshot you can see how my list item graphic shows up multiple times within the WYSIWYG editor. The second screenshot showcases the top header widget messed up when widget title editing is enabled. The final screenshot shows how the editor box appears to be wider than the content box itself.

Final Thoughts:

Other than these quirks which is probably due to the theme itself, this plugin works great. One thing I would suggest is that any editable area should have either an edit icon next to it or a small edit link. As it is currently, you have to double click an editable area such as a tag or post title in order to open the editor. I would also like the option to use the HTML version of the editor rather than the Visual version. Other than that, this plugin fits the bill quite nicely for moving WordPress administration from the dark ages to something more relevant. I bet if someone did a study of how much time was wasted during a year of using WordPress by doing all sorts of mundane tasks through the backend as opposed to a simple way of performing those tasks on the front end, I bet we would see a huge amount of time lost, like sitting at a red light.

I recommend this plugin to anyone who would like to perform simple tasks without the need to login and navigate your administration panel. Hopefully in the future, WordPress intertwines more backend tasks to the front end. Let me know if you experience the same theme quirks I did.


10 responses to “Review Of Front End Editor Plugin”

  1. I don’t really have a comment on the plugin itself, but I really dislike the concept of this. It is one of the things I disliked about Drupal (to some extent) and Joomla (to a huge extent).

    I really think that it is essential, for good workflow practices, to create a clear and clean separation between the website and the administration of that site.

    Andrew’s last blog post..Why I ditched Disqus

  2. @Andrew – I strongly disagree. There are many reasons for editing things on the front end, particularly if it is your users who are doing it. In theory you could style the backend to look like the front end, but that is going to create just as many (probably more) problems than doing it the other way.

    Imagine if everytime you wrote a forum post, you could whizzed away to an entirely different looking admin panel just to write a single post. Most people fine that very weird and hence most (all?) forum softwares allow you to write posts directly from the front end.

  3. @Ryan – Forum software is a very different matter which I don’t think applies here. I am talking about pre-prepared public facing content, that is, web pages and blog posts. Interactive communities that encourage discussion are something different from administering and publishing. At least the are to me.

    I think front end editing encourages quick change and sloppy practices which, in essence, makes it too easy and hence discourages thought. Going into the editor, making changes, previewing, and then making the decision to publish the amendments at least provides the opportunity to review and consider changes before they happen.

    Why do you think so many commenters on blogs leave a follow up comment with stuff they have forgotten? Because they type quickly, without thinking too much and miss a point of view that occurs when reading the comment afterwards. (I am not really talking about comments though, it just seemed a valid comparison.)

  4. I also tried this and experienced a completely borked layout on the front. I want to test it again with other themes though.

  5. I think this plugin is great, as it gives an option for quick editing.

    While I do agree with some of Andrew’s comments (about sloppy practices), I also think this will be a very useful tool.

    While I won’t use it for composing and posting entries, it will be handy for necessary edits or changes.

    ~ Dave

  6. @Andrew – My issue here is that not all WordPress sites are designed for only public facing use. I have a site with a large number of contributors and having everything powered from the front end would definitely be desirable. In fact this is the sort of thing I’d like to see implemented into the core.

  7. @Andrew

    I think that your you are hypocritical in your own argument:

    “I really think that it is essential, for good workflow practices, to create a clear and clean separation between the website and the administration of that site.”

    Workflow doesn’t have to be a system between the administrator and its end-user viewpoint. What if it is a site such as Bleacherreport? The conception of content creation revolves around users who are using their free time to invent content for a website. So their workflow, regardless of an front-end editor, is going to be imperfect considering the small rewards.

    Going into the editor, making changes, previewing, and then making the decision to publish the amendments at least provides the opportunity to review and consider changes before they happen.

    Workflow is always dependent on the talent of the content creator, divided by the time to create and improve his/her work. To say a content creator is going to be lazy because of an editor is the equivalent of saying the workflow of producing a database will suffer because of a GUI program ( are you prepared to go against Seaside DB or Ruby on Rails? ).

    Content is watered down because people are not talented. Period. If a content writer loses focus because he can easily edit his/her work, then they were not talented enough in the first place that they can overcome this fallacy and produce meaningful content.

    To create a clear and clean separation between the administration is already resolved due to the protocol of how a user can manipulate the information in front of him. This is called WordPress user levels. Administration is already clear. If you are confused by the separation, then you are not smart enough to be using WordPress. The separation is clear for the administrator, and if they don’t want this in the front end, I am more happy to make my site more efficient than theirs.

    Going into the editor, making changes, previewing, and then making the decision to publish the amendments at least provides the opportunity to review and consider changes before they happen.

    This, in comparison to a front-end editor, would be highly inefficient in the means of workflow. If I had to publish an article in 20 minutes, I would have less time to produce talent, and more time would be needed to manage. The mere existence of the blog is utilized to create more efficiency, so why is it that a front-end editor somehow doesn’t fit into this workflow?

    If one is so inclined to force people to go to the editor, why are people using WordPress? Why not have them use the editor in Microsoft Word? Or Wordpad? From there, they can then judge the opportunity to review and consider the changes before they happen. Right?

    So, I ask all of you, for the most proper talent, do not write in wordpress, or any word processor. You must become a traditionalist, and write in pen & paper. Shorthand some of your notes on the side. From there, you will have the greatest workflow that has existed amongst writers for many centuries.

    Or you can use WordPress. And use its efficient processes such as this plugin. Take your pick.

    Ps: I did not review this post. It is made up of Wolf Larsen’s fury.

  8. This is a good brief about the plugin.

    i compared and used 2 front editors
    (a) Front-end editor
    (b) inline editor

    Front end editor seems to have some compatibility issues with version 2.9
    Inline editor works excellent except that it cannot edit headers, footers, titles, etc which the front-end editor can do.

    Front end editor lacks the font color, font family tabs. Not sure why author has not included them. Also, there are bugs so it is not editing on doubleclick! if anyone ahs the same problem & / solved it, pls post here. Thanks

  9. worked pretty darn well on my child theme for BP 1.2.1 and WP 3.0a.

    would, like others above, be nice to limit inline editing to just admins who know what they’re doing.



Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: