As you might have noticed, a lot of work is going into this plugin:

Version 1.2 adds another editable field – the author description. It works if you have this somewhere in your theme:

the_author_meta('description');

Or, if you’re on an older version of WordPress:

the_author_description();

Besides that, several other improvements have been included:

  • while hovering over editable field, it will be highlighted
  • added experimental wysiwyg autogrow
  • it should generate valid xHTML
  • html code is cleaned up before saving
  • added Portuguese translation

Comments (71)

  • Chris says:

    I think I’ve pinpointed my problem but not the cause… can you think of any reason why jquery.wysiwyg.css would be in the head but NOT jquery.wysiwyg.js? I looked through your code and it looks like they’re being enqueued at the same spot… but if I view the souce of my page I see css from your plugin but NOT the javascript… it’s really odd because other javascript is working fine. And, since I’ve upgraded to v1.2 my fields are highlighting on mouseover, indicating that double clicking them should do SOMETHING… but nope.

    Any ideas?

    • scribu says:

      You don’t see the js in the head because it’s supposed to load in the footer, for better performance.

      Make sure your theme has wp_footer() somewhere in footer.php

  • Chris says:

    That was it! I wasn’t using wp_footer()!

    I don’t know if you mentioned that somewhere and I missed it but it might be worth noting. Previously, I found no need for wp_footer – or at least wasn’t aware it was so important.

    Thanks for walking me through this – looks like I’m going to love the plugin.

  • Li-An says:

    I don’t understand how to edit the tags. If I click on them, I go to the link ???

  • Li-An says:

    I does not work for me (FF, IE8). I suspect another plugin incompatibility… Not very important :-)

  • ashaman says:

    I also encountered a problem.
    Up until now everything worked fine, now double-clicking doesn’t work, and considering I’m using a dark-coloured theme, the highlighting is kind of an eye-cancer.

    Could you give out instructions on how to remove the highlighting, or provide an option in the settings in a coming update?

    Thanks a lot for the plugin!

    • scribu says:

      Until I add an option, you can see the FAQ on how to change the highlight color.

      What browser are you using? Try refreshing the cache with Ctrl + F5 or equivalent.

      • ashaman says:

        Ok, I’ll see what I can find in the faq then.
        I use Firefox 3.5, but why would I need to refresh the cache?
        To force the new colour to show?

      • ashaman says:

        I did add the line as instructed by the faq, but now the plugin seems to not work as far as editing a post is concerned. The hovering color appears as inputed though.
        Plus I upgraded to the recent 1.2.1 fix if that is in any way related.

  • Alan Guggenheim says:

    Getting errors on my pages:
    Warning: Missing argument 2 for frontEd_field::wrap() in /home/thewood3/public_html/wp-content/plugins/front-end-editor/core.php on line 187

  • Getting the error:

    Warning: Missing argument 2 for frontEd_field::wrap() in /home/.mophead/knightnet/j.knightnet.org.uk/wp-content/plugins/front-end-editor/core.php on line 187

    Occurs in any registered sidebars. Seems to be a problem with wigitized sidebars as it occurs within the widgit processing:

    < ?php
    /* Displays Widgetized sidebar if a widget is added to it */
    if ( !function_exists('dynamic_sidebar';)  || !dynamic_sidebar() ) {
    # Otherwise displays a warning
    	echo 'No widgets in sidebar';
    }
    ?>
  • Mark says:

    the sizing still doesnt work for me (remember, im not using the wysiwyg), so i cant see all the code to edit.

    Also, when the plugin is activated, it practically crashes my browser (FF 3.5 on Windows)

  • billn says:

    Hi Scribu – a very cool tool, but I found to my cost that I have to be very selective when to use it. I assume it’s the text editor that’s to blame (which is why I don’t use the wordpress one), but I noticed a short edit of a (long) page screwed up my formatting – on inspection lots of updating of code had been done, particularly changing of <a and <strong to <A and <STRONG… etc. – so my attempts at XHTML strict were no longer validated.
    Hope there's an easy fix that I may have missed…
    Cheers

  • billn says:

    okay – I found out how to disable the editor! ;-)

    • scribu says:

      In the latest version, the rich editor does the same corrections as TinyMCE, when switching from HTML mode.

  • Peter K says:

    This is a brilliant plugin!!

    I have discovered it doesn’t play nice with the post-tabs plugin though. It doesn’t know what to do with the tabbed content. Anyway suggestions on how to get around that (except for disabling either plugin)?

    • scribu says:

      I’ve tested Front-end Editor with postTabs and the only issue I could find is when clicking on the tab, you are redirected to an invalid url.

      I think I can fix that.

      • Peter K says:

        Ah, now that would be great! Is it an easy fix?

        I get the invalid url when clicking on a tab like you said, and it also seems I can’t select a single paragraph (it highlights the whole text regardless).

        • scribu says:

          It’s already fixed in the development version (1.2.2b).

          As for the paragraphs, you’ll have to disable the option from the settings page (I can’t make it work reliably with postTabs).

          • Peter K says:

            Great! Thank you for the plugin improvement. It works much better now on tabbed pages.

            I wonder if there are any plugins out there that allow one to toggle a plugin on and off and set options from a small widget that only appears when you’re logged in. Haven’t seen any ‘front-end’ plugin activators, I think it would be a nice feature to this plugin.

  • ashaman says:

    I installed the 1.2.2b version as well, but it seems not to working at all for me. I get the highlight in all the right areas, but double clicking has absolutely no effect.

    I’m not sure, but I think that this might have started after the 2.8.4 core update.

  • Ivan says:

    Hello! At usage of your plug-in has faced such problem that was output ul/li as in css subjects the map is registered. A problem has solved line addition in css a plugin

    .wysiwyg.panel li {list-style-image: none;! important}

    I suggest initially it to register in css a plugin that others did not have same problems, as for me.

  • Peter K says:

    Hello again,

    I’m trying to get it to work with taxonomies and made the adjustment to the file in the includes directory, but I’m still unable to select a taxonomy term. It doesn’t highlight or edit the terms. Is there something else I might be missing to get it to work?

    I’m also using “echo get_the_term_list( $post->ID, ‘project’, ‘project: ‘, ‘, ‘, ” );” to display a taxonomy called project in my theme

    I’m on wp 2.8.4 with the current development version.

  • Tyson Cecka says:

    I found a bug when the editor tries to wrap it’s code around an empty tag list.

    When testing if there are tags via if (get_the_tag_list()) it always returns true and will display [empty] instead of the preferred nothing.

    Awesome plugin! Keep up the good work. Oh and making the highlighting optional (or a toggle somewhere on the editor) would be appreciated for demoing a site.

  • al says:

    Still not valid xhtml….

    “rel” is not a valid attribute.

    • scribu says:

      If you have a better ideea. I’m all ears.

    • scribu says:

      Actually, I think I can easily replace rel=”…” with id=”…”

      • al says:

        yep, that would work.

        • al says:

          just tried id and actually it doesn’t work because an id can’t start with a number. I think adding it as a second class would be the best option:

          if ( $this->type == ‘input’ )
          return “{$content}”;
          else
          return “{$content}”;

          • scribu says:

            I’m afraid I can’t do that because there already are 2 classes and ambiguities can appear.

            Also, the reason I orriginally used rel instead of id is to avoid duplicate ids.

            Remember that only logged-in users can see the plugin markup.

          • al says:
            		if ( $this->type == 'input' )
            			return "{$content}";
            		else
            			return "{$content}";
            			</pre
  • al says:

    3rd class? Or would that start to cause other issues?

  • Steffen says:

    Hey scribu,

    I’m using ur plugin with the “more fields” plugin (wordpress.org/extend/plugins/more-fields/). It saves content into custom meta data, so it should be no problem to edit them with your plugin. But The Front end editor isn’t loading (yes, I checked wp_footer();) .

    I could’t find the check where your plugin decides to load or not to load. Can u help me with that.

    Thanks

    • scribu says:

      By default, it loads on all pages. I’ll need an admin account to see for myself. My email is scribu@gmail.com

      • Steffen says:

        Does your plugin check if the post type is post or page and then activate? The more fields plugin sets the page type to eg. ‘pager123′. The Plugin works at normal pages / posts. It only doesn’t work at ‘pager123′. (It is confidencial work, I can’t give you admin access….)

        any ideas?

        • scribu says:

          See frontEd_basic class, method check() in fields.php.

          • Steffen says:

            current_user_can returns 1 and it warps the meta fields with ” …” but it doesn’t load the header and footer scripts. It also doesn’t load the uncommented firebug-lite on these pages. Could it be that more fields overwrites the header and footer? That is freaking weird…

            • scribu says:

              It might have something to do with template_redirect. Try the development version of FEE and see what happens.

              • Steffen says:

                thanks for your help. I tried the dev version. At the pages that I created with the more fields plugin it doesn’t wrap the div around. So there must be something that prevents the whole plugin from Init…

              • Steffen says:

                I decided to dump more fields, just wasn’t worth it. Now everything works great expect that it strips all my tags when I use the WYSIWYG editor or when I type it manual via textfield.

                I couldn’t find the line of code to prevent your script (or WP) from filtering the br and p tags. Could you please help me with that?

              • Steffen says:

                OK I found it. For anybody who is interested:
                inc/editor/editor.js line 336-339

                Btw. I would be cool if there was an option in the admin menu. Something like:
                Do you trust me when I write a Tag:
                [ x ] Yes
                [ ] No

                Thanks again for your great plugin and the work you put in it.

  • gio says:

    so far this is the only working inline editor i’ve tried. i really love it.

    suggestion: how about editing the permalink URL when editing the title too? this perfectly makes sense, right?

  • Necati says:

    Would this work on WPMU?
    I tried to, but couldn’t (on 2.8.4a).

    What I did was put the folder inside the mu-plugins folder; anything else I should’ve done?

    • scribu says:

      Put it in the regular plugins folder and it should work.

      • Necati says:

        So, there isn’t a way to have this available by default?

        I am trying to find documentation showing insight into wpmuizing regular WP plugins… can’t find any.

        I’d think it is different for each plugin anyway, though.

        Thanks for your prompt response!

        • scribu says:

          You can make it a site-wide plugin. It’s basically the same thing.

          • Necati says:

            Yeah, OK, I don’t know how I missed that.

            By the way, I recall you commenting that there was nothing tiny about TinyMCE (I think it was on WP forums) and so you chose jQuery WYSIWYG.

            I am trying this other plugin called Rich Text Widget, which uses TinyMCE and the combined size of its included JS files is smaller than the jQuery included with FEE.

            http://wordpress.org/extend/plugins/rich-text-widget/

            FEE with TinyMCE would rock!

            • scribu says:

              That’s because the Rich Text Widget doesn’t include the actual TinyMCE code. It uses the one bundled with WP.

              However, there is a new package for TinyMCE built with jQuery that might allow me to use it with FEE. So, hope is not lost. :)