phpwiki-talk

Re: [Phpwiki-talk] CreateToc.php

[Reini U. <rei...@gm...>]

I'm out of my office for the next week.
What's the diff to my fixes last week in CVS? (cvs diff -bu CreateToc.php)
I thought it's complete now.

On 10/18/05, Stefan <son...@ba...> wrote:
> Here is a new Version of CreateToc.php with some little Bug fixes.
> Headline Links will now work better ...
>
> Maybe usefull for someone
--
Reini Urban

Re: [Phpwiki-talk] PATCH: local connection to pgsql

[strk <st...@ke...>]

On Tue, Oct 18, 2005 at 12:02:00PM +0200, Joel Uckelman wrote:
> Thus spake strk:
> > Hello, I've patched the lib/pgsql.php script
> > to allow for local (socket-based) connections.
> > 
> > Required change is at line 45 of that file:
> > 
> >       if ( defined($pg_dbhost) && $pg_dbhost != "" ) $connectstring = $pg_dbh
> > ost?"host=$pg_dbhost ":"";
> > 
> > This way you can set pg_dbhost to the empty string and the socket
> > will be used.
> 
> So this is against the 1.2 branch? I think that now we're only fixing
> bugs and security problems in the 1.2 branch.

Ehmm.. yes. 1.2.10.
I'd see it as a bug, BTW... the same check can be applied to
other parameters as well, an empty connect string is valid and
would use default paremeters (very useful for migrations).

> If you have a look at the config.ini for the current release (1.3.11p1),
> (you can see an example in CVS here: http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/config/config-dist.ini?rev=1.59&view=markup), you'll see in Part
> Two how to connect to the database via a socket.

Urgh... a complete change in config files ? :(
Thanks for pointing out, anyway,
and thanks for making phpwiki available :)

--strk;

Re: [Phpwiki-talk] PATCH: local connection to pgsql

[Joel U. <uck...@no...>]

Thus spake strk:
> Hello, I've patched the lib/pgsql.php script
> to allow for local (socket-based) connections.
> 
> Required change is at line 45 of that file:
> 
>       if ( defined($pg_dbhost) && $pg_dbhost != "" ) $connectstring = $pg_dbh
> ost?"host=$pg_dbhost ":"";
> 
> This way you can set pg_dbhost to the empty string and the socket
> will be used.

So this is against the 1.2 branch? I think that now we're only fixing
bugs and security problems in the 1.2 branch.

If you have a look at the config.ini for the current release (1.3.11p1),
(you can see an example in CVS here: http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/config/config-dist.ini?rev=1.59&view=markup), you'll see in Part
Two how to connect to the database via a socket.

-- 
J.

[Phpwiki-talk] CreateToc.php

[Stefan <son...@ba...>]

Here is a new Version of CreateToc.php with some little Bug fixes. 
Headline Links will now work better ...

Maybe usefull for someone

[Phpwiki-talk] bug: admin.php

[AI <ai...@gm...>]

I have to add &PHP_AUTH_USER=3Dmyusername&PHP_AUTH_PW=3Dmypassword
to the address bar to get into admin.php, and then copy the link to
the address bar with this behind it. Edits from inside admin.php won't
work, since I can't copy submit buttons to the address bar.

[Phpwiki-talk] PATCH: local connection to pgsql

[strk <st...@ke...>]

Hello, I've patched the lib/pgsql.php script
to allow for local (socket-based) connections.

Required change is at line 45 of that file:

      if ( defined($pg_dbhost) && $pg_dbhost != "" ) $connectstring = $pg_dbhost?"host=$pg_dbhost ":"";

This way you can set pg_dbhost to the empty string and the socket
will be used.

--strk;

Re: [Phpwiki-talk] creating new pages with mysql

[Reini U. <rei...@gm...>]

I cannot really help right now, because I'm away
and can only help with tips out of my head.

