phpwiki-talk

Re: [Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Aredridel <are...@nb...>]

On Wed, Feb 26, 2003 at 03:59:54AM -0500, Todd Mokros wrote:
> As a quick fix, the following patch seems to work for me.
> The only problem would be that the is_a() function requires php >=
> 4.2.0.  The method_exists function should work with all PHP4 versions,
> but is an uglier way to check.  The patch might get wrapped by my
> mailer, but should be easy patch by hand.

May I suggest a "versioncompat.php" that, for example, moves
HTTP_POST_VARS to _POST, HTTP_GET_VARS to _GET, if is_a is not defined,
defines one (it's trivial to make a function that does the same), and
various other things like that.  

If functions need _GET, one should global it, as it's not autoglobal in
< 4.3, but there's no reason not to use the new names. 

Makes life much easier, and you can write with the current idiom,
instead of making new versions backward compatible, you can just write
to a nice common denominator.

Ari

Re: [Phpwiki-talk] regex por offline lazzy developper

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

> I want to make wikiwords this way(*):
> 
> $func_ladder
> $rscript_mikmod 

You can try:

  $WikiNameRegexp = "(?<![[:alnum:]])\\$[_a-zA-Z]+(?![[:alnum:]])";

But that will give you links to pages named "$func_ladder" (i.e. the
$ will be part of the page name.)   If you want the $ to disappear,
you'll have to do more serious hacking in lib/InlineParser.php ---
and you're on your own, there.


> I am a coder, and for some reason i hate to write docs for my apps.
> Help me, please.

You are not alone.  Help us all, indeed!

Re: [Phpwiki-talk] Which release to install?

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

On Wed, 26 Feb 2003 08:23:04 -0800
Mark Lentczner <ma...@gl...> wrote:

> I've been pouring over various wiki's for the last week and I'd like to=20
> install phpWiki.  I'm confused about which release is the best to=20
> install.=20

> The other two=20
> aspects I'm interested in is: Some amount of user management=20
> (registration with e-mail would be nice...) and setting up my own theme=20
> so the wiki matches our 'look'.


Keep in mind that 1.3.x is still officially a development branch.
All of the 1.3.x "releases" have known bugs (at least known by
someone).  The only places these bugs get fixed is in CVS.

Personally, I'd either go with 1.2.x if stability and running
out-of-the-box is your top goal, or with current CVS code
if you want the 1.3.x features.  (And be prepared to periodically
merge CVS changes into your own code.)

My impression is that the 1.3.x releases are not outrageously=20
more stable or usable the the typical CVS snapshot.

> 	1.3.5 - does the existence of 1.3.5pre mean that 1.3.5 is near at=20
> hand... should I wait for it?

The 1.3.5pre is there just to indicate that it comes after 1.3.4, yet
before 1.3.5.  (Maybe 1.3.4post would be better?)


> Other concerns:
> =95=A0I found that someone has a UserRegistration patch, but, alas, it is=
=20
> clear that that patch isn't against 1.3.4 - but which revision is it=20
> against?

I couldn't tell you.   As you have surmised the user registration
code in PhpWiki is in a state of flux, and is not currently working.
Reini promises this will change soon --- so you may want to wait
for that.   On the other hand, if you're really only serving a
dozen or so people, maybe it's not such a high priority.

> =95=A0The template system seems very much in flux.  Is there a 1.3.x=20
> version where it is at least considered settled on the way it will be=20
> for awhile?

I'm not sure what you mean.  The template structure and syntax
has been pretty stable since at least 1.3.3.  It is, however,
poorly documented.  Expect some spin-up time (and to ask for
help here) if you want to change the look in non-superficial
ways.

Re: [Phpwiki-talk] Bug with TightSubBlock and plugins in lists

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

On 26 Feb 2003 03:59:54 -0500
Todd Mokros <tm...@ne...> wrote:

> As a quick fix, the following patch seems to work for me.

Thanks for the report and the patch, Todd.  I've just checked
it into CVS.

Jeff

PS:
> The only problem would be that the is_a() function requires php >=
> 4.2.0.

(Note that we have our own, more portable, isa() function in
lib/stdlib.php.)

[Phpwiki-talk] Which release to install?

[Mark L. <ma...@gl...>]

All -

I've been pouring over various wiki's for the last week and I'd like to=20=

install phpWiki.  I'm confused about which release is the best to=20
install.  I'm setting up a wiki that I expect to have used by a=20
community of about a dozen or so people for about six months.  I don't=20=

think that we need many of the newer features (transclusion, calendars,=20=

blogs, etc...) but I think we'd make use of features that make wiki'ing=20=

easy (backlinks in a sidebar, subpages (?), etc...).  The other two=20
aspects I'm interested in is: Some amount of user management=20
(registration with e-mail would be nice...) and setting up my own theme=20=

so the wiki matches our 'look'.

Given all this, here's what I've gleaned about phpWiki versions:

	1.2.x - too out-of-date, though editing the 'look' is easy
	1.3.x - a good substrate work with, and the base for many =
features I=20
want
	1.3.3 - stable, but I worry about bugs I read about ('double=20
rendering', for one)
	1.3.4 - seems good, but in my installation UserPreferences =
doesn't=20
work and so I wonder about other features too....
	1.3.5pre - I noticed this in the CVS logs for index.php, though =
there=20
is no label for it.
	1.3.5 - does the existence of 1.3.5pre mean that 1.3.5 is near =
at=20
hand... should I wait for it?

Other concerns:
=95=A0I found that someone has a UserRegistration patch, but, alas, it =
is=20
clear that that patch isn't against 1.3.4 - but which revision is it=20
against?
=95=A0The template system seems very much in flux.  Is there a 1.3.x=20
version where it is at least considered settled on the way it will be=20
for awhile?

Lastly, I have to say that it is hard to know what features are in=20
which release - there doesn't seem to be an authoritative file with=20
major features and changes - just the release notes with the tar=20
files.... and those seem lacking.

Any light anyone can shed on this would be much appreciated.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
ma...@gl...

[Phpwiki-talk] regex por offline lazzy developper

[Tei <42...@in...>]

Hello, I am a OpenGL developper and use PhpWiki for my website
(telejano.berlios.de) and want to use
PhpWiki to generate some documentation. I am extremly lazzy. My lazyness is
enormeous. I dislike tipping extra chars.... I am writting a big
documentation doc, with phpwiki, and I will externalize has .xhtml files,
and compile has a .chm help file. But is slow to write the "[" and "]"
around keywords to make then links. 
I have opened the index.php file and inside its a php-regular expresion to
detect wikiwords. Can aniyone in this list provide me a regex for my needs?

I want to make wikiwords this way(*):

$func_ladder
$rscript_mikmod 

Actually i need to type:

[func_ladder]
[rscript_mikmod]

I know this is absurd, lame, and extremlly lazzy, but i am a lazzy men. I
am a coder, and for some reason i hate to write docs for my apps. Help me,
please.

-Tei

note:
Yes, I actually post that because I want to save 1 extra typping char per
wikiword, whooooo.....

[Phpwiki-talk] comments in generated pages

[Leiss, Klaus-G. 3. S-PP-RD-E. <Kla...@he...>]

Hello,
I have noticed that the are a lot off
comments in the generated pages. Some can,
if I understand the source correct, disabled
through the DEBUG variable. But for others,
e.g in the templates, it seems to me that
they could not not controlled in any way.
I think this is unfortunately for users
of a metered connection. Maybe there should
be a configuration option that controls
how much of this will be included in the
resulting pages.

Klaus Leiss
=20

Re: [Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Todd M. <tm...@ne...>]

As a quick fix, the following patch seems to work for me.
The only problem would be that the is_a() function requires php >=
4.2.0.  The method_exists function should work with all PHP4 versions,
but is an uglier way to check.  The patch might get wrapped by my
mailer, but should be easy patch by hand.


Index: BlockParser.php
===================================================================
--- BlockParser.php     (revision 52)
+++ BlockParser.php     (working copy)
@@ -418,7 +418,7 @@
         // If content is a single paragraph, eliminate the paragraph...
         if (count($this->_content) == 1) {
             $elem = $this->_content[0];
-            if ($elem->getTag() == 'p') {
+            if (is_a($elem, 'XmlElement') && $elem->getTag() == 'p') {
                 assert($elem->getAttr('class') == 'tightenable top bottom');
                 $this->setContent($elem->getContent());
             }



On Wed, 2003-02-26 at 03:25, Todd Mokros wrote:
> With current cvs, if you have a plugin as part of a list, TightSubBlock
> errors out with: "PHP Fatal error:  Call to undefined function: 
> gettag() in lib/BlockParser.php on line 421"
> 
> The problem is that $elem in that line of code is an instance of
> Cached_PluginInvocation, which does not inherit from XmlElement.  I'm
> not sure if plugins shouldn't be allowed in lists and this error caught,
> or other changes are needed to allow this.

-- 
Todd Mokros <tm...@ne...>

[Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Todd M. <nil...@ne...>]

With current cvs, if you have a plugin as part of a list, TightSubBlock
errors out with: "PHP Fatal error:  Call to undefined function: 
gettag() in lib/BlockParser.php on line 421"

The problem is that $elem in that line of code is an instance of
Cached_PluginInvocation, which does not inherit from XmlElement.  I'm
not sure if plugins shouldn't be allowed in lists and this error caught,
or other changes are needed to allow this.

--start example--
test:
  <?plugin HelloWorld ?>

or

* <?plugin HelloWorld ?>
--end example--


-- 
Todd Mokros <nil...@ne...>

Re: [Phpwiki-talk] pgsrc

[Martin G. <gim...@gi...>]

Carsten <car...@ya...> writes:

> Klaus suggested to me that simply removing the % sign from PhpWiki
> dump / pgsrc filenames might eliminate such esoteric ftp problems.
> It means a bit more work to write code for PhpWiki to decode these
> filenames but I believe it can be done. Any comments / suggestions?

Couldn't we simply substiture the '%' sign with some other
non-alphanumeric character except '-', '_' and '.' which is ignored by
rawurlencode()? Perhaps '~' og '='...

When decoding, this character is then changed back to '%' and the
normal rawurldecode() is used.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] Bug Report 2

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

> There's a problem with using urlencoding to generate filenames for
> HTML output. That's because: how do you link to filenames with '%'s
> in them? Well ... it depends on whether you're going through a
> webserver, or just getting the files off of local disk.
>
> I think the answer is to switch to some other encoding scheme for
> filenames (probably of our own devising). That would get around the
> '/' in filenames problem too.

How about using quoted-printable? That's a standard for of encoding,
but it's not used in URLs (it's used in MIME in mails) so the
webserver won't decode it for us.

This function encodes everything outside the alphanumeric ASCII
characters as quoted-printable and then uses the builtin PHP function
quoted_printable_decode() to see if the input matches the output:

<?php
function quoted_printable_encode($str) {

  $output =3D '';
  $length =3D strlen($str);
=20=20
  for ($i =3D 0; $i < $length; $i++) {
    $char =3D $str[$i];
    if (ereg('[a-zA-Z ]', $char)) {
      $output .=3D $char;
    } else {
      $output .=3D sprintf('=3D%02X', ord($char));
    }
  }
=20=20
  return $output;

}

$input =3D '!"#=A4%&/()=3D?`|+^\'*=E6=F8=E5=E9=E8=E4=F1';

$qp =3D quoted_printable_encode($input);

$output =3D quoted_printable_decode($qp);

echo "Input:  $input\n";
echo "QP:     $qp\n";
echo "Output: $output\n";

if ($input =3D=3D=3D $output) {
  echo "Match\n";
} else {
  echo "Mismatch!\n";
}

?>

With the quoted-printable encoding you're allowed to encode
everything, or to leave some printable characters untouched (that's
what makes this encoding 'printable' --- it can be decoded by humans),
see Section 6.7 in RFC 2045:

  http://www.ietf.org/rfc/rfc2045.txt

> Anyhoo, I'm probably not going to get to looking at it for a bit.
> If someone else wants to take a crack at it, feel free.

It's important for me to be able to dump a WikiWikiWeb as XHTML, as
I'm going to use PhpWiki as a site generation tool. So I'll probably
have a look at it...

--=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather =3D> Shows the current weather on your webpage and
PHP Shell   =3D> A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] pgsrc

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

On Tue, 25 Feb 2003 09:00:40 -0800
Jeff Dairiki <da...@da...> wrote:


> Now might be a good time to think hard, and more precisely define
> what the space of allowed wiki page names is.

One more thing.

Currently (at least with the SQL backends)
pagenames are limited to 100 characters maximum length.
(This should be more strictly enforced and checked for, since
there are currently some nasty bugs which show up when one
attempts to use longer page names.)

Is this okay, or should we consider changing it? 

Re: [Phpwiki-talk] Ampersand

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

> On Sun, 23 Feb 2003 01:06:41 +0100
> Martin Geisler <gim...@gi...> wrote:
>
>> I noticed how the database is locked and unlocked with each
>> operation, even on backends like PostgreSQL (and now also MySQL
>> with InnoDB) that support transactions. This seams to be something
>> that could benefit from a cleanup.
>
> (Of course one of the big headaches is to optimize the schema while
> keeping the backend API general enough that we can write and
> maintain the non-SQL backends (dba, flat-file) as well. Also, it's
> good to share code as much as possible between the different flavors
> of SQL, otherwise we get all kinds of funny bugs creeping into the
> lesser-used backends...)

Yes, it's not easy have an efficient backend that works with several
different databases, some of which cannot use SQL. Or rather, it's
somewhat easy if you just reimplement the entire backend for each
database, but that's an awful waste of code...

>> A similar thing would be a plugin that generates an index like the
>> ones you find in the back of most books.
>
> That's an interesting idea. I'm beginning to think about a more a
> general API to allow caching of plugin ouput (this would be
> integrated with the caching of marked-up page content). Once that's
> in place a plugin like that would be viable. (Until then ... its
> worth playing with but is going to be slow.)

It doesn't matter much if it's slow, it should only be used on static
WikiWikiWebs where you cannot search.

> A related idea would be a way to manually enter search terms on
> pages. E.g. something like "<?plugin Keywords platypus, funny
> animals ?>" These could be used to form a real book-style index, and
> to generate a meta keywords tag for search engines...

That sounds like a really good idea! It would give much better results
than a raw index of all the words, because there keywords would be
selected with care...

Is there a way for a plugin to save some data (in this case the
keywords for a page) in a central place, so that an MakeIndex plugin
could get hold of the data to print an index?

> Basically the same as Category pages, I guess...

Yes, but much more fine-grained.

> (Maybe we should generate a keywords meta tag from Category links on
> each page?)
>
> Okay, so now I'm just rambling....

No :-) I like the idea of using links to Category pages as meta
information!

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Cheap web hosting (was Re: [Phpwiki-talk] pgsrc)

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

