Yes, a bug was reported in iG:Syntax Hiliter v3.0 that can stop the plugin from working, or in other words, can break your plugin and the post. This was due to the fact that a new RegEx was used for the tag parsing and I uh well…………..
So, if you used any square brackets like [ ] in your post, well, you can understand…………..
So here’s critical bug fix, iG:Syntax Hiliter v3.1 with not only this, but another minor bug fixed and some other bugs that I came across, including a bug fix in GeSHi. I’ve sent the fixed GeSHi to Nigel and hopefully it’ll be officially patched in its next release. But for now, you need to use the geshi.php provided with this plugin!! Also the language files bundled with iG:Syntax Hiliter have been updated with some style modifications, so essentially, you should make this a clean install, updating all files. 😉
So without further ado, please download iG:Syntax Hiliter v3.1, its a must update for users of v3.0 and ofcourse a most recommended update for v2.1 or lower(only if you are using WordPress 1.5 or above). 😀
As always, bugs/complaints/suggestions are welcome here or at the WP Support thread at http://wordpress.org/support/10/10533/ or you can Contact Me(please mention iG:Syntax Hiliter as the subject).
UPDATE: A more generic fix has been applied to remove the whitespace between the opening tag brace(<) and the first character of the tag, which is placed by WordPress. If you don’t display any code except that of PHP, JSP, ASP or RubyOnRails, then you won’t need it, but if you display any other tag based code, like ColdFusion, Blogger or MovableType template tags etc, then this fix is a must for you unless you prefer broken tags.
Please download the plugin again for the latest version.
IMPORTANT: iG:Syntax Hiliter doesn’t change or fix your code in anyway, it simply manipulates it a bit for on screen display. Your code remains saved in the same form as it was saved by you.
Hi,
I have the same problem that was already mentioned above. Downloaded, uploaded straight forward and got the error:
Plz. help.
Tom
if you saw the error mentioned above, then you also saw the solution posted above, right?
No.
I downloaded the file and didn’t modify anything, just unzipped.
I’ve tried your suggestion to save without modification in UTF-8 but that didn’t help.
Or do you mean with “the posted solution” the rollback??
Greetz,
Tom
I had the “headers already sent problem”. Checking headers_sent() would return true even at the very top. I copied and pasted the text into a new file, deleted the old one and put the new syntax_hiliter.php in its place, and that worked. I think somehow there are a couple of bytes at the start of the file that get output but don’t show up in regular text editors. Maybe some Unicode data or something? Might be something to do with Amit’s text editor, or FTP. Who knows!
Anyway I hope that helps point to the problem. After that was fixed it works fine, great plugin.
Hi,
Creating a new file, copy-paste works fine. Thanks.
Ok, I’ve modified the file(copy-paste to a new file) & uploaded the ZIP package again. Shouldn’t pose any more problems I hope!! 😉
Yes! The new package solved the header already sent error. I have upgraded to ver3.1.1!
Thank you, Amit. You are great guy! 😀
New package works, thanks very much for the quick support Amit!
Very nice and useful plugin. Thanks for write it. What about to implement a per-entry option setting?
An example:
[c plaintext=off langname=on showline=off]
//your code here
[/c]
[java plaintext=on langname=on]
//code here
[/java]
Or, simple use the option name to switch them on:
[cpp plaintext langname]..[/cpp] –> show link for plain text, show lang name.
In the option page every option could have a “Default on”
tick box.
I hope someone understand what I tried to explain.
Yeah, I know what you mean to say & want. I had something similar in my mind as well, but didn’t see any worth for it. For instance, I don’t understand why would someone want the PlainText view for one codebox & not for the other codebox. And then it puzzles me why one would want line-numbers in one codebox & not in other codebox, you can copy-paste the code without the fear of line-numbers being copied(not unless you are using FireFox).
So as I see it just an un-necessary overhead that will slow down the plugin. If you have any valid reasons for it, I’d be glad to know about them!! 🙂
A wonderful plugin but here is a fatal bug that forced me to close iG:Syntax Hiliter. As I have to use other ‘[”]’ plugins.
The bug is (or it probably is:
Once I used any kind of ‘[”]’ in post that not defined by iG:Syntax, such as another plugin for Flash, like [Flash], it was forced to use iG:Syntax and showed as it’s still source code.
A minor bug that I don’t know why I couldn’t save configuration setting permanently, I could save them after a moment but later when I check it, they’re still in default values.
Thanks for your great job though.
George,
I noticed same behavior whith the “mathml embedding” plugin which use [mathml] and [/mathml].
I am also having the same problem with wp_itemstats, the tag is [wowitem] and [/wowitem]. It gets forced to show as plain text unless I turn off iG:Syntax.
if you have an older version(prior to v3.x release), you can use that for the timebeing while I put together a new version with a fix. 🙂
sorry for the trouble everyone!!
Just upgraded from 2.1 and I have a couple of comments: First, the sooner you come up with code hiliting in comments, the sooner my readers will quit complaining. So add my vote to that feature request.
In 2.1 you had a comment like “Comment these lines for no fixed width and no scrollbars.” If you don’t want to make that configurable, you might include a note in the readme on what to delete from the css. (Yes I found it all by myself: I’m so proud.)
I’m still having a problem with blank lines in my code. Take a look at http://www.dicks-blog.com/archives/2006/02/06/active-directory/ . Below the Sub line there’s a space, but below Dim oUser there’s no space. Notice how the formatting changes? I had this same problem with previous versions, but thought I would mention it was still there.
Finally, I modified vb.php to include keywords that are peculiar to VBA/Excel and changed the color scheme to match what’s seen in the Visual Basic Editor. I made that file available here http://www.dicks-blog.com/archives/2006/02/07/ig_syntax_hiliter-for-vba/
Thanks for the great plug-in and keep up the good work.
Dick, the new line etc. has nothing to do with space. GeSHi tries to indent code as the spaces are found in it. So if you have a tab space, then it’ll be converted into four whitespace characters, so if your code will be displayed as its indented!! Its not a bug. 😉
And thanks for adding to the VB language file, however I would say that you should’ve created a seperate language file for VBA & left the VB one as it is!! 🙂
Amit: re blank lines – I’m not sure we’re talking about the same thing. I’m referring to the font above the blank line being 10 point serif and the font below being 9 point sans-serif. If I include a space (or anything else for that matter) then it renders it in a consistent font. If I’m still not explaining this well or if there’s a better way I can demonstrate this, I’m happy to do it.
ok Dick, I think I know what you are talking about. Sometime back, Nigel(the GeSHi developer) had a similar font related problem at his blog, but that wasn’t because of the plugin after he diagnosed it. It was related to the theme’s CSS. so you better check on your blog’s styles if there’s anything that can be done, since as far as I know, no text sizing is done by the plugin or GeSHi and I’ve it running on two live blogs without any problems of this kind on any of them!! 🙂
Thanks Amit. I’ll check my CSS.