phpwiki-talk

Re: [Phpwiki-talk] comment syntax?

[Steve W. <sw...@pa...>]

Adam Shand wrote:
>>>ah, i was orgininally thinking that we could just enable the comment
>>>html tag and let it pass through to the browser since it won't be seen.
>>> it didn't occur to me that there was a simpler alternative :)
>>>
>>Ooh.  We could do that, too.  Still not a problem, I think, as long as
>>the comment text is htmlspecialchar()ed ('<' -> '&lt;').
>>
> 
> if it can be done without security risks then that would be my vote. 
> the information isn't secret, just not displayed, so we may as well pass
> it to the browser, it might be useful for something.

Well, I'll be the curmudgeon here and voice two objections: one, the 
comment will appear in the HTML source and likely won't make any sense 
to the end user who views it (and won't know it came from the Wiki 
markup); and two, we are arbitrarily letting some HTML through and not 
others, like <i> and its kin; so we now send a confusing message to end 
users ("HTML is not allowed! Use HTML comments for your Wiki markup!")

My preference would be for Wiki-specific comment tags; but thinking of 
Ari's approach, there is no equivalent in the course of normal writing 
(except "asides" like this statement in parentheses).

Maybe ((I am a comment)) would suffice. Flame me as you must.

~swain

Re: [Phpwiki-talk] how to use categories?

[Steve W. <sw...@pa...>]

Hmm... since we have InterWiki linking, we could try adding pages to the 
default installation that point to pages in the c2.com Wiki.

http://c2.com/cgi/wiki?WikiCategories gives a rather obtuse explanation 
of Categories. (I think WikiBadges is another term here).

Simply put, if you want to add a page to a category you put CategoryFoo 
at the bottom of the page to add it to the Foo category.

If CategoryFoo didn't exist, the first time you follow the link you can 
create a page for it.

To me, category link/pages, and the idea of DocumentMode versus 
ThreadMode are two fundamental concepts to effective Wiki use.

~swain

Roel Vanhout wrote:
> Hi all,
> 
> While looking for documentation on the phpwiki site I noticed that there
> seems to be a concept of categories - how do I use these? How do I
> create one, and how do I add pages to a category? Is there a standard
> way to get a list of all categories? And from what version on does this
> work? Thanks!
> 
> cheers,
> 
> roel
> 
> 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 
> 
> 

Re: [Phpwiki-talk] comment syntax?

[Adam S. <ad...@pe...>]

> > ah, i was orgininally thinking that we could just enable the comment
> > html tag and let it pass through to the browser since it won't be seen.
> >  it didn't occur to me that there was a simpler alternative :)
> 
> Ooh.  We could do that, too.  Still not a problem, I think, as long as
> the comment text is htmlspecialchar()ed ('<' -> '&lt;').

if it can be done without security risks then that would be my vote. 
the information isn't secret, just not displayed, so we may as well pass
it to the browser, it might be useful for something.

adam.

[Phpwiki-talk] 1.3.3; and towards 1.4

[Steve W. <sw...@pa...>]

About two or three weeks ago I asked if we were ready for a new release 
on the 1.3 branch; Jeff, you said you and Carsten were busy with a 
serious refactoring. If that's settled down for now I'd like to put out 
1.3.3 before the week is out.

While I had goals for 1.4, the coders on the project had plenty of 
itches to scratch, and by letting them scratch away we've acheived a lot 
of new features, many never listed in the Task List. I have been very 
happy with this. You folks have done a really amazing job.


