Thoughts on Xinha, Text Control, and WordPress
***NOTICE***
All plugin information has moved to http://plugins.baptiste.us
Comments are now closed. Please use the new forums instead
Xinha for WordPress was my first plugin - so it was definitely a learning experience. The WordPress Codex was very helpful, but there still was a lot of trial and error involved in understanding how various actions and other parts of the API worked. But I also learned that no matter how hard you try, you can’t anticipate all impacts of your code or what type of setup other people will have. Needless to say I ran into a few unexpected things with v1.0 of Xinha4WP. One of the interesting ones was Text Control, Xinha, and a chicken and egg problem.
WordPress by default uses a filter called wpautop to format posts. If you have a double line feed in a post, it will insert a paragraph tag (<p>) automatically as the post is rendered for the user. Single line feeds will optionally insert <br /> tags as well for an HTML line break. This way authors don’t have to worry about inserting HTML tags for paragraphs and line breaks while they are writing up a post. The posts are stored in the database raw (i.e. just the linefeeds and line breaks) - wpautop is run and the tags are inserted when the post is displayed.
Xinha is more advanced as an editor and handles all the HTML generation on the fly. When you hit return in Xinha, a paragraph <p> tag is inserted automatically and a new paragraph is started. Shift-return will cause a simple line break with a <br /> tag automatically. So where normal WordPress posts insert the line spacing tags when a post is displayed - Xinha inserts them on the fly when the post is written (and thus the <br /> and <p> tags are saved to the database record for the post) Thus is you author a post in Xinha and then view it and it goes through wpautop, you’ll get double tags and other wild results.
Because of this, when I wrote Xinha4WP, I inserted a warning in the Post Options screen recommending you turn off dynamic post formatting (wpautop) using the Text Control plugin. Easy enough. Xinha takes care of all the backend HTML formatting for you, and Text Control ensures the Xinha generated HTML is left alone when each post is rendered and viewed. So what’s the problem?
Well, my blogs are not very big and I’ve been using Xinha with WordPress via a hand configured plugin/hack for all my posts since I switched to WordPress on my blogs. That means almost all of my blog posts were Xinha formatted when written. But what if you a have a couple hundred posts in WordPress already when you install Xinha4WP and turn off Post text formatting with Text Control? Your new posts will look fine. But all of your old posts that looked fine when wpautop was active will now be one long continuous paragraph - no line breaks at all.
Whoops.
So that presents a bit of a chicken and egg problem. You need to disable wpautop for any new posts created with Xinha, but if you do it via the default option screen, you’ll mess up all the formatting of your old posts. So what can you do? Don’t worry - you don’t have to go back and re-edit your old posts!
The good news is there is a way to get around this problem. If you have a sizable number of blog posts already, which were authored in the normal Post/Quicktags screen yet want to start using Xinha, leave Post Formatting in Text Control set to wpautop. This will ensure all your old posts are filtered through wpautop and are formatted properly. One of the nice things about Text Control is you can set the Post Formatting value for each post. Now for any NEW posts you write with Xinha, set Post Formatting to No Formatting. Wait, you say, you don’t see the Text Control option when writing a new post? No worries. Text Control v2.0b1 only displays the per post Text Control menus when editing a post. I’ve written a patch for Text Control that fixes this so you can set the Text Control Post Formatting when you first write a post in Xinha. Simply download this new version of text-control.php and overwrite it in your plugins directory. The Text Control options will now appear below the Xinha editor section for both new posts and edited posts.
So if you have an established blog and want to start using Xinha, I recommend you leave the default Text Control for Posts set to wpautop (and ignore the warning in Xinha4WP - I’ll tweak it some in v1.2). Then for any NEW posts you write with Xinha, make sure Text Control for Posts is set to No Formatting. And don’t worry - WordPress saves your post properly regardless of this setting. If you forget to flip it to No Formatting during an initial draft, you can always flip it later while editing the post in question without worry.
If you have a new blog and plan to use Xinha with it from the start or have a very small number of existing posts, I recommend setting the default Post Formatting in Text Control to No Formatting. But now those of you with large existing blogs can also use Xinha and maintain your old post formats.
Hopefully this clears up some of the confusion surrounding post pre-formatting (with Xinha) and post-formattng (with wpautop) and how to get them to play nice.
33 Responses
Trackbacks and Pingbacks
Comments
-
Robert Says:
November 5th, 2005 at 1:52 amHey Mike,
Let me just say, this plugin is fantastic! It worked straight out of the box, and I am very impressed (and pleased) with the promptness of your update for it. This is easily the best WYSIWYG for Wordpress yet.
I tried to implement Xinha for comments, however, and didn’t end up with the same results you apparently did. Any thoughts as to why mine appears the way it does in Firefox (most of the images aren’t appearing for the individual icons) or IE (all of the images show, but the bottom 1/12 of the icon appears at the top rather than the bottom)?
Thanks in advance!
-
Mike Baptiste Says:
November 6th, 2005 at 9:41 amRobert, Wow - that’s quite the bizarre behavior. Is this only for comments? Does it work fine for posts?
Just out of curiosity - I’m wondering if it might be theme related. Try flipping to the default WordPress theme and see if anything changes in the comments sections - especially if the problem only occurs in comments and not in the post authoring screen.
-
Harshblogger Says:
November 6th, 2005 at 3:22 pmI just wanted to mention that I have teh same issue as Robert. Xinha4WP workd perfectly for posts but missing the toolbar images for comments in FireFox. Works fine in IE only missing in FireFox.
-
Mike Baptiste Says:
November 6th, 2005 at 6:15 pmI’ll check into it. I’m using Firefox 1.5 Beta (RC1) - might be related to the 1.0.x series, or the themes. IE works for me as well - though the icons are farther apart.
What themes are you using for your sites? If either of you can get me a source link for your themes it’ll help me see if maybe a CSS style of some sort is causing problems.
-
Harshblogger Says:
November 7th, 2005 at 10:58 pmI’m using the default WP theme with some customization. I have some JavaScript that that is pulled from other sites (sitemeter for example) that may be causing a collision. I’ll try fooling around with it more later.
-
Harshblogger Says:
November 7th, 2005 at 11:59 pmLooking that the HTML source it appears that the css like (<link href=”/wp-content/plugins/xinha4wp/xinha_core/skins/blue-look/skin.css” rel=”Stylesheet” />) is missing on the comments page but present on the post page. For some reason IE can deal with that but Firefox cannot. Strange thing is your page here (the one I’m using to write this post) does have a css link.
-
Robert Says:
November 8th, 2005 at 8:30 pmHey Mike,
Sorry I’m responding so late! First of all, the plugin works perfectly for posts, just not in the comments section.
The problem must be theme related though, because I switched the the Classic theme and the plugin works correctly for my comments now. I don’t know if you have the time (or inclination) to look into this further, but I’m using the K2 theme by Michael Heilemann.
Thanks in advance for any help you can offer!
-
Harshblogger Says:
November 9th, 2005 at 7:20 pmI have tried switching Xinha styles without any improvement (buttons still don’t show). Robert.. did you switch the WP theme or the Xinha theme? Although the style sheet tag does appear so my previous assertion that the problem was cased by a missing style sheet is not valid.
-
Robert Says:
November 10th, 2005 at 12:33 amHarshblogger,
I changed the WP theme to Classic, and everything worked properly.
-
Mike Baptiste Says:
November 10th, 2005 at 7:22 amHarsh - The style link will not be in the source if you have the ‘Default’ skin selected. It only appears if you select a specific skin for Xinha for posts or comments. Can you do me this favor? Since you’re using the standard wordpress theme, but customized, that will help me identify what you might have changed that is giving Xinha fits.
Grab the ’stock’ WP theme css files from here:
http://baptiste.us/wp-content/themes/default/style.css
http://baptiste.us/wp-content/themes/classic/style.cssUse your browser if it’ll open them or use wget from your webserver shell.
If you are using ‘default’ rename the style.css file from above as style_def.css and then send me the output of this command from your web server (if you have shell access)
cd /path/to/your/blog/wp-content/themes/default
diff style.css style_def.cssThis will show me what you’ve changed and will help me figure this out.
Once I figure out what types of image styles are being changed in ways that make Xinha go nuts, I can override them for Xinha in the Xinha4WP style section (without affecting the rest of the Wordpress theme styling)
-
Mike Baptiste Says:
November 10th, 2005 at 7:44 amRobert - I’ll grab K2 and take a look later thuis week.
Harsh - One thing I’m wondering. Do you have access to your webserver access_log file? I can’t figure out if in your case you’re getting the ‘blank’ gif (which is there) or the other images are just not being accessed. Its not permissions - I was able to load and view the Bold and Italics buttons directly on your blog. If you can get to access_log, send me the logs you get when you reload a ’single’ page with a Xinha comment box (Hold your shift key and click reload in Firefox to ensure everythign is reloaded) This will tell me if its even TRYING to load the images. I’m poking around the styles and stuff with the Firefox WebDeveloper extension - see if anything pops out.
-
Mike Baptiste Says:
November 10th, 2005 at 8:13 amRobert,
Your problem is definitely theme related. At least the icons not being aligned properly. Still not sure about the buttons not appearing. But your K2 theme has a 4 pixel padding set for all images and since Xinha doesn’t specify a padding value, its using the theme value - thus all images are 4 pixels off.
I’m working on a patch for you to try out if you don’t mind.
Mike
-
Mike Baptiste Says:
November 10th, 2005 at 8:17 amHarsh,
Very interesting - in your case the buttons are definitely not there - even the stylesheet indicates that all you have is the ‘buttonContainer’ but no actual image to speak of which is VERY odd. If you have access to your logs it will be really helpful to see why Xinha isn’t loading the images or what might be preventing it from loading the images.
-
Mike Baptiste Says:
November 10th, 2005 at 10:14 amOK - If you are having weird theme problems, try this. Edit the file wp_xinha_plugin.php On line 233 (v1.1 that is) replace this line:
$style = ‘.htmlarea iframe { }’;
with this:
$style = “.htmlarea iframe { }\n”;
$style .= “.htmlarea .toolbar img { padding: 0; margin: 0; }\n”;And reupload or save it (some of you might be able to edit the file directly if you have that feature enabled in Wordpress). See if that changes anything. It should, at the very least, fix the problem where the images seemed to be shifted down a bit. Not sure if it’ll matter for the buttons that don’t show up at all. Let me know how it goes.
-
Harshblogger Says:
November 10th, 2005 at 1:37 pmMike,
Your last post fixed the issue. I took a quick scan at my css file an haven’t determined where I’m screwing up the img tags. I must be adding some padding to the global img tags somewhere. Thanks for the help.
-
Robert Says:
November 10th, 2005 at 1:46 pmOy Vey! What a dummy I was, not to check the CSS first!
I updated the wp_xinha_plugin.php file, but it didn’t change anything. However, I then went into my style.css file and excised the style mods under .primary img { } and voila, it works perfectly now in IE and Firefox (and Flock)! So apparently the problems I had were related solely to CSS.
Thanks for your help Mike, and this awesome plugin!
-
Mike Baptiste Says:
November 10th, 2005 at 4:13 pmRobert/Harsh - Great news! I can’t figure out why .primary img {} would apply to Xinha, but I’ll likely have to make sure the img tag for Xinha is complete enough to override thing. The .toolbar style SHOULD have fixed it (vs removing the primary section which I remember when browsing your CSS style sheet Robert) But I may have to set some of the other CSS styles for the toolbar style set. Knowing K2 breaks it - I can use that to test.
-
Harshblogger Says:
November 11th, 2005 at 2:47 amWell, almost there. I changed the wp_xinha_plugin.php as you said and thought I fixed the issue but then I went back to my css and undid what I had modified earlier the problem was back. I don’t have a .primary img {} tag. The tag screwing me up is:
p img {
padding: 0;
max-width: 100%;
}
if I remove the max-width: 100%; it works fine. That css tag is part of the WP default theme so I suspect others will have the same problem. I just deleted the whole tag as it appeared useless to me. -
Rhincewind Says:
November 14th, 2005 at 12:37 pmYep, removing the “max-width: 100%;” line from style.css worked for me as well. Nice images…
-
BlueWolfX31 Says:
November 22nd, 2005 at 2:58 pmFirst thing first: THAT IS A GREAT PLUG-IN! WOW! I can see a day where it will be a basic/built in WP plug-in =) Amazing work you did there =)
Now, my little tiny problem… I have to say that I’m NO programmer… Ok, I can “understand” pretty basic stuff in the codes will playing with it (In dreamweaver looking at things in code/design mode) but let just say that I just understood what h2 or h3 did to text…
Having said that, like others in this MS IE world, I’m a FireFox enthusiast =) On a Xinah level, I have about 2/3 of icons going blank on me With FireFox (no prob with IE of course)… I know it’s a Theme problem since it gets fixed by changing to an other one.
I managed to go in my css to change the P img (took me half an hour but…). No result…
I tryed replacing the $style = ‘.htmlarea iframe { }’;… My WP didn’t like it at all…
So now I wanted to send you a “compare” of my style.css / the style_def.css but I don’t have the knowledge to “shell it” & diff it?
I don’t want to change my theme since I’ve worked a lot on making it the way it is now…
If I send you my style.css, could you be kind enough to look at it? I’m using jakarta 1.5, you might just get it directly in the theme it self.
Thanks in advance for any and all help you could give me =)
-
Mike Baptiste Says:
November 25th, 2005 at 5:54 amBlueWolf,
I’ll take a look. I think someone else had trouble with Jakarta too and got it working. I’ll post when I figure it out.
Mike
-
Jan Dembowski Says:
December 10th, 2005 at 1:36 pmMike,
Great plugin. I modified the style.css and that took care of the icons not showing up.
I’ll peel over this web site; I have some issues with the <p> and <br>’s getting taken out.
Jan Dembowski
-
Cristian Mezei Says:
February 7th, 2006 at 3:30 pmHere is the <a href=’http://www.seopedia.org/graphics-and-design/fixed-ie-bug-in-jakarta-theme’>Jakarta theme</a> Internet Explorer fix
-
Cristian Mezei Says:
February 7th, 2006 at 3:30 pmHere is the Jakarta theme Internet Explorer fix
-
new guy Says:
April 6th, 2006 at 10:47 pmHi,
Thanks a lot for the plugin!
However, the problem I encountered is much worse, I guess. Whatever I typed in Xinha editor cannot show up in the post. It is lost except the title which is not by the Xinha.
Now, if I copy and paste what’s in Xinha into the default editor, it then shows up in the post but in a messed-up appearance.
I did all the required setup, but just could not fix the problem. Your help will be greatly appreciated!
Thanks!
-
new guy Says:
April 6th, 2006 at 10:57 pmsorry, I should have added that it seems everything worked fine for comments
-
Mike Baptiste Says:
April 6th, 2006 at 11:00 pmnew guy - are you using Wordpress 1.5.x or 2.0? Xinha4WP wont’ work properly with WP v2.0 yet.
-
new guy Says:
April 6th, 2006 at 11:06 pmoh, yah, I am using 2.x. Thanks for the tip! So should I just disable it first?
-
Mike Baptiste Says:
April 6th, 2006 at 11:09 pmYes, disable it for now. I hope to have v2.0 ready soon.
-
new guy Says:
April 6th, 2006 at 11:11 pmI will disable it now. Thanks again!











November 7th, 2005 at 6:09 pm
[...] If you want to install and try it for yourself though, you can download the plugin itself here. You’ll also need to download a third-party (or is that fourth-party?) plugin called Text Control. And then head back to Mike’s for a patch modifying how Text Control works. (See number 8 in his FAQ). And try this post if you have no idea what the hell I’m talking about - I didn’t at first either. [...]
August 14th, 2006 at 7:34 am
[...] After strugging to get Text Control 2.0b1 to work with Wordpress 2.1 even though other people are reporting it works fine, I found that someone had made entire code cleanups to Text control over here: http://www.baptiste.us/2005/11/02/thoughts-on-xinha-text-control-and-wordpress/ [...]
January 28th, 2007 at 8:12 pm
[...] [Originally posted at baptiste.us - See the original article for comments] [...]