phpwiki-talk

RE: [Phpwiki-talk] Server-side include

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

> After taking a second look at your e-mail, I seem to understand that I
> would need to add these php readfile calls inside of some of the code of
> phpwiki.
>
> I did not find that <?= "Time: ". strftime("%x %X") ?> line anywhere.
> Can you point out where I should add these php calls to go and read some
> external files?

In any template.
I put it into themes/default/bottom.tmpl
at the end, before the ?> tag

Those three lines of mine where my test, to print something useful.

-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wiki spam and the future of phpwiki

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

I tried to send this, and Sourceforge bounced it. Now, a week later, let 
me try again.

Dan

YOD,

90% of the code I took from editpage.php in CVS current of PhpWiki, 
thanks to Reini. The 10% was two changes:

1. Modify the end-user error message to say "Sorry, too many links (more 
than ##)" instead of "conflicts".
2. Add a configurable parameter SPAM_MAX_EXTERNAL_LINKS.

Below is an approximate patch to editpage.php. Since we are almost a 
year different from Phpwiki, I cannot guarantee that the patch is 
entirely accurate.

Also, I sent this patch to this list awhile ago. Perhaps I should also 
change it in CVS current?

Dan


(YOD) wrote:

>On Wed, 30 Mar 2005, Dan Frankowski wrote:
>  
>
>>1. Don't allow saving a page that has more than 20 external ("http://") 
>>links. In our code, I modified "20" to be a configurable parameter 
>>SPAM_MAX_EXTERNAL_LINKS. We've been completely spammed as well, and I 
>>believe this will help us a lot. We have a wiki where each legitimate 
>>page only contains a few external links, but spam pages contain tons 
>>(>50 for sure) external links.
>>    
>>
>
>I'd like to implement this modification. Would you be kind enough to send
>it to me? 
>
>I have three working PhpWikis but two (with a progressive
>political orientation) of them I have only open blogging but otherwise
>editing is now turned off due to excessive spamming. I just installed a
>third Wiki to play with and haven't decided yet what to do with it.
>
>I am just waiting to see how long it takes for spam to find the new open 
>Wiki and I suspect it won't be long (g). 
>
>I also want to explore other methods for securing Wiki from spambots 
>(intentional spammers are much easier to deal with) so I have been 
>following these discussions with much interest.
>
>Hank Roth
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/Info/Sentarus/hamr30
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>  
>

RE: [Phpwiki-talk] Server-side include

[Yannick L. <Yan...@en...>]

After taking a second look at your e-mail, I seem to understand that I would
need to add these php readfile calls inside of some of the code of phpwiki.

I did not find that <?= "Time: ". strftime("%x %X") ?> line anywhere. Can
you point out where I should add these php calls to go and read some
external files?

Thanks,

Yannick

> -----Original Message-----
> From: Reini Urban [mailto:ru...@x-...] 
> Sent: Wednesday, April 13, 2005 3:27 PM
> To: Yannick Lefebvre
> Cc: 'php...@li...'
> Subject: Re: [Phpwiki-talk] Server-side include
> 
> 
> Yannick Lefebvre schrieb:
> > I have just installed PhpWiki on our corporate intranet. 
> Everyone who
> > has started using it is really liking what they're seeing. 
> I do have one 
> > question. Our intranet pages use Server-side include to bring in 
> > contents from template pages into all of the other pages with the 
> > following syntax:
> >  
> > <!--#include virtual="/ssi/header.shtml" -->
> >  
> > I have tried adding such links inside of the template (browse.html) 
> > but
> > that did not work (probably because it's not a .shtml page 
> or perhaps 
> > for some other reason that I don't comprehend at this point).
> 
> Apache usually doesn't do shtml parsing after the php step, 
> because php can do much more.
> 
> > For PHP templates, I've also done SSI include with the following 
> > syntax
> > in the past:\
> >  
> >  <?php include("http://intranet/ssi/header.shtml") ?>
> 
> We use some safety measures against external code and 
> strings. Using the url_fopen feature is also not recommended.
> 
>    <?php readfile("/var/www/ssi/footer-start.shtml") ?>
>    <?= "Time: ". strftime("%x %X") ?>
>    <?php readfile("/var/www/ssi/footer-end.shtml") ?>
> 
> works for me.
> 
> > But that did not work either in the templates. Does anyone have
> > experience at using Server-side includes inside of PHPWiki 
> templates? If 
> > so, what is the syntax to use?
> -- 
> 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
> http://phpwiki.org/
> 

[Phpwiki-talk] Hit Count bug

[Jose V. <jo...@sv...>]

I'm running phpwiki 1.2.7.

A bug in hit counting routine makes it return wrong results. This is the
description and solution, please fix.

Symptoms: relevant pages are left out of the top hit list.B

Bug in files: dbalib.php, dbmlib.php and maybe other similar ones.

Function: InitMostPopular($dbi, $limit)

Where it says:

   if (!$removed and ($pscore = $lowest))


it should say:


   if (!$removed and ($pscore == $lowest))

Change:   =  ->  ==



Best regards,

jose.

[Phpwiki-talk] Inline svg, swf, pdf: enhance LinkImage?

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

I want to inline certain extensions, like svg, swf, pdf and more,
which normally would need the object tag and not img.

Esp. if they are uploaded or via cgi and not generated by some
WikiPluginCached, like GraphViz or Ploticus.

Should we add those extensions to INLINE_IMAGES and support them via
LinkImage() automatically then?
-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] Server-side include

