phpwiki-talk Mailing List for PhpWiki (Page 26)

2007年3月18日, Morten Sickel <ab...@si...>:
> Thanks for the quick reply. :-)
>
> Reini Urban skrev:
> >
> > /tmp is used in:
> > DATABASE_DIRECTORY (mandatory)
>
> DATABASE_DIRECTORY = pages
much better is to use absolute pathnames. in one stage we do chdir
(into the locale)
and I forgot what else does a chdir implicitly.
> > PLUGIN_CACHED_CACHE_DIR (mandatory) and
>
> so you say that I need to adjust
> ;PLUGIN_CACHED_CACHE_DIR = /tmp/cache
>
> out of /tmp even if I am not having database set to file?
>
> To quote from config.ini:
> "; This is only used if database is set to file.
> ; The webserver must have write access to this dir!"
This is wrong. CACHE_DIR is used for editing and some plugins.
I'll fix that.
> Ok, I'll have a look at that and see if it works then
>
>
> > TEMP_DIR (optional)
> TEMP_DIR =tmp
> > ACCESS_LOG (optional)
> ;ACCESS_LOG = /var/tmp/wiki_access_log
> which as far as I understood means that no access log will be created?
>
> I have also set
>
> DEFAULT_DUMP_DIR = tmp/wikidump
> HTML_DUMP_DIR = tmp/wikidumphtml
>
> even though I have not tried to do any dumps (yet).-
>
> >
> > This is is just the default if you didn't set DATABASE_DIRECTORY
> >
> Ok, that was what it looked like.
>
>
> M.
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://spacemovie.mur.at/ http://helsinki.at/

Thanks for the quick reply. :-)
Reini Urban skrev:
>
> /tmp is used in:
> DATABASE_DIRECTORY (mandatory)
DATABASE_DIRECTORY = pages
> PLUGIN_CACHED_CACHE_DIR (mandatory) and
so you say that I need to adjust
;PLUGIN_CACHED_CACHE_DIR = /tmp/cache
out of /tmp even if I am not having database set to file?
To quote from config.ini:
"; This is only used if database is set to file.
; The webserver must have write access to this dir!"
Ok, I'll have a look at that and see if it works then
> TEMP_DIR (optional)
TEMP_DIR =tmp
> ACCESS_LOG (optional)
;ACCESS_LOG = /var/tmp/wiki_access_log
which as far as I understood means that no access log will be created?
I have also set
DEFAULT_DUMP_DIR = tmp/wikidump
HTML_DUMP_DIR = tmp/wikidumphtml
even though I have not tried to do any dumps (yet).-
>
> This is is just the default if you didn't set DATABASE_DIRECTORY
>
Ok, that was what it looked like.
M.