On Tue, 25 Feb 2003 10:28:06 +0100
"Leiss, Klaus-Guenter 3188 S-PP-RD-E2"
<Kla...@he...> wrote:

> The problem is finding one that does not give me the same problems,
> but also does not cost me a hand and an arm. It is strictly a hobby
> site, at the moment I'm paying 5 Euro per Month, I would not mind
> paying up to 10 Euro. In germany I have not found webhosters that
> have good features like shell account for this price.

This may or may not be useful to y'all over there in Europe,
but I've been using http://www.digitalspace.net/ for a few years
now and am pretty happy.  They're not without flaws but for
$36 per year (for a shell account, PHP, MySQL) it's hard to go wrong
for "hobby site" hosting.

Re: [Phpwiki-talk] pgsrc

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

On Tue, 25 Feb 2003 10:49:35 +0100
"Leiss, Klaus-Guenter 3188 S-PP-RD-E2"
<Kla...@he...> wrote:

> > Klaus suggested to me that simply removing the % sign from 
> > PhpWiki dump 
> > / pgsrc filenames might eliminate such esoteric ftp problems. 
> > It means 
> > a bit more work to write code for PhpWiki to decode these 
> > filenames but 
> > I believe it can be done. Any comments / suggestions?

> It was not only because of my ftp problem, but also because
> somebody ( I think jeff ? ) mentioned something about a
> slash problem.

