phpwiki-talk

[Phpwiki-talk] WYSIWIKI

[Dan F. <dfr...@cs...>]

For your fun and enjoyment here is an undergraduate thesis on making 
PhpWiki into a WYSIWIKI:

http://www.tc.umn.edu/~yile0001/thesis.pdf

I am not necessarily recommending this as a plan of action, but I think 
it's good to be exposed to these ideas. I will say that one of my vocal 
users feels WYSIWIKI (without a save button!) would be a huge win. 
Disclosure: I did not write this thesis, but I did work with Scott on 
other things.

Dan

The short story:

- Markup is hard for some
- Markup is ambiguous sometimes (e.g., "*happy days*" produces a bullet 
instead of bold)
- Saving should happen more easily

A trial implementation:

- Bolt a WYSIWIG editor onto the wiki in this case SPAW, 
http://sourceforge.net/projects/spaw
- Save pages in straight HTML so it is a logical, consistent, powerful 
language
- Do it in a way so people don't have to hit an "edit" or "save" button 
anymore (!!). It just auto-saves every few seconds (to the same 
revision, so it doesn't create huge numbers of revisions)

Some limitations to be solved, with proposals for solutions for each:

- Lack of plugin support
- HTML vulnerability

Re: [Phpwiki-talk] WYSIWIKI

[Reini U. <rei...@gm...>]

We alread can do this since two yrears. You only have to add
htmlarea3.php and ENABLE_HTMLAREA. There's just nobody who uses it.

Two weeks I started to generalize WYSIWYG and added support for tiny_mce,
but this doesn't work yet.

On 10/19/05, Dan Frankowski <dfr...@cs...> wrote:
> For your fun and enjoyment here is an undergraduate thesis on making
> PhpWiki into a WYSIWIKI:
>
> http://www.tc.umn.edu/~yile0001/thesis.pdf

Thanks for the link.

> I am not necessarily recommending this as a plan of action, but I think
> it's good to be exposed to these ideas. I will say that one of my vocal
> users feels WYSIWIKI (without a save button!) would be a huge win.
> Disclosure: I did not write this thesis, but I did work with Scott on
> other things.
>
> Dan
>
> The short story:
>
> - Markup is hard for some
> - Markup is ambiguous sometimes (e.g., "*happy days*" produces a bullet
> instead of bold)
> - Saving should happen more easily
>
> A trial implementation:
>
> - Bolt a WYSIWIG editor onto the wiki in this case SPAW,
> http://sourceforge.net/projects/spaw
> - Save pages in straight HTML so it is a logical, consistent, powerful
> language
> - Do it in a way so people don't have to hit an "edit" or "save" button
> anymore (!!). It just auto-saves every few seconds (to the same
> revision, so it doesn't create huge numbers of revisions)
>
> Some limitations to be solved, with proposals for solutions for each:
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] WYSIWIKI

[Manuel V. <man...@gm...>]

2005/10/19, Dan Frankowski <dfr...@cs...>:
> - Do it in a way so people don't have to hit an "edit" or "save" button
> anymore (!!). It just auto-saves every few seconds (to the same
> revision, so it doesn't create huge numbers of revisions)
>
> Some limitations to be solved, with proposals for solutions for each:
>
> - Lack of plugin support
> - HTML vulnerability

I don't see why doubleclick on textarea to edit is more obvious than
click on an 'edit' button. A wiki is not a text editor like OpenOffice
Writer or Microsoft Word, it can be dangerous to try to hide this fact
to people, all the more since they are not confident with wiki
approach.

But this work is intresting, I think there are 2 ways that can easily
solve the current limitations:
* generate wiki markups instead of HTML
* keep the current 'edit' button and allow section edition.

For the first one, I think the objective of Scott (one wysiwyg
front-end to run them all) is not a good one because the current state
is: *there are differencies between wiki syntax*. So, adoption of
wysiwiki imply a modification of something somewhere:
* You can adapt the server to try to validate the submitted XML/HTML.
* You can adapt the client to be able to take in account different wiki mar=
kups.
I believe the second one is much safe and much acceptable for engine
maintainers than the first one.

The second proposition is to provide a "mix" between mediawiki and
gmail approach. From mediawiki, the section edition is really useful,
expecially on large documents. From gmail I take the 'edit inline'.

Now let's imagine: you are reading a large document, you want to edit
a small paragraph, just click on 'edit section' (mediawiki) you get a
wysiwyg interface (wysiwiki) instead of the current paragraph *with
other sections around* (gmail). You can now make your changes, save it
and continue reading the text without reloading the page (ajax).
Obviously, the legacy edit mode (without buzz technology) should be
always available.

I don't know if I was clear enough.
Is this proposition acceptable ?

-- Manuel

Re: [Phpwiki-talk] WYSIWIKI

[Reini U. <rei...@gm...>]

On 10/25/05, Manuel Vacelet <man...@gm...> wrote:
> 2005/10/19, Dan Frankowski <dfr...@cs...>:
> > - Do it in a way so people don't have to hit an "edit" or "save" button
> > anymore (!!). It just auto-saves every few seconds (to the same
> > revision, so it doesn't create huge numbers of revisions)
> >
> > Some limitations to be solved, with proposals for solutions for each:
> >
> > - Lack of plugin support
> > - HTML vulnerability
>
> I don't see why doubleclick on textarea to edit is more obvious than
> click on an 'edit' button. A wiki is not a text editor like OpenOffice
> Writer or Microsoft Word, it can be dangerous to try to hide this fact
> to people, all the more since they are not confident with wiki
> approach.

doubeclick in textarea is now off by default and can be enabled in the
users prefs.
so the user should now that this feature exists when he explictly turned it=
 on.

> But this work is intresting, I think there are 2 ways that can easily
> solve the current limitations:
> * generate wiki markups instead of HTML
> * keep the current 'edit' button and allow section edition.

Section editing is quite hard within the current HtmlObject tree. Not
impossible,
but much harder than with the simple mediawiki architecture.

> For the first one, I think the objective of Scott (one wysiwyg
> front-end to run them all) is not a good one because the current state
> is: *there are differencies between wiki syntax*. So, adoption of
> wysiwiki imply a modification of something somewhere:
> * You can adapt the server to try to validate the submitted XML/HTML.
> * You can adapt the client to be able to take in account different wiki m=
arkups.
> I believe the second one is much safe and much acceptable for engine
> maintainers than the first one.
>
> The second proposition is to provide a "mix" between mediawiki and
> gmail approach. From mediawiki, the section edition is really useful,
> expecially on large documents. From gmail I take the 'edit inline'.

Edit inline via AJAX can always be done.
It just makes an internal edit response without user-visible refresh,
but almost
the same delay of course.

> Now let's imagine: you are reading a large document, you want to edit
> a small paragraph, just click on 'edit section' (mediawiki) you get a
> wysiwyg interface (wysiwiki) instead of the current paragraph *with
> other sections around* (gmail). You can now make your changes, save it
> and continue reading the text without reloading the page (ajax).
> Obviously, the legacy edit mode (without buzz technology) should be
> always available.
>
> I don't know if I was clear enough.
> Is this proposition acceptable ?

Of course, but hard to implement.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] WYSIWIKI

[Manuel V. <man...@gm...>]

2005/10/27, Reini Urban <rei...@gm...>:
> > But this work is intresting, I think there are 2 ways that can easily
> > solve the current limitations:
> > * generate wiki markups instead of HTML
> > * keep the current 'edit' button and allow section edition.
>
> Section editing is quite hard within the current HtmlObject tree. Not
> impossible,
> but much harder than with the simple mediawiki architecture.

Can you details how it's harder (I didin't yet study this part of PhpWiki) =
?
Do you think it's reasonably feasible or not ?

Re: [Phpwiki-talk] WYSIWIKI

[Reini U. <rei...@gm...>]

On 10/27/05, Manuel Vacelet <man...@gm...> wrote:
> 2005/10/27, Reini Urban <rei...@gm...>:
> > > But this work is intresting, I think there are 2 ways that can easily
> > > solve the current limitations:
> > > * generate wiki markups instead of HTML
> > > * keep the current 'edit' button and allow section edition.
> >
> > Section editing is quite hard within the current HtmlObject tree. Not
> > impossible,
> > but much harder than with the simple mediawiki architecture.
>
> Can you details how it's harder (I didin't yet study this part of PhpWiki=
) ?
> Do you think it's reasonably feasible or not ?

