php-general Digest 16 Apr 2012 02:00:11 -0000 Issue 7776
Topics (messages 317553 through 317562):
Re: strict nannying ...
317553 by: Stuart Dallas
317554 by: Lester Caine
317555 by: Stuart Dallas
317556 by: Lester Caine
317557 by: Stuart Dallas
317558 by: Lester Caine
317559 by: Stuart Dallas
Customized Session Handler can not work for PHP 5.1.6 and CentOS 5.5
317560 by: Mingda
317561 by: Mingda
317562 by: Mingda
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 15 Apr 2012, at 11:44, Lester Caine wrote:
> I've got a machine set up with PHP5.4 and left the strict errors showing, and
> I'm falling at the first hurdle :)
>
> The functions for generating URL's are used both statically and as part of
> the class. STRICT complains because they are not marked 'static' ( and I'm
> assuming 'public static' is the correct addition here ) but then of cause the
> $this fallback fails because '$this' is not allowed IN the static use of the
> function?
>
> How do others get around this problem? I've some 120 static instances to fix
> in parallel with about the same number of class uses across about 40 odd
> functions. Do I really have to duplicate the code and rename every static use?
If the class can be used both statically and as an instance why is it referring
to $this? When called statically $this will not exist.
To refer to the class when in a static method use self...
<?php
class StaticClass
{
public static $staticVariable = 1234;
public static function staticMethod()
{
return self::otherStaticMethod();
}
public static function otherStaticMethod()
{
return self::$staticVariable;
}
}
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Stuart Dallas wrote:
On 15 Apr 2012, at 11:44, Lester Caine wrote:
I've got a machine set up with PHP5.4 and left the strict errors showing, and
I'm falling at the first hurdle :)
The functions for generating URL's are used both statically and as part of the
class. STRICT complains because they are not marked 'static' ( and I'm assuming
'public static' is the correct addition here ) but then of cause the $this
fallback fails because '$this' is not allowed IN the static use of the function?
How do others get around this problem? I've some 120 static instances to fix in
parallel with about the same number of class uses across about 40 odd
functions. Do I really have to duplicate the code and rename every static use?
If the class can be used both statically and as an instance why is it referring
to $this? When called statically $this will not exist.
To refer to the class when in a static method use self...
<?php
class StaticClass
{
public static $staticVariable = 1234;
public static function staticMethod()
{
return self::otherStaticMethod();
}
public static function otherStaticMethod()
{
return self::$staticVariable;
}
}
This is all legacy code only some of which I wrote, and the function IS working
happily with 'STRICT' switched off. I'm just trying to work out how to remove
the messages that switching 'STRICT' on creates - which in this case is
complaining when the function IS called statically without being defined as
such. The function creates a url based on the information supplied, and if no
information is supplied it uses $this to access the data directly. The problem
now is getting both uses of the function working, but it looks like I HAVE to
duplicate the code ... or rather work out how to get the correct values selected
before calling the static version of the code.
With reference to the above, does self:: replace parent:: when trying to call
the base functionality which is where I think I am trying to head ...
getDisplayUrl() gives me a url in one of a number of formats depending what
style of url is selected, and the base package that created it, so the use both
statically and 'dynamically' made perfect sense 10 years ago :)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
On 15 Apr 2012, at 13:30, Lester Caine wrote:
> Stuart Dallas wrote:
>> On 15 Apr 2012, at 11:44, Lester Caine wrote:
>>
>>> I've got a machine set up with PHP5.4 and left the strict errors showing,
>>> and I'm falling at the first hurdle :)
>>>
>>> The functions for generating URL's are used both statically and as part of
>>> the class. STRICT complains because they are not marked 'static' ( and I'm
>>> assuming 'public static' is the correct addition here ) but then of cause
>>> the $this fallback fails because '$this' is not allowed IN the static use
>>> of the function?
>>>
>>> How do others get around this problem? I've some 120 static instances to
>>> fix in parallel with about the same number of class uses across about 40
>>> odd functions. Do I really have to duplicate the code and rename every
>>> static use?
>>
>> If the class can be used both statically and as an instance why is it
>> referring to $this? When called statically $this will not exist.
>>
>> To refer to the class when in a static method use self...
>>
>> <?php
>> class StaticClass
>> {
>> public static $staticVariable = 1234;
>>
>> public static function staticMethod()
>> {
>> return self::otherStaticMethod();
>> }
>>
>> public static function otherStaticMethod()
>> {
>> return self::$staticVariable;
>> }
>> }
>
> This is all legacy code only some of which I wrote, and the function IS
> working happily with 'STRICT' switched off. I'm just trying to work out how
> to remove the messages that switching 'STRICT' on creates - which in this
> case is complaining when the function IS called statically without being
> defined as such. The function creates a url based on the information
> supplied, and if no information is supplied it uses $this to access the data
> directly. The problem now is getting both uses of the function working, but
> it looks like I HAVE to duplicate the code ... or rather work out how to get
> the correct values selected before calling the static version of the code.
You don't need to duplicate code, you simply need to create different entry
points to the class based on whether it's accessed statically or as an
instantiated object. Something like this...
<?php
class UrlGenerator
{
public static function buildURL($a, $b, $c)
{
...
}
public function getURL()
{
return self::buildURL($this->a, $this->b, $this->c);
}
}
?>
No code duplication but clear separation between static and instantiated usage.
However, this is not the best way to structure this code IMO. The better option
would be to extract the static parts into a separate class, and use that new
class from the instantiated version.
> With reference to the above, does self:: replace parent:: when trying to call
> the base functionality which is where I think I am trying to head ...
> getDisplayUrl() gives me a url in one of a number of formats depending what
> style of url is selected, and the base package that created it, so the use
> both statically and 'dynamically' made perfect sense 10 years ago :)
Using a class both statically and as instantiated objects makes sense now,
never mind ten years ago, but it has never made sense for both uses to share
the same entry points. It was possible, but that doesn't mean it makes sense.
The self and parent keywords do exactly what they say on the tin. Self refers
to the current class and parent refers to the parent class, both in a static
context. Some of these things are pretty self-explanatory.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Stuart Dallas wrote:
No code duplication but clear separation between static and instantiated usage.
However, this is not the best way to structure this code IMO. The better option
would be to extract the static parts into a separate class, and use that new
class from the instantiated version.
I've sort of got a problem with that since duplicating every content package
class and then deciding which version I should be accessing does not make sense.
I'm slowly pulling the 'static' elements into their own function and leaving the
instantiated elements alone but it's slow work. Those people who kept telling me
'just fix the errors' simply don't understand how complex that CAN be :( I've
only worked my way through half a dozen packages and I've 20 or so to go ... all
just to bring things 'up to acceptable php code' ;)
> With reference to the above, does self:: replace parent:: when trying to
call the base functionality which is where I think I am trying to head ...
getDisplayUrl() gives me a url in one of a number of formats depending what style
of url is selected, and the base package that created it, so the use both
statically and 'dynamically' made perfect sense 10 years ago:)
Using a class both statically and as instantiated objects makes sense now,
never mind ten years ago, but it has never made sense for both uses to share
the same entry points. It was possible, but that doesn't mean it makes sense.
The self and parent keywords do exactly what they say on the tin. Self refers
to the current class and parent refers to the parent class, both in a static
context. Some of these things are pretty self-explanatory.
I think I've got that under control now. the 'parent::' was giving me errors for
other reasons.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
On 15 Apr 2012, at 15:02, Lester Caine wrote:
> Stuart Dallas wrote:
>> No code duplication but clear separation between static and instantiated
>> usage. However, this is not the best way to structure this code IMO. The
>> better option would be to extract the static parts into a separate class,
>> and use that new class from the instantiated version.
>
> I've sort of got a problem with that since duplicating every content package
> class and then deciding which version I should be accessing does not make
> sense.
I didn't suggest duplicating anything, just separating the elements so there's
a clear distinction between static and instantiated. This is basic software
engineering if you ask me. I was going to rant about defensive programming
here, but life's too short!
> I'm slowly pulling the 'static' elements into their own function and leaving
> the instantiated elements alone but it's slow work. Those people who kept
> telling me 'just fix the errors' simply don't understand how complex that CAN
> be :( I've only worked my way through half a dozen packages and I've 20 or so
> to go ... all just to bring things 'up to acceptable php code' ;)
It is as simple as that. Fix the errors. There may be a lot of them, and there
may be complex interplay between different parts of your code, but it's still
as simple as just fixing the errors.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Stuart Dallas wrote:
Stuart Dallas wrote:
>> No code duplication but clear separation between static and instantiated
usage. However, this is not the best way to structure this code IMO. The better
option would be to extract the static parts into a separate class, and use that new
class from the instantiated version.
>
> I've sort of got a problem with that since duplicating every content package
class and then deciding which version I should be accessing does not make sense.
I didn't suggest duplicating anything, just separating the elements so there's
a clear distinction between static and instantiated. This is basic software
engineering if you ask me. I was going to rant about defensive programming
here, but life's too short!
> I'm slowly pulling the 'static' elements into their own function and leaving
the instantiated elements alone but it's slow work. Those people who kept telling
me 'just fix the errors' simply don't understand how complex that CAN be:( I've
only worked my way through half a dozen packages and I've 20 or so to go ... all
just to bring things 'up to acceptable php code';)
It is as simple as that. Fix the errors. There may be a lot of them, and there
may be complex interplay between different parts of your code, but it's still
as simple as just fixing the errors.
Actually is NOT as simple as that ...
I have fixed the problems on the package set I use on a number of my sites, but
it simply brings me back to your first comment, since fixing the problems is not
the same as producing tidy code going to build on. The original code base comes
from PHP4 times, but has now been developed into a base 'content' class from
which all other 'content' classes are descended. The static functions create
generic url, uri and the like, while the 'instantiated' version simply uses the
objects own values to provide the variable elements. If I move the static
functions into separate classes why is that better than packaging the descended
code in the class itself?
What I'm trying to establish here is in what way the code base needs re-writing
in line with 'current good practice' while keeping the sites running as reliably
as they have over the last few years with the 'bad practice' being flagged by
'STRICT' :(
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
On 15 Apr 2012, at 19:41, Lester Caine wrote:
> Stuart Dallas wrote:
>>> Stuart Dallas wrote:
>>>> >> No code duplication but clear separation between static and
>>>> >> instantiated usage. However, this is not the best way to structure this
>>>> >> code IMO. The better option would be to extract the static parts into a
>>>> >> separate class, and use that new class from the instantiated version.
>>> >
>>> > I've sort of got a problem with that since duplicating every content
>>> > package class and then deciding which version I should be accessing does
>>> > not make sense.
>> I didn't suggest duplicating anything, just separating the elements so
>> there's a clear distinction between static and instantiated. This is basic
>> software engineering if you ask me. I was going to rant about defensive
>> programming here, but life's too short!
>>
>>> > I'm slowly pulling the 'static' elements into their own function and
>>> > leaving the instantiated elements alone but it's slow work. Those people
>>> > who kept telling me 'just fix the errors' simply don't understand how
>>> > complex that CAN be:( I've only worked my way through half a dozen
>>> > packages and I've 20 or so to go ... all just to bring things 'up to
>>> > acceptable php code';)
>>
>> It is as simple as that. Fix the errors. There may be a lot of them, and
>> there may be complex interplay between different parts of your code, but
>> it's still as simple as just fixing the errors.
>
> Actually is NOT as simple as that ...
>
> I have fixed the problems on the package set I use on a number of my sites,
> but it simply brings me back to your first comment, since fixing the problems
> is not the same as producing tidy code going to build on. The original code
> base comes from PHP4 times, but has now been developed into a base 'content'
> class from which all other 'content' classes are descended. The static
> functions create generic url, uri and the like, while the 'instantiated'
> version simply uses the objects own values to provide the variable elements.
> If I move the static functions into separate classes why is that better than
> packaging the descended code in the class itself?
"Better" is highly subjective. For me it's better because it follows the DRY
and KISS principles. If the URL building is going to be used both statically as
well as within the context of an object, that code does not belong within the
class which is the type of that object. If we were only talking objects then
yes, it would make sense to put that functionality into the base class, but NOT
as a static method.
To repeat, this is highly subjective, and I can only base my opinion on my
education and experience. There is no "right" way.
> What I'm trying to establish here is in what way the code base needs
> re-writing in line with 'current good practice' while keeping the sites
> running as reliably as they have over the last few years with the 'bad
> practice' being flagged by 'STRICT' :(
The code needs rewriting so that static functions are called statically, and
non-static functions are called on an object. Outside of that and a few other
simple rules PHP doesn't care how you organise your code.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Hi, All,
I can't see the post I sent several hours ago, if repeated, please reply
to this one. Thanks!
System: CentOS 5.5; PHP version is 5.1.6.
I met a strange problem associate with session_save_handler in current
environment(The same code can work well in my local windows platform and
ubuntu system).
I just want to use a customized session save handler to be triggered, so
that I can call my own logic to handling the session. The testing in
local is pretty great but when migration to the VPS, it bring me the
following error:
Fatal error: session_start() [<a
href='function.session-start'>function.session-start</a>]: Failed to
initialize storage module: user (path: /tmp)
The default value for session save handler and session save path in
php.ini are:
session.save_handler = files
session.save_path = "/tmp"
session.name = PHPSESSID
And the bottom are the code for the session handler. I first called
ob_start(), and after calling session::init(), I called session_start().
Then the fatal error happen. It did not trigger any function in the
"session" class.
I tried change the php.ini from session.save_handler = user, but the
error remains. And I found no matter what session.save_handler type is,
after calling session_set_save_handler(), the session.save_handler will
always automatically changed to 'user', that's why the Fatal error info
shows user (path: /tmp).
Can anybody help me out for such error? I was stuck by this issue for
more than 2 days, but still haven't get any clue!
You can view more details from stackoverflow if you want. Here is the link:
http://stackoverflow.com/questions/8845924/session-set-save-handler-class-for-database-not-working
--- End Message ---
--- Begin Message ---
Hi, All,
System: CentOS 5.5; PHP version is 5.1.6.
I met a strange problem associate with session_save_handler in current
environment(The same code can work well in my local windows platform and
ubuntu system).
I just want to use a customized session save handler to be triggered, so
that I can call my own logic to handling the session. The testing in
local is pretty great but when migration to the VPS, it bring me the
following error:
Fatal error: session_start() [<a
href='function.session-start'>function.session-start</a>]: Failed to
initialize storage module: user (path: /tmp)
The default value for session save handler and session save path in
php.ini are:
session.save_handler = files
session.save_path = "/tmp"
session.name = PHPSESSID
And the bottom are the code for the session handler. I first called
ob_start(), and after calling session::init(), I called session_start().
Then the fatal error happen. It did not trigger any function in the
"session" class.
I tried change the php.ini from session.save_handler = user, but the
error remains. And I found no matter what session.save_handler type is,
after calling session_set_save_handler(), the session.save_handler will
always automatically changed to 'user', that's why the Fatal error info
shows user (path: /tmp).
Can anybody help me out for such error? I was stuck by this issue for
more than 2 days, but still haven't get any clue!
You can view more details from stackoverflow if you want. Here is the link:
http://stackoverflow.com/questions/8845924/session-set-save-handler-class-for-database-not-working
<?php
class session
{
public static function init()
{
session_set_save_handler('session::open', 'session::close',
'session::read', 'session::write', 'session::destroy', 'session::gc');
}
public static function open($save_path, $session_name)
{
if (!is_dir($save_path)) {
mkdir($save_path, 0777);
}
return true;
}
public static function close()
{
return true;
}
public static function read($sid)
{
global $db, $user;
register_shutdown_function('session_write_close');
if (!isset($_COOKIE[session_name()])) {
$user = anonymousUser($sid);
return '';
}
$result = $db->query('SELECT s.data as session_data, s.* , u.* FROM
users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = "' .
$db->escape($sid) .
'" AND timestamp >= ' . $db->escape(TIMESTAMP -
Bl_Config::get('session.lifetime', 10800)));
$user = $result->row();
if ($user) {
$data = $user->session_data;
unset($user->passwd, $user->session_data);
if ($user->uid > 0 && $user->status == 1) {
$userInstance = User_Model::getInstance();
$user->roles = $userInstance->getUserRoles($user->uid);
$user->roles[] = User_Model::ROLE_AUTHENTICATED_USER;
$user->permissions = array();
$user->data = (isset($user->data) && $user->data) ?
unserialize($user->data) : array();
foreach ($user->roles as $rid) {
$user->permissions = array_merge($user->permissions,
$userInstance->getRolePermissions($rid));
}
$user->permissions = array_unique($user->permissions);
} else {
$user = anonymousUser($sid);
}
return $data;
} else {
$user = anonymousUser($sid);
return '';
}
}
public static function write($sid, $data)
{
global $db, $user;
if (!isset($user) || ($user->uid == 0 &&
empty($_COOKIE[session_name()]) && empty($data))) {
return true;
}
$uri = '/' . Bl_Core::getUri();
$db->exec('UPDATE sessions SET uid = ' . $db->escape($user->uid) .
', ip = "' . $db->escape(ipAddress()) .
'", uri = "' . $db->escape($uri) . '", data = "' .
$db->escape($data) . '", timestamp = ' .
$db->escape(TIMESTAMP) . ' WHERE sid = "' . $db->escape($sid) . '"');
if (!$db->affected()) {
$db->exec('INSERT IGNORE INTO sessions (sid, uid, ip, uri, data,
timestamp) VALUES ("' . $db->escape($sid) .
'", ' . $db->escape($user->uid) . ', "' .
$db->escape(ipAddress()) . '", "' . $db->escape($uri) . '", "' .
$db->escape($data) . '", ' . $db->escape(TIMESTAMP) . ')');
}
return true;
}
public static function destroy($sid)
{
global $db;
$db->exec('DELETE FROM sessions WHERE sid = "' . $db->escape($sid)
.. '"');
return true;
}
public static function gc($lifetime)
{
global $db;
$db->exec('DELETE FROM sessions WHERE timestamp < ' .
$db->escape(TIMESTAMP - Bl_Config::get('session.lifetime', 10800)));
return true;
}
public static function count($timestamp = 0, $hasAnonymous = true)
{
global $db;
if (!$hasAnonymous) {
$cond = ' AND uid > 0';
} else {
$cond = '';
}
$result = $db->query('SELECT COUNT(0) FROM sessions WHERE timestamp
> ' . $timestamp . $cond);
return $result->one();
}
}
--- End Message ---
--- Begin Message ---
Hi, All,
System: CentOS 5.5; PHP version is 5.1.6.
I met a strange problem associate with session_save_handler in current
environment(The same code can work well in my local windows platform and
ubuntu system).
I just want to use a customized session save handler to be triggered, so
that I can call my own logic to handling the session. The testing in
local is pretty great but when migration to the VPS, it bring me the
following error:
Fatal error: session_start() [<a
href='function.session-start'>function.session-start</a>]: Failed to
initialize storage module: user (path: /tmp)
The default value for session save handler and session save path in
php.ini are:
session.save_handler = files
session.save_path = "/tmp"
session.name = PHPSESSID
And the bottom are the code for the session handler. I first called
ob_start(), and after calling session::init(), I called session_start().
Then the fatal error happen. It did not trigger any function in the
"session" class.
I tried change the php.ini from session.save_handler = user, but the
error remains. And I found no matter what session.save_handler type is,
after calling session_set_save_handler(), the session.save_handler will
always automatically changed to 'user', that's why the Fatal error info
shows user (path: /tmp).
Can anybody help me out for such error? I was stuck by this issue for
more than 2 days, but still haven't get any clue!
You can view more details from stackoverflow if you want. Here is the link:
http://stackoverflow.com/questions/8845924/session-set-save-handler-class-for-database-not-working
<?php
class session
{
public static function init()
{
session_set_save_handler('session::open', 'session::close',
'session::read', 'session::write', 'session::destroy', 'session::gc');
}
public static function open($save_path, $session_name)
{
if (!is_dir($save_path)) {
mkdir($save_path, 0777);
}
return true;
}
public static function close()
{
return true;
}
public static function read($sid)
{
global $db, $user;
register_shutdown_function('session_write_close');
if (!isset($_COOKIE[session_name()])) {
$user = anonymousUser($sid);
return '';
}
$result = $db->query('SELECT s.data as session_data, s.* , u.* FROM
users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = "' .
$db->escape($sid) .
'" AND timestamp >= ' . $db->escape(TIMESTAMP -
Bl_Config::get('session.lifetime', 10800)));
$user = $result->row();
if ($user) {
$data = $user->session_data;
unset($user->passwd, $user->session_data);
if ($user->uid > 0 && $user->status == 1) {
$userInstance = User_Model::getInstance();
$user->roles = $userInstance->getUserRoles($user->uid);
$user->roles[] = User_Model::ROLE_AUTHENTICATED_USER;
$user->permissions = array();
$user->data = (isset($user->data) && $user->data) ?
unserialize($user->data) : array();
foreach ($user->roles as $rid) {
$user->permissions = array_merge($user->permissions,
$userInstance->getRolePermissions($rid));
}
$user->permissions = array_unique($user->permissions);
} else {
$user = anonymousUser($sid);
}
return $data;
} else {
$user = anonymousUser($sid);
return '';
}
}
public static function write($sid, $data)
{
global $db, $user;
if (!isset($user) || ($user->uid == 0 &&
empty($_COOKIE[session_name()]) && empty($data))) {
return true;
}
$uri = '/' . Bl_Core::getUri();
$db->exec('UPDATE sessions SET uid = ' . $db->escape($user->uid) .
', ip = "' . $db->escape(ipAddress()) .
'", uri = "' . $db->escape($uri) . '", data = "' .
$db->escape($data) . '", timestamp = ' .
$db->escape(TIMESTAMP) . ' WHERE sid = "' . $db->escape($sid) . '"');
if (!$db->affected()) {
$db->exec('INSERT IGNORE INTO sessions (sid, uid, ip, uri, data,
timestamp) VALUES ("' . $db->escape($sid) .
'", ' . $db->escape($user->uid) . ', "' .
$db->escape(ipAddress()) . '", "' . $db->escape($uri) . '", "' .
$db->escape($data) . '", ' . $db->escape(TIMESTAMP) . ')');
}
return true;
}
public static function destroy($sid)
{
global $db;
$db->exec('DELETE FROM sessions WHERE sid = "' . $db->escape($sid)
.. '"');
return true;
}
public static function gc($lifetime)
{
global $db;
$db->exec('DELETE FROM sessions WHERE timestamp < ' .
$db->escape(TIMESTAMP - Bl_Config::get('session.lifetime', 10800)));
return true;
}
public static function count($timestamp = 0, $hasAnonymous = true)
{
global $db;
if (!$hasAnonymous) {
$cond = ' AND uid > 0';
} else {
$cond = '';
}
$result = $db->query('SELECT COUNT(0) FROM sessions WHERE timestamp
> ' . $timestamp . $cond);
return $result->one();
}
}
--- End Message ---
