abernaith's dashboard

If you'd like to try out this feature yourself..
you can add *yourself* to this wiki (using another trick that I'm cooking up)

http://copytest2.pbwiki.com/addself

then you can add/edit pages using the "classic editor" links on the right hand side..

feel free to create a new page with the wikistyle editor.

If you'd like to try out this feature yourself..
you can add *yourself* to this wiki (using another trick that I'm cooking up)

http://copytest2.pbwiki.com/addself

then you can add/edit pages using the "classic editor" links on the right hand side..

feel free to create a new page with the wikistyle editor.

Nathan Schmidt whipped up a quick pbwiki 2.0 API call for rendering wikistyle text into html, and I used that to create a classic editor for 2.0 wikis.

instructions for putting it on your wiki can be found here:

http://getsatisfaction.com/pbwiki/top...

Interesting point about the lack of wikistyle making the site more like something like geocities...

Going to the Oxford English Dictionary definition of a wiki: A type of web page designed so that its content can be edited by anyone who accesses it, using a simplified markup language.

pbwiki definately is straying away from being a true wiki.

So I just started playing with PBWiki today and I agree that the lack of WikiStyle is a real hinderance for people who write long documents - which is much easier to do offline in a simple text editor. Sure, writing docs offline and then uploading in one giant shot isn't very collaborative, but that's how a lot of things get started.

I understand the issue with WYSIWYG editors destroying WikiStyle (I've seen this with Confluence, SocialText, MediaWiki, etc.) but that seems solvable by constraining edits to what you can do in WikiStyle if the admin chooses to support that.

glad to see that you're taking the "expert user experience" into account since that's what everybody becomes eventually if they use your product as much as you'd like them to... Can't wait to see this stuff go in.... the return of mobile support will be awesome too... when I first started using pbWiki I read and updated it all the time through the web browser in my PSP... but those days are gone, and it'll be exciting if they return. – Tim, on May 16, 2008 20:46

I'm also loving the classic editor, especially creating links is extremely fast.
I use a private wiki with over 100 pages and over 1000 links, links are the core of my wiki and beeing forced to use the new editor would be really a problem.

It's not only the time you need more when using the mouse for links (even shortcuts are much slower and more intricate than classic editor) - the problem is the bad feeling everytime you make a link that it was much easier in the past and that is now called "improvement".

I know there is a problem that the classic formatting gets "destroyed" when someone uses the new editor once - so you can't relly switch back anymore then.
But why don't you make the new editor default and an option in the wiki settings to enable also classic editor which the wikiadmin can turn on and set write permissions to pages so that someones "classic" pages don't get broken.
At least on a private wiki classic editor should be available !

I tried adding jiglu to http://macewan.pbwiki.com , but it doesn't seem to know how to index PBwiki pages very well. – Guy Fawkes, on April 30, 2008 13:42

i bumped into jiglu.com - they have a great tags-that-think tool
it uses a oneliner javascript
is it possible to validate a library of validated javascripts like jiglu's ?
best regards, Ron

I miss WikiStyle too. WYSIWYG is the devil. It's so much more complicated and time consuming than just typing what you want on to the page. I don't get the point.

"losing that style of editing causes the service to no longer really be a wiki. It's just HTML pages (a la geocities) with a built in HTML editor."

Thank you.

I agree with Guy and others who are upset to see Wiki markup disappear. To me, losing that style of editing causes the service to no longer really be a wiki. It's just HTML pages (a la geocities) with a built in HTML editor.

Something that I like about wiki markup is the limiting factor that it puts on layout. As well as some of the automatic features such as creating tables of contents for the Headings on the page. This also allowed for anchors for each of those headings automatically. Of course, I might be recalling features that MediaWiki has and not PBwiki.

This strikes me as a difference between myspace and facebook in a way... Facebook was successful in part because it didn't let the user create super-ugly do anything-they-want-to pages. All Facebook pages follow the same formatting rules. Almost all myspace pages I've ever seen look terrible. Wiki markup when followed has a similar effect... It restrains craziness and focuses on the content.

I suggested PBwiki to a friend expecting him to be able to create real wiki pages on a real wiki service. I'm very disappointed to come look at the pages he made, click source, and see this inscrutable HTML appear behind the pages. I'm sorry to say that I regret recommending PBwiki now.

Well, anybody inserting script would still be somebody logged into the wiki, so assuming you have pretty exclusive membership in your wiki, it'd be pretty close to what you are looking for.

Hi mark,

Thanks for the explanation. Makes more sense to me now. Guy's suggestion would be good but I do think such priviliges should be restricted as mentioned by Guy and David below. Not sure if I like the idea of 'Tomfoolery mode' where anybody can insert script. It would be cool if you did call it Tomfoolery mode though!

Thank you, sir.

[clever comment pre-emptively redacted under threat of excommunication]

Let me offer a clear and official response: we've _temporarily_ disabled arbitrary Javascript on 2.0 wikis to beef up our security infrastructure and make it harder for 2.0 users to have their sessions stolen. We know people want to hack on PBwiki, drop in javascript widgets from other sites, etc. and we'd like to be a great platform for that. So we're looking at ways to let people safely experience the joys of javascript.

Guy: your suggestion about letting only Admins save JS seems reasonable until you realize that the next Writer to edit the page after the Admin adds some JS would cause the JS to be stripped out...unless the JS is specially "signed" in some unmodifiable way. And one of our engineers (Mark, per above) is looking into ways to do such block code signing as we speak.

We may also consider letting users toggle a "Tomfoolery Mode" where they can let people in to do whatever they want (e.g. letting anonymous users slap in javascript) but acknowledge that they are in Wildly Unsupported Land and are liable to shoot themselves in the foot.

We apologize for the temporary inconvenience of having Javascript offline in 2.0 and look forward to letting people tool around again with it as soon as we've made it just a touch safer to do so.

"The reason the HTML plugin in edit mode is filtered when the Custom HTML is not is because the Custom HTML can only be edited by an admin, someone who is presumably trustworthy."

I hadn't considered that aspect, but it certainly makes the solution quite obvious: don't strip out javascript (or CSS, or anything, for that matter) from the HTML plugin if the Admin is doing the editing. I'm pretty sure you are technically able to determine if I'm the wiki owner at the moment I click 'Save', right?

I would say "for that matter, don't strip it out of the Source View, either", but I'm willing to concede that FCKeditor can't handle some things in the source.

There are all sorts of evil things you can do with JavaScript, ranging from stealing cookies to redirecting you to unsavory destinations.

The reason the HTML plugin in edit mode is filtered when the Custom HTML is not is because the Custom HTML can only be edited by an admin, someone who is presumably trustworthy. Especially on public wikis, allowing anyone to insert a chunk of random JavaScript would be incredibly dangerous.

As for the “not very Web 2.0” statement, I think you'll find that JavaScript is stripped out pretty much everywhere. JavaScript getting through the cracks means the potential for Cross-Site Scripting attacks, and those are no good.

The bottom line is that we're continually hardening PBwiki 2.0's security, including its defenses against malicious code, but it's an ongoing process. Security is pretty meaningless if the service isn't useful for people. We will re-evaluate the dynamics of unfiltered user code again as conditions change. JavaScript can do a lot of amazing things, and believe me, no one wants to see those things more than we do.

I thought pbwiki 2.0 was the next step in the natural evolution of pbwiki and not the production of a completely different pbwiki platform. The idea that we can't talk about pbwiki 2.0 functionality while directly referring to it predecessor seems ludicrous given that it is expected that all pbwiki 1.0 wiki will migrate to 2.0 eventually. Javascript has always been available in 1.0 and it was not a gross assumption to think that it would be supported in 2.0. Just because you have stuck a 2.0 at the end and improved certain functionality does not mean you can take valuable functionality away from your users with them being unhappy.

I can possibly see the logic in applying a subscription to fend off spamers and the likes but I'd like to know how much of a problem it really is before I accept the justification for money to change hands. I work on evidence and I have not seen much in the way of that yet. The fact that the team skirt round meaty issues like this just fosters a belief that we are being screwed!

Finally, and I'll shut up after this. If you are working on the principle that charging for adding javascript to the header will put spammers off, why not allow page-by-page javascript in the same vein? Maybe there is a technical answer to this which is beyond me but I cannot understand this. Can anyone enlighten me?