We should probably nail down that which needs finishing before we do a 
1.4 release (as started on 
http://phpwiki.sourceforge.net/phpwiki/Release1.4), and I'm sorry to say 
the first thing that comes to my mind is user authentication. I feel 
like Frodo climbing towards Cirith Ungol.

I think I'd like to tackle the flat file database, since I haven't 
written any code for the project since... since I can't remember when! 
But this needs doing. For some people it's the only way.

If the new parse engine is integrated and it does not support the old 
markup, we will indeed need a conversion tool since all the PhpWiki 
sites on SF will not port.

Carsten, not to publicly flog you, but one of the reasons I've fallen 
behind on the CVS list is because of the volume of checkins you make. 
(Oh that all open source projects had such a complaint! :-) I have been 
wondering: if you make the same change to 10 different files, do you 
check in each one individually? It looked that way to me in the past. I 
haven't tried coding PhpWiki in ProjectBuilder yet, and it wouldn't 
suprise me if there were no way to do this (check in ten files at once). 
We could teach you to check in from the Terminal app and possibly save 
you a lot of work.

cheers
~swain

Re: [Phpwiki-talk] how to use categories?

[Adam S. <ad...@pe...>]

> While looking for documentation on the phpwiki site I noticed that there
> seems to be a concept of categories - how do I use these? How do I
> create one, and how do I add pages to a category? Is there a standard
> way to get a list of all categories? And from what version on does this
> work? Thanks!

Hey Roel,

Categories are just just another wikipage.  However by using them in a
certain way you can take advantage of a wiki's features to automatically
document and categorize your pages.

The standard "wiki way" of adding a page to a category is to put:

----
CategoryWhatever

at the bottom of the page where "Whatever" is the name of the category
that it belongs to.  Now when you go to the CategoryWhatever page it
does a full text search for all pages which belong to CategoryWhatever. 
Typically the Category* pages belong to a category called
CategoryCategory which will list all the known category pages for you.

Make sense?

There are some minor alternatives.  My favorite is to take advantage of
InterWiki links and mark pages as belonging to categories by having a
link at the bottom of a page like this:

----
Category:Whatever

the advantage of that is that it stops the CategoryWhatever page from
referencing pages which mention CategoryWhatever without actually
belonging to it.

The only problem is that the current backlinks method doesn't work on
the CategoryWhatever page because there isn't a page called
Category:Whatever and the FullTextSearch displays all the matching lines
from the page which makes for a rather cluttered display.

The solution would to either allow the BackLinks plugin to accept an
arbitrary page name to search for or to have an option to the
FullTextSearch to only return matching page names, not page contents. 
Neither should be hard to do but I haven't gotten to either of them yet.

Adasm.

Re: [Phpwiki-talk] comment syntax?

[Jeff D. <da...@da...>]

Adam Shand said:
>> Yes it is, but...   The whole point of the comment syntax is that the
>> comments don't get sent to the browser.  That makes it hard to do
>> anything malicious with them.
>
> ah, i was orgininally thinking that we could just enable the comment
> html tag and let it pass through to the browser since it won't be seen.
>  it didn't occur to me that there was a simpler alternative :)

Ooh.  We could do that, too.  Still not a problem, I think, as long as
the comment text is htmlspecialchar()ed ('<' -> '&lt;').

Re: [Phpwiki-talk] comment syntax?

[Adam S. <ad...@pe...>]

> Yes it is, but...   The whole point of the comment syntax is that the
> comments don't get sent to the browser.  That makes it hard to do anything
> malicious with them.

ah, i was orgininally thinking that we could just enable the comment
html tag and let it pass through to the browser since it won't be seen. 
it didn't occur to me that there was a simpler alternative :)
 
> Good point.  Though nearly any comment syntax will screw up pasting
> whatever kind of code the syntax is stolen from.
> 
> Probably: don't allow/recognize comments within <verbatim> blocks. 
> (Probably not within <pre> blocks either.  Also you can always escape
> them: 
>   ~// This is not a comment.

sounds reasonable to me.

thanks,
adam.

Re: [Phpwiki-talk] double click to edit

[Jeff D. <da...@da...>]

Carsten Klapp said:

> I just accidentally discovered the major flaw with the new
> double-click-to-edit-the-page feature.
>
> Now it's very difficult to select / highlight text for cut and paste:

Hmm.  Well, we/I should make sure to only enable the dbl-clk-to-edit on the
browse page.  (If at all.)

Might there be other ways around this?  Would it be possible to only enable
dbl-clk-to-edit in the margins of the page.  (I.e. that part of the
<body> which isn't covered by <div class="wikitext">?)  Is anyone expert
enough of JavaScript to know if this is possible (portably?)

Re: [Phpwiki-talk] gui configuration of index.php

[Jeff D. <da...@da...>]

I haven't looked at PHPweather, but have used Gallery
(http://gallery.sf.net/) which also has an on-line config system.

Here, to the best of my recollection, is how Gallery handles some of these
issues.

There one has to run a shell script (on the server) to enable configuration
mode.  The script changes some file permissions (and maybe adjusts .htaccess
files, and I don't know what all else.)  Then you fire up you browser and
point it to your index.php.  In configuration mode, you can only configure
--- all the regular functionality is disabled.   Once you're done
configurating, you need to run a second shell script to put things in run
mode.

RE: [Phpwiki-talk] gui configuration of index.php

[Preston L. B. <pre...@co...>]

You get partly get around the security issue by only responding
to requests from a fixed IP (default as localhost).

You also might want to "lock" the installation - perhaps by something
as simple as creating a "locked" file - so that privileged access is
required to "unlock" the installation and allow changes.  This protects
you from the install script being run unintentionally (or not).


From: Lawrence Akka
> I have been thinking for some time about some sort of InstallScript - see
> my comments at the bottom of
> http://phpwiki.sourceforge.net/phpwiki/NewUserPreferences
>
> Although I don't think it is that hard to edit index.php
> manually, I think
> a script would make phpWiki even easier.  It could even try to set up the
> relevant db tables, or report an error (and give instructions) if
> it could
> not do so.
>
> Security is a big problem however.  The webserver user must have write
> access to index.php (obviously), and experience says that no matter how
> often  or clearly you tell users to change the permissions after install
> (or to remove the install script completely), they often do not do so.

> At 09:09 21/02/2002, Carsten Klapp wrote:
>
> >PHPWeather uses an excellent web-based config-file generator. With
> >permission from Martin Geisler of course, I think it could be easily
> >adapted to generate an index.php file for PhpWiki.
> >
> >There are security issues to generating a config file this way, but they
> >can probably be overcome.
> >
> >The whole thing is completely self contained in one file. It makes the
> >necessary backups, provides text output for cut and paste when the file
> >couldn't be written, and allows for comments and instructions.
> >
> >Anyway take a look, it's pretty neat.
> >
> >http://cvs.sourceforge.net/cgi-
> >bin/viewcvs.cgi/phpweather/phpweather/configurator.php

Re: [Phpwiki-talk] gui configuration of index.php

[Lawrence A. <la...@us...>]

I have been thinking for some time about some sort of InstallScript - see 
my comments at the bottom of 
http://phpwiki.sourceforge.net/phpwiki/NewUserPreferences

Although I don't think it is that hard to edit index.php manually, I think 
a script would make phpWiki even easier.  It could even try to set up the 
relevant db tables, or report an error (and give instructions) if it could 
not do so.

Security is a big problem however.  The webserver user must have write 
access to index.php (obviously), and experience says that no matter how 
often  or clearly you tell users to change the permissions after install 
(or to remove the install script completely), they often do not do so.

Lawrence


At 09:09 21/02/2002, Carsten Klapp wrote:

>PHPWeather uses an excellent web-based config-file generator. With 
>permission from Martin Geisler of course, I think it could be easily 
>adapted to generate an index.php file for PhpWiki.
>
>There are security issues to generating a config file this way, but they 
>can probably be overcome.
>
>The whole thing is completely self contained in one file. It makes the 
>necessary backups, provides text output for cut and paste when the file 
>couldn't be written, and allows for comments and instructions.
>
>Anyway take a look, it's pretty neat.
>
>http://cvs.sourceforge.net/cgi-
>bin/viewcvs.cgi/phpweather/phpweather/configurator.php
>
>Carsten
>
>
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] double click to edit

[Jon <d9...@na...>]

On Thu, Feb 21, 2002 at 03:44:13AM -0500, Carsten Klapp wrote:
> I just accidentally discovered the major flaw with the new=20
> double-click-to-edit-the-page feature.
>=20
> Now it's very difficult to select / highlight text for cut and paste:
>=20
> :-( No more double-clicking or triple-clicking to select words or=20
> sentences.

I was just about to object to Adam's proposal, but this says it so
much better. Don't make this a default setting. It's very disturbing.

--=20
___\ Jon =C5slund

[Phpwiki-talk] how to use categories?

[Roel V. <rva...@ri...>]

Hi all,

While looking for documentation on the phpwiki site I noticed that there
seems to be a concept of categories - how do I use these? How do I
create one, and how do I add pages to a category? Is there a standard
way to get a list of all categories? And from what version on does this
work? Thanks!

cheers,

roel

[Phpwiki-talk] gui configuration of index.php

[Carsten K. <car...@ma...>]

PHPWeather uses an excellent web-based config-file generator. With 
permission from Martin Geisler of course, I think it could be easily 
adapted to generate an index.php file for PhpWiki.

There are security issues to generating a config file this way, but they 
can probably be overcome.

The whole thing is completely self contained in one file. It makes the 
necessary backups, provides text output for cut and paste when the file 
couldn't be written, and allows for comments and instructions.

Anyway take a look, it's pretty neat.

http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/phpweather/phpweather/configurator.php

Carsten

Re: [Phpwiki-talk] double click to edit

[Carsten K. <car...@ma...>]

Ahhhh...

I just accidentally discovered the major flaw with the new 
double-click-to-edit-the-page feature.

Now it's very difficult to select / highlight text for cut and paste:

:-( No more double-clicking or triple-clicking to select words or 
sentences.

Carsten :-)

On Wednesday, February 20, 2002, at 09:58  pm, Jeff Dairiki wrote:

> Adam Shand said:
>>> I'm not convinced this is a great thing to enable by default.  I think
>>> it might cause some confusion.
>>
>> i wasn't sure either, but it used it for awhile and it never caused me
>> any problems with doing it accidentally.
>>
>> how about if we enable it on the phpwiki site and see if anyone
>> complains or it causes hassle for anyone and decide based on that when
>> 1.4 is released based on what we learned?
>
> Sounds like a plan. I've just hacked double-click to edit into the
> main wiki.  If anyone doesn't like it, complain!
>

Re: [Phpwiki-talk] comment syntax?

[Jeff D. <da...@da...>]

On 20 Feb 2002 19:59:52 -0800
"Adam Shand" <ad...@pe...> wrote:

> > I can't see how it could be a security risk.  OTOH, both new and old
> 
> isn't javascript and other such stuff embedded in comment strings?

Yes it is, but...   The whole point of the comment syntax is that the
comments don't get sent to the browser.  That makes it hard to do anything
malicious with them.

> will it interfere with people who might paste c code into a wiki?  any
> other languages that use // as a comment string?

Good point.  Though nearly any comment syntax will screw up pasting
whatever kind of code the syntax is stolen from.

Probably: don't allow/recognize comments within <verbatim> blocks. 
(Probably not within <pre> blocks either.  Also you can always escape
them: 
  ~// This is not a comment.

Re: [Phpwiki-talk] double click to edit

[Jeff D. <da...@da...>]

Adam Shand said:
>> I'm not convinced this is a great thing to enable by default.  I think
>> it might cause some confusion.
>
> i wasn't sure either, but it used it for awhile and it never caused me
> any problems with doing it accidentally.
>
> how about if we enable it on the phpwiki site and see if anyone
> complains or it causes hassle for anyone and decide based on that when
> 1.4 is released based on what we learned?

Sounds like a plan. I've just hacked double-click to edit into the
main wiki.  If anyone doesn't like it, complain!

[Phpwiki-talk] Re: Info page (was Re: [phpwiki-checkins] CVS: phpwiki/lib main.php,1.55,1.56)

[Carsten K. <car...@ma...>]

I appreciate this feedback, and all very good points.

I will move the code out of main and start making a plugin, to keep this 
extra functionality separate from the core wiki functions.
In the mean time I will rethink the page. As you point out the need for a 
markup indicator will probably go away (also in agreement that PhpWiki 
should only support one markup style), and page size is of very limited 
interest.

Carsten

On Wednesday, February 20, 2002, at 01:11  pm, Jeff Dairiki wrote:

> Carsten Klapp said:
>
>> The short answer is yes, and no; try the new page out to see the
>> differences.
>
> I've tried it.  The only things it provides which are not
> immediately available on PageHistory are markup version,
> "size", and the hit count.
>
> Markup version will probably go away in any release version.
> I think the general concensus is that we should only support
> one markup style.  (I agree with that concensus.)
>
> "Size" is kind of useless to anyone except possibly an admin.  You
> can get a good idea of the size just by browsing the page --- if that's
> not good enough for you, ViewSource or edit it.
>
> Hit count could concievably be of interest, I suppose.
> But we don't need a whole new button/page/and all the code
> for it just for that.
>
> I think we really need to try hard to keep the user interface
> simple.   There are other wikis out there that do everything
> and have every possible feature, but even for me, they are not
> easy to use.  I believe our target with PhpWiki is to make it
> suitable for use by not-so-computer-literate users.
>
>
> In any case, something like this should be implemented as a
> plugin/ActionPage, just like PageHistory.  There's no need to
> add more code to main, etc...
>
>
>

Re: [Phpwiki-talk] comment syntax?

[Jeff D. <da...@da...>]

Adam Shand said:
> did we ever decide on a syntax for putting inline comments in the wiki
> text?

No.

> i believe that the two most obvious options "^#" and "^;" have been
> rejected due to collisions with other markup.

# clearly conflicts with lists...  The leading semi-colon could
co-exist with the new markup syntax if/when we switch completely to
that.

> what about allowing html style comments?  <!-- stuff --> or is that a
> security risk?

I can't see how it could be a security risk.  OTOH, both new and old
parsers at this point are fairly line oriented as would have trouble
dealing with things like <!-- inline comments -->, etc...  So it's
probably better to adopt a comment syntax which is inherently line
oriented.  Maybe the C++/PHP style:

// Here's a comment?




> adam.
>
>
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] comment syntax?

[Adam S. <ad...@pe...>]

did we ever decide on a syntax for putting inline comments in the wiki
text?

i think this would be useful for instructions which are important to
people editing the page but not to people reading the page (eg. please
add comments below here ... or please be careful not to screw up this
table ...).

i think it could also be useful as a primitive meta data system though i
know that other better systems for that have been discussed.

i believe that the two most obvious options "^#" and "^;" have been
rejected due to collisions with other markup.

what about allowing html style comments?  <!-- stuff --> or is that a
security risk?

adam.

[Phpwiki-talk] double click to edit

[Adam S. <ad...@pe...>]

i thought that had gotten added a while ago but could we again support
the double click of a page to edit it?  it's supported by mozilla and IE
(though sadly not galeon) but it doesn't hurt any browser i've tried
which doesn't support the feature or javascript.

i believe the idea first came from openwiki where you can see how they
have implemented it if you view source and check the <body> tag.

<body onload="window.defaultStatus='OpenWiki, the post-it note of the
web.'" ondblclick="location.href='ow.asp?p=OpenWiki&amp;a=edit'">

adam.

Re: [Phpwiki-talk] Another PEAR bug, and the move to adodb (possibly)

[Jeff D. <da...@da...>]

Steve Wainstead said:
>
> If we can distribute ADODB with PhpWiki in such a way that it can be
> called directly, no installation required, then fine, we could do it.

Right now the needed code from both the ADODB and PEAR libraries
are included (in our CVS repository.)  So that's not an issue.

Personally, I'm sort of straddling the fence on which interface to
prefer.  I like the Pear::DB API better than ADODB's.  I do not
doubt that ADODB is faster, but I do not think that's really a
big issue in our case.  If PHP does start shipping (consistently)
with a reliable version of the PEAR library, that's a strong
plus of Pear, in my view.

[Phpwiki-talk] Re: Info page (was Re: [phpwiki-checkins] CVS: phpwiki/lib main.php,1.55,1.56)

[Jeff D. <da...@da...>]

Carsten Klapp said:

> The short answer is yes, and no; try the new page out to see the
> differences.

I've tried it.  The only things it provides which are not
immediately available on PageHistory are markup version,
"size", and the hit count.

Markup version will probably go away in any release version.
I think the general concensus is that we should only support
one markup style.  (I agree with that concensus.)

"Size" is kind of useless to anyone except possibly an admin.  You
can get a good idea of the size just by browsing the page --- if that's
not good enough for you, ViewSource or edit it.

Hit count could concievably be of interest, I suppose.
But we don't need a whole new button/page/and all the code
for it just for that.

I think we really need to try hard to keep the user interface
simple.   There are other wikis out there that do everything
and have every possible feature, but even for me, they are not
easy to use.  I believe our target with PhpWiki is to make it
suitable for use by not-so-computer-literate users.


In any case, something like this should be implemented as a
plugin/ActionPage, just like PageHistory.  There's no need to
add more code to main, etc...

Re: [Phpwiki-talk] Re: PhpWiki: Alpha wiki

[Steve W. <sw...@pa...>]

Besides the little bit of work to make it so, the templates would need 
to contain the same META tag info as the index.html page does. This 
actually does help search engines.

I've never thought it was worth bothering about, but if you feel it 
would be a better intro to web surfers, it's OK with me.

~swain

Adam Shand wrote:
>>phpwiki.sf.net/phpwiki/ -- this would continue in its role as the
>>project site
>>
> 
> is there any reason that this shouldn't be the main page rather then the
> default page you get on phpwiki.sf.net?
> 
> adam.
> 
> 
> 
> 

Re: [Phpwiki-talk] Another PEAR bug, and the move to adodb (possibly)

[Lawrence A. <la...@us...>]

Yes we can.  We only need to include three or four files.  It might be 
better to check for a previously installed version, or at least allow the 
user to specify whether he wants to use the adodb that comes with phpwiki, 
or some other version.

At 16:31 20/02/2002, Steve Wainstead wrote:
>The reason I chose DB.php in the first place is it will eventually be 
>present on every installation of PHP. They have been very slow to make a 
>clean, featureful version though. Using ADODB means the user (admin) has 
>to install it on her box before installing PhpWiki, which is a barrier to 
>entry I try hard to avoid. (I can't use Galleon or Jabber for that very 
>reason; I can't be bothered to upgrade everything to the latest and 
>greatest just to test something out.)
>
>If we can distribute ADODB with PhpWiki in such a way that it can be 
>called directly, no installation required, then fine, we could do it.
>
>~swain
>
>Lawrence Akka wrote:
>>The backlinks from 
>>http://phpwiki.sourceforge.net/alpha/en/CarstenKlapp'sCalendar  do not 
>>work.  It looks like a PEAR quotestring problem to me.  I am pleased to 
>>say that the adodb version works fine (apart from a php notice which is 
>>something to do with the use of multiple index files on the alpha site, I 
>>think).
>>More generally, what are people's views on moving over to adodb permanently?
>>For some issues arising, see 
>>http://phpwiki.sourceforge.net/phpwiki/AdodbBackend
>>Lawrence
>>
>>_______________________________________________
>>Phpwiki-talk mailing list
>>Php...@li...
>>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>>
>