phpwiki-talk

WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshacks snapshot. )

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

> That was my idea some time ago. Conceptually, you can keep a weblog in one
> of two ways:
> 
> 1) You hand edit the Wiki markup every time you enter a new item. This is
> obviously the hard way, but one can start today with no code changes ;-)
> 
> 2) You have a sort of "helper form" to aid you in the formatting. ....

The other thing you might want from a wiki-weblog is enforced 
append-only
semantics.

This all ties in with the desire to write-protect portions of a page.

I think it was Reini who, some time ago, suggested a couple of ideas:
  1. Append-only pages.
  2. Partially locked pages --- only the part after the first <hr> 
("--------" )
     can be edited.  (Except by the page owner, of course.)
Both seem like clean solutions to the partial locking problem.  (Of 
course
they are of limited use until user authentication is implemented more 
completely.)

Which brings us to user authentication.

I recently had an idea: require every registered user to have a 
WikiHomepage.
The user's userid would be the same as the pagename of their homepage.
This accomplishes several things:
  1. Each user has a homepage (which would be linked to from 
RecentChanges, etc..)
     My guess is that most on wikis with authenticated users, each of 
the
     authenticated users would have a WikiHomepage with personal 
thoughts,
     contact information, etc. in any case. 
  2. We could store the users meta-data (password, e-mail, etc...) as 
part of
     their homepages meta-data.  This eliminates the need for a 
separate
     user database.

Disadvantages:  Somewhat kludgy, perhaps.   Somewhat restrictive: if a 
pagename
already exists, one must somehow usurp it (perhaps with admin 
assistance ?)
to use it as a userid.

Is this a crackpot idea or a stroke of genious?

Jeff

Re: [Phpwiki-talk] tab-width

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

On Sep 16, 2001, Steve Wainstead said:
> 
> Hmm. The page states: "Use an indent of 4 spaces, with no tabs. If you use
> Emacs to edit PEAR code, you should set indent-tabs-mode to nil." So the
> intention is to do away with tabs altogether, I suppose. If you need to
> put tabs in the code then \t is the way to go. However I'm in a flexible
> mood today...
> 
> I'm willing to concede this point for the greater good of the project: if
> everyone is happy with tabs, and adjusting your editor accordingly, we'll
> go with tabs and I'll have to fix my .emacs file.

To restate and (hopefully) clarify once again:

My only beef is with tab-width=4.  Setting indent-tabs-mode to nil is,
I think, a fine way to go.  But even with that setting, it's almost
inevitable that some real tabs will make their way into the source code.
(The PEAR source code demonstrates this quite well.)  I just think those
tabs that do make it into the source code should always be rendered as
eight-space tabs, rather than funky four-space tabs.

Here's what I'm proposing we use:

// Local Variables:
// mode: php
// tab-width: 8
// c-basic-offset: 4
// c-hanging-comment-ender-p: nil
// indent-tabs-mode: nil
// End:   

If we include the above cruft in our source code,  then you (probably)
don't even need to fix your .emacs.

Jeff

Mark-up for comments (was Re: [Phpwiki-talk] New jeffshacks snapshot.)

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

Steve Wainstead wrote:
> Wikis are commonly used by development folks as a sort of whiteboard/on
> the fly documentation system. This means any common comment tokens like
> 
> #
> ;
> /* */
> //
> --
> <!-- -->
> 
> are probably not a good idea,
>

An interesting point!  On the other hand, introducing yet another
quasi-random piece of markup syntax is not necessarily the greatest
idea either.   You can't really just paste code into PhpWiki even now.
If you ensure each line is indented, then it works okay, but you
still get sporadic WikiLinks...  (Note that if one requires comments
to start in column zero, then conflicts with cut-and-pasted code
are pretty much eliminated.)

UseMod has support for <pre></pre> tags which really do disable all
markup, and are therefore quite useful for posting code.
I wouldn't mind seeing something like this incorporated into PhpWiki.
 

[Phpwiki-talk] (Non-)Style Sheets

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

