phpwiki-talk

Re: [Phpwiki-talk] 1.3.2 almost there...

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

Steve Wainstead schrieb:
> ...if Sourceforge ever lists the tarball as available on the downloads
> page, we'll have a release! I've waited 20 minutes now and it still hasn't
> appeared, even though I uploaded it twice. Sigh.

rmdir docs

Re: [Phpwiki-talk] 1.3.2 almost there...

[Lawrence A. <Law...@th...>]

Congratulations on the birth of your latest.

It's on sf now - I've just seen it

Don't forget to update the download link on the wikipage itself

Lawrence

> 
> ...if Sourceforge ever lists the tarball as available on the downloads
> page, we'll have a release! I've waited 20 minutes now and it still
> hasn't appeared, even though I uploaded it twice. Sigh.
> 
> ~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
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

[Phpwiki-talk] 1.3.2 almost there...

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

...if Sourceforge ever lists the tarball as available on the downloads
page, we'll have a release! I've waited 20 minutes now and it still hasn't
appeared, even though I uploaded it twice. Sigh.

~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] German translations need proofing (volunteers?)

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

On Tue, 18 Dec 2001, Carsten Klapp wrote:

>
> Ok, I removed the fuzzies with emacs--what a cool little program! (I was
> used to using pico, never even new what emacs was.)

Gott im Himmel. You've been using Pico to edit source files? My fingers
hurt just thinking about it!

~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

[Phpwiki-talk] PHPWiki 1.3.1 (fwd)

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

---
                  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
---------- Forwarded message ----------
Date: Tue, 18 Dec 2001 16:28:38 -0500
From: Michael Gentry <Bla...@ma...>
To: sw...@pa...
Subject: PHPWiki 1.3.1

I've downloaded and setup version 1.3.1 and I've noticed a few weird
things ...

The first weird thing is that none of the search functions would work
unless I set this in index.php:

     define('SCRIPT_NAME', '/index.php');
     define('USE_PATH_INFO', true);

Of course, these may not be related, but it got things working.

You should also be aware that PNG files (like the logo) do not display
in Internet Explorer (at least IE 5.1 on the Macintosh, not positive
about IE on Windows).

When I do a FindPage (for example) and enter something like "SandBox" in
the TitleSearch field, I get these PHP errors:

Warning: The call_user_method() function is deprecated, use the
call_user_func variety with the array(&$obj, "method") syntax instead in
/usr/local/apache_1.3.20/vhosts/phpwiki-1.3.1/lib/ErrorManager.php on
line 138

lib/TextSearchQuery.php:144: Notice[8]: The call_user_method() function
is deprecated, use the call_user_func variety with the array(&$obj,
"method") syntax instead

I'll probably go hacking to try and fix that shortly.  Just though you
should be aware of them.  (It still works, just looks ugly.)

Thanks!

/dev/mrg

PS. Is there any information on how to setup multiple users/logins?
Also, the logout code doesn't seem exactly right ... might have to go
look into that shortly, too.
---
Gasoline is cheaper than bottled water.

[Phpwiki-talk] version 1.3.2

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

I think we're due for a release; we've had a number of new features and
document changes to warrant it. If there are no objections I will do this
tomorrow afternoon, eastern time, USA.

~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

[Phpwiki-talk] Thanks re: Sections in IncludePage plugin

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

Jeff,

Thank you for adding the section include capability to the IncludePage 
plugin so quickly.

When I looked at your code I dismally came to the conclusion that it would 
have taken me days (at best) to come up with a solution most certainly not 
as efficient  or as elegant as yours. :-)

The use of 'regular expressions' invariably seem to imbue allusions of 
"Great Powers" to the inexperienced (well *to me* anyway; somehow I once 
managed to conjure up a few file-processing sh scripts that used simple 
incantations of 'sed' and 'awk', Hah, and looking back I have no idea how 
I did it).

Carsten

Re: [Phpwiki-talk] German translations need proofing (volunteers?)

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

Hi,

Found my problem using sprintf in the html templates!

Turns out that variables in bracket form on the templates need to be 
quoted "${var}" or else they aren't eval()'d.

-<?php echo sprintf(_("Last edited on %s."),${LASTMODIFIED}); ?>
+<?php printf(_("Last edited on %s."),"${LASTMODIFIED}"); ?>

Thanks for the tip about printf.


Also the new variable reordering functions sound great. I'll try them 
later today.


carsten

On Tuesday, December 18, 2001, at 08:09  pm, Jeff Dairiki wrote:

> Carsten Klapp said:
>
>> 1. Variable reordering.
>
> That's a problem.  PHP doesn't seem to support the printf
> argument reordering...
>
> I'll see if I can think of a work-around.
>
>> 2. Strings in the html template don't seem to substitute for %s.
>> I tried:
>>          <?php echo sprintf(_("haystack %s"),_("needle")); ?>
>
> That works for me.  I just tried it.
> Also note that 'printf(...);' is equivalent to 'echo sprintf(...);'.

[Phpwiki-talk] =?iso-8859-1?Q?Re:_[Phpwiki-talk]_German_translations_need_proofing_(volunteers=3F)?=

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

Carsten Klapp said:

> 1. Variable reordering. In the case where word ordering differs during
> translation, the gettext manual suggests the following syntax to force
> the  correct text substitution:
>
>  #: ../lib/diff.php:251
>  #, c-format
>  msgid "Differences between %s and %s of %s."
>  msgstr "Der Unterschiedsergebnis von %3$s, zwischen %1$s und %2$s."

I've just checked three new functions into lib/stdlib.php.
__printf, __sprintf, and __vsprintf.  These behave like the
PHP's built-in printf functions, except:

 1. They pass the format string through gettext().
 2. The support the above method of argument reordering.

(I've also fixed locale/Makefile, so that xgettext will find
the format strings of __printf()s, __sprintf()s, __vsprintf()s...)



For the argument reordering to work, code like:

  printf(gettext("..format string.."), ..., ...);

needs to be changed to:

  __printf("..format string..", ..., ...);

(And similarly for sprintf.)

[Phpwiki-talk] =?iso-8859-1?Q?Re:_[Phpwiki-talk]_German_translations_need_proofing_(volunteers=3F)?=

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

Carsten Klapp said:

> 1. Variable reordering.

That's a problem.  PHP doesn't seem to support the printf
argument reordering...

I'll see if I can think of a work-around.

> 2. Strings in the html template don't seem to substitute for %s.
> I tried:
>          <?php echo sprintf(_("haystack %s"),_("needle")); ?>

That works for me.  I just tried it.
Also note that 'printf(...);' is equivalent to 'echo sprintf(...);'.

Re: [Phpwiki-talk] server shift => wiki problem

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

Sorry, I made a mistake in my previous instructions. The *correct* way to 
add a path in the php.ini file follows:

include_path = ".:/usr/local/whatever/share/php";

(No changes to the rest of the instructions.)


I also fixed my instructions which Adam added to the Wiki FAQ.
  <http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions>


Carsten


On Tuesday, December 18, 2001, at 04:28  pm, Carsten Klapp wrote:

>
> Hi Tara,
>
> Yes this happened to me too, Jeff explained the problem as written in 
> index.php. This error indicates PHPWiki can't find its PEAR libraries.
>
> (I added a couple lines specifically mentioning this error to index.php. 
> Probably it should go in the docs too.)
>
> 1. Do a search for PEAR.php to find out where it is. On unix-ish systems 
> this would be:
>    locate PEAR.php
> 2. Add the path to this file into index.php, something like:
>    ini_set('include_path', '.:/usr/local/whatever/share/php');
> 2. Alternatively you can edit the php.ini (probably at /usr/local/lib/php.
> ini) file and add the path in there (if you have root access to the 
> server)
> . The advantage of this is that php will be able to find it's PEAR 
> libraries even for other non-wiki php software:
>    ini_set('include_path', '.:/usr/local/whatever/share/php');
>
> PhpWiki already searches a number of common directories for the PEAR 
> libraries, so I'd like to see what directory yours was installed into.
>
> Carsten

Re: [Phpwiki-talk] German translations need proofing (volunteers?)

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

Ok, I removed the fuzzies with emacs--what a cool little program! (I was=20=

used to using pico, never even new what emacs was.)

Still verifying which strings weren't picked out by xgettext.

A couple more problems:

1. Variable reordering. In the case where word ordering differs during=20=

translation, the gettext manual suggests the following syntax to force =
the=20
correct text substitution:

  #: ../lib/diff.php:251
  #, c-format
  msgid "Differences between %s and %s of %s."
  msgstr "Der Unterschiedsergebnis von %3$s, zwischen %1$s und %2$s."

PHP doesn't like it. Probably the example from the gettext manual refers=20=

to C code.

  PHP Warnungen
  locale/de/LC_MESSAGES/phpwiki.php:57: Notice[8]: Undefined variable: s