All right here's a bit more ramblings and background about the
problem as I see it.

The slash problem is ancillary.  The real problem I see is as follows.

There are (at least) two common uses for static (X)HTML dumps:
  1. Dump to local file-system for off-line browsing.
  2. Static wiki image to be served up by a web-server for a 
     high-traffic, but infrequently edited wiki.

Now currently a page name like "A Page" gets dumped to
a file named "A%20Page.html".  The problem is, in case 1,
one must link to that page like:

 <a href="A%20Page.html">A Page</a>

While in case 2, you must double escape the %:

 <a href="A%2520Page.html">A Page</a>

The difference arises because in the second case, there's a
web server involved, and the web-server urldecodes the URL
before interpreting it.


So the problem is specifically one of using urlencoding to
generate file names.

I'm not sure what the best solution is.

I think (though I haven't though too hard about it) that
using something like MIME quoted-printable encoding
instead of urlencode() would work fine.  (The two encodings
are basically the same, except that quoted-printable uses an
equals sign ('=') instead of a percent sign as the escape
character.)  ( "A=20Page.html" )

Perhaps we should think ahead and pick an encoding which
is more Unicode friendly?

We also want to think about ways to encode page actions within
XHMTL dump filenames.  For example we might want to dump all
the backlinks for each page too (or dump all the versions of each
page, or...)


As for the slash problem: changing encodings could be used to 
fix the slash problem.  I'm not sure that's the best solution.
It may be better to actually reproduce the directory structure
implied by the slashes (with URLs in links from a subpage
would have have to be prefaced by the appropriate number of ../s.)




Some random points:

Encoding to completely alphanumeric [a-zA-Z0-9] filenames,
I think, is impractical, if only because that means we'll have
to encode nearly every page name.  We're going to have to
use at least one (funny character) in the encoding.


I don't really see this ftp-server problem as significant.
(Until someone convinces me it's a really common problem.
It seems appalling to me that a web host would not admit
that an ftp server which can't be used to upload a file
with a perfectly legal name is broken.)

(BTW, Klaus, did you have any luck using zipped pgsrc?)



Now might be a good time to think hard, and more precisely define
what the space of allowed wiki page names is.

E.g., since the introduction of subpages, page names beginning
with '/' have implicitly become illegal, since there's no way to
link to them. ('[/Page]' is always interpreted as a link to a subpage
of the page on which the link appears.)

So, if anyone had a wiki with a page name which began with a '/',
and then upgraded to a PhpWiki which subpages, now they can't
access their page anymore.

Another example is pages containing the '#' character.  Introduction
of the named anchor syntax broke those pages, since now '[Page#Two]'
is a link to the anchor named "Two" within the page named "Page".
(This is now "fixed" by supporting the escape character within bracket
links, so you can used '[Page~#Two]' to link to the page named
"Page#Two".  This is all very confusing though...)

It might be worth excluding certain characters from being allowed in
page names.

 0. Control characters should explicitly be illegal within page names.

 1. '/' only allowed as subpage-separator.

 2. Disallow '#' in page names?  That might be too painful, since
    "Bulletin #23" seems like a perfectly reasonable page name.

 3. Disallow ':'?  Again, one can envision reasonable page names
    containing a colon, but making it illegal would make parsing of
    InterWiki:Links much easier.  (E.g. one could recognized un-registered
    interwiki links as being such.)

 4. Disallow ';'?  If this were done, one could come up which a much
    cleaner MagicPhpWikiURL syntax: [SomePage;version=3] (or [SomePage;3])
    [AnotherPage;action=edit] (or [AnotherPage;edit]).

 5. It is currently hard but possible to create pages with leading and/or
    trailing space in the name.  This should probably be outlawed.
    In fact, we should probably canonicalize the spacing in page names:
    strip leading and trailing whitespace, convert each occurance
    of (possibly repeated) internal whitespace to single space characters.



Enough ramblings.   Comments welcome.

RE: [Phpwiki-talk] pgsrc

[Leiss, Klaus-G. 3. S-PP-RD-E. <Kla...@he...>]

Hello,

>=20
> Klaus suggested to me that simply removing the % sign from=20
> PhpWiki dump=20
> / pgsrc filenames might eliminate such esoteric ftp problems.=20
> It means=20
> a bit more work to write code for PhpWiki to decode these=20
> filenames but=20
> I believe it can be done. Any comments / suggestions?
>=20
> Carsten
It was not only because of my ftp problem, but also because
somebody ( I think jeff ? ) mentioned something about a
slash problem. What I really wanted to suggest is, at all
places that one goes through the url encoding for pagenames,
drop the % char, this would get internal pagesnames that
are straight alphanumeric. I think the representation to
the outside would be the same, since the links in the pages
would not affected. The only place where you would see the
mangled page names would be in the (X)HTML dumps. If would
want to avoid this, I think we have to have a translation
table between original page name and the mangled version.=20

Klaus Leiss
=20

RE: [Phpwiki-talk] pgsrc

[Leiss, Klaus-G. 3. S-PP-RD-E. <Kla...@he...>]

Hello,

>=20
> "Leiss, Klaus-Guenter 3188 S-PP-RD-E2" wrote:
>=20
> > I have a problem with pgsrc. My webspace provider has=20
> > only access through ftp and I got problems downloading=20
> > PhpWikiAdministration%2FRemove. I have tried various
>
> I had the same problem, it was the FTP server not allowing certain=20
> characters in filenames (not even for rename). Ask your provider.
I have exactly the same problem.
=20
> Suggestions:
>=20
> - ask your provider to fix this

> - ask him for a shell account (and upload an archive or rename the=20
> file). You should know what you do.
shell account not available for my account.

> - look for an solution to create the file with a script. Use this=20
> with care - you should know what you do.
I have used that.

> - go to another provider.
>=20
> Oliver
The problem is finding one that does not give me the same problems,
but also does not cost me a hand and an arm. It is strictly a hobby
site, at the moment I'm paying 5 Euro per Month, I would not mind
paying up to 10 Euro. In germany I have not found webhosters that
have good features like shell account for this price.

Klaus Leiss

Re: [Phpwiki-talk] pgsrc

[Carsten <car...@ya...>]

Klaus suggested to me that simply removing the % sign from PhpWiki dump 
/ pgsrc filenames might eliminate such esoteric ftp problems. It means 
a bit more work to write code for PhpWiki to decode these filenames but 
I believe it can be done. Any comments / suggestions?

Carsten

Re: [Phpwiki-talk] pgsrc

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

"Leiss, Klaus-Guenter 3188 S-PP-RD-E2" wrote:

> I have a problem with pgsrc. My webspace provider has 
> only access through ftp and I got problems downloading 
> PhpWikiAdministration%2FRemove. I have tried various

I had the same problem, it was the FTP server not allowing certain 
characters in filenames (not even for rename). Ask your provider.

Suggestions:

- ask your provider to fix this
- ask him for a shell account (and upload an archive or rename the 
file). You should know what you do.
- look for an solution to create the file with a script. Use this 
with care - you should know what you do.
- go to another provider.

Oliver

[Phpwiki-talk] performance prob, but only with InternetExplorer

[<je...@au...>]

Hi all,

I'm wondering if anyone else has noticed any problems with _just_
internet explorer.  With mozilla or opera it runs quite fast and such,
but with internet explorer, it's almost like something is having to
timeout first before it actually serves the page.

PhpWiki ver 1.3.4

thanks in advance for any help on this,
jeremy

-- 
Jeremy Kelley  <je...@au...>
Information Security Analyst

Re: [Phpwiki-talk] pb with 1.3.4 version

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

Hi Didier,

Try this patch to lib/FileFinder.php. It should fix the problem for you 
but it has not been tested on an actual WindowsNT machine yet.

Carsten

RCS file: /cvsroot/phpwiki/phpwiki/lib/FileFinder.php,v
retrieving revision 1.12
diff -U2 -r1.12 FileFinder.php
--- FileFinder.php	28 Jan 2003 21:06:05 -0000	1.12
+++ FileFinder.php	24 Feb 2003 19:02:18 -0000
@@ -401,5 +401,6 @@
      static $winnt;
      if (isset($winnt)) return $winnt;
-    $winnt = preg_match('/^Windows NT/', php_uname());
+    //$winnt = preg_match('/^Windows NT/', php_uname());
+    $winnt = (PHP_OS == "WINNT"); // example from 
http://www.php.net/manual/en/ref.readline.php
      return $winnt;
  }