[Yannick L. <Yan...@en...>]

Hello Reini,

> Yannick Lefebvre schrieb:
> > I have just installed PhpWiki on our corporate intranet. 
> Everyone who
> > has started using it is really liking what they're seeing. 
> I do have one 
> > question. Our intranet pages use Server-side include to bring in 
> > contents from template pages into all of the other pages with the 
> > following syntax:
> >  
> > <!--#include virtual="/ssi/header.shtml" -->
> >  
> > I have tried adding such links inside of the template (browse.html) 
> > but
> > that did not work (probably because it's not a .shtml page 
> or perhaps 
> > for some other reason that I don't comprehend at this point).
> 
> Apache usually doesn't do shtml parsing after the php step, 
> because php can do much more.

Actually, I'm running PhpWiki on IIS 6.0, not on Apache.
 
> > For PHP templates, I've also done SSI include with the following 
> > syntax
> > in the past:\
> >  
> >  <?php include("http://intranet/ssi/header.shtml") ?>
> 
> We use some safety measures against external code and 
> strings. Using the url_fopen feature is also not recommended.
> 
>    <?php readfile("/var/www/ssi/footer-start.shtml") ?>
>    <?= "Time: ". strftime("%x %X") ?>
>    <?php readfile("/var/www/ssi/footer-end.shtml") ?>
> 
> works for me.

Would I put these readfile calls inside of my template file where I want the
SSI files to be loaded? I have tried putting them there and that did not put
the contents of the file I listed.

Thanks for the help,

Yannick

Re: [Phpwiki-talk] Server-side include

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

Pascal Giard (QC/EMC) schrieb:
> A while back, i wrote myself a plugin to do that.
>  
> I believe it's not there on purpose... for security reasons.

Plugins can be abused by every nasty user out there.
Templates can only be edited by the admin.

   Until we allow wiki template editing, somewhen in the future.
   See wikilens.org

>     -----Original Message-----
>     *From:* php...@li...
>     [mailto:php...@li...]
>     *Sent:* April 13, 2005 11:42 AM
>     *To:* 'php...@li...'
>     *Subject:* [Phpwiki-talk] Server-side include
> 
>     Hello,
>      
>     I have just installed PhpWiki on our corporate intranet. Everyone
>     who has started using it is really liking what they're seeing. I do
>     have one question. Our intranet pages use Server-side include to
>     bring in contents from template pages into all of the other pages
>     with the following syntax:
>      
>     <!--#include virtual="/ssi/header.shtml" -->
>      
>     I have tried adding such links inside of the template (browse.html)
>     but that did not work (probably because it's not a .shtml page or
>     perhaps for some other reason that I don't comprehend at this point).
>      
>     For PHP templates, I've also done SSI include with the following
>     syntax in the past:\
>      
>      <?php include("http://intranet/ssi/header.shtml") ?>
>      
>     But that did not work either in the templates. Does anyone have
>     experience at using Server-side includes inside of PHPWiki
>     templates? If so, what is the syntax to use?
>      
>     Thanks for any help that can be provided,
>      
>     Yannick


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] Server-side include

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

Yannick Lefebvre schrieb:
> I have just installed PhpWiki on our corporate intranet. Everyone who 
> has started using it is really liking what they're seeing. I do have one 
> question. Our intranet pages use Server-side include to bring in 
> contents from template pages into all of the other pages with the 
> following syntax:
>  
> <!--#include virtual="/ssi/header.shtml" -->
>  
> I have tried adding such links inside of the template (browse.html) but 
> that did not work (probably because it's not a .shtml page or perhaps 
> for some other reason that I don't comprehend at this point).

Apache usually doesn't do shtml parsing after the php step,
because php can do much more.

> For PHP templates, I've also done SSI include with the following syntax 
> in the past:\
>  
>  <?php include("http://intranet/ssi/header.shtml") ?>

We use some safety measures against external code and strings.
Using the url_fopen feature is also not recommended.

   <?php readfile("/var/www/ssi/footer-start.shtml") ?>
   <?= "Time: ". strftime("%x %X") ?>
   <?php readfile("/var/www/ssi/footer-end.shtml") ?>

works for me.

> But that did not work either in the templates. Does anyone have 
> experience at using Server-side includes inside of PHPWiki templates? If 
> so, what is the syntax to use?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

RE: [Phpwiki-talk] Server-side include

[Pascal G. (QC/EMC) <Pas...@er...>]

A while back, i wrote myself a plugin to do that.
 
I believe it's not there on purpose... for security reasons.
 
-Pascal

-----Original Message-----
From: php...@li...
[mailto:php...@li...]
Sent: April 13, 2005 11:42 AM
To: 'php...@li...'
Subject: [Phpwiki-talk] Server-side include


Hello,
 
I have just installed PhpWiki on our corporate intranet. Everyone who has
started using it is really liking what they're seeing. I do have one
question. Our intranet pages use Server-side include to bring in contents
from template pages into all of the other pages with the following syntax:
 
<!--#include virtual="/ssi/header.shtml" -->
 
I have tried adding such links inside of the template (browse.html) but that
did not work (probably because it's not a .shtml page or perhaps for some
other reason that I don't comprehend at this point).
 
For PHP templates, I've also done SSI include with the following syntax in
the past:\
 
 <?php include(" http://intranet/ssi/header.shtml
<http://intranet/ssi/header.shtml> ") ?>

 
But that did not work either in the templates. Does anyone have experience
at using Server-side includes inside of PHPWiki templates? If so, what is
the syntax to use?
 
Thanks for any help that can be provided,
 
Yannick

[Phpwiki-talk] Server-side include

[Yannick L. <Yan...@en...>]

Hello,
 
I have just installed PhpWiki on our corporate intranet. Everyone who has
started using it is really liking what they're seeing. I do have one
question. Our intranet pages use Server-side include to bring in contents
from template pages into all of the other pages with the following syntax:
 
<!--#include virtual="/ssi/header.shtml" -->
 
I have tried adding such links inside of the template (browse.html) but that
did not work (probably because it's not a .shtml page or perhaps for some
other reason that I don't comprehend at this point).
 
For PHP templates, I've also done SSI include with the following syntax in
the past:\
 
 <?php include("http://intranet/ssi/header.shtml
<http://intranet/ssi/header.shtml> ") ?>

 
But that did not work either in the templates. Does anyone have experience
at using Server-side includes inside of PHPWiki templates? If so, what is
the syntax to use?
 
Thanks for any help that can be provided,
 
Yannick

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

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

Arnaud Fontaine schrieb:
>>3. A bigger bottom toolbar problem is that it doesn't scale in width
>>properly.  Even when the user is not logged in, it's still the same
>>width as if you were logged in (i.e. there is blank space on the left of
>>the toolbar for the icons only a logged-in user sees.
> 
> Yet another table related problem ... As I said, we're working on
> another table free crao version (Reini, you'll not be allowed to add
> tables to it ;))

I hope that I will not forget it :)

> Ok ... I'll check the sf bug tracker to raise the stats ;)
> 
> 
>>Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
>>have to stick that javascript hack for IE to make transparent PNGs work
>>back into my phpwiki.
> 
> 
> Why don't you all switch to firefox ? :)

It's not us. It's the userbase out there which we have to support.
I just had to add some stupid iehacks to the "smaller" theme, just for 
the size of lower actionbar buttons.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philip J. Hollenback a écrit :
> I just checked www.hollenback.net on IE 6.0, Win2K and it looks pretty
> bad.  Specifics below, but bottom line is the Crao theme that ships with
> 1.3.11rc3 has serious rendering problems in IE that have to be
> addressed. 

Good news for all : Laurent has set up a new 300 euros winxp box just to
be able to test themes with those crappy browsers :)


> I just checked http://crao.net/wiki and it exhibits this problem as
> well.

Right ... (btw, it's wiki.crao.net ...)

> 1. The larger fonts look bad (i.e. h1, h2, etc).  They're jagged and not
> scaled well.  I would say the base font is a little too large, then the
> steps for each successive font are too big.  Thus the largest heading
> fonts are enormous.

????????????????????????????
isn't it a problem local to your config ?

> 2. The bottom toolbar does not float on the bottom of the screen,
> instead it's stuck on the bottom of the actual page.  I assume that's
> just because getting IE to support that is just too hard, so I'm not
> particularly worried about it.

Right ... the floating stuff doesn't work with IE ... I'll ask Laurent
if he has found a nice hack.

> 3. A bigger bottom toolbar problem is that it doesn't scale in width
> properly.  Even when the user is not logged in, it's still the same
> width as if you were logged in (i.e. there is blank space on the left of
> the toolbar for the icons only a logged-in user sees.

Yet another table related problem ... As I said, we're working on
another table free crao version (Reini, you'll not be allowed to add
tables to it ;))

> 4. The topbar is too tall - there is a gap above and below the wiki logo
> text, when it should be flush.

Might be a side effect of another problem.

> Administrative question: should I be filing all these problems in the
> sf.net bug tracker?  I say yes because they are against files included
> in phpwiki, but I just wanted to make sure that's the most effective way
> to go.  Arnaud, do you check the Crao bugs that are posted there?

Ok ... I'll check the sf bug tracker to raise the stats ;)

> Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
> have to stick that javascript hack for IE to make transparent PNGs work
> back into my phpwiki.

Why don't you all switch to firefox ? :)

- --
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCWspOyAf3wgFyy1ARAirAAJwNo38OCP1FKQpF7AWbSX4wI0u03gCg0nMh
JNzcSfykJLwoRBHWKnvae28=
=4y1i
-----END PGP SIGNATURE-----

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

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

Philip J. Hollenback schrieb:
> Administrative question: should I be filing all these problems in the
> sf.net bug tracker?  I say yes because they are against files included
> in phpwiki, but I just wanted to make sure that's the most effective way
> to go.  Arnaud, do you check the Crao bugs that are posted there?

I would prefer this. It raises our sf-wide statistics activity level :)
Maybe we can make under the top ten again during 1.3.11 final.

> Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
> have to stick that javascript hack for IE to make transparent PNGs work
> back into my phpwiki.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] status on pagenames and wikinames

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

Joel Uckelman schrieb:

> Thus spake =?iso-8859-1?Q?J=E9r=F4me_WAGNER?=:
> 
>>Hello,
>>
>>=20
>>
>>Can someone give me the status of pagename rules in phpwiki ?
>>
>>=20
>>
>>Is is bullet proof to use =93beginner friendly=94 pagenames like 
this is the name of my page
> 
> 
> Yes. Non-wikiwords can be used without problems, so long as you wrap them
> in square brackets.
>  
> 
>>What is the current phpwiki opinion on this kind of pagenames  ?
> 
> 
> The removal of restrictions on pagenames is a fairly recent developement;
> we're not opposed to it, I guess.

It depends now only on the database backend and those rules:
See lib/stdlib.php:675 WikiPageName::_check()

* Compress internal white-space to single space character.
* On cvs and file delete any control characters.
   (typical filesystem restrictions)
* On cvs and file remove ".." and ":" by ''
* Strip leading and trailing white-space.
   so that users cannot be easily fooled into wrong pages.
* Leading SUBPAGE_SEPARATOR is disallowed. (e.g. "/Mypage")
* strlen($pagename) > MAX_PAGENAME_LENGTH is disallowed (100)
   To restrict get request overflows

Note:
* ";" is allowed since the pagename is urlencoded, so safe from php
   arg-delim problems.

For some time during 1.3.11 testing we had problems with "0" and ".", 
which should be solved now.

A similar problem are the backend-specific username restrictions,
which we don't use yet. Those isValidName methods have to be written and 
tested.
For now usernames are quite generally restrictive.
See _WikiUser::isValidName() in lib/WikiUserNew.php:511
   valid if preg_match("/^[\w\.@\-]+$/",$userid)
            and strlen($userid) < 32;

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

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

Philip J. Hollenback schrieb:
> On 04/10/05, Joel Uckelman wrote:
> I share your sentiment.  Another IE issue: I use a transparent png for
> my image/title at the top left.  That doesn't render properly in IE 5.x
> cause it doesn't understand transparent PNGs.

I know of this transparent PNG js hack for older IE's, but I thought we 
could go without it so far.
Well, if you can send it along, I will put it in.

> I found a javascript snippet that does some sort of magic to fix that
> for IE.  Is there any interest in incorporating that into phpwiki?  It's
> useful anywhere you want to use transparent pngs in themes.  It does
> bloat every page somewhat, but the javascript is only executed when the
> correct version of IE is detected, so the effect on other browsers in
> minimal.
> 
> It's the usual problem of how far do you go to support different
> browsers.
> 
> Thanks for the tip on how to fix this, I will tweak the layout to see if
> I can come up with something that works on IE and other browsers.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] Release Candidate 3 available

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

John Cole schrieb:
> Reini,
>   What is the status on the rename page problem?  I'll bring my test server
> up to date and see how the rest of things are shaping up.

I tested it at a new site, and succesfully renamed a subpage
with all its links. DATABASE_TYPE=dba
But I didn't test it yet for all backends.
I wanted to write a unittest for this and the owner cache problem.

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...] On Behalf Of Reini Urban
> Sent: Saturday, April 09, 2005 4:36 AM
> To: phpwiki
> Subject: [Phpwiki-talk] Release Candidate 3 available
> 
> http://sourceforge.net/project/shownotes.php?release_id=319077
> 
> Fixes since rc2:
>    recursive PageList azhead+cols listing
>    RichTablePlugin embedded plugin invocation and more formatting issues
>    empty SESSION_SAVE_PATH
>    Template("theme/name") inclusion
>    "smaller" theme IE aesthetics
>    postgresql schema, thanks to Marius Andreiana
>    add _SERVER[REMOTE_USER] check for pubcookie et al
>    add ENABLE_DISCUSSION_LINK dependency (to turn it off for 1.3.11)
>    fix WIKIDB_NOCACHE_MARKUP (bug #1175761)
>    fix email regex for RFC822 addresses (Joel Uckelman)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [Phpwiki-talk] status on pagenames and wikinames

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

Thus spake =?iso-8859-1?Q?J=E9r=F4me_WAGNER?=:
> 
> Hello,
> 
> =20
> 
> Can someone give me the status of pagename rules in phpwiki ?
> 
> =20
> 
> Is is bullet proof to use =93beginner friendly=94 pagenames like [ this =
> is the
> name of my page ] ?

Yes. Non-wikiwords can be used without problems, so long as you wrap them
in square brackets.
 
> What is the current phpwiki opinion on this kind of pagenames  ?

The removal of restrictions on pagenames is a fairly recent developement;
we're not opposed to it, I guess.

[Phpwiki-talk] status on pagenames and wikinames

[<jer...@we...>]

Hello,

=20

Can someone give me the status of pagename rules in phpwiki ?

=20

Is is bullet proof to use =93beginner friendly=94 pagenames like [ this =
is the
name of my page ] ?

=20

What is the current phpwiki opinion on this kind of pagenames  ?

=20

Thank you

J=E9r=F4me

RE: [Phpwiki-talk] Release Candidate 3 available

[John C. <joh...@ua...>]

Reini,
  What is the status on the rename page problem?  I'll bring my test server
up to date and see how the rest of things are shaping up.

Thanks,

John Cole

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini Urban
Sent: Saturday, April 09, 2005 4:36 AM
To: phpwiki
Subject: [Phpwiki-talk] Release Candidate 3 available

http://sourceforge.net/project/shownotes.php?release_id=319077

Fixes since rc2:
   recursive PageList azhead+cols listing
   RichTablePlugin embedded plugin invocation and more formatting issues
   empty SESSION_SAVE_PATH
   Template("theme/name") inclusion
   "smaller" theme IE aesthetics
   postgresql schema, thanks to Marius Andreiana
   add _SERVER[REMOTE_USER] check for pubcookie et al
   add ENABLE_DISCUSSION_LINK dependency (to turn it off for 1.3.11)
   fix WIKIDB_NOCACHE_MARKUP (bug #1175761)
   fix email regex for RFC822 addresses (Joel Uckelman)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

[Philip J. H. <ph...@po...>]

I just checked www.hollenback.net on IE 6.0, Win2K and it looks pretty
bad.  Specifics below, but bottom line is the Crao theme that ships with
1.3.11rc3 has serious rendering problems in IE that have to be
addressed.=20

On Sun, 10 Apr 2005 18:50:18 +0200, "Arnaud Fontaine" <ar...@cr...>
said:
> Joel Uckelman a =E9crit :
> >>Philip J. Hollenback schrieb:
> >>>3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
> >>>'prefs / admin / search' buttons and box on the right side are stacked
> >>>vertically instead of spread in a horizontal line like they should be.
> >>>I don't see this behavior with Safari.
> >=20
> > This is due to themes/Crao/templates/navbar.tmpl, line 20:
> >=20
> > <td align=3D"right" width=3D"150">
> >=20
> > Remove the width attribute, and the right end of the nav bar has suffic=
ient
> > space to display on a single line. That solves the problem for Firefox.
> > Unfortunately, I think the width attribute is there to coax IE into ren=
dering
> > the navbar correctly---without the width, the navbar extends well past
> > the right edge of the box containing the page contents. ARGH!

I left that setting alone in navbar.tmpl and I observe that the navbar
goes way too far off to the right.  So if that 150px setting is there to
fix that, it's not working on my setup.

I just checked http://crao.net/wiki and it exhibits this problem as
well.

Other problems:

1. The larger fonts look bad (i.e. h1, h2, etc).  They're jagged and not
scaled well.  I would say the base font is a little too large, then the
steps for each successive font are too big.  Thus the largest heading
fonts are enormous.

crao.net does not exhibit this problem.

2. The bottom toolbar does not float on the bottom of the screen,
instead it's stuck on the bottom of the actual page.  I assume that's
just because getting IE to support that is just too hard, so I'm not
particularly worried about it.

crao.net has this problem as well, but like I said this isn't a
showstopper.

3. A bigger bottom toolbar problem is that it doesn't scale in width
properly.  Even when the user is not logged in, it's still the same
width as if you were logged in (i.e. there is blank space on the left of
the toolbar for the icons only a logged-in user sees.

crao.net has this problem too.

4. The topbar is too tall - there is a gap above and below the wiki logo
text, when it should be flush.

I saw this same problem in my old 1.3.10 setup, and I seem to remember
it was due to some weirdness in the css for the topbar.  I fixed it then
and I suspect a diff of the css file will reveal where that is.

crao.net does not have this problem.

> Crao Theme used to work well ... until Reini changed stuff in it :) (oh
> ... a troll comes across the screen slowly walking ...)
> It used to be a table free theme ... so any table related stuff ...
>=20
> Well ... anyway, I changed some things in the theme, simplified the css,
> added some permission checked, etc ...
>=20
> Laurent (the co-author) will drop the tables again then we'll commit the
> new crao version.

I really like the clean, modern look of the Crao theme.  I really,
really hope we can get all the interface glitches worked out in that
theme before 1.3.11 final.  Arnaud, any help would be much appreciated,
and if you guys can get me that new crao theme I will be happy to test
it asap.

Administrative question: should I be filing all these problems in the
sf.net bug tracker?  I say yes because they are against files included
in phpwiki, but I just wanted to make sure that's the most effective way
to go.  Arnaud, do you check the Crao bugs that are posted there?

Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
have to stick that javascript hack for IE to make transparent PNGs work
back into my phpwiki.

Thanks,
P.
--=20=20
Philip J. Hollenback
ph...@po...
www.hollenback.net

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

[Philip J. H. <ph...@po...>]

On 04/10/05, Joel Uckelman wrote:
> > Philip J. Hollenback schrieb:
> > 
> > > 3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
> > > 'prefs / admin / search' buttons and box on the right side are stacked
> > > vertically instead of spread in a horizontal line like they should be.
> > > I don't see this behavior with Safari.
> 
> This is due to themes/Crao/templates/navbar.tmpl, line 20:
> 
> <td align="right" width="150">
> 
> Remove the width attribute, and the right end of the nav bar has sufficient
> space to display on a single line. That solves the problem for Firefox.
> Unfortunately, I think the width attribute is there to coax IE into rendering
> the navbar correctly---without the width, the navbar extends well past
> the right edge of the box containing the page contents. ARGH!

I share your sentiment.  Another IE issue: I use a transparent png for
my image/title at the top left.  That doesn't render properly in IE 5.x
cause it doesn't understand transparent PNGs.

I found a javascript snippet that does some sort of magic to fix that
for IE.  Is there any interest in incorporating that into phpwiki?  It's
useful anywhere you want to use transparent pngs in themes.  It does
bloat every page somewhat, but the javascript is only executed when the
correct version of IE is detected, so the effect on other browsers in
minimal.

It's the usual problem of how far do you go to support different
browsers.

Thanks for the tip on how to fix this, I will tweak the layout to see if
I can come up with something that works on IE and other browsers.

> > > 4. I could be imagining things, but the floating ttolbar on the bottom
> > > of the Crao theme now slows down page scrolling significantly.  I don't
> > > think it used to.
> > 
> > That's entirely a browser issue. Unfortunately the developer of this 
> > theme cannot check against MSIE.
> 
> Scrolling, in both IE and Firefox, seems the same for me with the Crao
> theme.

Huh.  Wonder if it's a problem with Firefox on the mac only?  I will
test Firefox and Konqueror on Linux tomorrow and report.

-- 
Philip J. Hollenback
www.hollenback.net

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

[Philip J. H. <ph...@po...>]

First of all, I have to really, really emphasize how useful it is to now
have official releases, even if they are just release candidates.  For
an end user, it is so much easier to file bugs, etc. with a known
baseline instead of just, "some cvs version from some date".  Thanks!
I'm returning the favor with lots of bug reports.

On 04/10/05, Reini Urban wrote:
> >2.  Thanks a bunch for the 'overwrite all' in the upgrade page.  Makes
> >the process much easier.  However, maybe that should be explained a bit
> >more?  Right now it doesn't exactly pop up off the page.
> 
> Hmm. You got an idea?

Bigger/bolder would be better, and maybe more text like 'click here to
overwite all old pages with new versions' or something.

> >3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
> >'prefs / admin / search' buttons and box on the right side are stacked
> >vertically instead of spread in a horizontal line like they should be.
> >I don't see this behavior with Safari.
> >
> >4. I could be imagining things, but the floating toolbar on the bottom
> >of the Crao theme now slows down page scrolling significantly.  I don't
> >think it used to.
> 
> That's entirely a browser issue. Unfortunately the developer of this 
> theme cannot check against MSIE.

Note that I'm using Firefox and Safari on Mac OS X.

Is the Crao developer on this list?  I'd really like to talk to him
about updating all the icons.  I have enough gimp skills to do the work,
but starting with some tips from the original developer would really
help.

> Thanks for all your reports at the sf.net tracker.
> This will need some time to be fixed.

Oh don't worry, I'm going to post a lot more bugsa :).  Speaking of which,
does anyone else find the bugs/support/patches division on the sf.net
tracker kind of bizarre?  I understand what they are trying to do by
separating those, but reading through what's posted in each, it's pretty
clear that no one really knows what they are all for.  There should be
just one big bug tracker, I think.  The current division just adds
confusion.

Also I posted a request for more categories in the bug tracker, so we
can sort out just 1.3.11rc3 bugs, for example.

Now if 1.3.11 becomes 1.4.0, I will be even happier.

Thanks,
P.

-- 
Philip J. Hollenback
www.hollenback.net

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joel Uckelman a écrit :
>>Philip J. Hollenback schrieb:
>>
>>
>>>3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
>>>'prefs / admin / search' buttons and box on the right side are stacked
>>>vertically instead of spread in a horizontal line like they should be.
>>>I don't see this behavior with Safari.
> 
> 
> This is due to themes/Crao/templates/navbar.tmpl, line 20:
> 
> <td align="right" width="150">
> 
> Remove the width attribute, and the right end of the nav bar has sufficient
> space to display on a single line. That solves the problem for Firefox.
> Unfortunately, I think the width attribute is there to coax IE into rendering
> the navbar correctly---without the width, the navbar extends well past
> the right edge of the box containing the page contents. ARGH!
> 
> 
>>>4. I could be imagining things, but the floating ttolbar on the bottom
>>>of the Crao theme now slows down page scrolling significantly.  I don't
>>>think it used to.
>>
>>That's entirely a browser issue. Unfortunately the developer of this 
>>theme cannot check against MSIE.
> 
> 
> Scrolling, in both IE and Firefox, seems the same for me with the Crao
> theme.

Crao Theme used to work well ... until Reini changed stuff in it :) (oh
... a troll comes accross the screen slowly walking ...)
It used to be a table free theme ... so any table related stuff ...

Well ... anyway, I changed some things in the theme, simplified the css,
added some permission checked, etc ...

Laurent (the co-author) will drop the tables again then we'll commit the
new crao version.

BTW, we can now check on MSIE thanks to vmware ...

We also have two brand new themes to commit ... just have to change the
way I deal with discussion pages (I coded discussions links long before
Reini add them into the default theme but not the same way. Reini's way
is better ... I gonna change my themes).

- --
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCWVlJyAf3wgFyy1ARAvluAKCqPbWw9CAn3O9ZQsEThPidn/XL3gCfayUh
maZDK7zGr3gR3otRPCqOJws=
=XXwg
-----END PGP SIGNATURE-----

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

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

> Philip J. Hollenback schrieb:
> 
> > 3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
> > 'prefs / admin / search' buttons and box on the right side are stacked
> > vertically instead of spread in a horizontal line like they should be.
> > I don't see this behavior with Safari.

This is due to themes/Crao/templates/navbar.tmpl, line 20:

<td align="right" width="150">

Remove the width attribute, and the right end of the nav bar has sufficient
space to display on a single line. That solves the problem for Firefox.
Unfortunately, I think the width attribute is there to coax IE into rendering
the navbar correctly---without the width, the navbar extends well past
the right edge of the box containing the page contents. ARGH!

> > 4. I could be imagining things, but the floating ttolbar on the bottom
> > of the Crao theme now slows down page scrolling significantly.  I don't
> > think it used to.
> 
> That's entirely a browser issue. Unfortunately the developer of this 
> theme cannot check against MSIE.

Scrolling, in both IE and Firefox, seems the same for me with the Crao
theme.
 

Re: [Phpwiki-talk] phpwiki.sf.net/phpwiki switched to 1.3.11_rc3

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

Reini Urban schrieb:
> I've switched our default wiki to the new codebase.
>   http://phpwiki.sourceforge.net/phpwiki/
> aliased under http://phpwiki.sourceforge.net/phpwiki11/
> 
> The old is under
>   http://phpwiki.sourceforge.net/phpwiki10/
> 
> The automatic demo update cronjob is working again.
> They switched the CVS servernames from "cvs1" back to "cvs", that's why 
> it failed.
> Just the nightly snapshot is missing now.

I've fixed the nightly snapshot also.
   http://phpwiki.sourceforge.net/phpwiki-nightly.tar.bz2

It's a bit unstable right now (stale nfs locks), we will see how it 
works during the next weeks.
The sf.net admins promised me to simplify those nightly builds
to be downloaded over the special download servers, not to harm the 
regular apache which such heavy streams. (Apache slows down a lot)
But this doesn't work yet. I don't want to wait any longer.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org