phpwiki-talk

Re: [Phpwiki-talk] [patch] efficiency improvement

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

I just merged my PersonalWiki up to the head of the 1.2 branch. There's
quite a few changes; do you think it would be worth tagging and rolling a
1.2.1 release?

Gary

On Fri, 21 Sep 2001, Steve Wainstead wrote:

> Sure, it would be a convenience to users of 1.2.0.
>
> ~swain
>
> On Fri, 21 Sep 2001, Gary Benson wrote:
>
> >
> > On Fri, 21 Sep 2001, Steve Wainstead wrote:
> >
> > > Gary, could you post these to
> > > https://sourceforge.net/tracker/?group_id=6121&atid=306121
> > >
> > > That way they are more accessible... patches sometimes get truncated in
> > > the mail archive.
> >
> > Jeff committed them; do you still want them posting?
> >
> >
> > _______________________________________________
> > 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
>

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

Re: [Phpwiki-talk] [patch] efficiency improvement

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

Sure, it would be a convenience to users of 1.2.0.

~swain

On Fri, 21 Sep 2001, Gary Benson wrote:

>
> On Fri, 21 Sep 2001, Steve Wainstead wrote:
>
> > Gary, could you post these to
> > https://sourceforge.net/tracker/?group_id=6121&atid=306121
> >
> > That way they are more accessible... patches sometimes get truncated in
> > the mail archive.
>
> Jeff committed them; do you still want them posting?
>
>
> _______________________________________________
> 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] [patch] efficiency improvement

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

On Fri, 21 Sep 2001, Steve Wainstead wrote:

> Gary, could you post these to
> https://sourceforge.net/tracker/?group_id=6121&atid=306121
>
> That way they are more accessible... patches sometimes get truncated in
> the mail archive.

Jeff committed them; do you still want them posting?

Re: [Phpwiki-talk] [patch] efficiency improvement

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

Gary, could you post these to
https://sourceforge.net/tracker/?group_id=6121&atid=306121

That way they are more accessible... patches sometimes get truncated in
the mail archive.

thx!
~swain

On Fri, 21 Sep 2001, Gary Benson wrote:

>
> On Fri, 21 Sep 2001, Gary Benson wrote:
>
> > > > Any of you guys who are running a PhpWiki-1.2.0 site may benefit from this
> > > > patch, which should lower the load on your server. It removes an
> > > > "efficiency" thing which meant that the MostPopular list was generated on
> > > > every pageview.
> > >
> > > Hi Gary,
> > >
> > > Good catch!
> > >
> > > But... I think your patch makes the situation worse.
> > >
> > > > +      $tmpline = str_replace('%%Search%%', RenderQuickSearch(), $tmpline);
> > > > +      $tmpline = str_replace('%%Fullsearch%%', RenderFullSearch(), $tmpline);
> > > > +      $tmpline = str_replace('%%Mostpopular%%', RenderMostPopular(), $tmpline);
> > >
> > > I think this calls RenderMostPopular() once for every line in the
> > > page...
> > > I think the correct fix is something like:
> > >
> > >   if (strstr($tmpline, '%%Mostpopular%%'))
> > >       $tmpline = str_replace('%%Mostpopular%%', RenderMostPopular(),
> > > $tmpline);
> > >
> > > (Not that I've tested any of this or anything...)
> >
> > Doh!
> >
> > Expect a revised patch soonish...
>
> Try these two instead...
>

---
                  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] [patch] efficiency improvement

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

On Fri, 21 Sep 2001, Gary Benson wrote:

> > > Any of you guys who are running a PhpWiki-1.2.0 site may benefit from this
> > > patch, which should lower the load on your server. It removes an
> > > "efficiency" thing which meant that the MostPopular list was generated on
> > > every pageview.
> >
> > Hi Gary,
> >
> > Good catch!
> >
> > But... I think your patch makes the situation worse.
> >
> > > +      $tmpline = str_replace('%%Search%%', RenderQuickSearch(), $tmpline);
> > > +      $tmpline = str_replace('%%Fullsearch%%', RenderFullSearch(), $tmpline);
> > > +      $tmpline = str_replace('%%Mostpopular%%', RenderMostPopular(), $tmpline);
> >
> > I think this calls RenderMostPopular() once for every line in the
> > page...
> > I think the correct fix is something like:
> >
> >   if (strstr($tmpline, '%%Mostpopular%%'))
> >       $tmpline = str_replace('%%Mostpopular%%', RenderMostPopular(),
> > $tmpline);
> >
> > (Not that I've tested any of this or anything...)
>
> Doh!
>
> Expect a revised patch soonish...

Try these two instead...

[Phpwiki-talk] [patch] efficiency improvement

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

Hi all,

Any of you guys who are running a PhpWiki-1.2.0 site may benefit from this
patch, which should lower the load on your server. It removes an
"efficiency" thing which meant that the MostPopular list was generated on
every pageview.

Have fun,
Gary

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

[Phpwiki-talk] Re: WikiAsPim (was: User registration (was: PHPGW plugin))

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

> Adam, I'd love to hear your ideas about this. I was planning on making
> something to scrape the phonelist off our company intranet and make
> homepages for people on my PersonalWiki.

ramble alert ...

well i hate to say it but i don't really have any good ones either.  i
have my personal wiki (www.spack.org) where i store bits and it works
*brilliantly* for geek related stuff.  i can stuff articles in there,
technical docs etc.  it's way better saving emails or text files cause
it's inherantly hypertext and searchable and yet i keep all the advantages
of text caue it is text on the server (i don't use a sql backend).

but i want to take it to the next step.  i want to move my palm pilot
contact database to it.  my plan had been to stuff everything via ldiff
into an ldap server adn then find or write a php web frontend to it, but
the idea of being able to manipulate this data via a wiki is great, but
contact details are inherantly private and structured, i don't want to put
my mom's email or phone number up for anyone so it has to be private and
starts to deviate meaningfully (imho) from what wiki is all about.

so maybe each user would have a personal data subwiki, where they could
clutter up the wiki name space as much as they like.  with a bit of
tweaking international phone numbers (or email addresses) would make good
unique page identifiers, and ldap plugin could fairly trivially grab info
from an ldap server, format it, maybe even load it into text boxes so it
can be changed in a structured mannor via the wiki.  hell, maybe you could
even create another export function (like the rss/rdf that we've been
talking about) for ldiff for export to a palm pilot or ldap database.
even better maybe i can sync "my wiki" (or my section of the wiki) with my
palm pilot ... and i'd actually start using it for somethign other then
off site backups of my contact database again :)

what i'm wrestling with is "what is a wiki" and what is it that i want to
keep, and what i'm willing to sacrifice for greater functionality.

would there be anything gained by embedding a webmail (say squirrelmail
which is what i think phpgroupware uses) in a wiki page called WebMail.
you preserve the wiki interface to a certain point but what do you really
accomplish other then more overhead?

i think the marriage with phpgroupware could be quite valuable but i
really like the idea (jeff's?) of being able to maintain the wiki
interface to it, so instead of the wiki appearing inside groupware,
groupware elements appear inside the wiki.  however i have no idea how to
structure that so it's *easy* and convenient enough that people will use
it that way.

... ramble off ...

adam.

[Phpwiki-talk] WikiAsPim (was: User registration (was: PHPGW plugin))

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

On Fri, 21 Sep 2001, Adam Shand wrote:

> i've been thinking more about WikiAsPim and such things and it solves a
> lot of the issues i have with heirarchical datastorage.  the problem all
> comes down to how to do you continue to embrace the simplicity and
> inherent flexibility of a wiki and still provide access to multiple
> datasources (like maybe ldap for a contact database) in a useful way.
> everything comes down to ui ... and that's hard to solve.

Adam, I'd love to hear your ideas about this. I was planning on making
something to scrape the phonelist off our company intranet and make
homepages for people on my PersonalWiki.

Gary

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

Re: [Phpwiki-talk] Re: User registration (was: PHPGW plugin)

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

> I myself am running a Wiki with a lot of 'discussion' and feeling that
> Wiki might be the wrong medium for it.  Some users like the ability to
> edit, some don't. But it's haphazard and not very 'clean' to read.  A
> good discussion board would probably replace those sections of the
> Wiki. leaving the more Wiki aligned pages to grow.

i'd like to see the story as a wiki page where it can slowly be refactored
and evolve as comments and more information comes in, with weblog style
comments attached because i think most people are more comfortable
participating that way.

adam.

Re: [Phpwiki-talk] User registration (was: PHPGW plugin)

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

> The one thing that bothers me about many of these tools is the lack of
> capability for combined registration / authentication.  We need some
> kind of SQL based auth plugin that other packages can use optionally,
> (instead of their own built in auth table).  Ideally, the login ID
> used should be an email address, per Jacob Nielson's suggestion,
> because it's guaranteed to be unique, and easy to remember.
>
> Does anyone know of a project that is addressing this?  If not,
> perhaps we can think about it for the new auth features of PhpWiki?

i think the stuff that drupal is doing is really cool and would be great
if phpwiki supported it.  drupal's also written in php so their may even
be code that we can rip off to do it.

	http://www.drop.org/node.php?id=531

it's overkill for what phpwiki needs, but if you want some sort of
centralized naming system this is what will hopefully be the "passport
killer" (ahhh, dreams).

the tricky bit is that it's not designed for wiki's and how do you
translate an email adress login name to a HomePage (eg. AdamShand) where
we're talking about storing user data.

i've been thinking more about WikiAsPim and such things and it solves a
lot of the issues i have with heirarchical datastorage.  the problem all
comes down to how to do you continue to embrace the simplicity and
inherent flexibility of a wiki and still provide access to multiple
datasources (like maybe ldap for a contact database) in a useful way.
everything comes down to ui ... and that's hard to solve.

adam.

[Phpwiki-talk] Re: User registration (was: PHPGW plugin)

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

> > Will do.  I think the PHP triad of Wiki/Nuke/Groupware will be a
> > killer combo.

> The one thing that bothers me about many of these tools is the lack of
> capability for combined registration / authentication.

The Wiki module that Olle wrote uses the existing Nuke login.
If not logged in, it's 'anonymous user' (settable), and he's going to
implement
the suggestion that if desired, you must login to edit.  Once logged in, it
uses your Nuke login as your userid, so I created a SethCohn login, and
it worked fine under RecentChanges.

> We need some
> kind of SQL based auth plugin that other packages can use optionally,
> (instead of their own built in auth table).  Ideally, the login ID
> used should be an email address, per Jacob Nielson's suggestion,
> because it's guaranteed to be unique, and easy to remember.

Doesn't need to nearly be so complex or reinvent the wheel.
Nuke works fine, and if you wanted to make Wiki a major part,
you could always add a check for WikiWord status
if you desired that.  (Nuke already checks for all sorts of things, like no
God/Root/Admin types names...)

If you want make something interoperable, look at how Nuke or GW do it, and
implement a similar scheme, so that an admin merely has to point the engine
to
the same database and it'll read the same users.

> Does anyone know of a project that is addressing this?  If not,
> perhaps we can think about it for the new auth features of PhpWiki?

I think it's already in the works with Jeff's recent cvs changes.

> Another fairly polished piece of php/MySQL code is phpBB, which I just
> installed for another site, and of course has its own auth system too.
> http://phpbb.com

This has been ported/modulized for Nuke.  It's a popular Nuke addon.
Thanks for pointing another case of the convergence.

I myself am running a Wiki with a lot of 'discussion' and feeling that Wiki
might be
the wrong medium for it.  Some users like the ability to edit, some don't.
But it's haphazard and not very 'clean' to read.  A good discussion board
would probably replace those sections of the Wiki. leaving the more Wiki
aligned pages to grow.

[Phpwiki-talk] User registration (was: PHPGW plugin)

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

On Thu, Sep 20, 2001 at 03:09:02PM -0700, Seth Cohn wrote:
> > can you keep us posted on your progress?
> 
> Will do.  I think the PHP triad of Wiki/Nuke/Groupware will be a
> killer combo.

Yeah, I've been moving in this direction too.  (I'm using Wiki
actively, have Groupware installed, and might install Nuke shortly.)

The one thing that bothers me about many of these tools is the lack of
capability for combined registration / authentication.  We need some
kind of SQL based auth plugin that other packages can use optionally,
(instead of their own built in auth table).  Ideally, the login ID
used should be an email address, per Jacob Nielson's suggestion,
because it's guaranteed to be unique, and easy to remember.

Does anyone know of a project that is addressing this?  If not,
perhaps we can think about it for the new auth features of PhpWiki?

> With it, you will have a complete intranet solution, and also a great
> community forum.

Another fairly polished piece of php/MySQL code is phpBB, which I just
installed for another site, and of course has its own auth system too.
http://phpbb.com

I think that kind of forum is useful for sites that don't want to make
their home page a rolling weblog of articles and discussion like
Nuke/K5/Slashdot.  (Instead, they can setup a dedicated discussion
area covering persistent topics of their choice...)

-jeb

Re: [Phpwiki-talk] DEFINITION: Ticket Tracking

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

Jeff Dairiki schrieb:
> Currently this is done using ExtractWikiPageLinks(), but I think we
> should eliminate that function and just use the transform code to find
> the links --- it eliminate duplicated code, and eliminates the
> opportunities for inconsistency regarding what is a link and what's
> not.)