On Monday, February 24, 2003, at 02:27  am, Didier Bretin wrote:

> FileFinder.php:403: Warning[2]: php_uname() has been disabled for 
> security reasons

Re: [Phpwiki-talk] pgsrc

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

> My webspace provider has 
> only access through ftp and I got problems downloading 
> PhpWikiAdministration%2FRemove.

I just tried uploading that file from Linux using both the
'ftp' and 'ncftp' ftp clients and had no problem.
Maybe it's a problem with your provider's ftp server?


> I have read in the
> source that there is a new (zip file ) and an old stile
> single files. Does this mean i have only to compress the
> files to a zip file and put this info in index.php.

Yes.  That should work fine.  I haven't tested it in awhile though,
so who knows.   (Caveat: If your PHP doesn't have zlib support, then
PhpWiki can only read uncompressed zip files.)

> What should i do with the localisated versions.

Err... well... that may be a bit of a problem.

The most straightforward thing to do would be to copy into
one directory all of the pgsrc you want in your wiki. Then
zip it into a zip file, upload the zip file, and point
WIKI_PGSRC at that.  Next set your DEFAULT_LANGUAGE to 'en',
to keep PhpWiki from looking for the localized pgsrc at all.
After you load up the wiki, you can set DEFAULT_LANGUAGE back
to whatever you really want it to be.


