phpwiki-talk

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[Carsten K. <car...@us...>]

Do you think it would cause any problems to just commit this change of 
FieldSeparator to '\xff'?

I'm going to leave it this way on my Wiki for a while to see how it 
works out as a permanent change. If this is not a good idea, maybe add 
a check in config.php for CHARSET==utf-8 and set FieldSeparator 
accordingly?

I'm amazed that I'm now able to use UTF-8 (Japanese etc) text in my 
personal wiki, even though my system has only MySQL 3.2.3.49 which does 
not support UTF-8, and is actually configured for iso-8859-1. The last 
time I tried to use UTF-8 in PhpWiki (over a year ago) I had to use 
PostgreSQL, and there were still lots of garbage display problems then.

So far the only (minor) problems I see running PhpWiki CVS in utf-8 are 
the field names on the DebugInfo page and character translation problem 
on the Sign In page.

I'm sure these two minor problems can be worked out, and if anyone 
volunteers to translate we could have Japanese/Chinese localizations 
included with PhpWiki too, the admin would just have to change CHARSET 
to utf-8 in index.php during installation.

Carsten

On Sunday, October 27, 2002, at 11:34  am, Jeff Dairiki wrote:

> This is hackish, but: you might try changing
> $FieldSeparator to '\xff' (which is an illegal
> byte in UTF-8) or to one of the lesser used ASCII

Re: [Phpwiki-talk] dsn for sockets

[Carsten K. <car...@us...>]

Hi Peter,

The dsn you gave is working for me too.

Since PhpWiki includes some PEAR code now does it mean this problem has 
been fixed, or am I just lucky that the PEAR that came with my system 
is new enough to avoid this socket problem?

Carsten

On Monday, October 28, 2002, at 11:42  am, Peter Holm wrote:

> Hi,
>
> in index.php I found this:
>
> // FIXME: My version Pear::DB seems to be broken enough that there
> // is no way to connect to a mysql server over a socket right now.
>
>
> Is this still an issue?
>
> You should use something like the following line to connect via
> sockets:
>
>
> 'dsn' => 'mysql://user:password@unix+localhost/phpwiki',
>
>
>
>
> Have a nice thread,
> Peter

Re: [Phpwiki-talk] general question: why do linebreaks not produce a <br>?

[Joby W. <joby@u.washington.edu>]

You need to have a blank line in between lines of text to generate 
seperate paragraphs.  Having separate lines merge into a single 
paragraph (if there is no blankspace) is a "feature".

jbw

Peter Holm wrote:
> Hi,
> 
> I am wondering about the fact tha a linebreak in the input textarea
> does not produce a <br> on the resulting page. is there a reason for
> this? 
> 
> I would like to have this enabled, is the right place to do it
> somewhere in editpage.php?
> 
> Thanks for your attention!
> 
> 
> 
> 
> Have a nice thread,
> Peter
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Path configuration

[Joby W. <joby@u.washington.edu>]

Peter,

Which version of phpwiki do you have installed?
Which OS is this on?
Which HTTP server are you using?

jbw

Peter Holm wrote:
> Hi,
>=20
> I wrote:
>=20
>=20
>>I just installed phpwiki on a local machine for testing, the vhost=20
>>this wiki runs on is configured to servername "phpwiki".
>=20
>=20
>>When I access http://phpwiki everything seems to work correctly,=20
>>BUT the browser tries to access www.themes.com, because in the=20
>>source a link like this is produced:
>=20
>=20
>><img src=3D"\/themes/default/images/logo.png"
>=20
>=20
>=20
> don=B4t think, that this is an error, but I could solve the problem
> defining DATA_PATH to '' or '..'.
>=20
> define('DATA_PATH', '');
> define('DATA_PATH', '..');
>=20
>=20
>>Is there something wrong with the link-generating code?
>=20
>=20
> I did not find the piece of code that tries to extract the actual
> path, but it does not seem to like the way i installed phpwiki...
>=20
> ok, just to let you know...
>=20
>=20
>=20
>=20
> Have a nice thread,
> Peter
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Date not shown...

[Peter H. <ph...@gm...>]

hi,

it=B4s me again... thanks for your fast response...

everything seems to work now, BUT the date shown does not generate
correctly:

Last edited on October , 2002 6:37 pm

is there some known bug about this?

Where can I find the responsible date() code to check this?=20

BTW I am testing this on windows...




Have a nice thread,
Peter