On Sep 16, 2001, Steve Wainstead said:
> 
> One request: I would like the default look-and-feel to be whatever the
> browser's defaults are. This is a basic Jakob Nielsen usability issue, and
> it just means (I would think) we'd provide a simple, nearly empty style
> sheet. We can provide other style sheets (like the current one you use)
> along with sheets contributed in the future for wikis that look like 1997
> Geocities pages, if that's what people want.
> 
> Not to belabor the point, but this would mean no background color setting,
> blue hyperlinks, black text, etc. I'm personally a fan of the gray
> background I get on Navigator/Linux :-)


ure, whatever your want.  Keep in mind, you can just delete the
stylesheet invocation (one -line) in each of the templates to get
the default style.

The main things the style-sheet does (currently) is:

 0. Set the background colors: the cream page background (holdover
    from traditional PhpWiki) and the white background behing the page
    text.
 1. Change the font to sans-serif.
 2. Disable the underlining on WikiLinks --- the font weight is 
increased
    on these to distinguish them.
 3. The action links ('Edit', etc...) are rendered with a gray 
background,
    and with a raised, button-like border (on those browsers which 
support
    this.) 

The text (foreground) colors are not set by the style sheet --- so you
are currently seeing your browsers defaults.  (Note that past versions
of PhpWiki do explicitly set the link colors to Netscape-like 
blue/purple,
but that those values are not exactly the same as the colors used by
(at least) my Netscape.)