> Another question is should the default version not be the "new".

It's more convenient to maintain/inspect pgsrc exploded in a directory
than in a zip file.  That's why we keep doing it that way.

> I don't know how many other people get the same problems.

I don't think it should be common.  It sound like a real bug
in something.  One should be able to FTP file with %'s in their names.

> Since I mentioned PhpWikiAdministration%2FRemove, what
> should it do. If I try it on my server at home I got
> if I remenber right "no pages selected" or something like
> that.

I just changed the default behavior so that it only lists
pages which have been "deleted".  ("Deleted" mean someone
has edited the page and set the page content to the empty
string --- when you do this, for most purposes PhpWiki treats
the page as non-existent.)

If you want it to list all pages add the arg min_age=-1.
(Either as a query arg, or, if you want to change the default,
edit PhpWikiAdministration/Remove and add "min_age||=-1" to
the plugin args.)

[Phpwiki-talk] Get Instant Access Now

[July <ju...@ya...>]

<HTML><HEAD><TITLE>Adult Dreams</TITLE></HEAD>
<BODY BGCOLOR=#FFFFFF><div align="center">
<TABLE WIDTH=600 BORDER=0 CELLPADDING=0 CELLSPACING=0>
<TR>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="spacer.gif" WIDTH=153 HEIGHT=1 BORDER=0></A></TD>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="spacer.gif" WIDTH=57 HEIGHT=1 BORDER=0></A></TD>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="spacer.gif" WIDTH=83 HEIGHT=1 BORDER=0></A></TD>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="spacer.gif" WIDTH=104 HEIGHT=1 BORDER=0></A></TD>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="spacer.gif" WIDTH=59 HEIGHT=1 BORDER=0></A></TD>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="spacer.gif" WIDTH=144 HEIGHT=1 BORDER=0></A></TD>
</TR>
<TR>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_01.jpg" WIDTH=210 HEIGHT=87 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_02.jpg" WIDTH=187 HEIGHT=87 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_03.jpg" WIDTH=203 HEIGHT=87 BORDER=0></A></TD>
</TR>
<TR>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_04.jpg" WIDTH=210 HEIGHT=87 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_05.jpg" WIDTH=187 HEIGHT=87 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_06.jpg" WIDTH=203 HEIGHT=87 BORDER=0></A></TD>
</TR>
<TR>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_07.jpg" WIDTH=210 HEIGHT=91 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_08.jpg" WIDTH=187 HEIGHT=91 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_09.jpg" WIDTH=203 HEIGHT=91 BORDER=0></A></TD>
</TR>
<TR>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_10.jpg" WIDTH=153 HEIGHT=107 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_11.gif" WIDTH=140 HEIGHT=107 BORDER=0></A></TD>
<TD COLSPAN=2><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_12.jpg" WIDTH=163 HEIGHT=107 BORDER=0></A></TD>
<TD><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_13.jpg" WIDTH=144 HEIGHT=107 BORDER=0></A></TD>
</TR>
<TR>
<TD COLSPAN=6><A HREF="http://www.maximumcash.com/cgi-bin/maxcash.cgi?id=sexo69&ps=nadultd"><IMG SRC="http://mipagina.cantv.net/sexo69/imag/ad_fpa_14.gif" WIDTH=600 HEIGHT=28 BORDER=0></A></TD>
</TR>
</TABLE>
<p align="center"><font color="#9966FF" size="2" face="Arial, Helvetica, sans-serif">THIS 
  MESSAGE IS BEING SENT IN COMPLIANCE WITH PENDING EMAIL BILLS &amp; LAWS:<br>
  SECTION 301. PER SECTION, PARAGRAPH (a) (2) (c) of S. 1618. This message is<br>
  not intended for residents in the State of WA, NV, CA &amp; VA. Screening of<br>
  addresses has been done to the best of our technical ability. We honor all<br>
  removal requests.</font></p>