Yes. ExtractWikiPageLinks() falsely stores external Interwiki links 
(the part before the ':' and the part after the ':') as pages.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] PHPGW plugin

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

> can you keep us posted on your progress?

Will do.  I think the PHP triad of Wiki/Nuke/Groupware will be a killer
combo.
With it, you will have a complete intranet solution, and also a great
community forum.

> i'm pretty entusiastic about all
> this.  i got sucked into the c2 wiki from the reference to wiki badges and
> started reading about the WikiPalm and WikiAsPim pages ... this is what i
> want ... i want it soooo bad. :)

Yeah, I have been telling people that Wiki is the next step.  I see more
Wikis springing up lately.  I think the Wiki idea is reaching critical mass.

Seth

[Phpwiki-talk] Testing code available

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

Hello,

The folks at my last job were very kind in turning over to me the rights
to a little testing system I wrote for them. I've added it to the 1.3
branch.

It consists of two Perl scripts; one generates a Makefile and a build.xml
file, the other generates Java source files based on input scripts.

To use this testing software, you need Java (java + javac), Perl, Ant
(from http://jakarta.apache.org/ant/) and httpunit (from
http://httpunit.sourceforge.net/).

Ant has to be in your PATH, and the three jar files in httpunit have to be
in your CLASSPATH.

The idea behind this is you can run a set of automated tests against the
Wiki as you do development. That way you can readily see if your code
changes broke anything. I will be adding some more tests, probably today,
and committing a few tutorial pages to pgsrc/ to show how to use it.

Hopefully, once you have Ant and httpunit set up, you will have to do very
little to run tests outside of:

cd tests/
./makemakebuild.pl
ant

and a whole bunch of tests will run against PhpWiki.

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] PHPGW plugin

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

