xoops-development — For those who are interested in XOOPS development

Re: [Xoops-development] Please delete this download at xoops.org

[K. O. <web...@my...>]

Thanks, I have deleted just now.

Kazu

----- Original Message ----- 
From: "Tobias Liegl" <in...@ch...>
To: <xoo...@li...>
Sent: Saturday, July 12, 2003 5:41 AM
Subject: [Xoops-development] Please delete this download at xoops.org


> Hi,
> 
> don't know if this mailing list is the right place for this issue but
> somebody should delete the following download at xoops.org. It doesn't
> look good on the homepage of xoops.org and it is there for nearly one
> day now!
> 
> http://www.xoops.org/modules/mydownloads/singlefile.php?lid=436
> 
> GreetZ
> Tobi
> 
> --
> www.chapi.de
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Xoops-development mailing list
> Xoo...@li...
> https://lists.sourceforge.net/lists/listinfo/xoops-development
> 

Re: [Xoops-development] addressing "blank page" problem

[K. O. <web...@my...>]

I guess we'd better stick with using the trigger_error function directly
otherwise we would need to pass the file name and line numbers explicitly
like
notice($msg, __FILE__, __LINE__); if we need to know where the error
occurred exactly and that doesn't seem to make things any easier for the
developers..

- Kazu


----- Original Message -----
From: "K. Ono" <web...@my...>
To: <xoo...@li...>
Sent: Thursday, July 10, 2003 4:21 PM
Subject: Re: [Xoops-development] addressing "blank page" problem


