phpwiki-talk

[Phpwiki-talk] LDAP Authentication...

[John C. <joh...@ya...>]

Reini,
  Here is the patch and the lines needed for AD in the
index.php.  Both are zipped so hopefully they will be
readable.

  Note:  you will need to rename the extension to zip,
as SF is blocking all zip files.

Thanks!

John

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Bob A. <apt...@cy...>]

On Fri, 27 Feb 2004 16:43:24 +0100 Reini Urban <ru...@x-...> wrote:

> Okay,
> Next PhpWiki project proposal:
>    Convert other Wiki Formats to ours.
>    Could happen that other wiki's will not be maintained anymore.
> 
>    And if there's such a converter class, we could also convert our
>    format to others. So we can get rid of XML.
>    Jeff's Inline/BlockParser framework comes quite handy for such
>    a job.
> 
> But at first I'll finish the more important goals. :)

When I start writing you a paycheck, you can pay more attention to me ;)

-- Bob

RE: [Phpwiki-talk] Re: Wiki RFC Discussion

[electron <ele...@mg...>]

On Fri, 27 Feb 2004 14:41:48 +0100 Reini Urban <ru...@x-...> wrote:

> electron schrieb:
> >>This seems fine by me, a standard could benefit everyone well. Below =
are
>  >
> > Standard for whom? There is no common wiki standard yet. If people =
will=20
> > decide on a standard one could switch from engine to engine, and =
only=20
> > the wiki's with the best features will survive. That's far too =
liberal=20
> > for me. Most new engines nowadays only survive because of their =
"weird"=20
> > new syntax and their usebase hooked to that, and not because of =
their=20
> > features. I don't like concentration that much.
> >=20
> > Before we get too far off base, are you for or against the RFC? I'm
going to
> > guess we are both on the same page as for it, if not what should it =
be?
>=20
> I'm strongly against this RFC, because I see only completely new=20
> inventions for wiki syntax. If so, then please a least common=20
> denominator of the most used wikis.

You'd think that an RFC would cover the most common cases in current use
so there'd be more chance of adoption by existing projects (especially
since Microsoft isn't involved...) Kinda stupid to spec out new,
incompatible syntax when there's already substantial overlap between the
various implementations.

---

Rurban knows common syntax a lot better than I do. RFCs, request for
comments, need commenting on. Especially if you think it sucks. The =
worst
thing that can happen is it gets published as-is, and then you have =
users
claiming your software is non-standard, creating a mess you now have to
implement and support. Especially if Tiki wants to claim standard.

---

> And in a less stronger opinion I'm against standardization of wiki=20
> syntax also. we already so many different wiki formats, which reminds =
me=20
> on lisp in the 80'ies or scheme on the 90'ies. if a standard will come =

> the small ones will die, because the features will then be more=20
> important.

You say this as if it's a bad thing.

Here's my perspective as a user/admin of open code. Like commercial
code, sometimes projects wither and die. For a few months I worried that
phpwiki was no longer actively maintained or developed and I was very
concerned about extracting and converting the substantial amount of wiki
content that I have to another wiki.

The worst thing that can happen to a wiki maintainer is losing the
content; having the content 'trapped' in a proprietary format is
possibly worse than just having it deleted because you still hold out
some hope that you can get it back.

A well-written standard would be a good thing so content can easily
transferred from one wiki to another. Wiki authors can use whatever
bizarre syntax suits them, as long as they can import and export the
content in a standard format.

> this happened to lisp with a complicated standard and scheme=20
> not with a super simple standard. that's why we have 300 different=20
> scheme implementations and 5 in lisp. (and only 3 of them strict ansi)

Why do we *want* 300 different scheme implementations? Think of it like
SQL and the weakness of the SQL standard: do we really want to have to
write SQL-for-Oracle, SQL-for-Sybase, SQL-for-Postgres, SQL-for-MySQL,
etc., etc.? What a waste of effort!

> > The XML schema is only for exporting/storage, not meant to be seen =
by
the
> > end user or even what we store in our databases. (Unless one is =
really
nuts
> > and has a ton of drive space.) Only to be included for engine
portability.
>=20
> I know I know. Another overly bloated XML parsing class just to please =

> some standard.

...and people who value their content and don't want to risk it being
trapped in code that no longer meets their needs.

> And which will never be supported by the smaller wiki's, where you =
will
> need it.

That's what an open set of standards-based libraries are for. Nobody can
force a developer to use them but if the standard is sane and everyone
else is using them, there's strong pressure to do so otherwise the
project will be (justifiably) marginalized.

I haven't looked at the draft in detail so I can't comment on specifics
(looks like they're just coding up Tiki syntax as the One True Way. Bad
idea.) I will say that there's a definite benefit to users in having a
standard simple data interchange format.

-- Bob

---

Besides saying I agree, I feel it's a waste to spend time on coding
something that's already implemented. Extensibility is a good thing.

-Jtp

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

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

Okay,
Next PhpWiki project proposal:
   Convert other Wiki Formats to ours.
   Could happen that other wiki's will not be maintained anymore.

   And if there's such a converter class, we could also convert our
   format to others. So we can get rid of XML.
   Jeff's Inline/BlockParser framework comes quite handy for such
   a job.

But at first I'll finish the more important goals. :)

Bob Apthorpe:
...
> The worst thing that can happen to a wiki maintainer is losing the
> content; having the content 'trapped' in a proprietary format is
> possibly worse than just having it deleted because you still hold out
> some hope that you can get it back.
> 
> A well-written standard would be a good thing so content can easily
> transferred from one wiki to another. Wiki authors can use whatever
> bizarre syntax suits them, as long as they can import and export the
> content in a standard format.
...