> Speaking of modules, I have the PHPWiki module for Php/PostNuke
> running.  It IS embedded into the Nuke, and it looks great.  The
> author, Olle Johansson, is looking into making a few changes based on
> feedback from myself and Andy Burham, including porting the code to
> 1.3 (it's 1.1.8 right now).  Between plugins and RSS, it should be
> possible to make the Wiki work really well with Nuke...

can you keep us posted on your progress?  i'm pretty entusiastic about all
this.  i got sucked into the c2 wiki from the reference to wiki badges and
started reading about the WikiPalm and WikiAsPim pages ... this is what i
want ... i want it soooo bad. :)

adam.

[Phpwiki-talk] PHPGW plugin

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

> 3. Seth Cohn writes that phpGroupWare has a nice ticket tracking system.
>    It does.  But phpGroupWare is *big* and one of the nicest things about
>    phpWiki is that it's still pretty simple and small.  So here's what I
>    will do: I will create a small, one page ticket tracker that can be
>    distributed with phpWiki and that uses its own database table, but I
>    will also include glue so that phpWiki can optionally call out to the
>    PHPGW API instead, so that if you already happen to be using PHPGW,
>    phpWiki will register tickets in it.  I've looked at the API, and this
>    shouldn't be too hard.

very cool.

I agree with the others, that just for a ticket tracker, WikiBadges would
work,
on a small scale.