> > Or maybe this:  Leave the error handler always ON.  If debug mode is on,
> > show all errors and warnings (native PHP messages AND explicitly
> > 'triggered' messages).  If debug mode is off, show only 'triggered'
> > messages.  If we use trigger_error very sparingly (or E_USER_ERROR for
> > errors-to-be-displayed) then the end user will only see a message if
> > something goes very wrong (e.g. can't connect to database), which may be
> > useful to alert the site administrator.  (In a custom error handler you
> > can strip out any path info so this is not a security risk.)
>
> I like this idea.. Maybe we can wrap the trigger_error() function with a
> custom function/class so that we
>  can always call the custom trigger error function/method within the codes
> which does
> not always call the native trigger_error function. This way, the coders
> wouldn't need to
> think about whether to use the native trigger_error() function in certain
> areas of their
> codes but just always use the custom one wherever something wrong might
> happen.
>
> For example,
>
>
> class ErrorHandler
> {
>
>  function ErrorHandler()
>  {
>   set_error_handler(array(&$this, 'trigger'));
>  }
>
>  function trigger($errno, $errstr, $errfile, $errline)
>  {
>   switch ($errno) {
>     case E_USER_ERROR:
>       // do something here
>       break;
>     case E_USER_WARNING:
>       // do something here
>       break;
>     case E_USER_NOTICE:
>       // do something here
>       break;
>     default:
>       // do something here
>       break;
>   }
>
>  }
>
> // A class that triggers all errors
> class ShowAllErrorHandler extends ErrorHandler
> {
>
>  function notice($msg)
>  {
>   trigger_error(E_USER_NOTICE, $msg);
>  }
>
>  function warning($msg)
>  {
>   trigger_error(E_USER_WARNING, $msg);
>  }
>
>  function fatal($msg)
>  {
>   trigger_error(E_USER_ERROR, $msg);
>  }
> }
>
> // A class that triggers only fatal-level errors
> class FatalErrorHandler extends ErrorHandler
> {
>  function notice($msg)
>  {
>   // do nothing
>  }
>
>  function warning($msg)
>  {
>   // do nothing
>  }
>
>  function fatal($msg)
>  {
>   trigger_error(E_USER_ERROR, $msg);
>  }
> }
>
>
> And at startup, we can use a factory method/class to create one of the
error
> handler classes
> depending on a config setting or the user level (admin, anonymous, etc).
>
> $debug_level = $xoopsUser->isAdmin() ? XOOPS_DEBUG_SHOWALL :
> $config['debug_level'];
> $error_handler =& ErrorHandler::getInstance($debug_level);
> ...
> $error_handler->notice('A notice error');
> ...

Re: [Xoops-development] addressing "blank page" problem

[K. O. <web...@my...>]

> Or maybe this:  Leave the error handler always ON.  If debug mode is on,
> show all errors and warnings (native PHP messages AND explicitly
> 'triggered' messages).  If debug mode is off, show only 'triggered'
> messages.  If we use trigger_error very sparingly (or E_USER_ERROR for
> errors-to-be-displayed) then the end user will only see a message if
> something goes very wrong (e.g. can't connect to database), which may be
> useful to alert the site administrator.  (In a custom error handler you
> can strip out any path info so this is not a security risk.)

I like this idea.. Maybe we can wrap the trigger_error() function with a
custom function/class so that we
 can always call the custom trigger error function/method within the codes
which does
not always call the native trigger_error function. This way, the coders
wouldn't need to
think about whether to use the native trigger_error() function in certain
areas of their
codes but just always use the custom one wherever something wrong might
happen.

For example,


class ErrorHandler
{

 function ErrorHandler()
 {
  set_error_handler(array(&$this, 'trigger'));
 }

 function trigger($errno, $errstr, $errfile, $errline)
 {
  switch ($errno) {
    case E_USER_ERROR:
      // do something here
      break;
    case E_USER_WARNING:
      // do something here
      break;
    case E_USER_NOTICE:
      // do something here
      break;
    default:
      // do something here
      break;
  }

 }

// A class that triggers all errors
class ShowAllErrorHandler extends ErrorHandler
{

 function notice($msg)
 {
  trigger_error(E_USER_NOTICE, $msg);
 }

 function warning($msg)
 {
  trigger_error(E_USER_WARNING, $msg);
 }

 function fatal($msg)
 {
  trigger_error(E_USER_ERROR, $msg);
 }
}

// A class that triggers only fatal-level errors
class FatalErrorHandler extends ErrorHandler
{
 function notice($msg)
 {
  // do nothing
 }

 function warning($msg)
 {
  // do nothing
 }

 function fatal($msg)
 {
  trigger_error(E_USER_ERROR, $msg);
 }
}


And at startup, we can use a factory method/class to create one of the error
handler classes
depending on a config setting or the user level (admin, anonymous, etc).

$debug_level = $xoopsUser->isAdmin() ? XOOPS_DEBUG_SHOWALL :
$config['debug_level'];
$error_handler =& ErrorHandler::getInstance($debug_level);
...
$error_handler->notice('A notice error');
...

Re: [Xoops-development] addressing "blank page" problem

[R. M. v. D. <mv...@ca...>]

Sounds good.  I have been playing around with this on another small
project I'm working on and it works pretty nicely.  PHP also allows you
to override the 'exit' function (register_shutdown_function).  What I've
done is have 'trigger_error' log the error message into a static array,
then when the script ends (perhaps due to an 'exit'), then the error
messages are appended to the output.

One problem with this:

It is nice to be able to provide users with the option of leaving
debugging on or off as desired on a production site.  But if debugging is
turned off, then it really doesn't help people with the 'blank page'
problem.  If debugging is *on* then all notices/warnings etc. will also be
displayed.

Perhaps we can turn on debugging by default during installation.  Then on
the admin pages we can have a big red box that says 'Warning: you have
debugging enabled which is a potential security risk.  Please turn it off
when your site is opened to visitors.'  That way the admin user gets to
see all the messages as the site is set up and can turn them off when
ready.

Or perhaps another alternative... leave the error handler *always* on.  If
the user is the admin user, then show the messages, otherwise do not show
them.  This does not allow debugging of problems which occur only for e.g.
anonymous users though.

Or maybe this:  Leave the error handler always ON.  If debug mode is on,
show all errors and warnings (native PHP messages AND explicitly
'triggered' messages).  If debug mode is off, show only 'triggered'
messages.  If we use trigger_error very sparingly (or E_USER_ERROR for
errors-to-be-displayed) then the end user will only see a message if
something goes very wrong (e.g. can't connect to database), which may be
useful to alert the site administrator.  (In a custom error handler you
can strip out any path info so this is not a security risk.)

Any other thoughts on this?

Regards,
Mike



On Thu, 10 Jul 2003, K. Ono wrote:

> I agree that Xoops needs a centralized mechanism for handling errors.
> Using the trigger_error/set_error_handler functions seem to be the way to
> go.
>
> - Kazu
>
> ----- Original Message -----
> From: "R. Michael van Dam" <mv...@ca...>
> To: <xoo...@li...>
> Sent: Thursday, July 10, 2003 2:07 AM
> Subject: [Xoops-development] addressing "blank page" problem
>
>
> >
> > Greetings,
> >
> > There has been a huge flurry of "blank page" posts on the forums in the
> > past few months.  I think we should do something about this... i.e. try
> > and give a meaningful message instead of just the script failing.
> >
> > For example, in include/common.php... if the DatabaseFactory returns
> > 'false', I think we should explicitly print an error and halt the script.
> > (Even if the install goes perfectly, the database setup can change or the
> > database can fail to restart when a machine is rebooted.)
> > Otherwise people get the problem of 'call to a member of a non-object'
> > later on which doesn't really identify the problem (for a non-programmer).
> >
> > I was about to add (after XoopsDatabaseFactory::get()) :
> >
> > if (false === $xoopsDB) {
> >   echo "ERROR: Could not connect to database.  Please check your settings
> > in mainfile.php";
> >   exit;
> > }
> >
> > But it seems like maybe xoops could benefit from a centralized mechanism
> > for doing this.  Perhaps we can provide a custom error handler
> > (set_error_handler) and use trigger_error?  Or maybe the 'echo/exit'
> > combination is good enough?
> >
> > Database failure seems to be the most common cause of the blank page
> > problem... I'm not sure if we can catch many others... some are due to
> > corrupt files (resulting in parse error or undefined function, which I
> > don't think we can 'catch' with a custom error handler)...
> >
> > Any suggestions on the best way to do this?
> >
> > Best regards,
> >
> > Mike
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps
> _______________________________________________
> Xoops-development mailing list
> Xoo...@li...
> https://lists.sourceforge.net/lists/listinfo/xoops-development
>
>

Re: [Xoops-development] addressing "blank page" problem

[K. O. <web...@my...>]

I agree that Xoops needs a centralized mechanism for handling errors.
Using the trigger_error/set_error_handler functions seem to be the way to
go.

- Kazu

----- Original Message -----
From: "R. Michael van Dam" <mv...@ca...>
To: <xoo...@li...>
Sent: Thursday, July 10, 2003 2:07 AM
Subject: [Xoops-development] addressing "blank page" problem


>
> Greetings,
>
> There has been a huge flurry of "blank page" posts on the forums in the
> past few months.  I think we should do something about this... i.e. try
> and give a meaningful message instead of just the script failing.
>
> For example, in include/common.php... if the DatabaseFactory returns
> 'false', I think we should explicitly print an error and halt the script.
> (Even if the install goes perfectly, the database setup can change or the
> database can fail to restart when a machine is rebooted.)
> Otherwise people get the problem of 'call to a member of a non-object'
> later on which doesn't really identify the problem (for a non-programmer).
>
> I was about to add (after XoopsDatabaseFactory::get()) :
>
> if (false === $xoopsDB) {
>   echo "ERROR: Could not connect to database.  Please check your settings
> in mainfile.php";
>   exit;
> }
>
> But it seems like maybe xoops could benefit from a centralized mechanism
> for doing this.  Perhaps we can provide a custom error handler
> (set_error_handler) and use trigger_error?  Or maybe the 'echo/exit'
> combination is good enough?
>
> Database failure seems to be the most common cause of the blank page
> problem... I'm not sure if we can catch many others... some are due to
> corrupt files (resulting in parse error or undefined function, which I
> don't think we can 'catch' with a custom error handler)...
>
> Any suggestions on the best way to do this?
>
> Best regards,
>
> Mike
>
>

Re: [Xoops-development] newbb minor bug

[R. M. v. D. <mv...@ca...>]

On Wed, 9 Jul 2003, K. Ono wrote:

> Hi Chapi,
>
> Sure, but unfortunately I do not have the time to look into them all.
> If possible, I would like somebody very familiar with XSS and related
> security vulnerabilities to take a look at the codes.
>
> There are really many hacks/modules that look very interesting and should be
> integrated to the core, but that's not very esay since some of them lack
> making the codes
> secure enough. It is very easy to secure them once they are found, but it is
> really easily
> forgotten as well. One little cross site scripting hole requires another
> 2.0.x. ;-)

I think all 'xss' vulnerabilities can be addressed simply by placing
the construct:

if (!defined('XOOPS_ROOT_PATH')) {
    exit();
}

at the top of any file which is not meant to be called directly.  (As is
done in xoops core now.)  Or is this too simplistic a view of the issue?

Other vulnerabilities need to be checked as well... e.g. all the
queries must be checked that any strings coming from GET/POST/etc args are
properly 'escaped/quoted' to prevent 'sql injection' attacks.  Also the
codes must be check that there are no 'register_globals' vulnerabilities,
and also that it works with 'register_globals' set to 'off'.

If I have some time I can start to look at some of these.  Are there any
hacks which should receive priority... i.e. most useful/desired in the
community?

Best regards,

Mike

[Xoops-development] addressing "blank page" problem

[R. M. v. D. <mv...@ca...>]

Greetings,

There has been a huge flurry of "blank page" posts on the forums in the
past few months.  I think we should do something about this... i.e. try
and give a meaningful message instead of just the script failing.

For example, in include/common.php... if the DatabaseFactory returns
'false', I think we should explicitly print an error and halt the script.
(Even if the install goes perfectly, the database setup can change or the
database can fail to restart when a machine is rebooted.)
Otherwise people get the problem of 'call to a member of a non-object'
later on which doesn't really identify the problem (for a non-programmer).

I was about to add (after XoopsDatabaseFactory::get()) :

if (false === $xoopsDB) {
  echo "ERROR: Could not connect to database.  Please check your settings
in mainfile.php";
  exit;
}

But it seems like maybe xoops could benefit from a centralized mechanism
for doing this.  Perhaps we can provide a custom error handler
(set_error_handler) and use trigger_error?  Or maybe the 'echo/exit'
combination is good enough?

Database failure seems to be the most common cause of the blank page
problem... I'm not sure if we can catch many others... some are due to
corrupt files (resulting in parse error or undefined function, which I
don't think we can 'catch' with a custom error handler)...

Any suggestions on the best way to do this?

Best regards,

Mike

Re: [Xoops-development] newbb minor bug

[K. O. <web...@my...>]

Hi Chapi,

Sure, but unfortunately I do not have the time to look into them all.
If possible, I would like somebody very familiar with XSS and related
security vulnerabilities to take a look at the codes.

There are really many hacks/modules that look very interesting and should be
integrated to the core, but that's not very esay since some of them lack
making the codes
secure enough. It is very easy to secure them once they are found, but it is
really easily
forgotten as well. One little cross site scripting hole requires another
2.0.x. ;-)

Anyway, the newbb hacks look really interesting and I will test them if time
permits..

- Kazu



----- Original Message -----
From: "Tobias Liegl" <in...@ch...>
To: <xoo...@li...>
Sent: Wednesday, July 09, 2003 12:29 AM
Subject: AW: [Xoops-development] newbb minor bug


Hi,

while you were fixing bugs of newbb. Did you saw the "hacks" contributed
for the newbb? Here is a listing of them:
http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=10078&forum=8

How about integrating these "hacks" too?

Also did you read the following thread?
http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=10156&forum=8
Catzwolf has integrade many features in the newbb of xoops1 and will
port these changes to the newbb of xoops2.

Maybe this is also a module enhancement to look after ..

This is just meant for information, as I don't know if your read ALL the
posts at xoops.org ;-)

Greetz
Tobi aka chapi
--
www.chapi.de

AW: [Xoops-development] newbb minor bug

[Tobias L. <in...@ch...>]

Hi,

while you were fixing bugs of newbb. Did you saw the "hacks" contributed
for the newbb? Here is a listing of them:
http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=3D10078&forum=3D=
8

How about integrating these "hacks" too?

Also did you read the following thread?
http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=3D10156&forum=3D=
8
Catzwolf has integrade many features in the newbb of xoops1 and will
port these changes to the newbb of xoops2.

Maybe this is also a module enhancement to look after ..

This is just meant for information, as I don't know if your read ALL the
posts at xoops.org ;-)

Greetz
Tobi aka chapi
--
www.chapi.de


-----Urspr=FCngliche Nachricht-----
Von: xoo...@li...
[mailto:xoo...@li...] Im Auftrag von K.
Ono
Gesendet: Dienstag, 8. Juli 2003 12:41
An: xoo...@li...
Betreff: Re: [Xoops-development] newbb minor bug

I have fixed the first one on CVS.

As for the second one, the showtree() function in viewtopic.php will
show
the correct post
at the top of the thread tree if post_id is provided in the URL. I have
added the post_id parameter
to the thread url (&post_id=3DXXX) of the notification mail by modifying
post.php.
 Have not tested it yet, but hopefully it should work fine now..

- Kazu

> A user on xoops.org, ScoobRS, has pointed out a minor bug with
newbb...
>
> (1) After submitting a 'post', you are redirected to a page with
'jump=3D1'
> which gives the thread in newest first order.  However the links to
> additional pages in the thread (1, 2, 3 at bottom) give the thread in
> oldest first order.  This is inconsistent and confusing.
>
> (2) The notification email and forum index try to jump to the correct
post
> (via an anchor #forumpostXYZ) but for a multi-page thread, this does
not
> automatically jump to the correct page.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Xoops-development mailing list
Xoo...@li...
https://lists.sourceforge.net/lists/listinfo/xoops-development

Re: [Xoops-development] newbb minor bug

[K. O. <web...@my...>]

I have fixed the first one on CVS.

As for the second one, the showtree() function in viewtopic.php will show
the correct post
at the top of the thread tree if post_id is provided in the URL. I have
added the post_id parameter
to the thread url (&post_id=XXX) of the notification mail by modifying
post.php.
 Have not tested it yet, but hopefully it should work fine now..

- Kazu

> A user on xoops.org, ScoobRS, has pointed out a minor bug with newbb...
>
> (1) After submitting a 'post', you are redirected to a page with 'jump=1'
> which gives the thread in newest first order.  However the links to
> additional pages in the thread (1, 2, 3 at bottom) give the thread in
> oldest first order.  This is inconsistent and confusing.
>
> (2) The notification email and forum index try to jump to the correct post
> (via an anchor #forumpostXYZ) but for a multi-page thread, this does not
> automatically jump to the correct page.

[Xoops-development] newbb minor bug

[R. M. v. D. <mv...@ca...>]

A user on xoops.org, ScoobRS, has pointed out a minor bug with newbb...

(1) After submitting a 'post', you are redirected to a page with 'jump=1'
which gives the thread in newest first order.  However the links to
additional pages in the thread (1, 2, 3 at bottom) give the thread in
oldest first order.  This is inconsistent and confusing.

(2) The notification email and forum index try to jump to the correct post
(via an anchor #forumpostXYZ) but for a multi-page thread, this does not
automatically jump to the correct page.

A possible fix is to:

- after 'post', go to oldest-first thread order and jump to the correct
post on the last page of the thread

- the page-number links should take into account the current 'order' of
the thread an be consistent with it

- the notification email and forum index links should also jump to the
correct page

The only worry is that, in some cases, we may need an extra query to get
the number of posts in the thread.  During a 'post' operation I don't
think this is critical, but during viewing of the thread it should be
avoided.  Perhaps there is some way to get this info by tapping into one
of the existing queries.

Any other thoughts?

Mike

[Xoops-development] Confirmation of bug 692756

[[Samwise] <sam...@op...>]

Sourceforge is giving me errors when I try to submit a comment to a bug, 
so I am sending this here.

  Per the request mvandam made on xoops.org today, I want to confirm 
that the oldest bug,
[ 692756 ] Whos Online, is reproduceable on my system.  I exhibit the 
same behavior as outlined by w4z004/Catzwolf. 

Also, if you disable this feature/block, whoever is online at the time 
gets frozen into a permanent state of being online.  You have to clear 
the table in the db manually.

Re: [Xoops-development] autologin ("remember me") for XOOPS)

[Martin K. <Mar...@bl...>]

Martin Kutschker <Mar...@bl...> writes on 
Sat, 21 Jun 2003 10:16:07 +0200 (METDST):

> Hi!
> 
> Found this hack recently:
>
> http://www.xoops.org/modules/newbb/viewtopic.php?forum=8&topic_id=10078#forumpost39652
>
> A nice start that needs some polishing (see my reply in the forum).


Ok, an auto-login hack exists already. The existing also has some flaws.

I want to see this in XOOPS. At least in XOOPS 2.1.

Masi

PS: Definitly whishing for a roadmap. 

[Xoops-development] autologin ("remember me") for XOOPS)

[Martin K. <Mar...@bl...>]

Hi!

Found this hack recently:

http://www.xoops.org/modules/newbb/viewtopic.php?forum=8&topic_id=10078#forumpost39652

A nice start that needs some polishing (see my reply in the forum).

Masi 

Re: [Xoops-development] XOOPS 2.0.3 released

[[Samwise] <sam...@op...>]

Hi Kazu,

Uploading

modules/newbb/class/class.forumposts.php

again appears to have fixed it. Sorry to bother y'all, but I didn't know
what file to look at. :-P

Thank you again for all your hard work on XOOPS.

Best regards,
Ron

K. Ono wrote:

>Hi,
>
>I am not sure why that happens.
>Can you try re-uploading the following file to your server?
>modules/newbb/class/class.forumposts.php
>
>And if that sill does not work, enable PHP debug in the preferences and see
>if you get any error on that page.
>
>- Kazu
>
>----- Original Message -----
>From: "[Samwise]" <sam...@op...>
>To: "K. Ono" <web...@my...>
>Cc: <xoo...@li...>
>Sent: Wednesday, June 18, 2003 9:13 PM
>Subject: Re: [Xoops-development] XOOPS 2.0.3 released
>
>
>  
>
>>Hi,
>>Thanks for the quick response.
>>
>>I get it on every forum post you open for the first time. If you reopen
>>it by clicking its name again without leaving the page, it goes away. If
>>you go to a different spot and return to the forum post (or any other
>>post) you see it again.
>>
>>If you go to http://linux-universe.com and click any of the "recent
>>forum posts" in my centerL block, you will see it more clearly.
>>
>>Thanks again!
>>
>>
>>K. Ono wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>On which page/file do you get this error?
>>>
>>>- Kazu
>>>
>>>----- Original Message -----
>>>From: "[Samwise]" <sam...@op...>
>>>To: "K. Ono" <web...@my...>
>>>Cc: <xoo...@li...>
>>>Sent: Wednesday, June 18, 2003 8:51 PM
>>>Subject: Re: [Xoops-development] XOOPS 2.0.3 released
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Hello,
>>>>Can anyone help me with this. After upgrading I have this when you open
>>>>a forum post for the first time:
>>>>
>>>>y; } function icon(){ return $this->icon; } function forum(){ return
>>>>$this->forum_id; } function attachsig(){ return $this->attachsig; }
>>>>function prefix(){ return $this->prefix; } function istopic() { if
>>>>($this->istopic) { return true; } return false; } function islocked() {
>>>>if ($this->islocked) { return true; } return false; } } ?>
>>>>
>>>>It appears on the top of the page before any of the HTML is parsed.
>>>>
>>>>Thank you.
>>>>
>>>>        
>>>>
>  
>

Re: [Xoops-development] XOOPS 2.0.3 released

[K. O. <web...@my...>]

Hi,

I am not sure why that happens.
Can you try re-uploading the following file to your server?
modules/newbb/class/class.forumposts.php

And if that sill does not work, enable PHP debug in the preferences and see
if you get any error on that page.

- Kazu

----- Original Message -----
From: "[Samwise]" <sam...@op...>
To: "K. Ono" <web...@my...>
Cc: <xoo...@li...>
Sent: Wednesday, June 18, 2003 9:13 PM
Subject: Re: [Xoops-development] XOOPS 2.0.3 released


> Hi,
> Thanks for the quick response.
>
> I get it on every forum post you open for the first time. If you reopen
> it by clicking its name again without leaving the page, it goes away. If
> you go to a different spot and return to the forum post (or any other
> post) you see it again.
>
> If you go to http://linux-universe.com and click any of the "recent
> forum posts" in my centerL block, you will see it more clearly.
>
> Thanks again!
>
>
> K. Ono wrote:
>
> >Hi,
> >
> >On which page/file do you get this error?
> >
> >- Kazu
> >
> >----- Original Message -----
> >From: "[Samwise]" <sam...@op...>
> >To: "K. Ono" <web...@my...>
> >Cc: <xoo...@li...>
> >Sent: Wednesday, June 18, 2003 8:51 PM
> >Subject: Re: [Xoops-development] XOOPS 2.0.3 released
> >
> >
> >
> >
> >>Hello,
> >>Can anyone help me with this. After upgrading I have this when you open
> >>a forum post for the first time:
> >>
> >>y; } function icon(){ return $this->icon; } function forum(){ return
> >>$this->forum_id; } function attachsig(){ return $this->attachsig; }
> >>function prefix(){ return $this->prefix; } function istopic() { if
> >>($this->istopic) { return true; } return false; } function islocked() {
> >>if ($this->islocked) { return true; } return false; } } ?>
> >>
> >>It appears on the top of the page before any of the HTML is parsed.
> >>
> >>Thank you.
> >>
> >>
> >>K. Ono wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>We have just released version 2.0.3, which includes patches for minor
> >>>
> >>>
> >bugs
> >
> >
> >>>and possible CSS vulnerability in the global search page. Please read
the
> >>>announcement at xoops.org for more information of the released package.
> >>>
> >>>- Kazu
> >>>
> >>>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: INetU
> >Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> >_______________________________________________
> >Xoops-development mailing list
> >Xoo...@li...
> >https://lists.sourceforge.net/lists/listinfo/xoops-development
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Xoops-development mailing list
> Xoo...@li...
> https://lists.sourceforge.net/lists/listinfo/xoops-development
>

Re: [Xoops-development] XOOPS 2.0.3 released

[[Samwise] <sam...@op...>]

Hi,
Thanks for the quick response.

I get it on every forum post you open for the first time. If you reopen
it by clicking its name again without leaving the page, it goes away. If
you go to a different spot and return to the forum post (or any other
post) you see it again.

If you go to http://linux-universe.com and click any of the "recent
forum posts" in my centerL block, you will see it more clearly.

Thanks again!


K. Ono wrote:

>Hi,
>
>On which page/file do you get this error?
>
>- Kazu
>
>----- Original Message -----
>From: "[Samwise]" <sam...@op...>
>To: "K. Ono" <web...@my...>
>Cc: <xoo...@li...>
>Sent: Wednesday, June 18, 2003 8:51 PM
>Subject: Re: [Xoops-development] XOOPS 2.0.3 released
>
>
>  
>
>>Hello,
>>Can anyone help me with this. After upgrading I have this when you open
>>a forum post for the first time:
>>
>>y; } function icon(){ return $this->icon; } function forum(){ return
>>$this->forum_id; } function attachsig(){ return $this->attachsig; }
>>function prefix(){ return $this->prefix; } function istopic() { if
>>($this->istopic) { return true; } return false; } function islocked() {
>>if ($this->islocked) { return true; } return false; } } ?>
>>
>>It appears on the top of the page before any of the HTML is parsed.
>>
>>Thank you.
>>
>>
>>K. Ono wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>We have just released version 2.0.3, which includes patches for minor
>>>      
>>>
>bugs
>  
>
>>>and possible CSS vulnerability in the global search page. Please read the
>>>announcement at xoops.org for more information of the released package.
>>>
>>>- Kazu
>>>      
>>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>Xoops-development mailing list
>Xoo...@li...
>https://lists.sourceforge.net/lists/listinfo/xoops-development
>
>  
>

