phpwiki-talk

Re: [Phpwiki-talk] upgrading for new features?

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

On Sep 17, 2001, "Philip J. Hollenback" said:
>
> So are these two things available in the development version?  I know
> there is a patch available for tables, but has it been integrated?

The current CVS code does include the table mark-up.  It does not
include support for file uploads.

> Is the development version usable and stable?

It's usable now.  As for stable: it's about to go through a very large 
refactoring, involving big changes to the php code as well as 
the database schema.  So no, it's not stable, at least not for long.

Jeff

Re: [Phpwiki-talk] New jeffshacks snapshot.

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

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

probably a good point.

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

what about a semi-colon?  at least that is used for comments in somethings
so should be kinda intuitive.  or maybe two semi-colons?  otherwise it
doesn't really matter.

oh, and i thought of another good reason for category/sub-category
metadata.  in intranet environments (cause i'm working on getting a wiki
installed at work to replace our existing intranet).  if category
information is meta data then you could use it for governing permissions
to view/edit/etc a page, it also means it's easier to enforce some
structure on a wiki ... which i know is wiki ananthma :-) but it's also
really useful for some settings.

maybe you could have the drop box either be dynamically generated based
off page names (preserving traditional wiki anarchy), or it could have to
updated on a special page or config file (which would be great for more
structured environments).

anyway, just yell at me if you get sick of me spouting ideas and not
contributing anything. i'm working on it.

adam.

[Phpwiki-talk] Trouble Tickets, Wiki, groupware and nuke....

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

Ah ha, and here I was going to post a suggestion already....

I am getting ahold of a PHPwiki 'port' that works with PHPNuke/PostNuke.
I should have a copy of the code in a few days.  The author hasn't cleaned
it up, but he says it works. This would allow the use of a wiki module with
a Slashdot-ish environment.
This would fit some people's need for a more structured webspace, but still
have wiki elements.

I am also working with PHPgroupware, which is amazingly good with a firm
API.
PHPGroupware has trouble tickets, and much much more.  PHPGW is fast
becoming popular, and I for one, will be using it in a great many business
environments.

To port PHPWiki into a PHPGroupware module seems to make a great deal of
sense.
With Jeff's hack, a simple plugin would allow links back and forth I'd
suspect, with a minimum of problems or coding needed.  A PHPGroupware API
plugin would give all of the features of PHPgroupware to PHPWiki. (imagine
embedding a calendar or todo list).

This might also solve the user auth issues we are talking about.

Joe, if you are interested in, I suspect making PHPWiki into a PHPgroupware
module would give you troubletickets without having to recode a complete
trouble ticket system from scratch, and also all sorts of other possiblities
with the same codebase.  In other words, you'd be adding _far_ more than
troubletickets with less work.

I suspect we could find people on the other side of the coin, PHPGW coders
who would be interested in helping on this too.

links:
http://www.phpgroupware.org

also
http://www.phpnuke.com
http://www.postnuke.org


> 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.
> >

[Phpwiki-talk] upgrading for new features?

[Philip J. H. <ph...@ho...>]

I'm running a 1.2 phpwiki on my site, www.hollenback.net.  I am very
interested in upgrading to the develomment version for two reasons:

1. file uploads.  I want to be able to upload files (pictures) through
   the wiki and then use them in wiki pages.

2. tables.  I'm putting a lot of pictures in my wiki, and not having
   tables makes the layout very difficult.  Since this is a public
   site, I'm not going to turn on html in pages either.

So are these two things available in the development version?  I know
there is a patch available for tables, but has it been integrated?

Is the development version usable and stable?

I'm trying to determine if it is worthwile to upgrade at this point to
get the new features, or if I should wait and work with what I have
now.

Thanks,

P.

-- 
Philip J. Hollenback
ph...@po...
http://www.hollenback.net

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

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

> Hmm. As a serialized string? You might want to expand on this. I think the
> idea of them having a home page on the wiki is a natural.

The new database API allows (more-or-less) for arbitrary key/value pairs
to be attached to pages as meta-data.  This data is accessed via the
WikiDB_Page::get() and WikiDB_Page::set() methods.  (And yes, the 
implementation involves storing a serialized hash.)  So this is a real
quick-and-dirty place to store user meta-data if we establish a 
correspondence
between users and pages.

I'm thinking that pages which serve as user homepages would have
additional meta-data something like:

  is_homepage: 1
     password:  md5:12ef...
   user_email: <da...@da...>

This is data that would otherwise be stored in a separate user database
(e.g. /etc/passwd).


> Like I said, it just seems like a natural. I would use SteveWainstead or
> just 'wainstead' as an ID and would want my name to hyperlink to a page
> about me.

Yes, my main point of concern/confusion right now concerns the
following scenario:

  You attempt to register (via some automatic scheme, like the one
  you've outlined below) as a new user with the userid SteveWainstead.

  The page SteveWainstead already exists.

  What to do?  Should you be allowed to take over the existing page
  as your homepage?  (What if you were trying to register under the
  userid of FrontPage or CategoryNextWiki?)

(I guess this scenario addresses a more generic issue than that of just
user registration --- more that of page ownership.  Who should be 
allowed
to own/lock which (pre-existing) pages?)

> What I would really like to see added is user registration, where users
> must have a valid email address to register with the Wiki. This would be
> useful for a public wiki that only allows members to edit pages, and
> guests can only browse. In corporate intranets this would be essential.

Yes.  This is what has been in the back of mind (I think you planted
the seed there) for awhile now.   I keep hoping to find some
pre-written library which handles the details, but I don't think
were going to find one...

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

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

On Mon, 17 Sep 2001, Steve Wainstead wrote:

> What I would really like to see added is user registration, where users
> must have a valid email address to register with the Wiki. This would be
> useful for a public wiki that only allows members to edit pages, and
> guests can only browse. In corporate intranets this would be essential.

And then you could make it mangle email addresses if you weren't logged in
-- instant spam filtering!

Gary

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

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

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

On Mon, 17 Sep 2001, Jeff Dairiki wrote:

> 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.)

I think it's inevitable that we have append-only mode. It will have many
uses.

> 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.

Hmm. As a serialized string? You might want to expand on this. I think the
idea of them having a home page on the wiki is a natural.

> 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?

Like I said, it just seems like a natural. I would use SteveWainstead or
just 'wainstead' as an ID and would want my name to hyperlink to a page
about me.

What I would really like to see added is user registration, where users
must have a valid email address to register with the Wiki. This would be
useful for a public wiki that only allows members to edit pages, and
guests can only browse. In corporate intranets this would be essential.

~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] tab-width

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

On Mon, 17 Sep 2001, Jeff Dairiki wrote:

> 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.

Aha! OK, now I see what you mean. I thought you wanted to indent code with
tabs, which I still have serious misgivings about. tab-width=8 is
preferable, indeed, if we are using indent-tabs-mode=nil.

>
> 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.

Perfect. We are in agreement and everyone is happy. :-)

~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

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