BlockParser recursively converts textblock sections into a big tree of
HTML Objects, which are then parsed with InlineParser.

To detect sections within that tree you have to find those in the tree,
let the user edit it,
and replace that section in the tree.

I wouldn't do that now, because I want the AJAX and blog features for 1.3.1=
2.
But I would help with patches.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] WYSIWIKI

[Reini U. <rei...@gm...>]

On 10/27/05, aphid <sp...@ap...> wrote:
> couple questions about this:
> 1) where would I change this to being on by default? (I really like
> the simplicity of this)

What?
http://phpwiki.org/SectionEdit cannot be turned on for now, because nobody =
has
written that so far.
But it's on the wishlist.

> 2) I'm using LDAP auth on my wiki, it isn't clear to me where I can
> store user prefs; as it stands now I get "Fatal error: Class
> '_PearDbPassUser' not found in [path]/lib/WikiUserNew.php on line
> 1101" when I try to update preferences.

This error was fixed at Fri Jun 10 06:10:35 2005 UTC (4 months, 2
weeks ago) by rurban.
http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/lib/WikiUserNew.php?r=
1=3D1.128&r2=3D1.129

> thanks
> aphid
>
> On Oct 27, 2005, at 2:00 AM, Reini Urban wrote:
> >
> > doubeclick in textarea is now off by default and can be enabled in the
> > users prefs.
> > so the user should now that this feature exists when he explictly
> > turned it on.
>
>