Re: [Xoops-development] XOOPS 2.0.3 released

[K. O. <web...@my...>]

Hi,

On which page/file do you get this error?

- Kazu

----- Original Message -----
From: "[Samwise]" <sam...@op...>
To: "K. Ono" <web...@my...>
Cc: <xoo...@li...>
Sent: Wednesday, June 18, 2003 8:51 PM
Subject: Re: [Xoops-development] XOOPS 2.0.3 released


> Hello,
> Can anyone help me with this. After upgrading I have this when you open
> a forum post for the first time:
>
> y; } function icon(){ return $this->icon; } function forum(){ return
> $this->forum_id; } function attachsig(){ return $this->attachsig; }
> function prefix(){ return $this->prefix; } function istopic() { if
> ($this->istopic) { return true; } return false; } function islocked() {
> if ($this->islocked) { return true; } return false; } } ?>
>
> It appears on the top of the page before any of the HTML is parsed.
>
> Thank you.
>
>
> K. Ono wrote:
>
> >Hi,
> >
> >We have just released version 2.0.3, which includes patches for minor
bugs
> >and possible CSS vulnerability in the global search page. Please read the
> >announcement at xoops.org for more information of the released package.
> >
> >- Kazu

Re: [Xoops-development] XOOPS 2.0.3 released

