phpwiki-talk

Re: [Phpwiki-talk] raw/naked/embeded wiki?

[Gary B. <ga...@in...>]

On Thu, 18 Oct 2001, Adam Shand wrote:

> > What I'd really _love_ to see would be a wiki engine that generated
> > XML, so that you could then format both wiki and non-wiki pages
> > through an XML application server. That would be embeddable in
> > anything, and IMO truly cool.
>
> i'm not overly familiar with xml.  there have been discussions about using
> rss/rdf as an output format, would that do what you want?

An ordinary web server runs like this:

 PHP stuff   -> [runs] -> HTML -> +------------+
 CGI stuff   -> [runs] -> HTML -> | web server | --> to browser
 Static html -------------------> +------------+

An XML application server runs like this:

 PHP stuff   -> [runs] -> XML -> +--------+
 CGI stuff   -> [runs] -> XML -> | XML AS | -> html -> +------------+
 Static XML -------------------> +--------+            | web server | -> ...
 (Static HTML) --------------------------------------> +------------+

Here, all the formatting (headers, footers, sidebars, what have you) gets
added in the XML server. What's more, you don't _just_ have to convert
the XML to HTML, you could add templates to convert it to text, PDF, Wiki
syntax, whatever.

Gary

Re: [Phpwiki-talk] raw/naked/embeded wiki?

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

> What I'd really _love_ to see would be a wiki engine that generated
> XML, so that you could then format both wiki and non-wiki pages
> through an XML application server. That would be embeddable in
> anything, and IMO truly cool.

i'm not overly familiar with xml.  there have been discussions about using
rss/rdf as an output format, would that do what you want?

if not what do you envision?

> Not that I'm volunteering to do it or anything. My cup runneth over
> already, so to speak.

yeah, that's the way it goes, it's still interesting to toss ideas around
though.

adam.

Re: [Phpwiki-talk] raw/naked/embeded wiki?

[Gary B. <ga...@in...>]

On Wed, 17 Oct 2001, Adam Shand wrote:

> I'm not sure on the exact terminology, I think NakedWiki is closest based
> on MeatBall.  Anyway what I'm talking about is no headers/footers but just
> raw HTML formatted wiki text (including links though).
>
> Anyway based on PhpWiki's template system I'm just curious if this is
> something which could be easily accomplished?

What I'd really _love_ to see would be a wiki engine that generated XML,
so that you could then format both wiki and non-wiki pages through an XML
application server. That would be embeddable in anything, and IMO truly
cool.

Not that I'm volunteering to do it or anything. My cup runneth over
already, so to speak.

Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

[Phpwiki-talk] raw/naked/embeded wiki?

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

I'm not sure on the exact terminology, I think NakedWiki is closest based
on MeatBall.  Anyway what I'm talking about is no headers/footers but just
raw HTML formatted wiki text (including links though).

Anyway based on PhpWiki's template system I'm just curious if this is
something which could be easily accomplished?

Adam.

Re: [Phpwiki-talk] Allowing non-pre monospaced text

[Gary B. <ga...@in...>]

> > The other day it hit me -- why not use the underused backtick? My
> > PersonalWiki now supports __bold__, ''italic'', and ``monospaced``
> > text. It works really well and is easy to type, so I'd ask you to
> > consider adding this feature to PhpWiki.
>
> that works for me.  if you are using the alpha version can you post a
> patch?

I'm using 1.2, but if you open transform.php, search for '', make a copy
of the two lines and replace '' with `` and <em> with <tt> you won't go
far wrong...

> ps. i assume everyone knows but moinmoin and twiki's sourceforge pages
> were totally wiped by someone the other day, and since the pages were
> read/write sf does't want to restore them.  it might pay to make sure that
> someone has a backup of the phpwiki page database in case this is wiki
> hatred :-)

For the GtmWiki, I have two complimentary backup(ish) strategies.
Firstly, I have a CGI containing the following (note that I use custom
table names):