The nice thing about doing a PHPGW plugin would be the multiple uses.
With a consistent API, adding ToDos, Calendar, Tickets, and dozens of other
features
would be easy.  For instance, let's say a cool module for PHPGW comes out
that does
double entry accounting.  Instead of Wiki having to add a new plugin, the
existing
plugin just passes the right API commands, and bingo, you get a nice Ledger
page
in the Wiki, right in your discussion of whatever the ledger is about.

>    I'm not, however, going to do the work to "embed" phpWiki into a PHPGW
>    module.  I have little interest in forcing the wiki into an even
smaller
>    box on my browser window, surrounded by even more buttons and menus.

No, I am not suggesting that.  The beauty of the plugin is that you could
have some users
using a standalone wiki, and it would handle the PHPGW stuff itself.

Speaking of modules, I have the PHPWiki module for Php/PostNuke running.  It
IS embedded into the Nuke, and it looks great.  The author, Olle Johansson,
is looking into making a few changes based on feedback from myself and Andy
Burham, including porting the code to 1.3 (it's 1.1.8 right now).  Between
plugins and RSS, it should be possible to make the Wiki work really well
with Nuke...

Seth

Re: [Phpwiki-talk] alpha site down.

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

> Thanks for the report.  I think it's fixed now.

yep, it came up, went down and came up again.  looks great now.  thanks.

adam.

Re: [Phpwiki-talk] alpha site down.

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

> Parse error: parse error in...

Thanks for the report.  I think it's fixed now.

[Phpwiki-talk] alpha site down.

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

http://phpwiki.sourceforge.net/alpha/

Parse error: parse error in /home/groups/p/ph/phpwiki/htdocs/alpha/lib/WikiDB/backend/PearDB.php on line 4
Fatal error: Class wikidb_backend_mysql: Cannot inherit from undefined class wikidb_backend_peardb in /home/groups/p/ph/phpwiki/htdocs/alpha/lib/WikiDB/backend/mysql.php on line 7

Re: [Phpwiki-talk] DEFINITION: Ticket Tracking

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

thanks to the pointer to wiki badges, i hadn't foudn that yet on c2.

> This gives you most of the functionality you want without any new
> code.  I guess the main thing you don't get is any sort of per ticket
> history: ticket creator/author, creation time, closed tickets (though
> you could use something like TicketApproveClosed (or TicketApproved ?)
> to keep track of closed tickets)...

this could almost be done with the same mechanism as a weblog.  both want
a mechanism for a tag to create sub pages.  for the weblog you want the
story blurb to create a story page.  here you want the ticket to create
the ticket history.  my main complaint with this idea is that having all
these pages automatically created seems like ti would clutter the wiki
name space a lot so maybe isolating them in a sub-wiki (or something)
would help?

----

side note, i got this from twiki today and the main new features in the
big new release is plugins.  i thought this was a perfect opportunity to
steal some ideas :-)