[[Samwise] <sam...@op...>]

Hello,
Can anyone help me with this. After upgrading I have this when you open
a forum post for the first time:

y; } function icon(){ return $this->icon; } function forum(){ return
$this->forum_id; } function attachsig(){ return $this->attachsig; }
function prefix(){ return $this->prefix; } function istopic() { if
($this->istopic) { return true; } return false; } function islocked() {
if ($this->islocked) { return true; } return false; } } ?>

It appears on the top of the page before any of the HTML is parsed.

Thank you.


K. Ono wrote:

>Hi,
>
>We have just released version 2.0.3, which includes patches for minor bugs
>and possible CSS vulnerability in the global search page. Please read the
>announcement at xoops.org for more information of the released package.
>
>- Kazu
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>Xoops-development mailing list
>Xoo...@li...
>https://lists.sourceforge.net/lists/listinfo/xoops-development
>
>  
>

[Xoops-development] XOOPS 2.0.3 released

[K. O. <web...@my...>]

Hi,

We have just released version 2.0.3, which includes patches for minor bugs
and possible CSS vulnerability in the global search page. Please read the
announcement at xoops.org for more information of the released package.

- Kazu

Re: [Xoops-development] new version XoopsObjectHandler

[Martin K. <Mar...@bl...>]

"K. Ono" <on...@xo...> writes on 
Sun, 08 Jun 2003 04:42:35 +0200 (METDST):