| #!/bin/sh
|
| echo "Content-type: text/plain"
| echo
|
| mysqldump 2>&1 -uUSER -pPASS DATABASE \
|                --add-drop-table --add-locks --quick --lock-tables \
|     wiki_pages \
|     wiki_archive \
|     wiki_links \
|     wiki_score \
|     wiki_hitcount \
|     wiki_hottopics

which gets called every night and the results saved. Secondly, I hacked
savepage.php to email me a diff of the edits, so a) I don't have to check
RecentChanges, and b) I have an evolving record of what changes.

Re: [Phpwiki-talk] Allowing non-pre monospaced text

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

Gary wrote ...

> I can't find the exact message in the archives, but someone a while
> ago mentioned that they wanted to have inlined monospaced text, ie
> using <tt> rather than <pre>. This bugged me, since I wanted it too,
> but the proposed syntax -- {{monospaced}} -- struck me as cumbersome.

that was me, and {{{text}}} is kinda cumbersome but it's what moin used.

> The other day it hit me -- why not use the underused backtick? My
> PersonalWiki now supports __bold__, ''italic'', and ``monospaced``
> text. It works really well and is easy to type, so I'd ask you to
> consider adding this feature to PhpWiki.

that works for me.  if you are using the alpha version can you post a
patch?

Sergio wrote ...

> speaking of this, my wiki has this semantics:
>
> __underline__
> **bold**
> //italic//
>
> isn't a little more intuitive ? (ie. is what most irc do this days, even
> mozilla)

yes, i think it is a little more intuitive, the problem i see is that
**bold** will interfere with double indented lists won't it?

it would be nice to see a standard wiki syntax, but then i guess that
would take some of the fun out of writing them.

adam.

ps. i assume everyone knows but moinmoin and twiki's sourceforge pages
were totally wiped by someone the other day, and since the pages were
read/write sf does't want to restore them.  it might pay to make sure that
someone has a backup of the phpwiki page database in case this is wiki
hatred :-)

Re: [Phpwiki-talk] Allowing non-pre monospaced text

[Sergio A. K. <ser...@ho...>]

----- Original Message ----- 
From: "Gary Benson" <ga...@in...>


> 
> The other day it hit me -- why not use the underused backtick? My
> PersonalWiki now supports __bold__, ''italic'', and ``monospaced`` text.
> It works really well and is easy to type, so I'd ask you to consider
> adding this feature to PhpWiki.

speaking of this, my wiki has this semantics:

__underline__

**bold**

//italic//

isn't a little more intuitive ?
(ie. is what most irc do this days, even mozilla)

/sergio

[Phpwiki-talk] Allowing non-pre monospaced text

[Gary B. <ga...@in...>]

I can't find the exact message in the archives, but someone a while ago
mentioned that they wanted to have inlined monospaced text, ie using <tt>
rather than <pre>. This bugged me, since I wanted it too, but the proposed
syntax -- {{monospaced}} -- struck me as cumbersome.

The other day it hit me -- why not use the underused backtick? My
PersonalWiki now supports __bold__, ''italic'', and ``monospaced`` text.
It works really well and is easy to type, so I'd ask you to consider
adding this feature to PhpWiki.

Later,
Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

RE: [Phpwiki-talk] Patrch for PHPNuke/PostNuke modulazation for PHPWiki

[Seth C. <se...@eu...>]

Andy wrote:
> confident to hack into Wiki so will leave that to the experts :-) but I
know PHP
> Nuke 5.0/5.2 pretty well so can help with the Nuke
end/testing/integration.

and Pablo wrote:
> I have in mind to do this integration when phpwiki 1.3 comes out.

1.3 'proper' will never come out.  1.3snapshot (if I read this correctly)
should be done _soon_, since the new code Jeff hacked in works right now.
Then 1.4 will be the next release, and who knows when that will be, but not
for a while, I'd guess.