What to do?


2. Strings in the html template don't seem to substitute for %s.
I tried:
          <?php echo sprintf(_("haystack %s"),_("needle")); ?>

and some permutations of $_() as they are used elsewhere on the page:
          <?php echo sprintf($_("haystack %s"),_("needle")); ?>


The purpose is to make the three following changes, the first and second=20=

are the most important:

1.=3D=3D=3D=3D
#: ../templates/browse.html:97 ../templates/editpage.html:71
-msgid "You are signed in as"
-msgstr "Du bist eingemeldet als"

+msgid "You are signed in as %s"
+msgstr "Du bist als %s eingemeldet"

2.=3D=3D=3D=3D
  #: ../templates/editpage.html:80
-msgid "You can change the size of the editing area in"

+msgid "You can change the size of the editing area in %s"

3.=3D=3D=3D=3D
-#: ../templates/editpage.html:82
-msgid "See"
-msgstr "Sehe"
  #: ../templates/editpage.html:82
  msgid "GoodStyle"
  msgstr "GuterStil"
-#: ../templates/editpage.html:82
-msgid "tips for editing."
-msgstr "tips f=B8rs Editieren."

+msgid "See %s tips for editing."
+msgstr "Sehe %s tips f=B8rs Editieren."

=3D=3D=3D=3D


Carsten

Re: [Phpwiki-talk] server shift => wiki problem

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

Hi Tara,

Yes this happened to me too, Jeff explained the problem as written in 
index.php. This error indicates PHPWiki can't find its PEAR libraries.

(I added a couple lines specifically mentioning this error to index.php. 
Probably it should go in the docs too.)

1. Do a search for PEAR.php to find out where it is. On unix-ish systems 
this would be:
    locate PEAR.php
2. Add the path to this file into index.php, something like:
    ini_set('include_path', '.:/usr/local/whatever/share/php');
2. Alternatively you can edit the php.ini (probably at /usr/local/lib/php.
ini) file and add the path in there (if you have root access to the server)
. The advantage of this is that php will be able to find it's PEAR 
libraries even for other non-wiki php software:
    ini_set('include_path', '.:/usr/local/whatever/share/php');

PhpWiki already searches a number of common directories for the PEAR 
libraries, so I'd like to see what directory yours was installed into.

Carsten

// Part Zero: If PHP needs help in finding where you installed the
//   rest of the PhpWiki code, you can set the include_path here.

// NOTE: phpwiki uses the PEAR library of php code for SQL database
// access.  Your PHP is probably already configured to set include_path
// so that PHP can find the pear code.  If not (or if you change
// include_path here) make sure you include the path to the PEAR
// code in include_path.  (To find the PEAR code on your system, search
// for a file named 'PEAR.php'.   Some common locations are:
//
//   Unixish systems:
//     /usr/share/php
//     /usr/local/share/php
//   Mac OS X:
//     /System/Library/PHP
//
// The above examples are already included by PhpWiki.
// You shouldn't have to change this unless you see a WikiFatalError:
//   lib/FileFinder.php:82: Fatal[256]: DB.php: file not found
//
//ini_set('include_path', '.:/where/you/installed/phpwiki');

Am Tuesday den, 18. December 2001, um 15:03, schrieb Tara Star:

> Hi all!
>
> My site has changed servers and I'm getting a new (unexplainable, as far 
> as the sysadmin and I are concerned) error:
>
> lib/FileFinder.php:82: Fatal[256]: DB.php: file not found
>
> lib/FileFinder.php:82: Fatal[256]: DB.php: file not found
>
> (try http://spirolattic.net/)
>
> Does anybody have an idea what the problem can be?
>
> Thanks a lot,
>
> Tara

[Phpwiki-talk] server shift => wiki problem

[Tara S. <te...@cl...>]

Hi all!

My site has changed servers and I'm getting a new (unexplainable, as far=20
as the sysadmin and I are concerned) error:

lib/FileFinder.php:82: Fatal[256]: DB.php: file not found

lib/FileFinder.php:82: Fatal[256]: DB.php: file not found

(try http://spirolattic.net/)

Does anybody have an idea what the problem can be?

Thanks a lot,

Tara
--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://spirolattic.net/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] German translations need proofing (volunteers?)

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

On Tue, 18 Dec 2001 04:26:34 -0500
"Carsten Klapp" <car...@ma...> wrote:

> - There are a few translated strings which still render in english, 
> offhand I don't know why (the word "edit" on the Diff page, for one 
> example).