> 
> > Set a limit (or start and limit) by itself (no where clause). I
> > didn't see
> a way to achieve this, so I did fetch() this way.
> 
> Yes, you can set it without the where part by creating an instance of
> the CriteriaCompo class
> that doesn't contain any child instance of the Criteria class.
> 
> $criteria = new CriteriaCompo();
> $criteria->setLimit(10);
> $criteria->setStart(5);
> With the above code, either $criteria->renderWhere() or
> $criteria->render()
> will return an empty string.


Ok, so we don't need a fetch() method like this. But I'd like to have a default sorting for the class. We could either let my extended constructor like it is (with sort ahnd sort order arguments) or remove them but retain the methods to set them explicitely. Or we could change the whole mechanism to a default Criteria object (again with the choices of constructor argument and/or method).

Should Criteria move to class if ObjectHandler depends on it (though indirectly).


> > I also wasn't sure if I could add multiple sort columns (with
> > separate sort order). Or how to use multiple group by columns. I
> > need some time to play with the class.
> 
> You're right and this is not currently possible. You can only set
> multiple sort columns.
> $criteria->setSort('id, title');


BTW, you cannot change the sort order after changing it from the default.

Masi

PS: How can some general info for a class/file be added to the documtation. I know how it works in Doxygen and would like to add some lines of tipps and tricks for Object and Criteria.