If I'm correct about the needed changes, based on the 1.1.8 patch, most of
the work is pretty trivial (changing all basedir references and so on), and
the rest _is_ Nuke integration issues like knowing how Nuke calls a module,
stores userinfo, etc
.
I know that I don't have the time to sit down and do the patch myself for
1.3, but I'd be willing to help someone else who does.  I just don't have
the hours right now.

Seth

RE: [Phpwiki-talk] Patrch for PHPNuke/PostNuke modulazation for PHPWiki.

[Pablo R. <pr...@cl...>]

I have in mind to do this integration when phpwiki 1.3 comes out.

Saludos,

Pablo Roca
La Coru=F1a - Espa=F1a
Sysop del Portal gratuito de Visualfoxpro en Espa=F1ol
http://www.portalfox.com

[Phpwiki-talk] Patrch for PHPNuke/PostNuke modulazation for PHPWiki.

[Andy B. - S. Uk - V. - S. E. <And...@Su...>]

> 
> I would however love to use a 1.3snapshot with this patched into it, so if
> someone else is interested in doing the patch work, please let me know or
> Olle know.  It really does look like most of the changes will be creating a
> set of modified templates, adding a $basedir prefix to all of the various
> directory references, and finally the small set of changes to truly let
> PHP/PostNuke drive the wiki with username etc...

Can I second that. This would be a very good thing to do IMHO. I don't feel 
confident to hack into Wiki so will leave that to the experts :-) but I know PHP 
Nuke 5.0/5.2 pretty well so can help with the Nuke end/testing/integration. 

It's not the cleanest portal system in the world but its easy to set up and most 
importantly has a huge following so would be a very good way to give visibility 
and promote the wiki concept to a wider audience if you get my drift.

Cheers,
Andy
http://www.megalithic.co.uk

[Phpwiki-talk] Patrch for PHPNuke/PostNuke modulazation for PHPWiki.

[Seth C. <se...@eu...>]

I haven't had time to play much with this hack that Olle (oej@edvina..net)
has created,
but when I did, it worked well.  I haven't heard back from him recently, but
he said he was going to try and merge it into 1.3

The patch itself is only about 14K, and most of it is either putting in
$basedir in front of  locations, or template changes to allow PHPNuke theme
colors, etc.

I've tried to apply the patch I created from the changes (1.1.8 and his
hacked version) but of course, the changes between 1.3cvs and 1.18 are very
large.  I suspect someone more familar with the codebase would have an easy
time, and I'm even sure I could eventually get it done by hand, but I don't
have the time to mess with it right now.

I would however love to use a 1.3snapshot with this patched into it, so if
someone else is interested in doing the patch work, please let me know or
Olle know.  It really does look like most of the changes will be creating a
set of modified templates, adding a $basedir prefix to all of the various
directory references, and finally the small set of changes to truly let
PHP/PostNuke drive the wiki with username etc...

Seth

RE: [Phpwiki-talk] UploadFile plugin.

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

> 1- Posibility to limit the size of the uploads (in config)
> 2- Posibility to limit file types

i believe that an upload size limit is already in place for the zip
uploads.  restricting file types is probably a good idea but is of limited
use i suspect as files can just be renamed to qualify.

long term quota's would probably be useful as well to restrict people's
ability to "mailbomb" (upload bomb?) the web server.

> Not in the dabatase for sure not. Maybe in a special dir only for this
> things.

yep, this was my thought as well.

adam.

RE: [Phpwiki-talk] UploadFile plugin.

[Pablo R. <pr...@cl...>]

>So this is one of the things I'd like to see in PhpWiki so I figure
I'll try and write it.  What I wanted was some feedback on how it should
be implemented.

Hi Adam,

Here are my oppinions:

1- Posibility to limit the size of the uploads (in config)
2- Posibility to limit file types

>The biggest question is where should it store the files?