Anyhow, so (besides #0: background colors) which of the other style
features listed above do you want removed?


Jeff

Re: [Phpwiki-talk] Re: greetings

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

Steve Wainstead schrieb:
> This gentleman volunteers to add a ticket tracking system. I dunno.
> Thoughts?

I'm not really familiar with the term "ticket tracking". 
I'm currently implementing a big B2B E-Commerce site with session tracking 
and user-auth, so I probably know the problem and implementation.
To me "ticket tracking" seems to be an identification/authentification 
method for asynchronous communication, mostly by e-mail. 
A unique tag bound to a user or session.

Joe, could you please elaborate what this system should do in more detail?
Do you want to add a parsable tag in the HTML code to be able to grep and 
filter it?  Or a page column in the DB?

something like:
  "list all pages where finance == approved", 
  "search in all pages where finance != approved"

html: 
  <!-- tag: finance:approve --> or something visible.

ticket plugin: 
  filter all multipage queries (search, list, ...) by a user-defined filter.

> On Sat, 8 Sep 2001, Joe Edelman wrote:
> > Hello.  I'm a new person interested in hacking on phpWiki.
> >
> > I have a bit of an agenda, though:  I want to use it as an intranet for a
> > non-profit I'm putting together, so I want to add some business/intranet
> > features.
> >
> > The only thing I want to add that's not already on your 1.3 to-do list is a
> > ticket tracking system.  I'd like to be able to embed tickets in wiki pages,
> > using a syntax like "((finance:approve))", and then have them visible from a
> > ticket tracking system.  This could be seen as an extension of what you're
> > already doing with search and "CategoryCategory" tags:  a new mechanism for
> > letting people list and sort pages by certain criteria.
> >
> > I'm also interested in and willing to help with user authentication and the
> > weblog/templating facility you describe.
> >
> > It seems like I can do these tickets using this new plugin system that Jeff
> > has made, although it needs to be extended in a small way.
> >
> > I'm not quite sure how to proceed:  can I assume that Jeff's changes will
> > probably become the HEAD?  Should I write a proposal about how I might
> > implement these tickets, then, and post it to the mailing list fpr review?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Does the INSTALL.mysql file tell all?

[Jeb B. <je...@oc...>]

On Sun, Sep 16, 2001 at 07:24:20PM -0400, Steve Wainstead wrote:
> On Sun, 16 Sep 2001, Gary Benson wrote:
> 
> > % mysql -uroot -p
> > Enter password: PrEtTySeKrEt
> > Welcome to the MySQL monitor.  Blah blah blah
> > mysql> GRANT select, insert, update, delete
> >     -> ON phpwiki.*
> >     -> TO wikiuser@localhost
> >     -> IDENTIFIED BY 'password';
> > Query OK, 0 rows affected (0.85 sec)
> > mysql> exit
> > Bye
> > % mysql -uroot -p phpwiki <schemas/schema.mysql
> > Enter password: PrEtTySeKrEt
> > %
> >
> > The database and all tables have now been created, so the wiki user does
> > not need CREATE permission. It is therefore in the interest of security
> > that the user does not have it, to protect from vulnerabilities which may
> > be in PhpWiki.
> >
> 
> I am told something about having to flush the tables too, for the
> permissions to take effect. Unfortunately I can't get at that comment
> right now...

I just happened to read the manual on this.  You don't need to flush
the tables when using the GRANT command, since that takes care of it
for you.  You would need to if you inserted the row in the mysql.users
directly, but that is only necessary in older versions of MySQL before
GRANT was working.  (I wouldn't bother documenting all that in PhpWiki
though, since it's already covered elsewhere, and people running older
versions of MySQL should probably know how to create a user anyway...)

Peace,
-jeb

[Phpwiki-talk] Re: greetings

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

This gentleman volunteers to add a ticket tracking system. I dunno.
Thoughts?

~swain

On Sat, 8 Sep 2001, Joe Edelman wrote:

> Hello.  I'm a new person interested in hacking on phpWiki.
>
> I have a bit of an agenda, though:  I want to use it as an intranet for a
> non-profit I'm putting together, so I want to add some business/intranet
> features.
>
> The only thing I want to add that's not already on your 1.3 to-do list is a
> ticket tracking system.  I'd like to be able to embed tickets in wiki pages,
> using a syntax like "((finance:approve))", and then have them visible from a
> ticket tracking system.  This could be seen as an extension of what you're
> already doing with search and "CategoryCategory" tags:  a new mechanism for
> letting people list and sort pages by certain criteria.
>
> I'm also interested in and willing to help with user authentication and the
> weblog/templating facility you describe.
>
> It seems like I can do these tickets using this new plugin system that Jeff
> has made, although it needs to be extended in a small way.
>
> I'm not quite sure how to proceed:  can I assume that Jeff's changes will
> probably become the HEAD?  Should I write a proposal about how I might
> implement these tickets, then, and post it to the mailing list fpr review?
>
> Thanks, and thanks for putting this project and this software together--
> it's something to be proud of.
>
>   Joe Edelman
>   Varanasi / Boston / San Francisco
>   <http://orbis-tertius.net/joe/>
>

---
                  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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Tables in Phpwiki 1.2

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

I dug out the patch from an old mail file on an old server... and viola!
Lemme know if this works.

cheers
~swain

On Tue, 11 Sep 2001, Steven Murdoch wrote:

>  --- "Philip J. Hollenback" <ph...@ho...> wrote:
> > Check the mailing list archive - there was a patch posted just a month
> > or two ago which added table support to phpwiki.
>
> The only one I could find is
> http://www.geocrawler.com/archives/3/4037/2000/7/0/4102765/
> which is quite old (July 2000). Also the patch is truncated in the archives so
> if this is the patch you meant then would you mind sending me a copy if you
> have one.
>
> Thanks,
>
> Steven Murdoch.
>
> =====
> Some mail programs use the incorrect email address in replies, so please ensure that any emails for me are sent to st...@mu...
>
> ____________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> or your free @yahoo.ie address at http://mail.yahoo.ie
>
> _______________________________________________
> 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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Jeff's amazingly cool hacks...

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

On Sat, 15 Sep 2001, Seth Cohn wrote:

> Very very cool.
>
> While you are it:
> User validation/database?

If you mean user auth, someone recently volunteered to work on this and
it's been on the todo list forever:

https://sourceforge.net/pm/task.php?group_project_id=7691&group_id=6121&func=browse

> Summary is a good idea, but it doesn't let you use WikiWords.
> Locking some content on page, even if only at the top of the page.

Locking *some* of the content is right up there with storing the links
separate from the pages. I can't remember why generating a list of
dangling references from the links table was not the way to go, but
storing links separately was the way to go if we wanted to give you the
ability to rename pages. So to lock just part of a page, we'd need a
similar scheme where that part is not displayed in the edit form unless
you own it... hmm.. I guess that might be a simple markup issue after all,
and we filter the page source before it goes into the edit form.

still rambling,
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

On Sat, 15 Sep 2001, Jeff Dairiki wrote:

> > it would be nice, i think, to be able to use a wike as an evolving story
> > and have weblog style comments attached to it.
>
> Yes.  I think Steve (Wainstead) has expressed interest in this idea as
> well.
> I think the idea for how to hook this into the wiki is to introduce
> "page types"
> --- the type of a page determines how it gets displayed (and edited).
> Straightforward, I think, but I'm not going to work on it, at this
> point.

That was my idea some time ago. Conceptually, you can keep a weblog in one
of two ways:

1) You hand edit the Wiki markup every time you enter a new item. This is
obviously the hard way, but one can start today with no code changes ;-)

