by the way....is it just me or does it not work to set a default text formating thing. when i set it to markdown or textile for example...the preferences dont get saved. they default to text everytime :(
yeah i noticed that safari has some ajax glitches :( there are also other problems with safari.
for example...do you ppl remember that when there are multiple versions of the same animated gif file...then only one is animated and the others are not? they fixed that if you include the gif with <img> but if you include the image like here...with css as background then the safari bug is there again..
thats of course no fault of you mark...and you should not change it to fix safari in my opinion..because its something the safari ppl have to fix. just something i noticed...i wonder if anyone else has seen that...or if i was just too tired yesterday to think right :D
yeah, i merged that change into the one that i have up for download now, too.
after talking with jonezy real quick the problem at hand could be this: MAKE SURE YOU SAVE THE FILE AS .PHP AND NOT .PHPS
PHPS is for PHP Source files (on many but not all PHP servers that enables automatic syntax highlighting), but you need .php files for vanilla to pick it up and do the actual work with it.
nifkin, that was me on the wiki. I've been waiting for my account here to be approved.
Basically, I found Vanilla last week via kottkes blog. I installed it two days ago and did a little playing around. I found the Textile extension this morning. I cut and pasted the phps file and saved it as Textile2.php in the extensions folder. Then I went into Settings > Manage Extensions and enabled it. It now appears under every textarea, but when i tick it and type in *bold* or _emphasis_ textile formatting, nothing happens. They appear exactly as I've posted them here - plain text with the Textile formatting showing.
I'm using vanilla 0.9.2 on Apache/2.0.53 (Win32) PHP/4.3.10
Yes, the PHP opening and closing tags are there (I highly doubt if it'd run without them) and after a look through the code, I can't see why it wouldn't work.
Bit of a mystery if its working fine for everyone else, will look into it more later.
I just installed the Textile extension and it works fine but when I press "add your comments" it goes to post.php and it freezes there. If I press the Back button the text I wrote appears correctly posted. Has it anything to do with cookies?
I know it should put me back to te conversation, but the problem is that it doesn't work O_O Sniff, sniff. I will try it again without Textile, because maybe it's a problem in my server.
No, actually. But that's not such a bad idea. Though i'm sure it'd take a *lot* of work on the codebase but log production might be a nifty feature. Vanilla does, however, print most errors to the screen (in a human format) so chances are really that the log would just contain what it would otherwise echo out. The only time it doesnt print errors is on the actual php function errors because theyre all silenced with the aim that the vanilla error checking thing will pick up the problem and tell us it more usefully. If you coud find the function thats being used when people click to save a comment and remove the @ from the front it'l echo any problems it's having if there are any. Which function it is i'm not sure, sorry.
I've developed indipendently a TextileCode extension... I've seen this one just too late. but... I've used the original textile() function and adapted it... seems that this one doesn't have any encoding problem (at least for all my chars).
I've updated nifkin's textileformatter extension for forthcoming vanilla 1.0 and have it working fine with latest svn 294 on a local install. To be fair to nifkin, I've passed it back to him first to look over/adjust as he sees fit.
In my test situation it does not throw up errors and works fine with German characters, quotes, double-dashes etc., but I do not know what problems the previous version threw up.
I exchanged textile 2.08 wholesale for the current textile implementation from textpattern, primarily because I am more familiar with it and because it has gone through some rigorous testing in the txp community. It seems to work fine for me and I was able to remove the error_reporting(0) from the plug-in, whilst keeping nifkin's code to trip up javascript, onMouse... etc. and embed being executed.
I've noticed that some small CSS modifications in vanilla or extensions may be necessary for the message windows and preview field as a result (one already mentioned on the dev forum), but that would apply in any case.