[Phpwiki-talk] Bugs! - IncludeSiteMap

[Micki K. <mic...@co...>]

Reini's rewrite of IncludeSiteMap looks great, but needs a bit more 
bugproofing.

Right now, it appears not to load the included pages on the second 
page load. In addition, it's unclear how to bypass the reclimit and 
includepages defaults, to allow inclusion of a page's full content 
and modify the depth of recursion.

Anyone else using IncludeSiteMap - can you verify?

Thanks!
Micki

>Hi Reini. Testing my migrated wiki in my test environment - 1.3.8 looks good!
>
>One question with my tests re: 'IncludeSiteMap' - For document 
>chunking (Single-source), we need full, quiet includes as in the 
>original.
>
>Currently, it's defaulted to 50 words, and I can't seem to make a 
>change by editing the IncludeSiteMap source. If you have a moment, 
>do you mind helping me figure out how can I accomplish this?
>
>Thanks,
>Micki
-- 

Micki
mailto:mic...@co...

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Bob A. <apt...@cy...>]

Hi,

On Fri, 27 Feb 2004 14:41:48 +0100 Reini Urban <ru...@x-...> wrote:

> electron schrieb:
> >>This seems fine by me, a standard could benefit everyone well. Below are
>  >
> > Standard for whom? There is no common wiki standard yet. If people will 
> > decide on a standard one could switch from engine to engine, and only 
> > the wiki's with the best features will survive. That's far too liberal 
> > for me. Most new engines nowadays only survive because of their "weird" 
> > new syntax and their usebase hooked to that, and not because of their 
> > features. I don't like concentration that much.
> > 
> > Before we get too far off base, are you for or against the RFC? I'm going to
> > guess we are both on the same page as for it, if not what should it be?
> 
> I'm strongly against this RFC, because I see only completely new 
> inventions for wiki syntax. If so, then please a least common 
> denominator of the most used wikis.

You'd think that an RFC would cover the most common cases in current use
so there'd be more chance of adoption by existing projects (especially
since Microsoft isn't involved...) Kinda stupid to spec out new,
incompatible syntax when there's already substantial overlap between the
various implementations.

> And in a less stronger opinion I'm against standardization of wiki 
> syntax also. we already so many different wiki formats, which reminds me 
> on lisp in the 80'ies or scheme on the 90'ies. if a standard will come 
> the small ones will die, because the features will then be more 
> important.

You say this as if it's a bad thing.

Here's my perspective as a user/admin of open code. Like commercial
code, sometimes projects wither and die. For a few months I worried that
phpwiki was no longer actively maintained or developed and I was very
concerned about extracting and converting the substantial amount of wiki
content that I have to another wiki.

The worst thing that can happen to a wiki maintainer is losing the
content; having the content 'trapped' in a proprietary format is
possibly worse than just having it deleted because you still hold out
some hope that you can get it back.

A well-written standard would be a good thing so content can easily
transferred from one wiki to another. Wiki authors can use whatever
bizarre syntax suits them, as long as they can import and export the
content in a standard format.

> this happened to lisp with a complicated standard and scheme 
> not with a super simple standard. that's why we have 300 different 
> scheme implementations and 5 in lisp. (and only 3 of them strict ansi)

Why do we *want* 300 different scheme implementations? Think of it like
SQL and the weakness of the SQL standard: do we really want to have to
write SQL-for-Oracle, SQL-for-Sybase, SQL-for-Postgres, SQL-for-MySQL,
etc., etc.? What a waste of effort!

> > The XML schema is only for exporting/storage, not meant to be seen by the
> > end user or even what we store in our databases. (Unless one is really nuts
> > and has a ton of drive space.) Only to be included for engine portability.
> 
> I know I know. Another overly bloated XML parsing class just to please 
> some standard.

...and people who value their content and don't want to risk it being
trapped in code that no longer meets their needs.

> And which will never be supported by the smaller wiki's, where you will
> need it.

That's what an open set of standards-based libraries are for. Nobody can
force a developer to use them but if the standard is sane and everyone
else is using them, there's strong pressure to do so otherwise the
project will be (justifiably) marginalized.

I haven't looked at the draft in detail so I can't comment on specifics
(looks like they're just coding up Tiki syntax as the One True Way. Bad
idea.) I will say that there's a definite benefit to users in having a
standard simple data interchange format.

-- Bob

Re: [Phpwiki-talk] "Fatal Database Error"

[Tony L. <la...@is...>]

On Fri, 27 Feb 2004 10:30:06 +0100
Reini Urban <ru...@x-...> wrote:

> I don't speak korean :)

You don't _even_ have to speak wiki 
to post to "PolyglotBang" from IRC. 
_Tolerance_ of languages other than 
one's own is, of course, a prerequisite. 

-- 
Tony Laszlo
irc://irc.freenode.net/issho
talking.to/blog

Re: [Phpwiki-talk] Someone is proposing a Wiki RFC with strange syntax

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

Olivier Fambon schrieb:
> http://textism.com/tools/textile/index.html
> http://textism.com/
> 
> Don't really know if this is just minor dandy stuff...

if this would be javascript it would be cool. as cgi it is dandy.

I already saw such javascript formatters, which would come handy to 
paste from word or html, and let it strip the wrong chars and do some 
major conversion and formatting very fast.
even some kind of mini wiki in jscript.

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

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

electron schrieb:
>>This seems fine by me, a standard could benefit everyone well. Below are
 >
> Standard for whom? There is no common wiki standard yet. If people will 
> decide on a standard one could switch from engine to engine, and only 
> the wiki's with the best features will survive. That's far too liberal 
> for me. Most new engines nowadays only survive because of their "weird" 
> new syntax and their usebase hooked to that, and not because of their 
> features. I don't like concentration that much.
> 
> Before we get too far off base, are you for or against the RFC? I'm going to
> guess we are both on the same page as for it, if not what should it be?