2) You have a sort of "helper form" to aid you in the formatting. It would
just be a series of <input>s for title, time, category, author, summary.
At some point I thought about other "types" of pages, and why not make
this process generic?

This is a sort of counterpart to the display templates... or perhaps,
something to be hacked into the templates? Is there any reason why we
can't use templates to create edit forms?

Then the next issue was database structure. This is where it gets to the
point where you want the pages stored as XML so you can have different
page types which transmogrify into whatever output you want (RSS, XHTML,
plain text, png image files, binary gibberish... you get the idea) and now
we should simply incorporate and sell the damn thing. I mean, it sounds
like WORK! ;-) But it's also the Right Thing, and we get into "don't let
the best be the enemy of the good," and all that philosophy about coding
and design.

Ahem. My preference for "Worse Is Better" would say, hack in a new form
for a WikiLog, or WikiWikiWebLog, or whatever you want to call it; later
someone will merge it into the template engine, and later someone will
generalize it so you can have multiple input forms for multiple page
types...

sorry for the ramble, but the escape from recent events is good.

cheers
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

On Fri, 14 Sep 2001, Jeff Dairiki wrote:

> > and then comments would just be:
> >
> > # blah blah
> > # please leave the below lines intact.
>
> Of course, that syntax is already used in PhpWiki for ordered lists.
> It would have to be something uglier like:
>
> // please steal this comment

Wikis are commonly used by development folks as a sort of whiteboard/on
the fly documentation system. This means any common comment tokens like

#
;
/* */
//
--
<!-- -->

are probably not a good idea, unfortunately. Hash marks are already used
by PhpWiki for numbered lists... how about:

%%
@@

or something equally wretched? I do think comments are a good thing
though.

~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

Hi Jeff, finally had some time to play with the new code you've done. It
looks great! I say go ahead and merge it into the 1.3 tree.

One request: I would like the default look-and-feel to be whatever the
browser's defaults are. This is a basic Jakob Nielsen usability issue, and
it just means (I would think) we'd provide a simple, nearly empty style
sheet. We can provide other style sheets (like the current one you use)
along with sheets contributed in the future for wikis that look like 1997
Geocities pages, if that's what people want.

Not to belabor the point, but this would mean no background color setting,
blue hyperlinks, black text, etc. I'm personally a fan of the gray
background I get on Navigator/Linux :-)

I'm anxious to see a unified interface for the database in place... this
stops me from doing other things on the todo list. I'm also really glad
you put a lot of comments in.

cheers
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Does the INSTALL.mysql file tell all?

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

On Sun, 16 Sep 2001, Gary Benson wrote:

> % mysql -uroot -p
> Enter password: PrEtTySeKrEt
> Welcome to the MySQL monitor.  Blah blah blah
> mysql> GRANT select, insert, update, delete
>     -> ON phpwiki.*
>     -> TO wikiuser@localhost
>     -> IDENTIFIED BY 'password';
> Query OK, 0 rows affected (0.85 sec)
> mysql> exit
> Bye
> % mysql -uroot -p phpwiki <schemas/schema.mysql
> Enter password: PrEtTySeKrEt
> %
>
> The database and all tables have now been created, so the wiki user does
> not need CREATE permission. It is therefore in the interest of security
> that the user does not have it, to protect from vulnerabilities which may
> be in PhpWiki.
>

I am told something about having to flush the tables too, for the
permissions to take effect. Unfortunately I can't get at that comment
right now...

~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Does the INSTALL.mysql file tell all?

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

On Sun, 16 Sep 2001, Steve Wainstead wrote:

> On Mon, 10 Sep 2001, Marjorie Roswell wrote:
>
> > Seems to me that the directions should add "CREATE" permissions along
> > with the select, insert, update, and delete that are provided in the
> > INSTALL.mysql.
> >
> > Am I right about that?
>
> You may be right... read on:

I meant to reply to this a while ago, but I too spent a lot of time
watching TV and then got food poisoning and spent most of the weekend
vomiting :-(

I think that INSTALL.mysql should say "-uroot -p" instead of "-uuser
-ppassword", since _all_ of the stuff mentioned in there should be done as
the MySQL user. Okay, if someone has set up another user to have CREATE
and GRANT permissions then they can use another user, but then anyone
who has set that up should know how to do it anyway ;-)

The session should look like:

% mysqladmin -uroot -p create phpwiki
Enter password: PrEtTySeKrEt
% mysql -uroot -p
Enter password: PrEtTySeKrEt
Welcome to the MySQL monitor.  Blah blah blah
mysql> GRANT select, insert, update, delete
    -> ON phpwiki.*
    -> TO wikiuser@localhost
    -> IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.85 sec)
mysql> exit
Bye
% mysql -uroot -p phpwiki <schemas/schema.mysql
Enter password: PrEtTySeKrEt
%

The database and all tables have now been created, so the wiki user does
not need CREATE permission. It is therefore in the interest of security
that the user does not have it, to protect from vulnerabilities which may
be in PhpWiki.

Cheers,
Gary

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

Re: [Phpwiki-talk] tab-width

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

On Sat, 8 Sep 2001, Jeff Dairiki wrote:

> I think the intention of the PEAR standards is that indentation be
> achieved using only tabs.  This allows individuals to adjust
> the displayed indentation just by changing the tab-width.
> The problem is that even when tab-width == c-basic-offset, emacs
> does not really guarantee that all indentation is achieved using
> tabs rather than spaces.

Hmm. The page states: "Use an indent of 4 spaces, with no tabs. If you use
Emacs to edit PEAR code, you should set indent-tabs-mode to nil." So the
intention is to do away with tabs altogether, I suppose. If you need to
put tabs in the code then \t is the way to go. However I'm in a flexible
mood today...

I'm willing to concede this point for the greater good of the project: if
everyone is happy with tabs, and adjusting your editor accordingly, we'll
go with tabs and I'll have to fix my .emacs file.

cheers
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] September 11

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

I'm touched by your inquiries... Sorry for not closing this thread
earlier. I'm fine.

I was sleeping when my dad called me at just before 9am EST. He asked if I
knew what was going on, a plane hit the WTC. I said no and turned the TV
on. While we were talking we watched the second plane hit the other
building! Later I heard jet engines, which for once was a very scary
sound, but it turned out to be F-15 Eagles providing air cover for NYC.
Every time one flew over I got chills.

Although my apartment faces south I can't see the WTC because of another
building. After sitting home all day I got restless and took a bike ride
at about midnight.

There were police all along the major crossstreets, and at most
intersections. I eventually made it through several police baracades by
riding my bike on the sidewalk (they only wanted to keep cars out) and I
made it all the way to Canal street. South of Canal was all evacuated.

At Canal and Church steets I could look south a few blocks and see some of
the debris. There were trucks filled with generators, lights, cranes,
National Guardsmen all going back and forth, into the site. I took some
pictures with my new digital camera but it was too dark and they came out
funny. All blood red.

The next two days it was unusually quiet here. There were police
everywhere. There were few ways into Manhattan so the city was quiet and
mostly shut down.

Things are returning to normal. For a while they were using the ice rink
at my gym as a morgue, but they've since started moving all the bodies
across the river to New Jersey. My friends tease me that I came back from
Key West just in time.

cheers
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Does the INSTALL.mysql file tell all?

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

Hi Marjorie, sorry for the delay. I've been watching TV a lot lately and
waiting to hear from friends, and I finally have and they are all OK. (I
live in Manhattan).

On Mon, 10 Sep 2001, Marjorie Roswell wrote:

> Hello,
>
> I spent a gazillion hours, as a frustrated sort-of newbie, unable to
> create the mysql database.
>
> Seems to me that the directions should add "CREATE" permissions along
> with the select, insert, update, and delete that are provided in the
> INSTALL.mysql.
>
> Am I right about that?

You may be right... read on:

> Even when I tried to update my username with these permissions, my
> grant statement didn't work (for hours, and hours of trying every
> which possibility.) I think I might've gotten it, though I finally
> ended up with the lovely username "testnew."
>
> I have a lot of questions, etc, but this is just an ode to how hard it
> is not be an expert in something. Things that are completely trivial
> to an expert can take hours and hours, or days, or weeks, for a
> newbie...