That's because the translation for "Edit:" is tagged as 'fuzzy' in the
local/po/de.po.  "Fuzzy" means that (at some point) the translation was
_automagically_  (had to use that word, just for you :-) ) guessed 
by msgmerge base on similarity to some other translation already
in de.po.  (Msgfmt, by default, ignores the 'fuzzy' entries.)

If you use po-mode in emacs, it's very easy to find and manipulate these
flags ('f' takes you to the next fuzzy translation, 'TAB' un-fuzzies it.)


> - There are other strings I know of that weren't automatically picked
out > of the source code by xgettext for inclusion in the .po files, and
on > quick inspection of the files I couldn't yet see why.

Which ones?

[Phpwiki-talk] German translations need proofing (volunteers?)

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

Hi,

German translations for PhpWiki 1.3 are 90% complete. I welcome any 
suggestions for change, especially the grammar. :-)

Cheers,
Carsten

P.S.
- There are a few translated strings which still render in english, 
offhand I don't know why (the word "edit" on the Diff page, for one 
example).
- There are other strings I know of that weren't automatically picked out 
of the source code by xgettext for inclusion in the .po files, and on 
quick inspection of the files I couldn't yet see why.

[Phpwiki-talk] FrischeSeiten

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

Hi,

I've added some more German translations, and updated certain pages to=20=

work with the new plugins in the Development branch.

I had some difficulty with the ISO translations during uploading but I=20=

think I got it in the end. If someone could verify that the umlauts =
(=E4=EB=F6=FC=DF)
  arrived ok please let me know.

Also the old file /locale/de/pgsrc/GaesteBuch can now be deleted. The =
new=20
file G%E4steBuch was added to replace it.

Carsten

[Phpwiki-talk] css style names

[Lawrence A. <Law...@th...>]

This thought was triggered by seeing Carsten's suggestion to replace 
<B> tags on the summary page with a style called "summary".

Could we standardise on styles called "wiki-summary", "wiki-diff" etc (I 
think we do already use the latter)?

Just helps me avoid conflicts with other style sheets I use which use 
more generic names.

Lawrence Akka--------------------------------------------------------
Confidentiality Notice

The information contained in this e-mail is confidential.  It is for the
use of the named recipient only.  If you are not the named recipient, 
please destroy and do not disclose the contents of this e-mail
to any other person, or copy it.  Thank you for your co-operation.

[Phpwiki-talk] 3 recent changes ideas

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

Hi Jeff,

I have a few suggestions for the recent changes plugin.

* Use css <span class="summary"> for the summary instead of <b>.

* Exclude the [brackets] from the bold effect, I think this helps to make 
the list a little easier to read (look at the code below to see what I 
mean by exclude).

* I don't know how easy this is to do: clickable WikiWords in the subject.

"What you say !!"

Carsten


+++ phpwiki/lib/plugin/RecentChanges.php	2001/12/15 05:15:52
@@ -186,8 +186,9 @@

      function format_revision ($rev) {
          if ( ($summary = $this->summary($rev)) )
-            $summary = QElement('b', "[$summary]");
+            $summary = "[" . Element('span', array('class' => "summary"),
+                                             "$summary") . "]";

          $class = 'rc-' . $this->importance($rev);

          return Element('li', array('class' => $class),



+++ phpwiki/phpwiki.css

.summary  { font-weight: bold; }

Re: [Phpwiki-talk] rss for RecentChanges

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

Thanks, you've answered my question too (even before I had a chance to ask 
it!) :-)

My browser OmniWeb also downloads the RSS file as a gz archive. No problem 
with that, it just surprised me.

Carsten

On Friday, December 14, 2001, at 12:17  am, Jeff Dairiki wrote:

> On seemingly gzipped data:
>
> Currently, PhpWiki (1.3) uses PHP's ob_gzhandler() function to
> gzip-compress data sent to clients who send an 'Accept-Encoding:
> application/gzip' header in their request.  When this happens, the fact
> that the data is compressed in indicated by a 'Content-Encoding' header in
> the response --- then the client/browser is supposed to uncompress the
> data before doing anything else with it.
>
> If you're seeing seemingly random (gzipped looking) binary data, then
> something is wrong with this process.  (The RSS data is XML, and should
> look like something if you look at it with a text viewer.)

Re: [Phpwiki-talk] rss for RecentChanges

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