That is, if I find the time ;-) 

Re: [Xoops-development] xoops.org stats

[R. M. v. D. <mv...@ca...>]

Thanks very much for checking.  The message I am getting is (from the
'Edit User' page):

  Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
  allocate 41 bytes) in [...]/xoops2/kernel/object.php on line 176

The strange thing (at least I *think* it is strange), is that it always
runs out of memory at a *different* point.  e.g. If I print out loop
iterations, I never get the exact same number before it quits.  Roughly
it loads about 200-400 of the 700 users usually.

Any thoughts as to what this might be, and why when I reload the page it
runs out of memory at a different point??  I'm going to look into PHP and
see if there are any memory leak issues with 4.1.2.  Perhaps it could also
be a mysql issue... my version is 4.1alpha (and the other user who had
the problem was running 3.23.x)...

Regards,
Mike


On Sun, 8 Jun 2003, K. Ono wrote:

> Yes, it is set to 8M in php.ini and the edit users page works fine. I've
> enabled
> the access right to that page on your account in case you need to test it
> online..
>
> BTW, what exact error message do you get for the error?
> If it is really an issue of the memory limit setting in php, you would
> probably get
> a 'Fatal error' message that php generates. If not, it might be an error
> reported by mysql.
>
> Thanks and regards,
> K. Ono
>
>
> ----- Original Message -----
> From: "R. Michael van Dam" <mv...@ca...>
> To: "K. Ono" <on...@xo...>
> Sent: Sunday, June 08, 2003 12:25 PM
> Subject: Re: [Xoops-development] xoops.org stats
>
>
> >
> > Just to follow up on this... I *was* able to reproduce the problem on my
> > own site.
> >
> > I am using latest CVS codes, have register_globals ON, am running PHP
> > 4.1.2 with all standard settings in that version including the 8M memory
> > limit.  I created 700 bogus users (as that is how many another user who
> > reported this problem had) and suffered the same problems.
> >
> > There are a couple places where it loads ALL users.  In administration,
> > under 'edit user', it loads the whole list of usernames to show the
> > 'select' to choose which user you want to edit.  Also in administration
> > under 'edit groups', when you choose a group to edit, it shows at the
> > bottom of the screen a list of *all* users so you can select which ones to
> > add to the current group.  This also happens on mail users, when the
> > number of selected users become large (e.g. choosing 'registered users').
> >
> > The rest of the site seems to function normally.
> >
> > To run out of 8MB loading only 700 users means that each user object takes
> > up at least 10kB in memory.  (Of course things like smarty etc. are taking
> > up a large chunk so this estimate is probably a little large.)  This seems
> > like an awfully huge amount of overhead.
> >
> > I don't know enough about PHP to know if it just has enormous overhead in
> > its handling of classes, or perhaps there are some memory errors in this
> > version of PHP.  (Unfortunately I don't have a server available at the
> > moment where I can install a later version of PHP.)  The other user with
> > the problem is running 4.1.2 also.
> >
> > If it is not too much trouble, could you just confirm in /etc/php.ini that
> > you have 'memory_limit = 8M', and that 'Edit User' works correctly on the
> > xoops.org site?  I assume there are more than 700 users there.  If
> > everything checks out, then this probably points to PHP 4.1.2 as the
> > culprit, and would give me a concrete place to start looking for problems.
> >
> > Thanks!
> >
> > Regards,
> > Mike
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Xoops-development mailing list
> Xoo...@li...
> https://lists.sourceforge.net/lists/listinfo/xoops-development
>
>