I share your pain. Postgresql and Mysql are notoriously difficult to set
up and administrate. And they both do it in totally different ways. I know
once I have one or the other set up it's a long time before I have to do
it again and by then I've forgotten, and it takes at least an evening to
do it over. I hate it.


> The neighbor says that everything2 is cooler than phpwiki, by the way.
> Any thoughts on that? This somehow seemed more manageable to me
> (notwithstanding the last 7 hours!).

everything2, from my limited exposure to it, is very very different from a
Wiki. I don't think you can edit the existing content, only add new ones
(thus an append-only kind of information repostitory). However I almost
guarantee you it runs on Mysql, which as we all know is the source of a
lot of Slashdot's problems ;-)

So is it better for you? Depends on what you are doing.


> What is the real benefit of moving the phpwiki to mysql, anyhow? Will
> it be faster than the default DBM system?

To answer that might start a holy war ;-)

But to be short and fair, there are advantages and disadvantages to all
three types (you left out flat file, which you might want to try).

RDBMS (mysql, pgsql etc): data integrity, data manipulation through a 4G
language (SQL), a simple interface to access the database through (its
API), portability, lots more. But it can be hard to set up and
administrate. This forms a large barrier to entry for a lot of people.

DBM (gdbm, ndbm, sdmb etc) are available on most Unix systems, Linux in
particular, so it was a good choice for the default database. However in
order to have the same set of features as we have for the Mysql version,
we have to write a lot more code to manipulate the data.

Flat file: This might be a better choice in the future for the default
setup, since we can probably get away with creating a directory in /tmp.
It will require even more coding than DBM though. Not a lot more maybe,
but still more. I don't know how portable the code would be (did I just
say that? I never used to care if it ran on Windows systems ;-)


> Margie-near-midnight, and smart enough to know that I should wait
> until a different day to try to actually upgrade my wiki, for fear of
> losing it all.

As always, backup, backup, backup. Don't upgrade your existing Wiki
either; set up a whole new one, with Mysql, then port the content over via
zip file. We'll tell you how to do that when you are ready. I think it's
also documented in the config.php file.

cheers
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

> I've got a perl script which at this point can parse the RecentChanges
> from UseMod and PhpWiki wikis.  Dave Jacoby has done this all before
> me, too, and has his own version...  (If you actually want RSS feeds
> from UseMod, Meatball or PhpWiki, let me know, I can put them
> someplace public...)

nah, it's of no real use to me until i can get it to work for me.  which
at this point either means writing a parser for moinmoin or hopefully
waiting for your changes to propagate into the main phpwiki src and
migrate to that.  updating all the wiki syntax is gonna suck.

> That's what I'm thinking, too...  Note that some RSS implementations
> can't deal with more than 15 entries, so that's sort of the default
> value...

good point, but there might be a time when you only want 5 ... or
something like that.

> Actually, I'm the one who started that page on MeatballWiki.  You're
> the first one who's shown much interest in it.

oh, cool.  sorry i musta mis-read the page.  yeah, i'm really interested
in this stuff.

> As an alternative, maybe there's a way to extend the plugin idea so
> that the plugin can read/write page (meta-)data.  Then one could
> implement a weblog plugin.  Yeah, in fact, that's kind of a neat
> idea...

this sounds cool, i think the plugin architecture will be very valuable
for all sorts of things in the long run.

i need to bust out my php book and get my hands dirty.  unfortunely
running personaltelco sucks up most of my spare time. :)  anyone else wish
they didn't have to sleep? :)

adam.

[Phpwiki-talk] Jeff's amazingly cool hacks...

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

Very very cool.