Not in the dabatase for sure not. Maybe in a special dir only for this
things.

Saludos,

Pablo Roca - MS VFP - MVP
La Coru=F1a - Espa=F1a
Sysop del Portal gratuito de Visualfoxpro en Espa=F1ol
http://www.portalfox.com


-----Mensaje original-----
De: php...@li...
[mailto:php...@li...] En nombre de Adam
Shand
Enviado el: lunes, 08 de octubre de 2001 20:06
Para: PhpWikiTalk
Asunto: [Phpwiki-talk] UploadFile plugin.




I would like it if files were associated with a wiki page and could then
be referenced by the Interwiki mechanism.

The biggest question is where should it store the files?  I'm not sure
it makes sense to store potentially large files in the database so I was
thinking of uploading files to the filesystem, something like this:

/var/www/wiki/files/PageName
/var/www/wiki/files/OtherPageName

and then files could be accessed via Interwiki with something like this:

Files:PageName/picture.jpg
Files:OtherPageName/presentation.ppt

Does this make sense?

Adam.


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

[Phpwiki-talk] UploadFile plugin.

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

So this is one of the things I'd like to see in PhpWiki so I figure I'll
try and write it.  What I wanted was some feedback on how it should be
implemented.

I would like it if files were associated with a wiki page and could then
be referenced by the Interwiki mechanism.

The biggest question is where should it store the files?  I'm not sure it
makes sense to store potentially large files in the database so I was
thinking of uploading files to the filesystem, something like this:

/var/www/wiki/files/PageName
/var/www/wiki/files/OtherPageName

and then files could be accessed via Interwiki with something like this:

Files:PageName/picture.jpg
Files:OtherPageName/presentation.ppt

Does this make sense?

Adam.

Re: [Phpwiki-talk] Dumping out the wiki to static web pages?

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

> With phpwiki v1.2, what is the best way to dump out the entire wiki
> page database as a set of HTML pages?  (I am thinking about how one
> might export the pages to another server, and also using the generated
> HTML pages as a (non-editable) backup copy of the database.)

For this the easiest thing I can think of is to use something like wget to
recursively download your wiki to html files.

> Also, to back up the database, is it only necessary to copy the files
> in the pages/ subdirectory?  i.e. could the database be restored by
> just overwriting the files in pages/ with the archived ones?  I am
> using the dbm storage method.

I'm not sure if what you say will work or not, however Steve posted
instructions for using PhpWiki's built in zip backup utility here, I
suspect that this is the easiest way to back up the raw source for your
wiki.

  http://www.geocrawler.com/lists/3/SourceForge/4037/0/6765555/

adam.

[Phpwiki-talk] Dumping out the wiki to static web pages?

[Richard C. <Ric...@st...>]

With phpwiki v1.2, what is the best way to dump out the entire wiki page
database as a set of HTML pages?  (I am thinking about how one might export the
pages to another server, and also using the generated HTML pages as a
(non-editable) backup copy of the database.)

Also, to back up the database, is it only necessary to copy the files in the
pages/ subdirectory?  i.e. could the database be restored by just overwriting
the files in pages/ with the archived ones?  I am using the dbm storage method.

-- 
Richard | SuperH Core Architecture  ///                 .... At home ...
Curnow  | cu...@br...    ///     ri...@rr...
        | http://www.superh.com/    /// http://www.rrbcurnow.freeuk.com/

[Phpwiki-talk] Possible bug with IsProbablyRedirectToIndex()

[Steven M. <st...@mu...>]

Hi All,

My Phpwiki is installed in http://server/alphaWiki/index.php but when I 
tried it with http://server/alphaWiki/?ReleaseNotes the page is displayed 
correctly but links from it are wrong, for example:
http://server/alphaWiki/WikiPlugin
I fixed the problem by setting VIRTUAL_PATH to be alphaWiki/index.php but I 
am not sure whether this is the right thing to do.