<p align="center"><font color="#9966FF" size="2" face="Arial, Helvetica, sans-serif">You 
  are currently subscribed to receive our special emails. to unscribe,<br>
  please reply with Remove on your subject line.</font></p>
<p align="center"><font color="#9966FF" size="2" face="Arial, Helvetica, sans-serif"><br>
  </font> </p>
</div></BODY></HTML>

Re: [Phpwiki-talk] pgsrc

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

Hi Klaus,

I am guessing the strange filename is causing problems for some ftp 
clients (or perhaps your server) who tries to automatically decode the 
%2F into a "/".

We had to take this approach because CVS was designed for and only 
works consistenyly with 7-bit US-ASCII filenames. As Jeff mentioned in 
his other message we may need to look at designing a new method to 
store filenames because it can also cause problems for the XHTML dump 
(view from local hard drive versus on a web server).

When loading files, you would need to specify the directory where you 
uploaded the files, relative to PhpWiki. So if you upload into a 
directory called "pages" inside phpwiki:

     pages/PhpWikiAdministration%2FRemove

or for localized files (so long as you uploaded them there:)

     locale/de/pgsrc/MyPage.zip

I believe that simply zipping the file should work in the same way.

If you have access to the global /tmp directory on the server via FTP 
that should work too, but add "/" to the front for absolute path:

    /tmp/phpwiki/

