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

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?
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
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.
Added to the FAQ.
I don’t understand how to edit the tags. If I click on them, I go to the link ???
You have to double-click on them (fast).
I does not work for me (FF, IE8). I suspect another plugin incompatibility… Not very important
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!
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.
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?
Yes, to get the updated CSS. Hint: you can use inherit as the color.
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.
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
Next to what is this error? Post title, tags etc. ?
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';
}
?>It will be fixed in 1.2.1.
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)
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
okay – I found out how to disable the editor!
In the latest version, the rich editor does the same corrections as TinyMCE, when switching from HTML mode.
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)?
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.
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).
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).
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.
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.
Try disabling all other plugins.
Also, make sure your theme has wp_footer() called in footer.php
Ok, it was wp_footer missing after all, thanx for pointing it out!
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.
Thanks, will add that line in the next version.
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.
You have to use
Ahhhh! working now, damn I love this plugin!
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.
I agree with that. It’s a little tiring this highlighting…
Yeah, the next version will have an option to disable it.
Still not valid xhtml….
“rel” is not a valid attribute.
If you have a better ideea. I’m all ears.
Actually, I think I can easily replace rel=”…” with id=”…”
yep, that would work.
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}”;
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.
if ( $this->type == 'input' ) return "{$content}"; else return "{$content}"; </pre3rd class? Or would that start to cause other issues?
I think I’ll add a prefix to the id, like id=”fee_123″.
sounds good!
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
By default, it loads on all pages. I’ll need an admin account to see for myself. My email is scribu@gmail.com
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?
See frontEd_basic class, method check() in fields.php.
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…
It might have something to do with template_redirect. Try the development version of FEE and see what happens.
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…
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?
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.
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?
If you haven’t explicitly set a post slug, when you edit the title, the slug will also be updated.
Otherwise, I think it’s best you go to the admin to modify your slug, as some other actions occur when you do that.
still not working. the slug is not changing.
I’ll look into it.
Check the development version (1.3b).
url slug still not changing. by the way my wordpress version is 2.8.4
Should be working in 1.3b2 (also tested in 2.8.4).
Before editing, make sure your slug matches the title.
so where can i download 1.3b2? or is it still under development?
Just update to 1.3 proper.
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?
Put it in the regular plugins folder and it should work.
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!
You can make it a site-wide plugin. It’s basically the same thing.
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!
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.