My opinion is that PhpWiki's RSS should follow these three XML 1.0 
recommendations (but I haven't yet checked whether it actually does or not)
.

1. RSS files are written in XML, so text/xml or application/xml should be 
used:

RFC 3023: XML Media Types <ftp://ftp.isi.edu/in-notes/rfc3023.txt>

 >If an XML document -- that is, the unprocessed, source XML document
 >   -- is readable by casual users, text/xml is preferable to
 >   application/xml.  MIME user agents (and web user agents) that do not
 >   have explicit support for text/xml will treat it as text/plain, for
 >   example, by displaying the XML MIME entity as plain text.
 >   Application/xml is preferable when the XML MIME entity is unreadable
 >   by casual users.  Similarly, text/xml-external-parsed-entity is
 >   preferable when an external parsed entity is readable by casual
 >   users, but application/xml-external-parsed-entity is preferable when
 >   a plain text display is inappropriate.

2. It appears some RSS implementations omit the XML declaration line. I 
believe many XML readers will interpret this as incorrect XML.

XML Declaration: <http://www.w3.org/TR/REC-xml#dt-xmldecl>

 > XML documents should begin with an XML declaration which specifies
 > the version of XML being used; the document type declaration must
 > appear before the first element in the document.

3. The XML declaration line must indicate the character set in use when 
unicode or UTF-8 is NOT being used. For example here is a declaration for 
an XML document encoded with ISO-8859-1:

    <?xml version="1.0" encoding='ISO-8859-1"?>

Carsten


On Thursday, December 13, 2001, at 05:42  pm, Steve Wainstead wrote:

>
> I would think RSS files should come out as text/plain.
>
> ~swain
>
> On Wed, 12 Dec 2001, Aredridel wrote:
>
>>>
>>> No, it's coming out as a gz file (my guess). I tried to look at it in 
>>> Lynx
>>> and Lynx asked me if I wanted to download it (type oct/gz).
>>
>> Same for me.  Galeon just displays it as if it were HTML.  Any idea what 
>> the
>> content-type should be?
>>
>> Ari
>>

Re: [Phpwiki-talk] rss for RecentChanges

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

On seemingly gzipped data:

Currently, PhpWiki (1.3) uses PHP's ob_gzhandler() function to
gzip-compress data sent to clients who send an 'Accept-Encoding:
application/gzip' header in their request.  When this happens, the fact
that the data is compressed in indicated by a 'Content-Encoding' header in
the response --- then the client/browser is supposed to uncompress the
data before doing anything else with it.

If you're seeing seemingly random (gzipped looking) binary data, then
something is wrong with this process.  (The RSS data is XML, and should
look like something if you look at it with a text viewer.)


====
On viewing RSS with Galeon:

Separate issue:  Galeon treats all XML files as if they were 'text/xml'. 
It assumes they're marked up text, and tries to display the file as such. 
In the case of RSS, since none of the tags have any mark-up styles
associated with them, what you see is the RSS file with all of the XML
tags removed.  As mentioned in my previous note, this will not make a lot
of sense.

Re: [Phpwiki-talk] rss for RecentChanges

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

On Thu, 13 Dec 2001 17:42:17 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> 
> I would think RSS files should come out as text/plain.
> 
> ~swain

According to the RSS 1.0 spec, it should be 'application/xml'.  Makes
sense to me: it's XML, so the choices are either 'application/xml' or
'text/xml'.  (There are no registered MIME types especially for RDF or
RSS.)  If you strip the XML tags, what's left doesn't really make any
sense to humans --- so 'application/xml' it is.

See http://groups.yahoo.com/group/rss-dev/files/specification.html#s5

Re: [Phpwiki-talk] rss for RecentChanges

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

> 
> I would think RSS files should come out as text/plain.
> 
> ~swain
> 

After looking through all the URIs in my ~/.nautilus/news_channels.xml file,
there seems to be a trend of using text/plain, text/xml, and one case of
text/html among the sites.

I bet that's what's keeping me from loading the rss into Nautilus.

Aredridel

Re: [Phpwiki-talk] rss for RecentChanges

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

I would think RSS files should come out as text/plain.

~swain

On Wed, 12 Dec 2001, Aredridel wrote:

> >
> > No, it's coming out as a gz file (my guess). I tried to look at it in Lynx
> > and Lynx asked me if I wanted to download it (type oct/gz).
>
> Same for me.  Galeon just displays it as if it were HTML.  Any idea what the
> content-type should be?
>
> Ari
>

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