Re: [Xoops-development] xoops.org stats

[K. O. <on...@xo...>]

Yes, it is set to 8M in php.ini and the edit users page works fine. I've
enabled
the access right to that page on your account in case you need to test it
online..

BTW, what exact error message do you get for the error?
If it is really an issue of the memory limit setting in php, you would
probably get
a 'Fatal error' message that php generates. If not, it might be an error
reported by mysql.

Thanks and regards,
K. Ono


----- Original Message -----
From: "R. Michael van Dam" <mv...@ca...>
To: "K. Ono" <on...@xo...>
Sent: Sunday, June 08, 2003 12:25 PM
Subject: Re: [Xoops-development] xoops.org stats


>
> Just to follow up on this... I *was* able to reproduce the problem on my
> own site.
>
> I am using latest CVS codes, have register_globals ON, am running PHP
> 4.1.2 with all standard settings in that version including the 8M memory
> limit.  I created 700 bogus users (as that is how many another user who
> reported this problem had) and suffered the same problems.
>
> There are a couple places where it loads ALL users.  In administration,
> under 'edit user', it loads the whole list of usernames to show the
> 'select' to choose which user you want to edit.  Also in administration
> under 'edit groups', when you choose a group to edit, it shows at the
> bottom of the screen a list of *all* users so you can select which ones to
> add to the current group.  This also happens on mail users, when the
> number of selected users become large (e.g. choosing 'registered users').
>
> The rest of the site seems to function normally.
>
> To run out of 8MB loading only 700 users means that each user object takes
> up at least 10kB in memory.  (Of course things like smarty etc. are taking
> up a large chunk so this estimate is probably a little large.)  This seems
> like an awfully huge amount of overhead.
>
> I don't know enough about PHP to know if it just has enormous overhead in
> its handling of classes, or perhaps there are some memory errors in this
> version of PHP.  (Unfortunately I don't have a server available at the
> moment where I can install a later version of PHP.)  The other user with
> the problem is running 4.1.2 also.
>
> If it is not too much trouble, could you just confirm in /etc/php.ini that
> you have 'memory_limit = 8M', and that 'Edit User' works correctly on the
> xoops.org site?  I assume there are more than 700 users there.  If
> everything checks out, then this probably points to PHP 4.1.2 as the
> culprit, and would give me a concrete place to start looking for problems.
>
> Thanks!
>
> Regards,
> Mike
>