Sorry I can't be of more help, but I'm not sure what is going on 
in  IsProbablyRedirectToIndex() and the other parts of lib/config.php which 
are to do with setting VIRTUAL_PATH. Would it be better to just set 
USE_PATH_INFO to false and ignore these sorts of things?

Thanks in advance,

Steven Murdoch.

--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html

Re: [Phpwiki-talk] How usable is the Alpha version

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

On Sat, 6 Oct 2001, Steven Murdoch wrote:

> Thanks for the reply.
>
> Perhaps an option that could be considered is that one of the nightly
> builds could be taken as a "testing release" (like Debian) before the large
> changes go in. It would still be considered unstable, but would give
> inexperienced users like me something that would have most of the features
> of the alpha version but more stable than the future nightly builds. It is
> only a suggestion so feel free to ignore it.

Yes, something along the lines of a 1.3.1 release has been on my mind.
We're at a good point to do this. (The 1.3 branch is "developmental", and
when we finish we will release version 1.4, like the Linux kernel does.
i.e. even numbered releases are stable, odd numbered releases are
experimental.)

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] How usable is the Alpha version

[Gary B. <ga...@in...>]

On Sat, 6 Oct 2001, Steven Murdoch wrote:

> Thanks for the reply.
>
> At 19:11 05/10/01 -0400, you wrote:
> >There are no serious problems in the code base at the moment, but there
> >are larger changes coming so I would recommend using a nightly build as
> >soon as possible if you take the plunge. We've had it running on dba,
> >Mysql and Postgresql and it looks OK. There will be small bugs though,
> >like not being able to delete a page.
>
> Perhaps an option that could be considered is that one of the nightly
> builds could be taken as a "testing release" (like Debian) before the large
> changes go in. It would still be considered unstable, but would give
> inexperienced users like me something that would have most of the features
> of the alpha version but more stable than the future nightly builds. It is
> only a suggestion so feel free to ignore it.