Preview - Perfect!  Really needed.
RSS - good idea, the number of PHPNuke/PostNuke/Slash/etc/etc sites that
could use that is huge. (Someone supposedly did a PHPWiki plugin/port for
PHPNuke, but I can't find it)

plugins - very neat.  Yes, the Calendar idea is a good one.  Can you use the
code that was recently submitted as a patch?

While you are it:
User validation/database?
Summary is a good idea, but it doesn't let you use WikiWords.
Locking some content on page, even if only at the top of the page.

Seth

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

> for the archives try this instead:
> 
> 	http://www.dairiki.org/rss1.0/hammondwiki.rdf

Yup.  Sorry.

> does meatball already support an rss feed of it's RecentChanges?  if not
> are you manually parsing it?

I've got a perl script which at this point can parse the RecentChanges
from UseMod and PhpWiki wikis.  Dave Jacoby has done this all before
me, too, and has his own version...  (If you actually want RSS feeds
from UseMod, Meatball or PhpWiki, let me know, I can put them someplace
public...)

>   http://personaltelco.net/index.cgi/RecentChanges?action=rss&num=10

That's what I'm thinking, too...  Note that some RSS implementations
can't deal with more than 15 entries, so that's sort of the default
value...

> in all the instances i can think of actually wanting to use it i would
> want the content exported as well eg. RecentChanges, CategoryXxxxx

Okay, then we're on the same page...

> as sunir suggested an extension to the rss spec to cater to wiki's
> might be do-able.

Actually, I'm the one who started that page on MeatballWiki.  You're the
first one who's shown much interest in it.

> it would be nice, i think, to be able to use a wike as an evolving story
> and have weblog style comments attached to it.

Yes.  I think Steve (Wainstead) has expressed interest in this idea as 
well.
I think the idea for how to hook this into the wiki is to introduce 
"page types"
--- the type of a page determines how it gets displayed (and edited).
Straightforward, I think, but I'm not going to work on it, at this 
point.

As an alternative, maybe there's a way to extend the plugin idea so that
the plugin can read/write page (meta-)data.  Then one could implement
a weblog plugin.  Yeah, in fact, that's kind of a neat idea...

Jeff

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

> When you say RDF/RSS output for _any_ wiki page, what exactly do you
> mean?

oh.  i forgot to include this.  one of my other thoughts for any page to
be an rss source was to to be able to use a wiki page as a source for the
new weblog story syndication standards which are evolving.

it would be nice, i think, to be able to use a wike as an evolving story
and have weblog style comments attached to it.

adam.

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

>  http://www.dairiki.org/hammondwiki.rdf

for the archives try this instead:

	http://www.dairiki.org/rss1.0/hammondwiki.rdf

> My main interest in RSS was to get a UnifiedRecentChanges index going.
> I've got a prototype sort of working, but have stopped working on it
> while I'm working on jeffs-hacks.

ah crap, i can't believe i didn't find this.  i've been wanting this
forever, and here i thought i was the only one.  doh.

>  http://matthews.dairiki.org/urc.html

does meatball already support an rss feed of it's RecentChanges?  if not
are you manually parsing it?

> When you say RDF/RSS output for _any_ wiki page, what exactly do you
> mean?

well my original thought had been that you'd do something like this (i'm
using moin syntax here cause i'm more familiar with it but you get the
idea):

  http://personaltelco.net/index.cgi/RecentChanges?action=rss&num=10

or something like that.  so that you could specify how many of the last
changes you wanted.  i have to apologise that i'm not hugely familiar with
rss/rdf/xml yet but i'm learning.

however if you're going to do that you may as well have any page be
capable of being exported this way.  this would be useful for my end goal
which is wiki/weblog integration.  now a category page exported as an rss
feed and become a slashbox.

> Do you want just the page meta-data (page name, author, edit date) or
> do you want all the content, too?  I've been thinking about that a
> bit.

in all the instances i can think of actually wanting to use it i would
want the content exported as well eg. RecentChanges, CategoryXxxxx

> I'm no expert, but it seems that RDF is ideally suited for the
> meta-data, but not really meant for storing the content.  (It seems
> some more general form of XML might be better suited for that.)

right but then we loose the main advantage of being able to munge wiki's
into rss feeds and slashboxes.  as sunir suggested an extension to the rss
spec to cater to wiki's might be do-able.

> The other problem with RDF, is that I suspect it's going to be awhile
> before a good full-blown RDF parser is available in PHP.  (Parsing RSS
> is one thing, parsing generic RDF is quite a bit trickier.)

i think we really want to shoehorn this into rss because the main point of
it is to leverage other software that's already out there.  unfortunately
i'm not entirely sure what the differences between rss and rdf are as i
search around for software for freshmeat rss and rdf seem to be used
interchangably.

> Of course, that syntax is already used in PhpWiki for ordered lists.
> It would have to be something uglier like:
>
> // please steal this comment

that'll work.  sorry for the moin-ism :)