On 10/16/05, Joel Uckelman <uck...@no...> wrote:
> Thus spake Geoff Dougherty:
> > I'm running 1.2 and mysql, and I need to pull page
> > content from a non-phpwiki database and create new
> > phpwiki pages containing the same content.
> >
> > I've uploaded some test content to the wiki table in
> > the database, and updated the wikilinks table to
> > reflect the new content (i.e., INSERT INTO
> > wikilink(frompage,topage,) VALUES
> > ('RecentChanges,'MyNewContentPage')
> >
> > I've confirmed that the tables hold the new stories
> > and links, but they're not showing up in
> > RecentChanges, or any of the other pages I've tried to
> > link the content to.
> >
> > What else do I need to change to make sure the new
> > content is displayed?

Look at the admin/*.php pages for actions to import content.
And if this fails put your non-sql pages into pgsrc like files
(header can be omitted, just plain-text() and fire up a new wiki
(DELETE FROM wikipages ?) with this pgsrc. This would  be the easiest.

> I'm looking back at the table structure for 1.2, and I'm not seeing
> any obvious thing to do. Are the new pages accessible directly?
--
Reini Urban

Re: [Phpwiki-talk] RSS

[Reini U. <rei...@gm...>]

Hi Walter,
[I'm just in Vienna at the Viennale, BTW]

Sure it is possible. It's even on my plan for 1.3.12,
together with the other blog-like services: TalkBack and PingBack.
RSS and ATOM for the latest blog entries (plugin BlogJournal) is the easies=
t.

The starting points would be RecentChanges and XmlRpcServer.


On 10/17/05, Walter Rafelsberger <wa...@ra...> wrote:
> I was wondering if it's possible to adjust the phpwiki-rss-solution
> for other purposes.
> The RSS-Feed via RecentChanges is great, but I'm looking for a
> solution to create a Feed which has more "Blog-Style".
> For example an RSS-Feed generated from WikiBlogPlugin or from
> UnfoldSubPages which contains not just a summary but the actual page
> content also.
> I had no time yet to have a look into the code and will have none
> until november. I would be thankful for any starting hints.
--
Reini Urban

[Phpwiki-talk] RSS

[Walter R. <wa...@ra...>]

Hello,

I was wondering if it's possible to adjust the phpwiki-rss-solution  
for other purposes.
The RSS-Feed via RecentChanges is great, but I'm looking for a  
solution to create a Feed which has more "Blog-Style".
For example an RSS-Feed generated from WikiBlogPlugin or from  
UnfoldSubPages which contains not just a summary but the actual page  
content also.
I had no time yet to have a look into the code and will have none  
until november. I would be thankful for any starting hints.

kind regards,
Walter Rafelsberger



--

| Contact.
|
| email
| wa...@ra...
|
| web
| www.rafelsberger.at
|

Re: [Phpwiki-talk] css classes, ids in markup

[John K. <jo...@ke...>]

At 19:12 +0200 16/10/05, Joel Uckelman wrote:
>So, what I'm suggesting is:
>
>1. Extending the markup syntax to permit classes and ids, perhaps like this:
>
>markupelement{class1 class2... #id}
>
>so that you could do this with any markup element you wanted, say
>
>!!!{enormous orangebox #title} A Gigantic Orange-Boxed Title
>
>2. Providing an easy interface for adding new markup, as Reini suggested in
>his response higher up in this thread.
>
>3. Making a div and span markup plugin which uses 2 and can be turned on
>from the config.ini.
>
>4. Making a plugin which reads wiki pages for user-generated css, which can
>be turned on from the config.ini and used in conjunction with 1-3.
>
>Comments?

Wow - that would be excellent :)

One suggestion I'd add would be the option to define styles on the 
fly, maybe using "..." eg

!!!{enormous orangebox "margin:2em; border:3px solid red;" #title} A 
Gigantic Orange-Boxed Title with a solid red border and 2ems of space 
around it

partly for handling one-off situations that don't warrant knocking up 
a separate class, partly for 'mucking around' with some formatting 
(wiki-style tweaking) til you get it just right, at which point you 
may or may not 'solidify' that style info into a class. This is how 
new styles end up being arrived at in the real world.

In the mean-time, what tentative steps would I have to take to figure 
out what mods I've added to my existing twenty or so 1.3.0 wikis (not 
all of which have needed all the mods I've added - eek!) and how to 
begin the (enormous) task of upgrading them to phpwiki 
1.3.whatever-we're-at? I'm guessing something to do with diff & patch 
(which are to me like distant cousins - I've heard of them but 
they're not exactly familiar). Can I still download a clean copy of 
1.3.0 from somewhere to diff against one of my current wikis? Anyone 
want to help me (off-list) with diff commands and such?

John.
-- 
-------------------------------------------------------------------
T:01274 581519 / M:07944 755613   www.kershaw.org  jo...@ke...
skype:johnmkershaw  AIM:johnkershaw  MSN:joh...@ho...

Re: [Phpwiki-talk] css classes, ids in markup

[Joel U. <uck...@no...>]

Thus spake Matt Brown:
> 
> I'm still vaguely uncomfortable with the idea of allowing users to add
> arbitrary classes to objects. I can't pinpoint exactly why though. I
> guess it's the whole trade off between flexibility and correctness. If
> you let users define arbitrary classes/ids you can bet it's going to be
> misused quicker than you can blink your eye. I'm not sure that that is a
> strong argument against your proposal though... just thinking aloud
> here.

That was my initial response as well, but I'm not convinced that it's
warranted. Even in the case where users can define arbitrary classes
and ids, it's still all style information. It's not like it's executable
code. On the other hand, we'd have to be careful about users stepping
on ids and classes used by the Wiki itself.

> Could it be split into two parts?
> - Some extra syntactical features to define some commonly used page
> elements 
>
> - An extra plugin that when included allows precise specification of
> class names / ids for attributes.
>

Splitting is good. I think that what we're facing here is the intersection
of two useful features, viz.:

1. the ability of the user to specify style information in the wiki text
2. the ability to the admin to extend the wiki markup on a per-site basis

What Reini was talking about was the second, what I was initially thinking
of is the first, and what John was talking about is a combination of these two.

So, what I'm suggesting is:

1. Extending the markup syntax to permit classes and ids, perhaps like this:

markupelement{class1 class2... #id}

so that you could do this with any markup element you wanted, say

!!!{enormous orangebox #title} A Gigantic Orange-Boxed Title

2. Providing an easy interface for adding new markup, as Reini suggested in
his response higher up in this thread.

3. Making a div and span markup plugin which uses 2 and can be turned on
from the config.ini.

4. Making a plugin which reads wiki pages for user-generated css, which can
be turned on from the config.ini and used in conjunction with 1-3.

Comments?

-- 
J.

Re: [Phpwiki-talk] css classes, ids in markup

[Joel U. <uck...@el...>]

Thus spake Matt Brown:
> 
> I think this goes for much of PHPwiki at the moment. There are heaps and
> heaps of features that are not used for many wikis and having them in
> the default installation makes it much more complex to maintain a
> PHPwiki installation. Breaking them out into plugins would make PHPwiki
> vastly superior. 
> 

Have you singled out some features in particular?

-- 
J.

Re: [Phpwiki-talk] creating new pages with mysql

[Joel U. <uck...@no...>]

Thus spake Geoff Dougherty:
> Hi. 
> 
> I'm running 1.2 and mysql, and I need to pull page
> content from a non-phpwiki database and create new
> phpwiki pages containing the same content. 
> 
> I've uploaded some test content to the wiki table in
> the database, and updated the wikilinks table to
> reflect the new content (i.e., INSERT INTO
> wikilink(frompage,topage,) VALUES
> ('RecentChanges,'MyNewContentPage')
> 
> I've confirmed that the tables hold the new stories
> and links, but they're not showing up in
> RecentChanges, or any of the other pages I've tried to
> link the content to. 
> 
> What else do I need to change to make sure the new
> content is displayed? 
> 
> Thanks. 

I'm looking back at the table structure for 1.2, and I'm not seeing
any obvious thing to do. Are the new pages accessible directly? 

-- 
J.

Re: [Phpwiki-talk] More spam filtering

[Joel U. <uck...@el...>]

> At 18:04 +0200 15/10/05, Joel Uckelman wrote:
> >Can you tell how the spammers are doing it? If it's being done by a bot,
> >then at least we can keep doing things to confuse it. But if it's become
> >cost-effective for spammers to spam wikis by hand, then the game is over
> >and we've lost.
> 
> My wikis send me an email whenever anyone makes a change, showing the 
> new page text. Would it be possible to mail out a diff each time a 
> page is edited, with a link at the bottom to revert to previous?

The current version sends a diff instead of the full page text.

This happens in sendPageChangeNotification() in lib/WikiDB.php. All you'd
need to do is add a line to create the link:

$revertlink = WikiURL($this->_pagename, array('action'=>'revert','version'=>$previous), true);

and then make sure that $revertlink ends up in the mail which goes out at
toward the end of the function.


-- 
J.

Re: [Phpwiki-talk] More spam filtering

[Reini U. <rei...@gm...>]

Sending the Diff plus the url for the diff is a standard feature.
The revert url not directly.

On 10/16/05, John Kershaw <jo...@ke...> wrote:
> At 18:04 +0200 15/10/05, Joel Uckelman wrote:
> >Can you tell how the spammers are doing it? If it's being done by a bot,
> >then at least we can keep doing things to confuse it. But if it's become
> >cost-effective for spammers to spam wikis by hand, then the game is over
> >and we've lost.
>
> My wikis send me an email whenever anyone makes a change, showing the
> new page text. Would it be possible to mail out a diff each time a
> page is edited, with a link at the bottom to revert to previous?
--
Reini

[Phpwiki-talk] =?ISO-2022-JP?B?WyCIyZOhgZuN546XgsyO4Ymcl2yCqoFFgUWBRSBdkm2CwYLEgumQbIK+gq+Tvg==?= =?ISO-2022-JP?B?gvCCt4LpgUmDR4ONg2yDYoNnj+6V8TE4OjQyOjIz?=

[nlvrbbt <nlv...@hi...>]

DQqBn4SqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE
qoGfDQqBQIFAgUCBQIFAiMmToYGbjeeOl4LMjuGJnJdsgqqVc5fPkcyMsYtMgvCMg5SSDQqBn4Sq
hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoGfDQph
Y3QuMYGZg4GBW4OLgsWDWoNig06DWA0KYWN0LjKBmZNkmGKCxYNag2KDToNYDQphY3QuM4GZie+C
wYLEg1qDYoNOg1gNCoLggsGCxo/agrWCrYGEgYSBhCBodHRwOi8vd3d3LnRvdWtvdS5iaXovDQoN
CoGhYWN0LjEgg4GBW4OLgsWDWoNig06DWIFAgXWJmIKijL6XdILFjoSC8JDTgt+CxIFJgXYNCoSq
hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE
qoSqhKqEqoSqhKoNCoGliMmToYGbjeeOl4LMjuGJnJdsgs2SypTMgsWDUoNig1yDio13k/yCtYK9
g3ODk4NOg42BW4NegVuV0I7ogskNCoFAkF6Si4rUgqmC549vie+Cooxug1SDQ4NngsmDQYNOg1qD
WIK1gtyCt4FCDQqBQIKojN2CooLMi0OOnYK/gqqNgpdngreC6oLOg4GBW4OLgs2Ct4LFgsmDYIOD
g2KDZ4/zkdSBQg0KDQqO4Ymcl2yBdYKigtyBQYONgVuDXoFbgvCDToOKgr+C4YLxgsmJn4K1k5aC
xILEgtyCt4FFgUWBRYF2DQoNCpJqkKuBQIF1kmqC3YK9gqKCyZZ1i06CtYLEgumC8YK2guGCyIKi
gqmBSIyDgrWCrYKzguqC6YLGg0ODQ4Lxgr6C64KkgUmBSIF2DQoNCo7hiZyXbIF1gruCpILFgreB
QZP7jvGC4ILCgtyC8YLFg06DioK/guGC8YLwlMaCtYLEl36CtYKigqGCoYFJgUmBdg0KDQoNCjwx
OIvWPpVzl8+ShoLMkGyNyIKqgrGCzInEgsySv1uDYIOTXZHMjLGC8IyDlJKBSQ0KaHR0cDovL3d3
dy50b3Vrb3UuYml6Lw0KDQqBoWFjdC4yIJNkmGKCxYNag2KDToNYgUCBdYLggqSBQYzjlt+C6ILF
gquCyIKigvGCxYK3gXYNCoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE
qoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKoNCoGljcWPiYLNjHiJ+oK1gsSCooK9juGJnJds
guCBQY6plaqCzJKGgsyBeYm9gqmBeoKqibmC8JengsSCxJX2guqOboLfgUENCoFAjMiCzJd+ll2C
yY+ZgViCyY54lHqCs4LqgsSCooKrgtyCt4FFgUWBRQ0KgUCTZJhilNSNhoLwkmqQq4LJk2CCpoFB
g2WDjIN6g5ODWoNig06DWILJlr6Cr5XpguqC6ZaIk/qBQg0KDQqO4Ymcl2yBdYLggqSDX4OBgsWC
t4FBlnuVqILMgUGWe5WogsyDSYGbg5ODYIOTgvCCrYK+grOCooF2DQoNCpJqkKuBQIF1graC4YKg
gruCzJFPgsmMZ5HRgvCDfYGbg1KCyYN1g2CNnoLxgsWC3YLrgUmDgYNYk9iBSYFJgXYNCg0KjuGJ
nJdsgXWCoIKfgp+Cn4LBgsGCw4FFgUWBRYLNgqKCwYK9gUWBRYFFg0yDZINDgqGCoYFJgUmBdg0K
DQoNCjwxOIvWPo7hiZyXbILMkcyMsZJrgqqWno3agsWCtw0KaHR0cDovL3d3dy50b3Vrb3UuYml6
Lw0KDQqBoWFjdC4zIInvgsGCxINag2KDToNYgUCBdY7lkGyCzILmguiBQYNDg0OBSYFJgXYNCoSq
hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE
qoSqhKqEqoSqhKoNCoGlgsKCooLJkmqQq4LGj2+J74LBgr2IyZOhgZuN546XgsyO4Ymcl2yBQg0K
gUCCooLCguCCzONZl+2CyIrnl6eCv4KqiVKCzILmgqSCyYFBjPuC8IpKgq+CxIOIg1+DjILwkIKC
54K1gsSCooLcgreBQg0KgUCCu4LqguCCu4LMgs2CuIFBgqKCqYLCgq2WdYtOgrWCvYNggZuDUoKq
k8uCq45ogrOCwYLEgqKC6YKpgueBRYFFgUWBSQ0KDQqO4Ymcl2yBdYK1guOBQY7lkGyCzILmguiC
4INDg0OCxYK3gUmC4IKkibqUvJBngsmXzYKqk/yC54LIgqKBRYFFgUWBdg0KDQqSapCrgUCBdYNJ
g4mBQYK7guuCu4Lrj2+Ct4K8gUExj1SK1Jetgt+CxILigsGCvYKpgueCyIFJgXYNCg0KjuGJnJds
gXWUWoKigsyCrYK+grOCooFBkoaCyYKigsGCz4Kiko2CooLFgq2CvoKzgqKCwYFJgUmBdg0KDQoN
CjwxOIvWPojJk6GBm43njpeCzI7hiZyXbIKql5iXcIK1gr2P6o+Kgs2BRYFFgUUNCmh0dHA6Ly93
d3cudG91a291LmJpei8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPJBsjciVc5fPTmV3cyBUb3BpY3M+DQqB
RZFTjZGO4ZBsjciCs4LxMTAwkGyCzCKI+iKU6ZangsyQq5C2ioiR5Yz2ikqBSQ0KgUWDbINig2eC
xYypgsKCr4K9lXOXz5KGkGyNyILMjIOUkg0KgUWSbojmlcqQbI3IlK2MqY/qj4qBdYKmgUmCooKi
gsyBSYFIgXaVc5fPkoaQbI3Ij1cNCg0KkN+TeILwjp2CwYLEkeWQbILMitaMV4LwgqiKeYK1gt2C
rYK+grOCog0KaHR0cDovL3d3dy50b3Vrb3UuYml6Lw0KhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq
hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqg0KNDU4OTkNCg0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBodHRwOi8vZXRpZGUuNTEubmV0LyAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCtLUyc/E2sjd08lWb2xsZXlNYWlsw+K30cjtvP63osvNo6y1q8TayN3T61ZvbGxl
eU1haWzO3rnYo6zM2LTLyfnD96Oh

Re: [Phpwiki-talk] More spam filtering

[John K. <jo...@ke...>]

At 18:04 +0200 15/10/05, Joel Uckelman wrote:
>Can you tell how the spammers are doing it? If it's being done by a bot,
>then at least we can keep doing things to confuse it. But if it's become
>cost-effective for spammers to spam wikis by hand, then the game is over
>and we've lost.

My wikis send me an email whenever anyone makes a change, showing the 
new page text. Would it be possible to mail out a diff each time a 
page is edited, with a link at the bottom to revert to previous?

John.
-- 
-------------------------------------------------------------------
T:01274 581519 / M:07944 755613   www.kershaw.org  jo...@ke...
skype:johnmkershaw  AIM:johnkershaw  MSN:joh...@ho...

Re: [Phpwiki-talk] Wiki stopped working ?

[Marco G. <gru...@ho...>]

Okay, it turned out that the server config was changed and the leading
directory was no longer returned in the HTTP global variables. Thus the
filename comparison in index.php failed and main() never got called.

- Marco

----- Original Message ----- 
From: "Joel Uckelman" <uck...@el...>
To: "Marco Grubert" <gru...@ho...>
Cc: <php...@li...>
Sent: Saturday, October 15, 2005 07:32 AM
Subject: Re: [Phpwiki-talk] Wiki stopped working ?


> > Our wiki pages over at http://www.coniserver.net/wiki/ were working fine
for
> > the past few months, but now all I get is a blank page when launching
the
> > index.php file. As far as I can tell all the source files are there and
the
> > databases look good too.
> > What are the recommended debugging steps to find out where exactly
things go
> > wrong ?
> >
> > Thanks,
> >   Marco
>
> The first place I'd look is in the web server's error logs.
>

Re: [Phpwiki-talk] More spam filtering

[Joel U. <uck...@el...>]

> 
> If you had my wiki, you would not say that. I'm getting killed. I even 
> had to close the wiki, and now they are creating accounts to do it from 
> the inside. VERY soon (like next day or so) I will have to implement 
> filterlists.

Can you tell how the spammers are doing it? If it's being done by a bot,
then at least we can keep doing things to confuse it. But if it's become
cost-effective for spammers to spam wikis by hand, then the game is over
and we've lost. 
 
> 
> >Only a global filterlist would help here. mediawiki is also
> >looking into this. We will see.
> >  
> >
> 
> The "revert" button would be good too, but I am still at 1.3.9, and am 
> afraid of the amount of effort it would take to get the revert button 
> integrated.

I can say that using the Revert button is far better than manually reverting
spammed pages; however, it wouldn't take much additional spamming to make
using the Revert button unbearably time-consuming as well.

Most of the spam I see on my wikis now involves putting the same single link
on multiple pages, not multiple links on single pages. Reverting is much more
efficient in the latter case than in the former.

-- 
J.

Re: [Phpwiki-talk] Wiki stopped working ?

[Joel U. <uck...@el...>]

> Our wiki pages over at http://www.coniserver.net/wiki/ were working fine for 
> the past few months, but now all I get is a blank page when launching the 
> index.php file. As far as I can tell all the source files are there and the 
> databases look good too.
> What are the recommended debugging steps to find out where exactly things go 
> wrong ?
> 
> Thanks,
>   Marco 

The first place I'd look is in the web server's error logs.

-- 
J.

Re: [Phpwiki-talk] More spam filtering

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

>This kind of five-casino-url spam (even with a nice announce) is
>imho not that annoying than hundreds of links making the text
>effectively unreadable.
>  
>

If you had my wiki, you would not say that. I'm getting killed. I even 
had to close the wiki, and now they are creating accounts to do it from 
the inside. VERY soon (like next day or so) I will have to implement 
filterlists.


>Only a global filterlist would help here. mediawiki is also
>looking into this. We will see.
>  
>

The "revert" button would be good too, but I am still at 1.3.9, and am 
afraid of the amount of effort it would take to get the revert button 
integrated.

Dan

[Phpwiki-talk] Wiki stopped working ?

[Marco G. <gru...@ho...>]

Our wiki pages over at http://www.coniserver.net/wiki/ were working fine for 
the past few months, but now all I get is a blank page when launching the 
index.php file. As far as I can tell all the source files are there and the 
databases look good too.
What are the recommended debugging steps to find out where exactly things go 
wrong ?

Thanks,
  Marco 

[Phpwiki-talk] creating new pages with mysql

[Geoff D. <geo...@ya...>]

Hi. 

I'm running 1.2 and mysql, and I need to pull page
content from a non-phpwiki database and create new
phpwiki pages containing the same content. 

I've uploaded some test content to the wiki table in
the database, and updated the wikilinks table to
reflect the new content (i.e., INSERT INTO
wikilink(frompage,topage,) VALUES
('RecentChanges,'MyNewContentPage')

I've confirmed that the tables hold the new stories
and links, but they're not showing up in
RecentChanges, or any of the other pages I've tried to
link the content to. 

What else do I need to change to make sure the new
content is displayed? 

Thanks. 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[Phpwiki-talk] SPAM from me? SPAM von uns?

[<in...@al...>]

Deutscher Text folgt unten.

--English--

We do not dispatch Spam!

To 12.10.2005 an unknown quantity penetrated in our Mailserver over a sys=
tem
account and dispatched enamels to 60.000 receivers.  The break-down
succeeded over trying different passwords out.  Do not have we simple pas=
swords
in use. ;-(

A warning to the concerning:  Enter NO data into the form of the Spam Mai=
l and
click you on NONE link, but you delete the Spam Mail immediately.

We regret this much.

AL Systeme

http://www.al-systeme.de/



--Deutsch--

Wir versenden keine SPAM eMails!

Am 12.10.2005 ist ein Unbekannter in unseren Mailserver ueber einen
Systemaccount eingedrungen und hat eMails an 60.000 Empfaenger versendet.
Der Einbruch gelang ueber das Ausprobieren verschiedener Passwoerter. Eig=
ndlich
haben wir keine einfachen Passwoerter in verwendung. ;-(

Eine Warnung an die Betroffenen: Geben Sie KEINE Daten in das Formular de=
r
Spam Mail ein und klicken Sie auf KEINE Link, sondern loeschen Sie die SP=
AM
Mail sofort.

Wir bedauern diesen Zwischefall sehr.

AL Systeme

http://www.al-systeme.de/

Re: [Phpwiki-talk] css classes, ids in markup

[John K. <jo...@ke...>]

At 23:25 +1300 13/10/05, Matt Brown wrote:
>I'm still vaguely uncomfortable with the idea of allowing users to add
>arbitrary classes to objects. I can't pinpoint exactly why though. I
>guess it's the whole trade off between flexibility and correctness. If
>you let users define arbitrary classes/ids you can bet it's going to be
>misused quicker than you can blink your eye.

I have two distinct kinds of user/site in mind.

Person A: wiki = easy. These people don't know their html from their 
http, and don't want to. My mum is one of these - she runs a web site 
for the old folks at the nursing home where she works. She helps them 
put their war memories etc online for their far-flung children to 
read:
http://sycamoreclose.com/Stan

Person B: wiki = fast. People like me, my friend in the Physics 
Department, and the Head of ICT at my daughter's school. We can code 
html pages in a text editor, we embrace W3C recommendations, we test 
our sites in 10 different browsers (okay, these days more like 3). 
BUT WE DON"T WANT TO! For me, wiki means when the client phones for a 
minor text alt to his site, I can do it whilst he's on the phone. No 
invoice required(TM). I've converted a bunch of my old html sites to 
phpwiki cos they're easy to maintain and I can hand over some of the 
day to day to the people who hold the information. I want an easy 
life - wiki gives it to me, in spades.

erson A and person B often work on the same site. I want to be able 
to fancy up the recipe page on my mum's site in a consistent fashion, 
using markup she can understand and reuse (with baby steps 
hand-holding the first couple of times). She doesn't need to mess 
with the css definitions, but she likes what happens to her 
dull-looking pages when I do (though on her site I'd probably leave 
them in .css files where she can't mess them up). A simple 'class' 
markup she could understand (and auto-ids) would enable us to work 
together to produce something visually spectacular without too much 
pain for her (no disrespect ma!).

My mum *enjoys* making wiki pages - it only takes a few seconds and 
she's got something the old folks can appreciate. I know from 
experience that making & altering web pages has a very high indolence 
threshold (I avoid it unless absolutely necessary). I enjoy making 
wiki pages too, but I crave more power!

Interestingly, though my mum started out completely computer-phobic, 
she's getting more savvy all the time. Sooner or later she could well 
end up being a Person B and I can hand over more of the site to her. 
But without the initial simplicity of wiki markup, she'd never have 
started.

So yes, users are dangerous, and they can harm themselves if they're 
given too much too soon too easily. But the clumsy 7-year old you 
train to carefully handle wood-working tools may well outstrip you in 
years to come. Let them have that chance. I don't want my users to 
forever live in a dumbed-down, M$ wizards, Eating for Dummies world. 
Give them the option of infinite power, but let them start small.

John.
-- 
-------------------------------------------------------------------
T:01274 581519 / M:07944 755613   www.kershaw.org  jo...@ke...
skype:johnmkershaw  AIM:johnkershaw  MSN:joh...@ho...