ALL-NEW PLUG-INS FEATURE

Check out the initial set of Plugins, like SessionPlugin, SmiliesPlugin,
SpreadSheetPlugin, TOCPlugin and more, at
http://twiki.org/cgi-bin/view/Plugins/WebHome. The new Plugins web is
already quite filled out, and building up steadily. Stay tuned.

Developers, you're encouraged to write your own Plugins and contribute
back to the TWiki community. Our goal is to establish Plugins as the
foundation of a powerful, versatile collaboration platform.

adam.

Re: [Phpwiki-talk] DEFINITION: Ticket Tracking

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

Just to ramble some more on the topic:

The ticket idea is, I think, closer to the concept of WikiBadges
than Categories. See http://c2.com/cgi/wiki?WikiBadge.
Of course, on a traditional wiki, the implementation of WikiBadges is
identical to that of Categories...


In the latest PhpWiki, plugins can be used to generate in-line lists
of Badges/Categories/Tickets.  <?plugin BackLinks page=TicketApprove?>
will generate a list of all pages which link to TicketApprove.
You can use this to write a ticket index page which will list all
ticketed pages (or certain subsets of them).
(If you wanted, you could write a custom plugin to perform
specialized smart ticket searches...)

This gives you most of the functionality you want without any new
code.  I guess the main thing you don't get is any sort of per ticket
history: ticket creator/author, creation time, closed tickets
(though you could use something like TicketApproveClosed (or 
TicketApproved ?) to keep track of closed tickets)...


A few more comments:

> ((rewrite)) ((check)) ((fixme))

These  correspond pretty much exactly to traditional WikiBadges....

> NOTES AS TO IMPLEMENTATION
>
> 2. The logical time to create/open/close tickets is when the page
>    containing them (or from which they have been deleted) is first saved.
>    Right now the only parsing of page text on save is for converting tabs.
>    This is in savepage.php.

When a new page is saved, it gets parsed for WikiLinks.  (This is 
necessary
to properly update the link table which is used to find BackLinks, 
etc...)
Currently this is done using ExtractWikiPageLinks(), but I think we
should eliminate that function and just use the transform code to find
the links --- it eliminate duplicated code, and eliminates the
opportunities for inconsistency regarding what is a link and what's 
not.)

The tab conversion stuff is obsolete, and should probably be deleted at 
this
point.  (I have already taken the checkbox off the editpage template, so
without some hackage, the tab conversion code never gets invoked.)

Jeff

Re: [Phpwiki-talk] DEFINITION: Ticket Tracking

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

Hi Joe, thanks so much for outlining the whole idea!

I have a question. Are you familiar with the "Category" and "Topic"
conventions used on some Wikis? I think this might work for you. Let me
outline it.

A set of pages in a Wiki that are of a particular category will get a
link placed at the bottom of the page:

CategoryStarTrek

When you go to CategoryStarTrek, the page will describe that category;
by clicking on the page title you will see a list of all pages
belonging to that Category. We use this on SourceForge:

http://phpwiki.sourceforge.net/phpwiki/index.php?CategoryNextWiki

For a ticket tracking system, you could just create a page for a
problem (TicketCallBob, TicketFinanceApprove) and put CategoryTicket
at the bottom (or better yet, CategoryTicketOpen, which could become
CategoryTicketClosed when done).

This is simplistic but places all the responsibility for organizing
the data on the users. (Which is the Wiki Way, apparently).

For a very small organization this might be suitable. Your approach makes
the machine do much more of the work.

~swain

On Wed, 19 Sep 2001, Joe Edelman wrote:

> Hello everyone.
>
> "Ticket tracking" is like a to-do list for a group of people, or for many
> groups of people.  The phpwiki to-do list on sourceforge is a kind of
> ticket tracker, as are bug trackers like the ones on sourceforge or
> "Bugzilla".  Help desks and call centers often use ticket tracking systems
> to keep track of who they've helped and who else needs help.
>
> Generally a ticket corresponds to some task that needs doing or something
> that needs attention-- a disk that needs to be backed up, or a customer who
> needs to be called back, or a report that needs to be looked over and
> signed by a manager. Tickets begin their lives "open", and when the task is
> completed, they are "closed".  Generally tickets contain some more state
> than just that: they may know what kind of skills are necessary for their
> completion, and they have a log of who has done work towards that ticket
> and any comments they left.  Anyone can log in to the ticket tracking
> system and see, with one search, which "open" (not-yet-completed) tickets
> (tasks) there are for people with their expertise.
>
> What I'm proposing is to add some new syntax to phpWiki pages that
> integrate them into a ticket tracking system, so that if someone writes
> text like "((finance:approve))" in their wiki page-- which means that they
> want someone from the finance department to approve what they've written on
> the page-- then a new ticket will be created which says just that.  If ever
> someone from finance edits the page and removes that text
> ("((finance:approve))"), the ticket is closed.
>
> Other tickets might look like:
>
>         ((sales:rewrite))
>         ((CEO:approve))
>         ((george:explain))
>
> Or, if you're a small company or just a single person, you can use this
> system for reminders for yourself about where in your phpwiki you would
> like some additional information, or what you would like to rewrite, using
> the shorter form:
>
>         ((rewrite))
>         ((check))
>         ((fixme))
>
> And then from one page, the ticket tracking page, you get links to every
> wiki page that needs some work, and you can search or sort through these
> wiki pages based on what kind of expertise they need (sales/CEO/george) or
> what needs to be done (rewrite/approve/explain/check), or when they were
> last worked on, or who entered the request, etc.
>
>
> NOTES AS TO IMPLEMENTATION
>
> 1. It's clear that this feature wouldn't be of use to everyone, and the
>    phpwiki syntax-space is already getting kind of cluttered.  It would be
>    nice, and fairly easy, to be able to turn syntax elements, including
>    ticket recognition ("(())"), on and off.  So maybe a global ("define()")
>    in the index.php file would turn this whole system on and off, and it
>    would be off by default.
>
> 2. The logical time to create/open/close tickets is when the page
>    containing them (or from which they have been deleted) is first saved.
>    Right now the only parsing of page text on save is for converting tabs.
>    This is in savepage.php.  I would have to add something, either there or
>    in WikiDB_PageRevision::createRevision(), that checks for occurrences of
>    the syntax and called out to the ticket functions is they are found.
>
> 3. Seth Cohn writes that phpGroupWare has a nice ticket tracking system.
>    It does.  But phpGroupWare is *big* and one of the nicest things about
>    phpWiki is that it's still pretty simple and small.  So here's what I
>    will do: I will create a small, one page ticket tracker that can be
>    distributed with phpWiki and that uses its own database table, but I
>    will also include glue so that phpWiki can optionally call out to the
>    PHPGW API instead, so that if you already happen to be using PHPGW,
>    phpWiki will register tickets in it.  I've looked at the API, and this
>    shouldn't be too hard.
>
>    I'm not, however, going to do the work to "embed" phpWiki into a PHPGW
>    module.  I have little interest in forcing the wiki into an even smaller
>    box on my browser window, surrounded by even more buttons and menus.
>
> That's all for now.  There are a lot of design decisions I haven't made yet.
> I'll post a summary asking the groups opinion on a number of possibilities
> in the next day or so.
>
> Thanks,
>
>         Joe
>         http://orbis-tertius.net/joe/
>
> _______________________________________________
> 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

[Phpwiki-talk] DEFINITION: Ticket Tracking

[<jo...@or...>]

Hello everyone.

"Ticket tracking" is like a to-do list for a group of people, or for many
groups of people.  The phpwiki to-do list on sourceforge is a kind of
ticket tracker, as are bug trackers like the ones on sourceforge or
"Bugzilla".  Help desks and call centers often use ticket tracking systems
to keep track of who they've helped and who else needs help.