--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] WYSIWIKI

[Reini U. <ru...@x-...>]

2005/10/19, Dan Frankowski <dfr...@cs...>:
> For your fun and enjoyment here is an undergraduate thesis on making
> PhpWiki into a WYSIWIKI:
>
> http://www.tc.umn.edu/~yile0001/thesis.pdf
>
> I am not necessarily recommending this as a plan of action, but I think
> it's good to be exposed to these ideas. I will say that one of my vocal
> users feels WYSIWIKI (without a save button!) would be a huge win.
> Disclosure: I did not write this thesis, but I did work with Scott on
> other things.
>
> Dan
>
> The short story:
>
> - Markup is hard for some
> - Markup is ambiguous sometimes (e.g., "*happy days*" produces a bullet
> instead of bold)

This is a bug which should be fixed somewhen...

> - Saving should happen more easily

Very good idea.

> A trial implementation:

Can Scott please make CinchWiki available?
I agree with most if his points.

> - Bolt a WYSIWIG editor onto the wiki in this case SPAW,
> http://sourceforge.net/projects/spaw

My initial WYSIWYG wiki was guiki. Brain dead simple.

> - Save pages in straight HTML so it is a logical, consistent, powerful
> language

pagetype=3Dhtml

> - Do it in a way so people don't have to hit an "edit" or "save" button
> anymore (!!). It just auto-saves every few seconds (to the same
> revision, so it doesn't create huge numbers of revisions)

InlineEditing can only be done if ENABLE_WYSIWYG is the one and
only editing option.
Maybe provide an link to the traditional wikimarkup edit textarea...

> Some limitations to be solved, with proposals for solutions for each:
>
> - Lack of plugin support

This can be done by some custom insert plugin button (as phpwiki-1.3.11)
and a form to edit the args, as described in the thesis, plus some
AJAX code in the background.

I don't like the idea of magic HTML comments.
Plugins should be translated with pagetype=3Dhtml to use xml syntax.
<plugin name=3DAllUsers options>
  <ul><li>intermediate list by AJAX</li>
  </ul>
</plugin>

> - HTML vulnerability

The RawHtml plugin uses a safe_html lib to strip possible vulnerabilities.

http://chxo.com/scripts/safe_html-test.php
A set of functions for sanitizing user input:
    keeps "friendly" tags but strips javascript events and style attributes
    closes any open comment tags
    closes any open HTML tags - results may not be valid HTML, but
        at least they will keep the rest of the page from breaking

    treats the following as malicious conditions and returns text stripped
    of all html tags:
        any instances of =3D'javascript:
        event or style attributes remaining after initial replacement

See also http://simon.incutio.com/archive/2003/02/23/safeHtmlChecker
--
Reini Urban
http://phpwiki.org/