That would be cool. I personally would like to see a new `stable' release,
even if it is just semi-stable.

Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

Re: [Phpwiki-talk] How usable is the Alpha version

[Steven M. <st...@mu...>]

Thanks for the reply.

At 19:11 05/10/01 -0400, you wrote:
>There are no serious problems in the code base at the moment, but there
>are larger changes coming so I would recommend using a nightly build as
>soon as possible if you take the plunge. We've had it running on dba,
>Mysql and Postgresql and it looks OK. There will be small bugs though,
>like not being able to delete a page.

Perhaps an option that could be considered is that one of the nightly 
builds could be taken as a "testing release" (like Debian) before the large 
changes go in. It would still be considered unstable, but would give 
inexperienced users like me something that would have most of the features 
of the alpha version but more stable than the future nightly builds. It is 
only a suggestion so feel free to ignore it.

Thanks,
Steven Murdoch.

--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html

Re: [Phpwiki-talk] remove page fails in alpha version (patch).

[Steven M. <st...@mu...>]

At 20:11 04/10/01 -0700, Adam Shand wrote:
>trying to remove a page fails with this error:
>
>Fatal error: Failed opening required 'lib/template.php'
>(include_path='.:/var/lib/phpwiki-alpha') in
>/var/lib/phpwiki-alpha/admin/removepage.php on line 19
>
>and template really doesn't exist anywhere that i could see.  updating
>admin/removepage.php to point to Template.php fixes this but then it gets
>caught in a loop and won't delete the page when you click "here".

It was only after I sent in my own bug report that I noticed your mail, 
sorry for the duplicate. I know no PHP programming but it looks a bit like 
Perl and I know a little of that so I thought I'd give it a go.

Like you I tried changing "template.php" to "Template.php" and I 
encountered the same problem as you have mentioned. As I said I know no PHP 
but this problems seems unconnected.

In removepage.php there is an "if" statement to check whether the remove 
action has been verified, by checking whether the "verify=okay" parameter 
has been passed. It seems like the content of the verify parameter should 
go in $verify but when I checked, $verify was undefined so the remove is 
always seen to be unverified. Perhaps PHP is meant to automatically assign 
variable to parameters but my installation doesn't seem to.

I tried adding in a line explicitly grab the contents of verify, and it 
seems to fix the problem (patch attached). It might not be the neatest way 
to do it but it works for me. Perhaps one of the developers will check it 
over and see if it is sane, or perhaps suggest a more elegant way to fix 
the problem.

Hope this helps,
Steven Murdoch.

[Phpwiki-talk] Question on nightly build of PHPWiki alpha (maybe a bug)

[Steven M. <st...@mu...>]

Hi All,

I downloaded the alpha version of the wiki last night and I have to say I'm 
very impressed. I did have one problem so I am documenting them so that it 
may help future development.

When I attempt to remove any page the following error is brought up:
Fatal error: Failed opening required 'lib/template.php' 
(include_path='.:/usr/share/php') in
/home/murdocsj/projects/wiki/phpwiki/alpha/phpwiki/admin/removepage.php on 
line 19

I'm not sure but perhaps the lib/template.php refered to in 
admin/removepage.php on line 19, should actually be lib/Template.php?

Also are empty days in RecentChanges deleted? They aren't deleted by 
default by PHPWiki 1.2 but Gary Benson's patch allows this to be done. Do I 
need something similar for the Alpha?.

Thanks in advance,
Steven.



--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html

Re: [Phpwiki-talk] How usable is the Alpha version

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

Hi Steven,

Sorry you had vandalism problems. Right now the 1.3 branch is alpha,
use-at-your-own-risk. However I find it fairly stable at the moment.

There are no serious problems in the code base at the moment, but there
are larger changes coming so I would recommend using a nightly build as
soon as possible if you take the plunge. We've had it running on dba,
Mysql and Postgresql and it looks OK. There will be small bugs though,
like not being able to delete a page.

Do save a zip file of all the Wiki pages and try to schedule some kind of
backup solution and you should be fine.

~swain

On Sat, 6 Oct 2001, Steven Murdoch wrote:

> Hi All,
>
> I asked something like this a while back but since then my needs have
> changed. I've been having a little difficulty with the current stable
> version's backup policy since my requirements are a little unusual, since
> someone attacked my Wiki from two IPs and so I lost the online backup
> (fortunately I still had an offline set) and most of my visitors access via
> my University's proxy server so intermediate pages are not saved even
> though the authors are different.
>
> I would seem that these problems have been avoided in the Alpha version by
> having multiple generations of backups and it looks very good. I'd really
> like this feature so I was wondering how usable this Alpha version is, both
> in installation and day-to-day use?
>
> If it is OK so setup and use should I go for the latest version or are
> there snapshots that represent the Alpha's more stable states?
>
> Thanks for writing such a cool program,
> Steven Murdoch.
>
> --
> email: st...@mu...
> web: http://www.murdomedia.net/
> PGP/GnuPG keys: http://www.murdomedia.net/keys.html
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] How usable is the Alpha version

[Steven M. <st...@mu...>]

Hi All,

I asked something like this a while back but since then my needs have 
changed. I've been having a little difficulty with the current stable 
version's backup policy since my requirements are a little unusual, since 
someone attacked my Wiki from two IPs and so I lost the online backup 
(fortunately I still had an offline set) and most of my visitors access via 
my University's proxy server so intermediate pages are not saved even 
though the authors are different.

I would seem that these problems have been avoided in the Alpha version by 
having multiple generations of backups and it looks very good. I'd really 
like this feature so I was wondering how usable this Alpha version is, both 
in installation and day-to-day use?

If it is OK so setup and use should I go for the latest version or are 
there snapshots that represent the Alpha's more stable states?

Thanks for writing such a cool program,
Steven Murdoch.

--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html