adam.

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

On Sep 14, 2001, Adam Shand said:
> i think the easist way to do this (and i've mumbled about this before so
> excuse me if you're sick of it already :-) is to make a generic output
> mode for any wiki page which will output as rdf/rss and then a php rss/rdf
> parser to build side boxes for whatever from that.

Yes.  That may be the way to go, at least for RecentChanges, and
also perhaps various search outputs.  RSS RecentChanges have been
on my todo list for awhile.  (I've already hacked the PhpWiki 1.2.0
code which runs HammondWiki to produce an RSS version of recent 
changes.)
 http://www.dairiki.org/hammondwiki.rdf

My main interest in RSS was to get a UnifiedRecentChanges
index going.  I've got a prototype sort of working, but have
stopped working on it while I'm working on jeffs-hacks.
 http://matthews.dairiki.org/urc.html
 http://www.usemod.com/cgi-bin/mb.pl?UnifiedRecentChanges
 http://www.usemod.com/cgi-bin/mb.pl?RssExtensionModuleForWikis

When you say RDF/RSS output for _any_ wiki page, what exactly do you 
mean?
Do you want just the page meta-data (page name, author, edit date) or
do you want all the content, too?  I've been thinking about that a bit.
I'm no expert, but it seems that RDF is ideally suited for the 
meta-data,
but not really meant for storing the content.  (It seems some more 
general
form of XML might be better suited for that.)

The other problem with RDF, is that I suspect it's going to be awhile
before a good full-blown RDF parser is available in PHP.  (Parsing RSS
is one thing, parsing generic RDF is quite a bit trickier.)

> and then comments would just be:
> 
> # blah blah
> # please leave the below lines intact.

Of course, that syntax is already used in PhpWiki for ordered lists.
It would have to be something uglier like:

// please steal this comment

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

> To me, that seems like a lot of work (and complication) for not much
> gain. (And also fairly non-wiki-like.)  Note that, at this point, the
> LikePages plugin can be used to generate a list of Categories or
> Topics on the fly.

there are some good reasons and some fairly trivial reasons i want this:

 * it gives an easy way to track un-categorized pages (because by default
   they go into CategoryUncategorized or something).
 * it stops false positives if someone mentions a categories page without
   that page actually belonging to a category.
 * it stops people making typos when typing the category names.
 * it means that i can have a category keyword and put it elsewhere in the
   page where it's more visible/prettier etc.

> (And, I'm working on the ability to embed plugins within the
> templates, as well --- this would allow one to do fancy things like
> put a category index in a side-bar.)

oooh!  cool!  now how about recent changes as a side bar as well, and
recent changes and category pages as rdf for syndication to remote
weblogs and wiki sites?

i think the easist way to do this (and i've mumbled about this before so
excuse me if you're sick of it already :-) is to make a generic output
mode for any wiki page which will output as rdf/rss and then a php rss/rdf
parser to build side boxes for whatever from that.

> This is an interesting idea.  It would be easy enough to hack this
> into the transform code --- one just needs to settle on a good markup
> syntax for comments.  What kinds of things would you use this for?

i forget the exact thing i wanted it for, but mostly for notes to people
who are editing the page.  commets could also be an easy way to embed meta
data.

#category: documentation:hardware
#redirect: http://www.spack.org/
#redirect: WirelessCommunitites

and then comments would just be:

# blah blah
# please leave the below lines intact.

adam.

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

> this is great!

Thanks again, Adam.

> any chance of making categories meta data which is
> selected via drop box on the edit page?  and maybe a similar thing for
> sub-categories?  i know it kinda breaks the wiki ideal but i think it's
> going to become increasingly useful as wiki's increase in complexity.

To me, that seems like a lot of work (and complication) for not much 
gain.
(And also fairly non-wiki-like.)  Note that, at this point, the 
LikePages
plugin can be used to generate a list of Categories or Topics on the 
fly.
(And, I'm working on the ability to embed plugins within the templates,
as well --- this would allow one to do fancy things like put a category
index in a side-bar.)

> also are comments (ie. they show up in the edit box but not on the actual
> wiki page) a possibility?

This is an interesting idea.  It would be easy enough to hack this
into the transform code --- one just needs to settle on a good markup
syntax for comments.  What kinds of things would you use this for?

Jeff