2007年3月18日, Morten Sickel <ab...@si...>:
> I just have tried to upgrade a phpwiki installation from 1.2.10 to the latest.
> I am trying to set it up at an isp where I have no access whatsoever outside
> my own directory and no possibility to do anything on the set up of the
> server.
>
> I am then only greeted with
>
> Fatal Error:
> lib/FileFinder.php:191 Error: /tmp: file not found
>
> lib/FileFinder.php:191 Error: /tmp: file not found
>
> This happens both when (trying to) using dba and mysql.
/tmp is used in:
DATABASE_DIRECTORY (mandatory)
PLUGIN_CACHED_CACHE_DIR (mandatory) and
TEMP_DIR (optional)
ACCESS_LOG (optional)
> I have been looking into config.ini, and changed all occurences of /tmp there
> to tmp and made a directory tmp under my phpwiki installation that is
> writeable for the server. No help. When grepping for /tmp in the source, I
> find quite a few occurances where that is hard coded, so it seems to me that
> even if I am telling it through config.ini to stay away from /tmp, it cannot
> be avoided (without going deep diving into the code) e.g. in l
> lib/WikiDB/backend/dba.php I find:
This is is just the default if you didn't set DATABASE_DIRECTORY
> class WikiDB_backend_dba
> extends WikiDB_backend_dbaBase
> {
> function WikiDB_backend_dba ($dbparams) {
> $directory = '/tmp';
> $prefix = 'wiki_';
> ...
>
> of cource, it might be that the $directory is set to something else further
> down the road through the extract($dbparams) call, but it is obious that it
> is presently no simple way for an end user (even one with quite a bit of php
> experience) to tell phpwiki to stay away from /tmp
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://spacemovie.mur.at/ http://helsinki.at/

I just have tried to upgrade a phpwiki installation from 1.2.10 to the latest. 
I am trying to set it up at an isp where I have no access whatsoever outside 
my own directory and no possibility to do anything on the set up of the 
server.
I am then only greeted with
Fatal Error:
lib/FileFinder.php:191 Error: /tmp: file not found 
lib/FileFinder.php:191 Error: /tmp: file not found 
This happens both when (trying to) using dba and mysql. 
I have been looking into config.ini, and changed all occurences of /tmp there 
to tmp and made a directory tmp under my phpwiki installation that is 
writeable for the server. No help. When grepping for /tmp in the source, I 
find quite a few occurances where that is hard coded, so it seems to me that 
even if I am telling it through config.ini to stay away from /tmp, it cannot 
be avoided (without going deep diving into the code) e.g. in l
lib/WikiDB/backend/dba.php I find:
class WikiDB_backend_dba
extends WikiDB_backend_dbaBase
{
 function WikiDB_backend_dba ($dbparams) {
 $directory = '/tmp';
 $prefix = 'wiki_';
...
of cource, it might be that the $directory is set to something else further 
down the road through the extract($dbparams) call, but it is obious that it 
is presently no simple way for an end user (even one with quite a bit of php 
experience) to tell phpwiki to stay away from /tmp
Morten

Morten Sickel wrote:
> Hi, I have just started to use phpwiki, and have installed version
just out of curiosity: what were your reasons to select PhpWiki?
I'm in the process to switch from PhpWiki to PmWiki. Maybe I 
shouldn't do so.
> 1.2.10 which as far as I could understand was the current stable a
> couple of weeks ago. I have two wishlist items and two possible bugs.
it's _very_ old and lacks many interesting improvements of 1.3.*
> I have been looking around a bit, but have so far not been able to see
> if any work is been done on these issues.
> 
> Would you recommend using any newer version than 1.2.10?
It depends on what you need. Authentication, ACL, many new plugins?
1.3.13 would be my choice (if I used PhpWiki again) but 
http://phpwiki.org/ states since nearly one year "The current 1.3.x 
phpwiki on sf.net is currently down, due to yet unknown 
circumstances" so there is a risk you get in trouble, too. I'm 
running 1.3.12p3 without larger problems, but I once had a problem 
with PhpWiki 1.3.4 when my ISP updated to PHP 4.4.4 (database 
corrupted, had to restore from plain text backup).
[...]
> WL 2: table prefix. I wanted to run two separate wikis on a domain
> that is run by a ISP I have access to one mysql database there, so to
Any special reason why you want to use MySQL?
Oliver
-- 
Oliver Betz, Muenchen

da...@an... schrieb:
> First off, I'd like to say thanks for all the exceptional work that you have
> done in phpwiki. The design and architecture is elegant, and I have learnt very
> much in the understanding of the system. I greatly appreciate the style and
> flow of the coding.
> 
> I sent a message to the phpwiki talk mailing list a few days ago with a phpwiki
> issue (Subject: Authentication not persisting). THIS email is not intended as
> attempting to get a private answer, or to speed up an answer, or to hassle you
> at all.
> 
> Rather, I would like to know if there is something in my asking, or something in
> my problem that I could have asked more wisely (more information, or anything
> else) or in a better way to receive some help on this issue. Or perhaps
> something in the nature of the problem that makes it non answerable.
> 
> If not, then please take this communique as an expression of gratitude and
> nothing more.
Sorry for not answering that fast as it used to happen here.
1. I was the whole week on a business trip and my UMTS modem didn't work 
in germany and england.
2. Your question is a FAQ. Loosing session information is very common. 
Unusual is that you debugged the code very far. But a solution is still 
pending.
We should really switch to a more light weight session handling with 
simple hashes instead of objects.
But this will not happen until summer.
The most common error is within your php installation.

Hi all,
Sometimes after saving a wiki page I have the following warning:
PHP Warning
Lib/stdlib.php:1511:Warning: Unknown modifier 'N'
Can this be dangerous ?
Any ideas?
Cheers,
Sabri.

Hi folks, no more thought on this anyone ? :-(
I guess the problems were introduced in file rev. 1.9, so
could banjo please get in touch with me ?
Thanks, Tom.
> > Try the latest CalendarList version from CVS or the latest release.
> > This error was fixed recently.
>
> Thanks, but the Calendar List in "Browse CVS" on the SF site is
> CalendarList.php,v 1.9 2006年05月14日 17:40:31 rurban
> Sun May 14 17:40:31 2006 UTC (9 months, 3 weeks ago) by rurban
> and that is what I have on disk.
> 
> I also replaced Calendar.php (now I have weeknums, cool ;-)
> but that also didn't help with the list problem.
> 
> Any other file I need to replace ?
> 
> If the file is not yet in CVS, could you please mail it to me?
> 
> Thanks, Cheers,
> Tom.
> 

Hi Frank,
I'm the Debian Maintainer for PHPwiki, so I'll see if I can help you out.
On 3/15/07, Frank Van Damme <fra...@gm...> wrote:
>
> I have a phpwiki running. It's on version 1.3.4 and when I upgraded my
> distribution to Debian Etch lately, phpwiki stopped serving me wiki
> pages but opted for error messages instead. They probably have
> something to do with php being upgraded, but I'm not too concerned
> about *that*.
That's not very good. What version of the package were you upgrading from?
If you can send me some details about teh upgrade process, versions,
database backend, error messages, etc. I'll be happy to look into it and
make sure it's not a bug in the package. I have not had any other failed
upgrade reports recently.
That doesn't work for me. I get asked to sign in. I enter the values of
> ADMIN_USER and ADMIN_PASSWD in /etc/phpwiki/config.ini respectively.
> The result:
>
> Fatal Error:
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
> DB Error: no such table
> (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
> Table 'phpwiki.pref' doesn't exist])
Is this while trying to load upgrade.php?
Cheers
-- 
Matt Brown
ma...@ma...
Mob +64 21 611 544 www.mattb.net.nz

Hi all,
(I hope I'm writing this to the right wiki now. This mail accidentally
ended up in pmwiki's mailing list first. Oops.)
I have a phpwiki running. It's on version 1.3.4 and when I upgraded my
distribution to Debian Etch lately, phpwiki stopped serving me wiki
pages but opted for error messages instead. They probably have
something to do with php being upgraded, but I'm not too concerned
about *that*.
Since Debian now offers packages of phpwiki, I figured it's about time
to upgrade, using the Debian packages. apt-get install phpwiki
blablabla ...
Debian installs version 1.3.12p3. Now the question. having read
INSTALL.mysql, I concluded that normally phpwiki should upgrade the
database when you start load phpwiki in a browser. If not, you could
add ?action=upgrade to the url.
That doesn't work for me. I get asked to sign in. I enter the values of
ADMIN_USER and ADMIN_PASSWD in /etc/phpwiki/config.ini respectively.
The result:
Fatal Error:
lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such table
 (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
Table 'phpwiki.pref' doesn't exist])
Fatal PhpWiki Error
lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such table
 (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
Table 'phpwiki.pref' doesn't exist])
 Notice: Undefined property: WikiRequest::$_user in
/usr/share/phpwiki/lib/main.php on line 736
 DB Error: no such fieldDB Error: no such field
I did not forget to give the phpwiki mysql user create table/alter
table privileges.
Could someone give me a gentle push in the back please?
-- 
Frank Van Damme
This weekend, I've been mostly wearing geeky T-shirts.

Hi, I have just started to use phpwiki, and have installed version 1.2.10
which as far as I could understand was the current stable a couple of
weeks ago. I have two wishlist items and two possible bugs. I have been
looking around a bit, but have so far not been able to see if any work is
been done on these issues.
Would you recommend using any newer version than 1.2.10?
WL 1: css In 1.2.10, the page color and so on is defined in the body tag.
I am going to use css to be able to tweak the look of the pages a bit
more. Has this been done in any newer version? I am going to rewrite my
own installation, so if there is any interest, I can contribute my
patches.
WL 2: table prefix. I wanted to run two separate wikis on a domain that is
run by a ISP I have access to one mysql database there, so to be able to
run two separate wikis on that database, i need to be able to define som
prefix or suffix on the tables. (like eg wordpress is doing)
For both the bugs, I am not quite sure if the problem can be solved from
withing phpwiki or if it is on another level, but, anyhow, it is two
issues I ran accross:
bug 1: When installing the second wiki, I had to use dba rather than
mysql. After some trial and failure with a blank page, I found out that my
ISP was using db4 libs... (I found them using phpinfo()) I do not know if
it is possible, but if that does not work automagically, the configuration
is far from userfriendly.. Could it be possible to somehow give some more
feedback of what is happening? Also, make explicit driver selections that
can be commented out. Hmm, this maybe ended up as a whishlist item...
bug 2: Administration / login. One of my wikis runs in a password
protected area on my server. Even if I set it up with the same password
valid for external login and on the admin, I cannot log onto admin as long
as the directory is password protected. This may of cource be an issue
with how http-autentication is working. Maybe you could change the admin
password to use some custom session administration system rather than http
autentication?
anyhow, thanks for a great little software package! I would not have
bothered to write this if I did not generally like what I was seeing!
My server: php 446, apache 2.0.something / linux 2.4.x
browser: tested in Firefox on Win XP and linux as well as Konqueror on linux.
Morten

no, never on the server. but certain clients could execute this in the
worst case on pageview, and normally when they click on it.
by forcing the uploader to rename it, the user must rename it to
original to be able to execute it.
2007年3月12日, Manuel Vacelet <man...@gm...>:
> 2007年3月10日, Reini Urban <ru...@x-...>:
> > 2007年3月9日, Manuel Vacelet <man...@gm...>:
> > > 2007年3月9日, Sabri LABBENE <sab...@st...>:
> > > > BTW, we also turned off getimagesize() because it make the page loading very
> > > > slow. Will there be then any risk related to spam prevention ?
> > >
> > > In a intranet there is no risk.
> >
> > There's still the cockpit error risc. The risc of unaware users, who
> > just upload .vbs files as one just did yesterday in my companies'
> > super-secure intranet. Thanksfully we had the extension check.
> >
> > After renaming the .vbs to .vbs_ he could upload it, and users could
> > download it without immediate execution.
>
> I'm not that Microsoft Windows aware but this is a client executable
> not a server one isn't it ?
>
> I mean, there are no risks to see this vbs executed on the server
> (even a windows one) ?
>
> -- Manuel
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://spacemovie.mur.at/ http://helsinki.at/

2007年3月10日, Reini Urban <ru...@x-...>:
> 2007年3月9日, Manuel Vacelet <man...@gm...>:
> > 2007年3月9日, Sabri LABBENE <sab...@st...>:
> > > BTW, we also turned off getimagesize() because it make the page loading very
> > > slow. Will there be then any risk related to spam prevention ?
> >
> > In a intranet there is no risk.
>
> There's still the cockpit error risc. The risc of unaware users, who
> just upload .vbs files as one just did yesterday in my companies'
> super-secure intranet. Thanksfully we had the extension check.
>
> After renaming the .vbs to .vbs_ he could upload it, and users could
> download it without immediate execution.
I'm not that Microsoft Windows aware but this is a client executable
not a server one isn't it ?
I mean, there are no risks to see this vbs executed on the server
(even a windows one) ?
-- Manuel

2007年3月9日, Manuel Vacelet <man...@gm...>:
> 2007年3月9日, Sabri LABBENE <sab...@st...>:
> > BTW, we also turned off getimagesize() because it make the page loading very
> > slow. Will there be then any risk related to spam prevention ?
>
> In a intranet there is no risk.
There's still the cockpit error risc. The risc of unaware users, who
just upload .vbs files as one just did yesterday in my companies'
super-secure intranet. Thanksfully we had the extension check.
After renaming the .vbs to .vbs_ he could upload it, and users could
download it without immediate execution.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://spacemovie.mur.at/ http://helsinki.at/

2007年3月9日, Sabri LABBENE <sab...@st...>:
> BTW, we also turned off getimagesize() because it make the page loading very
> slow. Will there be then any risk related to spam prevention ?
In a intranet there is no risk.
-- Manuel

Reini Urban wrote:
>2007年3月8日, Sabri LABBENE <sab...@st...>:
>> Few days ago, I recieved a claim from a customer in our 
>company about not being able to upload a ".pl" file into 
>phpwiki. As you know ".pl" files and others are not allowed to 
>be uploaded for security reasons.
>> This raised several questions in my team:
>>
>> - What is the risk?
>> - Is the risk due to the usage of attachments by phpWiki?
>> - Could the risk be related to apache and upload directory 
>configurations ?
>> - If we configure apache to not execute files in the upload 
>directory, will be then a risk to run those files into the server?
>>
>> Is there any illustration/evidence related to the subject 
>that was identified or discussed before.
>>
>> What do you advise ?
>
>The risc is only due to apache or webserver or browser 
>configurations so that people might execute unwanted programs. 
>In a secure or trusted environments I would turn off this 
>extensions check.
In our site apache is configured to not execute files into the upload
directory of PhpWiki. Could this be sufficient?
>Be aware of INLINE_IMAGES. This list of extensions will be 
>inlined and executed per page view.
We commented this line in the config file:
;INLINE_IMAGES = "png|jpg|jpeg|gif"
So I think that there is no risk with inlined images.
BTW, we also turned off getimagesize() because it make the page loading very
slow. Will there be then any risk related to spam prevention ?
Thanks,
-- Sabri.

2007年3月7日, John Stevens <jst...@gm...>:
> On 3/7/07, Reini Urban <ru...@x-...> wrote:
> > plugin arguments get distorted, but the controls and the radio buttons
> > to switch between the two modes should appear and work.
> > Can you send me a screenshot and some environment info if it doesn't
> > work for you?
> >
>
> Hi Reini,
> Attached is a screenshot. This is all running on a RHEL4 AS host under
> apache php. It is a completely new install with the config file created
> with the configurator.php page, and edited to turn on Wysiwig editing. The
> install of Wikiwyg is out of the box from JSAN, version 1.2. Any assistance
> would be appreciated.
Ah, this is the problem! We heavily patched Wysiwig. you have to use
our version, not the official one.
> I really need to find out if this is competitive to
> Confluence which allows tables etc to be edited in a wysiwig fashion.
We do the table editing with the help of the RichTable plugin.
It's not that cool as with Confluence, but phpwiki has more advanced
features in its plugins.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://spacemovie.mur.at/ http://helsinki.at/

2007年3月8日, Sabri LABBENE <sab...@st...>:
> Few days ago, I recieved a claim from a customer in our company about not being able to upload a ".pl" file into phpwiki. As you know ".pl" files and others are not allowed to be uploaded for security reasons.
> This raised several questions in my team:
>
> - What is the risk?
> - Is the risk due to the usage of attachments by phpWiki?
> - Could the risk be related to apache and upload directory configurations ?
> - If we configure apache to not execute files in the upload directory, will be then a risk to run those files into the server?
>
> Is there any illustration/evidence related to the subject that was identified or discussed before.
>
> What do you advise ?
The risc is only due to apache or webserver or browser configurations
so that people might execute unwanted programs. In a secure or trusted
environments I would turn off this extensions check.
Be aware of INLINE_IMAGES. This list of extensions will be inlined and executed
per page view.

Hi all,
Few days ago, I recieved a claim from a customer in our company about =
not being able to upload a ".pl" file into phpwiki. As you know ".pl" =
files and others are not allowed to be uploaded for security reasons.
This raised several questions in my team:
- What is the risk?
- Is the risk due to the usage of attachments by phpWiki?
- Could the risk be related to apache and upload directory =
configurations ?
- If we configure apache to not execute files in the upload directory, =
will be then a risk to run those files into the server?=20
Is there any illustration/evidence related to the subject that was =
identified or discussed before.
What do you advise ?
Thanks,
Sabri LABBENE.

John Stevens schrieb:
> Long time no post. I am trying to find out the status of WYSIWYG 
> editing. The reason being that a lot of my users (my manager in 
> particular) are unhappy to use wiki markup, and hence are less inclined 
> to use phpwiki and want to move to another wiki, probably confluence. 
> What is the status of Wysiwyg, and how long before is is working well 
> enough to do it?
> 
> I am also having difficulty getting Wikiwyg working in a new instance of 
> the 1.3.13rc1. Ther is just a banner about the Beta quality, but no 
> controls to do editing with, or switch in/out of wysiwig mode. So any 
> ideas appreciated.
plugin arguments get distorted, but the controls and the radio buttons 
to switch between the two modes should appear and work.
Can you send me a screenshot and some environment info if it doesn't 
work for you?
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://helsinki.at/ http://spacemovie.mur.at/

Hi All,
Long time no post. I am trying to find out the status of WYSIWYG editing.
The reason being that a lot of my users (my manager in particular) are
unhappy to use wiki markup, and hence are less inclined to use phpwiki and
want to move to another wiki, probably confluence. What is the status of
Wysiwyg, and how long before is is working well enough to do it?
I am also having difficulty getting Wikiwyg working in a new instance of the
1.3.13rc1. Ther is just a banner about the Beta quality, but no controls to
do editing with, or switch in/out of wysiwig mode. So any ideas
appreciated.
Cheers
John

While working with phpwiki, I have run into a problem which has frustrated me
repeatedly for quite some time now. So I would like to open my case for review
by the experts.
Context:
A (considerably customized) wiki with a single administrator logon, no other
user accounts. Administrator gets password from config file.
Symptoms:
Administrator logs on, at which point user is authenticated and signed.
However, the logon does not stick, and the next page which is loaded is back to
only being signed, not authenticated.
Analysis:
In my searching, I believe I have nailed it down to the following:
In request.php
 in class Request_SessionVars
it attempts to save an object of type AdminUser into the session variable
'wikiuser'. However it is not retrievable on a reload of the page.
However, if I slightly modify the code so that instead of saving an AdminUser
object to the session variable wikiuser, it saves the UserPreferences object of
that AdminUser object, it is able to load the UserPreferences object back in.
Additionally, when tweaked to save the print_r of the AdminUser object (so
saving a long string to session var) it works correctly.
Only when attempting to save the AdminUser object does it not work.
My guess is that the AdminUser object cannot save because it seems to contain
references to database resources..? But I have tried modifying the AdminUser
object to not include these references with no result.

Hello Reini,
> Try the latest CalendarList version from CVS or the latest release.
> This error was fixed recently.
Thanks, but the Calendar List in "Browse CVS" on the SF site is
 CalendarList.php,v 1.9 2006年05月14日 17:40:31 rurban
 Sun May 14 17:40:31 2006 UTC (9 months, 3 weeks ago) by rurban
and that is what I have on disk.
I also replaced Calendar.php (now I have weeknums, cool ;-)
but that also didn't help with the list problem.
Any other file I need to replace ?
If the file is not yet in CVS, could you please mail it to me?
Thanks, Cheers,
Tom.
-- 
teicher.net - Guaranteed to be free of any useable content.

Tom Eicher schrieb:
> Hi again,
> 
> The CalendarList plugin seems to be broken in 1.3.12p3.
> 
> Today is 2007年03月04日. I have the Calendar started without a date
> and it correctly shows the "today".
> But the CalendarList shows dates from 2007年03月01日 until 2007年03月22日.
> (i.e. dates from 3 days ago)
> 
> Now when I click "next month" twice (month=5&year=2007) the list is
> empty, although I have (and the calendar shows) dates in Mai.
> 
> When going back in time: month=2&year=2007 displays
> all dates 2007年02月02日 - 2007年03月22日
> 
> I have
> <?plugin Calendar?>
> <?plugin CalendarList next_n_days='40'?>
> 
> Do I need to put more / other options ?
Try the latest CalendarList version from CVS or the latest release. This 
error was fixed recently.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://helsinki.at/ http://spacemovie.mur.at/

Hi again,
The CalendarList plugin seems to be broken in 1.3.12p3.
Today is 2007年03月04日. I have the Calendar started without a date
and it correctly shows the "today".
But the CalendarList shows dates from 2007年03月01日 until 2007年03月22日.
(i.e. dates from 3 days ago)
Now when I click "next month" twice (month=5&year=2007) the list is
empty, although I have (and the calendar shows) dates in Mai.
When going back in time: month=2&year=2007 displays
all dates 2007年02月02日 - 2007年03月22日
I have
<?plugin Calendar?>
<?plugin CalendarList next_n_days='40'?>
Do I need to put more / other options ?
Thanks & Cheers, Tom.