I'm strongly against this RFC, because I see only completely new 
inventions for wiki syntax. If so, then please a least common 
denominator of the most used wikis.

And in a less stronger opinion I'm against standardization of wiki 
syntax also. we already so many different wiki formats, which reminds me 
on lisp in the 80'ies or scheme on the 90'ies. if a standard will come 
the small ones will die, because the features will then be more 
important. this happened to lisp with a complicated standard and scheme 
not with a super simple standard. that's why we have 300 different 
scheme implementations and 5 in lisp. (and only 3 of them strict ansi)

> The XML schema is only for exporting/storage, not meant to be seen by the
> end user or even what we store in our databases. (Unless one is really nuts
> and has a ton of drive space.) Only to be included for engine portability.

I know I know. Another overly bloated XML parsing class just to please 
some standard. And which will never be supported by the smaller wiki's, 
where you will need it.
At least it must be loaded only on demand :)

RE: [Phpwiki-talk] Re: Wiki RFC Discussion

[electron <ele...@mg...>]

electron schrieb:
> This seems fine by me, a standard could benefit everyone well. Below =
are
my
> thoughts:

Standard for whom? There is no common wiki standard yet. If people will=20
decide on a standard one could switch from engine to engine, and only=20
the wiki's with the best features will survive. That's far too liberal=20
for me. Most new engines nowadays only survive because of their "weird"=20
new syntax and their usebase hooked to that, and not because of their=20
features. I don't like concentration that much.

---

Before we get too far off base, are you for or against the RFC? I'm =
going to
guess we are both on the same page as for it, if not what should it be?


---

> PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully =
the
> goal will be a dump from phpwiki could be imported with ease to =
another
> wiki.

Not ugly. We have to support the old schema's also.
The new MIME-ified syntax is the easiest, best and most general for us.

XML is pure hype with no substance and generally overkill for such=20
simple data as wiki formated text, which is just plaintext like =3Dpod=20
with headers.
We have no loops, and almost no recursive structures in wikitext.
Only our new blockformatter is moderately recursive, but other wikis are =

not that clever, so it's generally not mapable.

---
Ugly I say, in jest. When I first picked up PhpWiki I thought the MIME
solution was very creative.=20

I'm not an XML fan, I'm a standards fan. Implementing XML is a pain and
overkill and a bunch of swearing. The point and strength on XML is it is =
a
way to export data that non-similar databases can read. If you don't do =
a
good job implementing HTML, the browser can compensate. If you don't do =
a
good job in XML, the parser kicks out a strict error. XML just makes =
sure
everyone is on the same page and doesn't have to deal with
silly-implementation-things(TM). Like the crap we have to go through for
pear/adodb.

---


Personally I prefer to do the translation on purpose in one of my=20
favorite languages (lisp or perl or php) with a couple of lines, such as =

MoinMoin =3D> PhpWiki, but if someone ever will come up with a unified=20
wiki schema, we might have to think of supporting this new out- and=20
input format also. Hopefully its no XML.
This RFC format for example looks fine for such an intermediate format,=20
because it's easy to read and easy to write. As any Wiki syntax, in=20
contrast to XML as we all know.
That's the whole reason why we use wiki or pod, and not HTML or troff.

> I intend to write a schema if none exists but not for a month or two.
> Requires digging into more than one of my XML books. :)

Please do so :)  I'd like to see such a thing in existance.

---

The XML schema is only for exporting/storage, not meant to be seen by =
the
end user or even what we store in our databases. (Unless one is really =
nuts
and has a ton of drive space.) Only to be included for engine =
portability.

And on a final note:

Nonprogrammers <3 wiki.

Programmers who know what $_ is <3 wiki too.

-Jtp

[Phpwiki-talk] Re: Wiki RFC Discussion

[Philippe C. <ch...@sy...>]

electron wrote:

>This seems fine by me, a standard could benefit everyone well. Below are my
>thoughts:
>
>---
>
>2.2. Colored Text 
>Text can be any color you want it to be. Two Tildes (~) are used followed by
>the name of a color and a Colon (:) to specify the start of the Colored
>Text. Two additional Tildes (~) are used to end the Colored Text. 
>
>Example: ~~red:This is text is Red~~ 
>
>Colored Text can also be specified using HTML colors. HTML colors use 3
>pairs of Hex numbers; one for Red, Blue, & Green so that 00 00 00 would
>produce white. The syntax is two Tildes (~) followed by the Pound (#)
>character and the Hex Numbers with a Colon (:) followed by the text to be
>colored. Two Tildes (~) mark the end of the Colored Text. 
>
>Example: ~~#ff00ff:This is text is the color Magenta ~~ 
>
>Note: Not all Color Names are valid in all Browsers, so to be on the safe
>side, it is usually best to use the HTML number by default.
>
>---
>
> Add Section 2.2.1 or an appendix where Wiki applications define red, blue,
>green, etc. Wiki applications should not pass on these words to the browser,
>only the #sequence. One has to think of international compatibility as not
>everyone speaks English.
>
>---
>
>2.11. Page Breaks 
>Page breaks allow you to control the length of a page for easy reading. A
>new page can be added anywhere but should start at the beginning of a line.
>A page break uses 3 Periods (.), the keyword page and another 3 periods (.) 
>
>Example: ...page...
>
>---
>
>Suggestion: Use 3 underscores instead. (___) No need for any sort of
>"Keywords" in Wiki. Wiki is supposed to be simple.
>  
>
Good idea I think. "page" is only francophone and anglophone AFAIK.

>---
>
>2.15. Non-parsed text 
>It may be needed in some instances to avoid wiki to interpret any text. The
>use of (~np~) and (~/np~) can be used to enclose a non parsed text. 
>
>Example: ~np~ non parsed text ~/np~
>
>---
>
>Suggestion: Use 3 tildes instead (~~~). I see HTML leaking in there. :)
>
>  
>
Seems better, rendering of ~~~ in tutorials would be done with special 
characters instead but that's a very minor disadvantage. TikiWiki would 
currently need a bit of hacking for this change when plugins are embedded.