Generally a ticket corresponds to some task that needs doing or something
that needs attention-- a disk that needs to be backed up, or a customer who
needs to be called back, or a report that needs to be looked over and
signed by a manager. Tickets begin their lives "open", and when the task is
completed, they are "closed".  Generally tickets contain some more state
than just that: they may know what kind of skills are necessary for their
completion, and they have a log of who has done work towards that ticket
and any comments they left.  Anyone can log in to the ticket tracking
system and see, with one search, which "open" (not-yet-completed) tickets
(tasks) there are for people with their expertise.

What I'm proposing is to add some new syntax to phpWiki pages that
integrate them into a ticket tracking system, so that if someone writes
text like "((finance:approve))" in their wiki page-- which means that they
want someone from the finance department to approve what they've written on
the page-- then a new ticket will be created which says just that.  If ever
someone from finance edits the page and removes that text
("((finance:approve))"), the ticket is closed.

Other tickets might look like:

        ((sales:rewrite))
        ((CEO:approve))
        ((george:explain))

Or, if you're a small company or just a single person, you can use this
system for reminders for yourself about where in your phpwiki you would
like some additional information, or what you would like to rewrite, using
the shorter form:

        ((rewrite))
        ((check))
        ((fixme))

And then from one page, the ticket tracking page, you get links to every
wiki page that needs some work, and you can search or sort through these
wiki pages based on what kind of expertise they need (sales/CEO/george) or
what needs to be done (rewrite/approve/explain/check), or when they were
last worked on, or who entered the request, etc.


NOTES AS TO IMPLEMENTATION

1. It's clear that this feature wouldn't be of use to everyone, and the
   phpwiki syntax-space is already getting kind of cluttered.  It would be
   nice, and fairly easy, to be able to turn syntax elements, including
   ticket recognition ("(())"), on and off.  So maybe a global ("define()")
   in the index.php file would turn this whole system on and off, and it
   would be off by default.

2. The logical time to create/open/close tickets is when the page
   containing them (or from which they have been deleted) is first saved.
   Right now the only parsing of page text on save is for converting tabs.
   This is in savepage.php.  I would have to add something, either there or
   in WikiDB_PageRevision::createRevision(), that checks for occurrences of
   the syntax and called out to the ticket functions is they are found.

3. Seth Cohn writes that phpGroupWare has a nice ticket tracking system.
   It does.  But phpGroupWare is *big* and one of the nicest things about
   phpWiki is that it's still pretty simple and small.  So here's what I
   will do: I will create a small, one page ticket tracker that can be
   distributed with phpWiki and that uses its own database table, but I
   will also include glue so that phpWiki can optionally call out to the
   PHPGW API instead, so that if you already happen to be using PHPGW,
   phpWiki will register tickets in it.  I've looked at the API, and this
   shouldn't be too hard.

   I'm not, however, going to do the work to "embed" phpWiki into a PHPGW
   module.  I have little interest in forcing the wiki into an even smaller
   box on my browser window, surrounded by even more buttons and menus.

That's all for now.  There are a lot of design decisions I haven't made yet.
I'll post a summary asking the groups opinion on a number of possibilities
in the next day or so.

Thanks,

        Joe
        http://orbis-tertius.net/joe/

[Phpwiki-talk] bug report.

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

i've just updated the site with css reports for all the browers i have
access to (just put them on the release notes page, maybe you want to
refactor that to somewhere else?).  over all it looks fine on all the
browers i tried though obviously there are some slight differences
(unsurprisingly netcape 4.77 was the worst).

one bug i've noticed is that if you log in and then surf around and then
back up to the point where you first logged in, it just logs you out.
this bit me a couple of times until i realised what i'd done.  once you've
logged in it shouldn't matter if you hit back in the brower, it should
still know who you are.

on some browsers as soon as you hit back and go past that login point, you
get the user/pass prompt again.  others just silently log you out.

adam.