[Phpwiki-talk] general question: why do linebreaks not produce a <br>?

[Peter H. <ph...@gm...>]

Hi,

I am wondering about the fact tha a linebreak in the input textarea
does not produce a <br> on the resulting page. is there a reason for
this?=20

I would like to have this enabled, is the right place to do it
somewhere in editpage.php?

Thanks for your attention!




Have a nice thread,
Peter

[Phpwiki-talk] Path configuration

[Peter H. <ph...@gm...>]

Hi,

I wrote:

>I just installed phpwiki on a local machine for testing, the vhost=20
>this wiki runs on is configured to servername "phpwiki".

>When I access http://phpwiki everything seems to work correctly,=20
>BUT the browser tries to access www.themes.com, because in the=20
>source a link like this is produced:

><img src=3D"\/themes/default/images/logo.png"


don=B4t think, that this is an error, but I could solve the problem
defining DATA_PATH to '' or '..'.

define('DATA_PATH', '');
define('DATA_PATH', '..');

>Is there something wrong with the link-generating code?

I did not find the piece of code that tries to extract the actual
path, but it does not seem to like the way i installed phpwiki...

ok, just to let you know...




Have a nice thread,
Peter

Re: [Phpwiki-talk] Path configuration

[Joby W. <joby@u.washington.edu>]

In Part 6 (URL Options) of index.php you can hard code the server name 
(SERVER_NAME), and url relative to the server root (SCRIPT_NAME).  This 
should solve your problem.

jbw

Peter Holm wrote:
> Hi,
> 
> I just installed phpwiki on a local machine for testing, the vhost
> this wiki runs on is configured to servername "phpwiki".
> 
> When I access http://phpwiki everything seems to work correctly, BUT
> the browser tries to access www.themes.com, because in the source a
> link like this is produced:
> 
> <img src="\/themes/default/images/logo.png"
> 
> Is there something wrong with the link-generating code?
> 
> Maybe anyone can give me a hint?
> 
> 
> Thanks!
> 
> Have a nice thread,
> Peter
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] dsn for sockets

[Peter H. <ph...@gm...>]

Hi,

in index.php I found this:

// FIXME: My version Pear::DB seems to be broken enough that there
// is no way to connect to a mysql server over a socket right now.


Is this still an issue?=20

You should use something like the following line to connect via
sockets:


'dsn' =3D> 'mysql://user:password@unix+localhost/phpwiki',




Have a nice thread,
Peter

[Phpwiki-talk] Path configuration

[Peter H. <ph...@gm...>]

Hi,

I just installed phpwiki on a local machine for testing, the vhost
this wiki runs on is configured to servername "phpwiki".

When I access http://phpwiki everything seems to work correctly, BUT
the browser tries to access www.themes.com, because in the source a
link like this is produced:

<img src=3D"\/themes/default/images/logo.png"

Is there something wrong with the link-generating code?

Maybe anyone can give me a hint?


Thanks!

Have a nice thread,
Peter

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

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

> Thank you!

NP. 

> While we are on this subject, could I trouble you for 
> advice on how to insert the control character \xff 
> directly into the MySQL database via the command line? 
> I tried inserting '\\xff' but that just inserts the actual 
> string, doesn't it...

Reading the mysql docs, the only way I could figure to
generate '\xff' is CHAR(255) (which you would then need to
CONCAT() with other strings if you wanted to make a string
longer than one character.)  See:

 http://www.mysql.com/doc/en/String_functions.html#IDX1161

That said, I don't see why you would want to insert \xff's
into the MySQL database.  Since '\xff' isn't valid within
UTF-8 strings, I think that will just break things more
than they are already broken.

> ... but that string is not being highlighted 
> when it turns up in a different location ...

Yes, it sounds like you figured it out.  Strings are not
"hilit" (or "linkified") based on whether they exist as
pages or not; rather whether they are hilit depends on
whether they match certain regexps.  In the wiki tradition
CamelCase words (multiple capitalized words run together
with no spaces) are what normally gets linkified ---
and square brackets can be used to "force" linkification
of anything that doesn't match the CamelCase pattern.

Jeff

PS: From the "it's no big deal, but you might like to know"
department: Your ISP won't allow me to send e-mail directly
to you Tony.  My mail server runs on an AT&T cable modem
connection --- apparently, as an anti-spam measure, your
ISP blocks mail from all such hosts.  This is the first
time I've encountered such a restriction...

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[Tony L. <la...@is...>]