>---
>
>2.16. Tables 
>Tables can be rendered using the double bar separator (||) to mark the
>begining and end of a table, the bar separator (|) to define cells limits
>and carriage line return to define the end of the row. 
>
>Example: 
>|| 
>::Color Name:: | :: Color HEX :: | :: - Colored Text - :: 
>AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~ 
>AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~ 
>||
>
>---
>
>Suggestion:  Tables can be rendered using the triple bar separator (|||) to
>mark the begining and end of a table, the bar separator (|) to define cells
>limits and double bar (||) to define the end of the row. 
>
>Never rely on /n.
>
>Example: 
>||| 
>::Color Name:: | :: Color HEX :: | :: - Colored Text - :: ||
>AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~ ||
>AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~ || 
>|||
>
>---
>
>2.17. Images 
>Images can be used in text using a syntax similar to the HTML sysntax but
>using ({) and (}) to enclose the image. 
>
>Example: {src=http://tikiwiki.org/logo.png width=20 height=10 desc=Logo} 
>
>The application MUST check that the image is in fact an image and process it
>accordingly.
>
>---
>
>Suggestion: {src|desc|height|width}
>
>Example: {http://www.phpwiki.org/images/logo.png|Logo}
>Example: {http://www.phpwiki.org/images/logo.png|Logo|10|20}
>
>Simplify, Simplify.
>
>---
>2.18. Special Characters 
>Of course - any of the characters in the ASCII table can be added to a wiki
>page by enclosing it's number within a pair of Tildies. 
>
>Example: ~169~
>
>---
>
>This should be expanded to include Unicode characters. My only suggestion
>could be including ~U:450373~ . I don't have a better way.
>
>---
>
>2.22. Adding Hidden Details in Lists 
>An expandable area allows you to display the major items in your list by
>default. Every item is still there, but it needs to be expanded to become
>visible. An expandable area is created by adding a minus (-) character after
>the star (*) characters. 
>
>Example: 
>*This is a Level 1 item. 
>*This Level 1 item has Hidden Details. Click the Plus [+] to open it. 
>**-This is a Level 2 item. Clicking the Minus [-] will close it. 
>**This Level 2 item did not need the minus character. 
>*Back to Level 1. 
>
>Expandable areas work with Bulleted and Numbered lists. 
>
>---
>
>This can cause some really strange behaviors and puzzled users. ("Where did
>my text go?!!") Possibly require the previous line has a +, such as:
>
>Example: 
>*This is a Level 1 item. 
>*+This Level 1 item has Hidden Details. Click the Plus [+] to open it. 
>**-This is a Level 2 item. Clicking the Minus [-] will close it. 
>**This Level 2 item did not need the minus character. 
>*Back to Level 1. 
>
>Maybe that was an omission?
>
>  
>
I don't really understand the objection, as why is *+ on second line? 
Obviously users can be puzzled a bit at first time. We use it (and also 
for titles) in TikiWiki documentation though, and it's pretty useful.

>---
>
>2.25. HTML 
>Any HTML syntax can be used but MUST not be rendered by default displaying
>HTML as normal text unless the user or administrator authorize the rendering
>of HTML syntax in the application. In that way any application is by default
>exempt of any scripting, embedded object or HTML vulnerability. 
>HTML rendering is discouraged. 
>
>---
>
>PhpWiki requires HTML to be Encapsulated, I suggest it in the RFC as well.
>
>Example: [[<a href=http://www.phpwiki.org>Hi!</a>]]
>
>---
>
>Section 3 XML Schema:
>
>Here the RFC should include the schema for Wiki XML files. Content between
>Wikis should be easily movable and dumps/revisions should have a standard
>schema.
>
>PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully the
>goal will be a dump from phpwiki could be imported with ease to another
>wiki.
>
>I intend to write a schema if none exists but not for a month or two.
>Requires digging into more than one of my XML books. :)
>
>
>Jason Potkanski
>Potkanski System Services
>Orland Park, IL 60462
>
>E-mail: ele...@mg...
>
>
>Comments in this email above this line are under the Creative Commons
>License. Comments below are owned by their respective persons.
>
>
>
>
>
>-----Original Message-----
>From: php...@li...
>[mailto:php...@li...] On Behalf Of Reini Urban
>Sent: Thursday, February 26, 2004 10:44 PM
>To: php...@li...
>Subject: [Phpwiki-talk] Someone is proposing a Wiki RFC with strange syntax
>
>See http://tikiwiki.org/tiki-index.php?page=RFCWiki
>
>hey! want to fix some wiki format conventions, which is based NOT in the 
>Wiki's I used to know: c2, usemod, phpwiki, moinmoin to mention the 
>biggest and oldest ones, though tiki is of course the biggest now in 
>terms of features.
>
>Bold Text 2 Underscores "_" 	__text__
>Centered Text 2 Colons ":" 	::text::
>Colored Text  2 Tildes "~" 	~~blue:text~~
>Italic Text   2 Single Quotes "'"  ''text''
>MonoSpaced Text                 -+text+-
>Underlined Text 3 Equals "=" 	===text===
>
>~~red:This is text is Red~~
>Example: -=~~red:::A Red Centered Title Bar:: ~~ =-
>Example: ^ This is a Box ^.
>Example: ...page...
>
>Example: ((new page))
>Example: NewPage
>Example: ))NotAWikiPage((
>Example: ((New Page|Description of my new page))
>Example: [http://tikiwiki.org/]
>Example: [mailto:so...@so...]
>Example: [http://tikiwiki.org/|The TikiWiki Site]
>
>by some guy from the fiji's.
>  
>
I'm posting this to Tiki devel-list.
A comment on syntax I already received from a Tiki admin was that using 
__ for bold instead of underlining (currently ===) was strange. This 
makes sense to me at first glance. Luis Argerich first implemented that 
syntax, I think it would be interesting to get his comments on those 
changes.

Philippe Cloutier

Re: [Phpwiki-talk] phpxref.sf.net

[Oliver B. <ob...@de...>]

Reini Urban wrote:

[PHPXref]

Thanks for the hint, I will hava a look at it. Maybe I can learn some 
PHP finally.

> phpxref for phpwiki 1.3.8 needs 76 MB
> steve, do we have this enough webspace on sf.net?

I would prefer a local installation, not least because browsing is 
faster. I see no need for an online version.

Oliver

Re: [Phpwiki-talk] "Fatal Database Error"

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

Tony Laszlo schrieb:
>>your page or link table is corrupt.
>>Try to delete all pages with empty pagename AND all links to it.
> 
> Oh darn. 
> Maybe I can do this with phpmyadmin?

sure.

>>BTW: fine WikiChump plugin!> -- 
> Glad you like it. 
> Drop by the channel sometime to give it a spin. 

I don't speak korean :)

RE : [Phpwiki-talk] Standard Content Storage API

[<jw...@fi...>]

Hello,
Just for your information, the best content management model i have seen =
so
far is
http://www.fedora.info

there is no php implementation so far, so not really usable for phpwiki, =
but
the conceptual model behind it seems to be quite robust (it is developed =
and
used within several libraries in the u.s.)

it can fetch data from anywhere (database, soap, filesystem,..) and has =
a
concept (the Digital Object) that is very close to the WikiPage concept.

I think remote fetching of wiki pages (complex interwiki) could be done =
in a
robust way using the concepts of fedora.

J=E9r=F4me

-----Message d'origine-----
De=A0: php...@li...
[mailto:php...@li...] De la part de electron
Envoy=E9=A0: vendredi 27 f=E9vrier 2004 08:25
=C0=A0: php...@li...; =
el...@us...
Objet=A0: RE: [Phpwiki-talk] Standard Content Storage API

Best I can tell is it's a request to support Object Orientated =
Databases,
like Zope. It would be kinda neat and efficient to bypass SQL altogether =
and
dump wikiuser and wikipage straight to the Database as an object.=20

This does require a learning curve. Some might even say steep, myself
included.

Back burner this as a post 1.4 thing.

-Jtp


-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini =
Urban
Sent: Thursday, February 26, 2004 11:48 PM
To: el...@us...; php...@li...
Subject: [Phpwiki-talk] Standard Content Storage API

ad PhpWiki:
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D863533&group=
_id=3D612
1&atid=3D356121

Would you like to support content storage independence?
Content Repository
http://jcp.org/en/jsr/detail?id=3D170


Hi, could you please describe shortly what that is, what it means,
and why we should support that?

Do you want to support JDBC backends or something like that? Is that=20
possible and practical from php? Php usually has good db access.
Or do you need a wiki as frontend with a java backend.

Whenever I hear java I am a bit overwhelmed.
But no panic, I usually do common lisp.
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE : [Phpwiki-talk] Is there a flow diagram for the components?

[<jw...@fi...>]

Hello,
A while ago i did the attached drawing of the sequential flow within =
phpwiki

This was a first draft as I didn't get time to continue, but it may help =
for
the doc overhaul.

I can send the visio version to those who want it (sorry I hadn't =
installed
Dia at the time..)

J=E9r=F4me


-----Message d'origine-----
De=A0: php...@li...
[mailto:php...@li...] De la part de electron
Envoy=E9=A0: vendredi 27 f=E9vrier 2004 08:15
=C0=A0: php...@li...
Objet=A0: RE: [Phpwiki-talk] Is there a flow diagram for the components?

Doxygen is fine. PhpWiki needs a BIG doc overhaul anyway.

My suggestion to those who want to understand what is going on with =
PhpWiki
is to use an IDE (Integrated Development Environment).

I use phpEd by nusphere.com. It comes with a professional version of the =
php
module DBG (2.16) which connects to apache and does code steping!

There are other products like Zend Studio and open source ones like =
phpEdit
and a couple I can't remember. Each works well. Komodo deserves a =
mention.

There are PEAR modules to help debugging as well and a couple of others.

All things need to be evaluated based on cost and setup. (Hence why I =
choose
phped!)

-Jtp




I've stopped 7,398 spam messages. You can too!
One month FREE spam protection at http://www.cloudmark.com/spamnetsig/}

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Oliver =
Betz
Sent: Thursday, February 26, 2004 4:54 PM
To: php...@li...
Subject: Re: [Phpwiki-talk] Is there a flow diagram for the components?

Reini Urban wrote:

> Whit Blauvelt schrieb:
> > Probably this is just a documentation request, but it would be =
really
> > helpful if there were a good visualization of the inter-relation of
> > PhpWiki's components, particularly the plugin design.=20
>=20
> That would be indeed  very helpful. Once you are in it, you will =
admire=20
> it, but it needs some time to get into it...

Maybe a documentation tool like doxygen could help.

I started using it in my last embedded project and it's really useful=20
and very little effort to maintain. Besides putting special marked=20
comments into the right places of the documentation, it generates=20
nice cross reference lists or even graphs with AT&T's dot.

I have to admit that using doxygen only for C programs, I'm not sure=20
how good it is in extracting information from PHP code.

If wanted, I could try it with the Phpwiki code.

Do you think, Pwpwiki programmers would accept to use doxygen=20
comments? This would make it even more useful as it is the intended=20
use of doxygen...

Oliver
--=20
Oliver Betz, Muenchen




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] "Fatal Database Error"

[Tony L. <la...@is...>]

Thanks for your response, Reini. 

On Fri, 27 Feb 2004 01:12:22 +0100
Reini Urban <ru...@x-...> wrote:

> your page or link table is corrupt.
> Try to delete all pages with empty pagename AND all links to it.

Oh darn. 
Maybe I can do this with phpmyadmin?

> BTW: fine WikiChump plugin!> -- 

Glad you like it. 
Drop by the channel sometime to give it a spin. 


-- 
Tony Laszlo
irc://irc.freenode.net/issho
talking.to/blog

Re: [Phpwiki-talk] bogo login bug - auth_dsn

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

electron schrieb:
> I've been having bogo login trouble as well. I suggest using Wiki_user_new
> to false and dbtype to SQL until the spaghetti is untangled.

Bogo is a intermediate bastard class (designed by carsten)
between anon and passuser.
I've create a special _BogoLoginPassUser class also, which fits into
my upgrading loop.
$USER_AUTH_ORDER = array("BogoLogin", ...);

But I will try to squeeze the _bogouser problems out also.

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...] On Behalf Of Micki Kaufman
> Sent: Thursday, February 26, 2004 10:47 PM
> To: php...@li...
> Subject: [Phpwiki-talk] bogo login bug - auth_dsn
> 
> I just wanted to get to say 'bogo login bug'.
> 
> Seriously, though - I'm trying to Bogo login, getting the following 
> weird behavior.
> 
> Invalid password or userid.
> ------------------------------------------------------------------------
> 
> PHP Warnings
> 
> lib/WikiUserNew.php:676: Notice[8]: Undefined index: auth_dsn
> 
> DEBUG: ALLOW_ANON_EDIT = true, ALLOW_BOGO_LOGIN = true, 
> ALLOW_USER_PASSWORDS = true USER_AUTH_ORDER: PersonalPage => Db => 
> Forbidden, USER_AUTH_POLICY: old, PASSWORD_LENGTH_MINIMUM: 2
> 
> 
> 


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

[Phpwiki-talk] Re: Wiki RFC Discussion

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

electron schrieb:
> This seems fine by me, a standard could benefit everyone well. Below are my
> thoughts:

> Section 3 XML Schema:
> 
> Here the RFC should include the schema for Wiki XML files. Content between
> Wikis should be easily movable and dumps/revisions should have a standard
> schema.

Standard for whom? There is no common wiki standard yet. If people will 
decide on a standard one could switch from engine to engine, and only 
the wiki's with the best features will survive. That's far too liberal 
for me. Most new engines nowadays only survive because of their "weird" 
new syntax and their usebase hooked to that, and not because of their 
features. I don't like concentration that much.

> PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully the
> goal will be a dump from phpwiki could be imported with ease to another
> wiki.

Not ugly. We have to support the old schema's also.
The new MIME-ified syntax is the easiest, best and most general for us.

XML is pure hype with no substance and generally overkill for such 
simple data as wiki formated text, which is just plaintext like =pod 
with headers.
We have no loops, and almost no recursive structures in wikitext.
Only our new blockformatter is moderately recursive, but other wikis are 
not that clever, so it's generally not mapable.

Personally I prefer to do the translation on purpose in one of my 
favorite languages (lisp or perl or php) with a couple of lines, such as 
MoinMoin => PhpWiki, but if someone ever will come up with a unified 
wiki schema, we might have to think of supporting this new out- and 
input format also. Hopefully its no XML.
This RFC format for example looks fine for such an intermediate format, 
because it's easy to read and easy to write. As any Wiki syntax, in 
contrast to XML as we all know.
That's the whole reason why we use wiki or pod, and not HTML or troff.

> I intend to write a schema if none exists but not for a month or two.
> Requires digging into more than one of my XML books. :)

Please do so :)  I'd like to see such a thing in existance.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] bogo login bug - auth_dsn

[electron <ele...@mg...>]

I've been having bogo login trouble as well. I suggest using =
Wiki_user_new
to false and dbtype to SQL until the spaghetti is untangled.

-Jtp




I've stopped 7,398 spam messages. You can too!
One month FREE spam protection at http://www.cloudmark.com/spamnetsig/}

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Micki =
Kaufman
Sent: Thursday, February 26, 2004 10:47 PM
To: php...@li...
Subject: [Phpwiki-talk] bogo login bug - auth_dsn

I just wanted to get to say 'bogo login bug'.

Seriously, though - I'm trying to Bogo login, getting the following=20
weird behavior.

Invalid password or userid.
------------------------------------------------------------------------

PHP Warnings

lib/WikiUserNew.php:676: Notice[8]: Undefined index: auth_dsn

DEBUG: ALLOW_ANON_EDIT =3D true, ALLOW_BOGO_LOGIN =3D true,=20
ALLOW_USER_PASSWORDS =3D true USER_AUTH_ORDER: PersonalPage =3D> Db =3D> =

Forbidden, USER_AUTH_POLICY: old, PASSWORD_LENGTH_MINIMUM: 2



--=20

Micki
mailto:mic...@co...


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE: [Phpwiki-talk] Standard Content Storage API

[electron <ele...@mg...>]

Best I can tell is it's a request to support Object Orientated =
Databases,
like Zope. It would be kinda neat and efficient to bypass SQL altogether =
and
dump wikiuser and wikipage straight to the Database as an object.=20

This does require a learning curve. Some might even say steep, myself
included.

Back burner this as a post 1.4 thing.

-Jtp


-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini =
Urban
Sent: Thursday, February 26, 2004 11:48 PM
To: el...@us...; php...@li...
Subject: [Phpwiki-talk] Standard Content Storage API

ad PhpWiki:
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D863533&group=
_id=3D612
1&atid=3D356121

Would you like to support content storage independence?
Content Repository
http://jcp.org/en/jsr/detail?id=3D170


Hi, could you please describe shortly what that is, what it means,
and why we should support that?

Do you want to support JDBC backends or something like that? Is that=20
possible and practical from php? Php usually has good db access.
Or do you need a wiki as frontend with a java backend.

Whenever I hear java I am a bit overwhelmed.
But no panic, I usually do common lisp.
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE: [Phpwiki-talk] Is there a flow diagram for the components?

[electron <ele...@mg...>]

Doxygen is fine. PhpWiki needs a BIG doc overhaul anyway.

My suggestion to those who want to understand what is going on with =
PhpWiki
is to use an IDE (Integrated Development Environment).

I use phpEd by nusphere.com. It comes with a professional version of the =
php
module DBG (2.16) which connects to apache and does code steping!

There are other products like Zend Studio and open source ones like =
phpEdit
and a couple I can't remember. Each works well. Komodo deserves a =
mention.

There are PEAR modules to help debugging as well and a couple of others.

All things need to be evaluated based on cost and setup. (Hence why I =
choose
phped!)

-Jtp




I've stopped 7,398 spam messages. You can too!
One month FREE spam protection at http://www.cloudmark.com/spamnetsig/}

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Oliver =
Betz
Sent: Thursday, February 26, 2004 4:54 PM
To: php...@li...
Subject: Re: [Phpwiki-talk] Is there a flow diagram for the components?

Reini Urban wrote:

> Whit Blauvelt schrieb:
> > Probably this is just a documentation request, but it would be =
really
> > helpful if there were a good visualization of the inter-relation of
> > PhpWiki's components, particularly the plugin design.=20
>=20
> That would be indeed  very helpful. Once you are in it, you will =
admire=20
> it, but it needs some time to get into it...

Maybe a documentation tool like doxygen could help.

I started using it in my last embedded project and it's really useful=20
and very little effort to maintain. Besides putting special marked=20
comments into the right places of the documentation, it generates=20
nice cross reference lists or even graphs with AT&T's dot.

I have to admit that using doxygen only for C programs, I'm not sure=20
how good it is in extracting information from PHP code.

If wanted, I could try it with the Phpwiki code.

Do you think, Pwpwiki programmers would accept to use doxygen=20
comments? This would make it even more useful as it is the intended=20
use of doxygen...

Oliver
--=20
Oliver Betz, Muenchen

[Phpwiki-talk] Wiki RFC Discussion Was: Someone is proposing a Wiki RFC with strange syntax

[electron <ele...@mg...>]

This seems fine by me, a standard could benefit everyone well. Below are =
my
thoughts:

---

2.2. Colored Text=20
Text can be any color you want it to be. Two Tildes (~) are used =
followed by
the name of a color and a Colon (:) to specify the start of the Colored
Text. Two additional Tildes (~) are used to end the Colored Text.=20

Example: ~~red:This is text is Red~~=20

Colored Text can also be specified using HTML colors. HTML colors use 3
pairs of Hex numbers; one for Red, Blue, & Green so that 00 00 00 would
produce white. The syntax is two Tildes (~) followed by the Pound (#)
character and the Hex Numbers with a Colon (:) followed by the text to =
be
colored. Two Tildes (~) mark the end of the Colored Text.=20

Example: ~~#ff00ff:This is text is the color Magenta ~~=20

Note: Not all Color Names are valid in all Browsers, so to be on the =
safe
side, it is usually best to use the HTML number by default.

---

 Add Section 2.2.1 or an appendix where Wiki applications define red, =
blue,
green, etc. Wiki applications should not pass on these words to the =
browser,
only the #sequence. One has to think of international compatibility as =
not
everyone speaks English.

---

2.11. Page Breaks=20
Page breaks allow you to control the length of a page for easy reading. =
A
new page can be added anywhere but should start at the beginning of a =
line.
A page break uses 3 Periods (.), the keyword page and another 3 periods =
(.)=20

Example: ...page...

---

Suggestion: Use 3 underscores instead. (___) No need for any sort of
"Keywords" in Wiki. Wiki is supposed to be simple.

---

2.15. Non-parsed text=20
It may be needed in some instances to avoid wiki to interpret any text. =
The
use of (~np~) and (~/np~) can be used to enclose a non parsed text.=20

Example: ~np~ non parsed text ~/np~

---

Suggestion: Use 3 tildes instead (~~~). I see HTML leaking in there. :)

---

2.16. Tables=20
Tables can be rendered using the double bar separator (||) to mark the
begining and end of a table, the bar separator (|) to define cells =
limits
and carriage line return to define the end of the row.=20

Example:=20
||=20
::Color Name:: | :: Color HEX :: | :: - Colored Text - ::=20
AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~=20
AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~=20
||

---

Suggestion:  Tables can be rendered using the triple bar separator (|||) =
to
mark the begining and end of a table, the bar separator (|) to define =
cells
limits and double bar (||) to define the end of the row.=20

Never rely on /n.

Example:=20
|||=20
::Color Name:: | :: Color HEX :: | :: - Colored Text - :: ||
AliceBlue| ::#F0F8FF:: | ~~#F0F8FF:Colored Text~~ ||
AntiqueWhite| ::#FAEBD7:: | ~~#FAEBD7:Colored Text~~ ||=20
|||

---

2.17. Images=20
Images can be used in text using a syntax similar to the HTML sysntax =
but
using ({) and (}) to enclose the image.=20

Example: {src=3Dhttp://tikiwiki.org/logo.png width=3D20 height=3D10 =
desc=3DLogo}=20

The application MUST check that the image is in fact an image and =
process it
accordingly.

---

Suggestion: {src|desc|height|width}

Example: {http://www.phpwiki.org/images/logo.png|Logo}
Example: {http://www.phpwiki.org/images/logo.png|Logo|10|20}

Simplify, Simplify.

---
2.18. Special Characters=20
Of course - any of the characters in the ASCII table can be added to a =
wiki
page by enclosing it's number within a pair of Tildies.=20

Example: ~169~

---

This should be expanded to include Unicode characters. My only =
suggestion
could be including ~U:450373~ . I don't have a better way.

---

2.22. Adding Hidden Details in Lists=20
An expandable area allows you to display the major items in your list by
default. Every item is still there, but it needs to be expanded to =
become
visible. An expandable area is created by adding a minus (-) character =
after
the star (*) characters.=20

Example:=20
*This is a Level 1 item.=20
*This Level 1 item has Hidden Details. Click the Plus [+] to open it.=20
**-This is a Level 2 item. Clicking the Minus [-] will close it.=20
**This Level 2 item did not need the minus character.=20
*Back to Level 1.=20

Expandable areas work with Bulleted and Numbered lists.=20

---

This can cause some really strange behaviors and puzzled users. ("Where =
did
my text go?!!") Possibly require the previous line has a +, such as:

Example:=20
*This is a Level 1 item.=20
*+This Level 1 item has Hidden Details. Click the Plus [+] to open it.=20
**-This is a Level 2 item. Clicking the Minus [-] will close it.=20
**This Level 2 item did not need the minus character.=20
*Back to Level 1.=20

Maybe that was an omission?

---

2.25. HTML=20
Any HTML syntax can be used but MUST not be rendered by default =
displaying
HTML as normal text unless the user or administrator authorize the =
rendering
of HTML syntax in the application. In that way any application is by =
default
exempt of any scripting, embedded object or HTML vulnerability.=20
HTML rendering is discouraged.=20

---

PhpWiki requires HTML to be Encapsulated, I suggest it in the RFC as =
well.

Example: [[<a href=3Dhttp://www.phpwiki.org>Hi!</a>]]

---

Section 3 XML Schema:

Here the RFC should include the schema for Wiki XML files. Content =
between
Wikis should be easily movable and dumps/revisions should have a =
standard
schema.

PhpWiki uses 3 different methods for database dumps. Ugly. Hopefully the
goal will be a dump from phpwiki could be imported with ease to another
wiki.

I intend to write a schema if none exists but not for a month or two.
Requires digging into more than one of my XML books. :)


Jason Potkanski
Potkanski System Services
Orland Park, IL 60462

E-mail: ele...@mg...


Comments in this email above this line are under the Creative Commons
License. Comments below are owned by their respective persons.





-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini =
Urban
Sent: Thursday, February 26, 2004 10:44 PM
To: php...@li...
Subject: [Phpwiki-talk] Someone is proposing a Wiki RFC with strange =
syntax

See http://tikiwiki.org/tiki-index.php?page=3DRFCWiki

hey! want to fix some wiki format conventions, which is based NOT in the =

Wiki's I used to know: c2, usemod, phpwiki, moinmoin to mention the=20
biggest and oldest ones, though tiki is of course the biggest now in=20
terms of features.

Bold Text 2 Underscores "_" 	__text__
Centered Text 2 Colons ":" 	::text::
Colored Text  2 Tildes "~" 	~~blue:text~~
Italic Text   2 Single Quotes "'"  ''text''
MonoSpaced Text                 -+text+-
Underlined Text 3 Equals "=3D" 	=3D=3D=3Dtext=3D=3D=3D

~~red:This is text is Red~~
Example: -=3D~~red:::A Red Centered Title Bar:: ~~ =3D-
Example: ^ This is a Box ^.
Example: ...page...

Example: ((new page))
Example: NewPage
Example: ))NotAWikiPage((
Example: ((New Page|Description of my new page))
Example: [http://tikiwiki.org/]
Example: [mailto:so...@so...]
Example: [http://tikiwiki.org/|The TikiWiki Site]

by some guy from the fiji's.
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Standard Content Storage API

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

ad PhpWiki:
http://sourceforge.net/tracker/index.php?func=detail&aid=863533&group_id=6121&atid=356121

Would you like to support content storage independence?
Content Repository
http://jcp.org/en/jsr/detail?id=170


Hi, could you please describe shortly what that is, what it means,
and why we should support that?

Do you want to support JDBC backends or something like that? Is that 
possible and practical from php? Php usually has good db access.
Or do you need a wiki as frontend with a java backend.

Whenever I hear java I am a bit overwhelmed.
But no panic, I usually do common lisp.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpxref.sf.net

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

Reini Urban schrieb:
> Would this be a useful to understand the source better?
> 
> http://phpxref.sf.net
> sample: http://de.tikiwiki.org/xref-fix/nav.html?index.html
> 
> should be easy to setup on sf.net, if there's enough space left.

phpxref for phpwiki 1.3.8 needs 76 MB
steve, do we have this enough webspace on sf.net?

I seem to like it. Much better than doxygen.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] phpxref.sf.net

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

Would this be a useful to understand the source better?

http://phpxref.sf.net
sample: http://de.tikiwiki.org/xref-fix/nav.html?index.html

should be easy to setup on sf.net, if there's enough space left.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/