Using the above, PhpWiki should load all pages found in "/tmp/phpwiki/".

I hope this helps,

Carsten

On Monday, February 24, 2003, at 03:53  am, Leiss, Klaus-Guenter 3188 
S-PP-RD-E2 wrote:

> Hello,
> I have a problem with pgsrc. My webspace provider has
> only access through ftp and I got problems downloading
> PhpWikiAdministration%2FRemove. I have tried various
> ftp clients on linux and windows. I got the same problem
> with some of the localisated files. Since I can only
> connect through ftp, no ssh or telnet i can not download
> the complete archive of phpwiki.  I have read in the
> source that there is a new (zip file ) and an old stile
> single files. Does this mean i have only to compress the
> files to a zip file and put this info in index.php. What
> should i do with the localisated versions. Another
> question is should the default version not be the "new".
> I don't know how many other people get the same problems.
>
> Since I mentioned PhpWikiAdministration%2FRemove, what
> should it do. If I try it on my server at home I got
> if I remenber right "no pages selected" or something like
> that.
>
> Klaus Leiss

[Phpwiki-talk] pgsrc

[Leiss, Klaus-G. 3. S-PP-RD-E. <Kla...@he...>]

Hello,
I have a problem with pgsrc. My webspace provider has=20
only access through ftp and I got problems downloading=20
PhpWikiAdministration%2FRemove. I have tried various
ftp clients on linux and windows. I got the same problem
with some of the localisated files. Since I can only
connect through ftp, no ssh or telnet i can not download
the complete archive of phpwiki.  I have read in the
source that there is a new (zip file ) and an old stile
single files. Does this mean i have only to compress the
files to a zip file and put this info in index.php. What
should i do with the localisated versions. Another
question is should the default version not be the "new".
I don't know how many other people get the same problems.

Since I mentioned PhpWikiAdministration%2FRemove, what
should it do. If I try it on my server at home I got
if I remenber right "no pages selected" or something like
that.

Klaus Leiss