On Mon, 28 Oct 2002, Tony Laszlo wrote:

> One last thing. Are there any things to look out for 
> when putting brackets [] around a utf-8 string in phpWiki, 
> so as to define it? I notice that one such string is getting 
> defined in one place, but that string is not being highlighted 
> when it turns up in a different location (the definition is 
> not being picked up). Also, I guess phpWiki is set not to 
> ignore underscores _ in such a string, by default? A string 
> with such an underscore was successfully defined, but that 
> definition also did not stick. 

Strike this last bit. 
I understand what is happening now. 
phpWiki will highlight terms that have been defined 
but not if the terms were defined via the bracket [] 
method. 
So, one needs to put brackets around the definded 
terms every time they are used, rather than having 
automatic highlighting. 
We can live with this, I think. :)

Great tool!
Kudos to all. 

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[Tony L. <la...@is...>]

On Sun, 27 Oct 2002, Jeff Dairiki wrote:

> This is hackish, but: you might try changing
> $FieldSeparator to '\xff' (which is an illegal
> byte in UTF-8) or to one of the lesser used ASCII
> control characters: maybe '\x01' (SOH).

I changed the relevant line in /lib/config.php 
so that FieldSeparator = \xff . That seems to have 
done the trick, at least with regard to this particular 
page (so far so good). 

Thank you!

While we are on this subject, could I trouble you for 
advice on how to insert the control character \xff 
directly into the MySQL database via the command line? 
I tried inserting '\\xff' but that just inserts the actual 
string, doesn't it...
I would like to see if anything different happens using 
that method vs. the above method. 

One last thing. Are there any things to look out for 
when putting brackets [] around a utf-8 string in phpWiki, 
so as to define it? I notice that one such string is getting 
defined in one place, but that string is not being highlighted 
when it turns up in a different location (the definition is 
not being picked up). Also, I guess phpWiki is set not to 
ignore underscores _ in such a string, by default? A string 
with such an underscore was successfully defined, but that 
definition also did not stick. 

Thanks! 

> I am away from home at the moment, and have jsut picked up your messages.  

Thank you for your pn implementation, Lawrence. 
Works great! 


Tony Laszlo, Tokyo
http://www.issho.org/laszlo.html

[Phpwiki-talk] Authentication related questions

[S. M. <the...@ta...>]

Hi, everyone,

I'll start by telling you that PHPWiki is quite impressive in its way.
I've spent the last two months shoping, so to speak, for a wiki engine
and I was quite excited to discover this one. I'm starting a few
projects with friends of mine who are rather on the end-user side of
things and have asked them to evaluate PHPWiki along with the bare-bones
(but simple) UseMod and the featureful (but quite complex) TWiki and
they all chose PHPWiki... So PHPWiki it is.

Now I'll be setting up a few wikiss (one for each project) but most of
them need to be closed to the outside world for now, which leads me to
worry about authentication and such things. I guess I'll be using code
from CVS since it seems to be the one that supports authentication best.
I can't use external auth for now (though I suppose I will find a way to
if I have no other choice). So as I understand things, my choices are
between internal auth and HTTP auth. Now, my perception of things is
that internal auth isn't functional at all yet, is that correct?
This then leaves me with HTTP auth as my only choice. From index.php:
// The wiki can be protected by HTTP Auth. Use the username and password
// from there, but this is not sufficient. Try the other methods also.

What I hope this means is that I could just set up HTTP auth and have
PHPWiki use the authenticated user name. However this doesn't seem to
work for me. I set ALLOW_HTTP_AUTH_LOGIN to true and added this
statement to my .htaccess file:
<Files "index.php">
        require valid-user
</Files> # WARNING: my knowledge of Apache is rather limited...

I can authenticate, as far as accessing the wiki goes, but then I'm
still required to sign in. Am I missing something?