Re: [Xoops-development] xoops.org stats

[K. O. <on...@xo...>]

> I was just wondering if someone could quickly let me know a few stats of
> the xoops.org site.  I am trying to help someone who is getting an 'out of
> memory' error with an 8M limit (php.ini) while loading a user
> administration page (just over 700 users).

The xoops.org site is using the default setting of php.ini included in 4.3.1
but with register_globals
turned on. So far, I haven't experienced any error like that yet on the
site..
I had some users complain about this before, but those people had a very
large site with thousands of
registered users, and was using an old version of XOOPS which did not have
paging capability in the
'Edit groups' page.

- Kazu

Re: [Xoops-development] new version XoopsObjectHandler

[K. O. <on...@xo...>]

> Set a limit (or start and limit) by itself (no where clause). I didn't see
a way to achieve this, so I did fetch() this way.

Yes, you can set it without the where part by creating an instance of the
CriteriaCompo class
that doesn't contain any child instance of the Criteria class.

$criteria = new CriteriaCompo();
$criteria->setLimit(10);
$criteria->setStart(5);
With the above code, either $criteria->renderWhere() or $criteria->render()
will return an empty string.


> I also wasn't sure if I could add multiple sort columns (with separate
sort order). Or how to use multiple group by columns. I need some time to
play with the class.

You're right and this is not currently possible. You can only set multiple
sort columns.
$criteria->setSort('id, title');


- Kazu