(That's with a fresh tarball of the nightly snapshop, BTW.)

Oh, and I think the plans for the internal auth scheme are realy
promising; just with it were already there. :(

Thanks for your help,
S. Massy

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[<la...@us...>]

Tony,

I am away from home at the moment, and have jsut picked up your messages.  I 
have to say (as the author of the PN module) that I don't think that the 
problem is caused by anything PN specific in the code.

Is it possible for you to try a standalone phpwiki installation, using the code 
from CVS?  If you could make the site accessible to us, that would help.

Lawrence

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

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

Here's a guess:

The code in lib/transform.php (the "old" transform code)
mangles one "magic" byte-value.  Which character it
is that get mangled is determined by the setting of the
global $FieldSeparator.  By default, it is the 
value '\x81'.  (This value is picked because it is a
non-printing control character in all the ISO-8859-x
encodings.)  (The trasform.php code uses this byte to
insert temporary markers within the page text as it
processes it...)

(In PhpWiki 1.3.3 there are two separate markup engines.
The "old" one in transform.php, and the new one in
BlockParser.php and InlineParser.php.  The new one
gets used if you check the "use new markup" box when
you're editing the page.   In the most recent CVS code
only the new markup engine is used.
I have no idea how recent the postnuke module code is,
so can't tell you where you are within this timeline.)

This is hackish, but: you might try changing
$FieldSeparator to '\xff' (which is an illegal
byte in UTF-8) or to one of the lesser used ASCII
control characters: maybe '\x01' (SOH).

If that doesn't help, then this is a red herring.
In that case, if you can determine exactly which
byte-values/characters are being mangled it might
help diagnose the problem...

Jeff

[Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[Tony L. <la...@is...>]

Further to this issue. 

We have read through the utf8migration and doublebyte documents, 
and through the archives of phpwiki-talk. We have also downloaded 
index.php and the template files (browse.html, et al) from the cvs, 
and hacked them to get them to work with Postnuke. 
Tried sticking on those header lines mentioned on the the above-mentioned 
wiki pages. 

We were not able to get that utf-8 data that was screen garbage, to display 
correctly (though other pages with utf-8 were displaying properly). 
Then we experimented a bit more and discovered that certain characters 
in the strings being input were being mangled by the wiki. 

Thus, we determined that the utf-8 in the sandbox and homepage is being 
displayed largely due to luck; the characters being used were somehow 
passing through unscathed - probably the exception rather than the rule.   
 
We also compared the source of the pages that were being displayed 
properly and those not being displayed properly, and found the header  
information to be identical. The page is being displayed properly 
(the Postnuke-generated utf-8 data is fine), but the stuff in between 
the div /div that phpWiki generates, is getting mangled.  

Wiki clones in Asia have made refinements to Wiki code (or designed 
their code) so that this doesn't happen. We are looking into what they 
are doing, and hope to see if it can be applied to this rather specific 
problem, i.e., the code for the phpWiki module for Postnuke. Quite 
possibly it will involve the use of things mb_* things, or maybe 
rawurlencode something or other. 

However, we are quite puzzled, and suspect that there is an easy answer 
within the domain and experience of phpWiki users that might be had. 

What might that be? 

For those of you not familiar, the phpWiki module for Postnuke 
includes the latter's "header.php" file, and so allows the CMS 
to deal with the header issue for each page generated. Thus, 
phpWiki's index.php is missing all that header information that 
is in that of phpWiki proper. 

The relevant lines from Postnuke's header.php are as follow: 


else {
        echo "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\
n";
        echo "<html>\n<head>\n";

        if (defined("_CHARSET") && _CHARSET != "") {
                echo "<meta http-equiv=\"Content-Type\" ".
                     "content=\"text/html; charset="._CHARSET."\">\n";
        }


There is no mention of mb_ anything anywhere in the code, yet 
there is no problem with screen garbage. 

That _CHARSET, btw, is set to utf-8 on our system, in all instances. 

These lines are the only relevant code that exists within the 
Postnuke that we are running. Thus, these lines and these lines 
alone are able to ensure that all pages display all the utf-8 
data correctly, in Postnuke. For our purposes, the reported limitations 
that php and mysql have regarding utf-8 are not an issue. That is also 
 true with all modules we use with Postnuke. Except, unfortunately, 
for this one (so far). 

So, we suspect that there may be something that is causing the 
data in between the div /div that phpWiki makes, to get mangled, 
while the page itself is displayed properly. If we can locate it, 
and tweak that, we should be in business. 

But, we haven't managed to find out what that mechanism might 
be just yet. 

Looking forward to advice from both the Wabi and Sabi experts among you. 
 
Thanks. 

Tony Laszlo, ISSHO
http://www.issho.org


 

On Sat, 26 Oct 2002, Tony Laszlo wrote:

> on a soon-to-be-launched multilingual site whose data is 
> all stored as utf-8. 
> We were able to save small strings of non-English data on the 
> homepage and in the Sandbox, with no problem. 
> Those pages can be seen here: 
> http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=HomePage
However, [we have major problems otherwise, see here]: 
> http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=IsshoSelfSupport_en

[Phpwiki-talk] phpWiki and utf-8/double-byte

[Tony L. <la...@is...>]

Greetings. 

ISSHO Kikaku, a non-profit that studies diversity, 
multicultural and multilingual issues, has begun using 
the Postnuke module phpWiki
(phpWiki module v0.1 - Implementation of phpWiki v1.3.1)

on a soon-to-be-launched multilingual site whose data is 
all stored as utf-8. All the data has been converted to 
utf-8, and charsets have all been changed where appropriate. 
No changes were made to the charset settings in phpWiki, if 
we can recall correctly. 

We were able to save small strings of non-English data on the 
homepage and in the Sandbox, with no problem. 
Those pages can be seen here: 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=HomePage
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=SandBox


However, we are experiencing a major problem when we do the following: 
* define a term on the homepage (by clicking on the question 
mark) and inputting text that was all non-English (Japanese, 
in this case). 
The problem: 
screen garbage on preview, and after saving. 
Other characteristics: 
when going back to editing that page again, 
the characters display correctly. 
That page can be seen here: 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=IsshoSelfSupport_en

Constructive hints on what needs to be done to alleviate this 
problem would be very much appreciated. 
Thanks very much in advance. 

Tony Laszlo
Director, ISSHO Kikaku
http://www.issho.org/laszlo.html

[Phpwiki-talk] 100% Guaranteed Breast Enlargement

[<mw...@ya...>]

The best bust bust enlargement pill ever!  

Why wait?  If you don't see the effect, you'll get the money back.

http://www.ccipowergriphosting.com/business/dreambreasts/

Click on the link below to remove yourself
http://www.ccipowergripresponder.com/cgi-bin/varpro/29.cgi?id=dreambreast&a=php...@li...

AOL Users
<a href="http://www.ccipowergripresponder.com/cgi-bin/varpro/29.cgi?id=dreambreast&a=php...@li..."> Remove Me</a>

OT: Re: [Phpwiki-talk] Wiki Module Doesnt Work with PN 0.7.2

[Lawrence A. <la...@us...>]

Dimitris,

This  list  is really for discussing phpWiki, not the Postnuke module.
You may email me directly if you have any questions about the module.

I  am  not  sure exactly what you need to know, but I can say that the
"Activate wiki for this module" has nothing to do with phpwiki. It was
written  by Sebastien Barnard and was originally intended to allow the
use  of wiki markup in news articles. I know very little about it. The
wiki module (by me) is basically an embedded version of phpWiki.

If  you  have questions about the wiki module, please let me know, but
say  exactly  what the problem is. If you have questions about the use
of wiki markup in the News module,its probably best if you ask them on
the postnuke list or in one of the postnuke forums.



 --

 Regards,


Lawrence Akka

On Friday, October 25, 2002 at 12:11:23 PM, you wrote:

> Hello,  I  am a newbie at PostNuke and I realy need to use Wiki as a
> module  in  my  Site. I have 2 problems 1. I cant use phpWiki Module
> with  pn  V0.7.2  Even if i did every posible Solutoin writen in the
> INSTALL  README and all other manuals were included with the phpWiki
> module  i  had downloaded. 2. I cant understand the diff bettewn the
> module  I downloaded and the WIki module the exists in pn V0.7.2.. I
> tryed to use this module by usind the Choice "Activate wiki for this
> module"  for All Module but when i wrote in the News module with the
> Wiki test Rules didnt work :(

> I am looking forword for your answer,
> Thank you for your help
> D.P.


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

[Phpwiki-talk] Wiki Module Doesnt Work with PN 0.7.2

[Dimitris P. <dpr...@la...>]

Hello,
I am a newbie at PostNuke and I realy need to use Wiki as a module in my =
Site.
I have 2 problems
1. I cant use phpWiki Module with pn V0.7.2 Even if i did every posible =
Solutoin writen in the INSTALL README and all other manuals were =
included with the phpWiki module i had downloaded.
2. I cant understand the diff bettewn the module I downloaded and the =
WIki module the exists in pn V0.7.2..
I tryed to use this module by usind the Choice "Activate wiki for this =
module" for All Module but when i wrote in the News module with the Wiki =
test Rules didnt work :(

I am looking forword for your answer,
Thank you for your help
D.P.  

[Phpwiki-talk] load bug?

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

I recently did an update from CVS, wiped the database (mysql) here on my
home box, and when I load the Wiki all the pages (English) load fine. But
it looks like pages for all languages load.

mysql> select pagename from page;
Empty set (0.00 sec)

(then I call the wiki in mozilla, and...)

mysql> select pagename from page;
+--------------------------------+
| pagename                       |
+--------------------------------+
| %%%                            |
| AbbeNormal                     |
| AcadWiki                       |
| Accueil                        |
| AddingPages                    |
| AdministrationDePhpWiki        |
| AggiungerePagine               |
| AgregarPaginas                 |
| AjouterDesPages                |
| AllPages                       |
| AllUsers                       |
| AlleSeiten                     |
| AmministrazioneDiPhpWiki       |
| AndStuff                       |
| BacASable                      |
| BackLinks                      |
| BcWireless                     |
| BenefitsWiki                   |
| BraStil                        |
| BridgesWiki                    |
| BuenEstilo                     |
| BuonStile                      |
| BuscarP=E1gina                   |


etc. etc.

Have I missed something in the last seven months? :-)

~swain

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

Re: [Phpwiki-talk] How to submit bug fixes?

[Oliver B. <ob...@de...>]

Reini Urban <ru...@x-...> wrote:

> > where is the right place to post a suggestion for a bug fix?

> post the patch at the sf.net patch page and here an announcement.

Didn't dare to do so with my rudimentary PHP knowledge but will do so 
in the future.

Oliver

Re: [Phpwiki-talk] Bug fix for removepage.php

[Oliver B. <ob...@de...>]

Jeff Dairiki wrote:

[...]

> > I assume that there is a reason for the nesting and against combining it
> > in request(). 
> 
> You mean WikiRequest vs. Request?  They could be combined with no

Yes, especially things like _deduceSomething() in the constructor. Thanks 
for the explanation, now the reason is obvious.

[missing argument from the "action" of a "get" form]
 
> Is this still a problem in the current CVS code?

No - I don't think so because I added the same hidden fields to the 
template(s) and it works now. The snapshot doesn't run here and I still 
had no time to investigate it further.

I still wonder why the argument is passed with a POST request but not with 
a GET but stop bother about.

After all, with these patches the 1.3.3 version runs very well with 
USE_PATH_INFO set to "false" and I hope now to be able to convince some 
people to share knowledge. I'm afraid that's more difficult than fixing 
some minor problems in PHPWiki.

Thanks again,

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] Troubles with PhpWiki recently developed

[Joby W. <joby@u.washington.edu>]

Johnny L. Wales wrote:
>>1) The error is caused when a variable is assumed to be an object of a 
>>particular type, but for some reason it isn't (probably a null).  Sounds 
>>  like it might have been a bad write (note there is no pagedata).
>>
>>Does it fail on this page or all pages?
> 
> 
> Just this one page. Actually, there are 2 of them now. But, now that you
> mention a bad write, I think I recall my last fsck having some troubles
> with bad sectors. Hmm.. Maybe that problem is bigger than I thought.
> 
> 

Yeah you might want to track that down...

>>2) The error message says exactly where the files are:
>>/home/mark/public_html/phpwiki/lib/Template.php line 212
>>/home/mark/public_html/phpwiki/lib/WikiDB.php line 536
> 
> 
> No, those aren't the files I wanted to know the location of. I mean the
> files where the wiki data is stored. Like, if I edit a page named
> "FoOo" and I write in "Bar!", I wanna know where that "Bar!" is stored.
> 
> 

Phpwiki, unlike twiki, uses databases not flatfiles.  The default is to 
use a gdbm db in /tmp.  The settings are in 
/home/mark/public_html/phpwiki/index.php

>>Which version of phpwiki are you using?  Without that it is pretty hard 
>>to figure out what is happending or you could post +/- 10 lines around 
>>the lines in question.
> 
> 
> The last update to the HISTORY file is as follows:
> 02/12/01 More Jeff's hacks:
> 
> * More CSS stuff.  I think it's neat.
> * Added tables! And modified the footnote stuff a litte.
>   See TextFormattingRules for details.
> * Fixed bugs: including (I hope the two which
>   Reini Urban <ru...@x-...> just reported.)  Also added
>   Reini's patches to the README.  Thanks!
> 

Version is listed in /home/mark/public_html/phpwiki/index.php