Serendipity Forums

It looks like a bug in the smarty code, i dont use smarty its very bloaty, flexy is quite solid and flexible, what do you think of this ?

in core.get_include_path
function smarty_core_get_include_path(&$params, &$smarty)
{
static $_path_array = null;

if(!isset($_path_array)) {
$_ini_include_path = ini_get('include_path');

if(strstr($_ini_include_path,';')) {
// windows pathnames
$_path_array = explode(';',$_ini_include_path);
} else {
$_path_array = explode(':',$_ini_include_path);
}
}
foreach ($_path_array as $_include_path) {

echo $_include_path . DIRECTORY_SEPARATOR . $params['file_path'];
if (@is_readable($_include_path . DIRECTORY_SEPARATOR . $params['file_path'])) {
$params['new_file_path'] = $_include_path . DIRECTORY_SEPARATOR . $params['file_path'];
return true;
}
}
return false;
}

Its not including the SMARTY_DIR constant, i would file this as a bug? I can of course make another setting tot he default include path to include the smarty libs folder ?

I dont know where it is, but somehow the bundled libs is hard coding the setting, yes adding the smarty lib path to the default includes works

include_path => .:/www/classes/PEAR:./classes:./includes:/www/classes/PEAR/Smarty/libs

It looks like updertEntry gets called twice, i appended all the sql into a log. There is about 32k worth of sql text, i must say just to update an entry its alot of sql, and alot of it seems to be not needed for an xmlrpc entry ?

So on the first update its updating the proper timestamp, and then on the second update its the current timestamp.

please post the 32k sql code somwhere like on http://nopaste.php-q.net/.

The whole content of your entries are also inside the SQL, so the length of SQL depends on the length of your entry.

Hi, its actually updating 3 times , logged this from the serendipity_db_update method.

http://nopaste.php-q.net/201546

Today I patched a few things. Sadly my ecto just ran out of trial period and I can test it no more.

But maybe it works now. If not, someone needs to sponsore me with a ecto license, else I cannot make anymore debugging. Or tell me how to get another trial period.

Best regards,
Garvin

Dude its like 17 buks ? I did ask if they have developer licences, you can imagine what they said :\

Where is this patch ?

IF you need me to buy u one lt me know its pretty good, i was actually reluctant to purchase it though as I generally choose open source first, but even commercial products like Navicat have bugs which annoy me, but ecto is truely bug free !

You want ME to pay 17 bucks just that what YOU want to use will work? ) Of course I support commercial software when I use it, but since I don'T use ecto, I'm not willing to pay for it. I very much like the s9y entry interface. *g*

Patch was commited to CVS yesterday. I also got feedback from the nice ecto guys on how to enlarge the trial period. So if my patch from yesterday won't work, I can work from there.

I'm loaded with work today and tomorrow, so I'll try to see if it helped you on the weekend.

Best regards,
Garvin

Dude im not a cvs hacker, you'll have to give me info on how to get it + what the cause of the problem was as ive been forced to debug the internals so i know whats goin on now anyway.

Besides the point, I dont think its a ecto bug, but a bug with the xmlrpc interface right ?

Hi!

Oh, I'm really sorry. I figured from the extensive debugging you did that you were familar with CVS. The latest version is committed here:

http://cvs.sourceforge.net/viewcvs.py/p ... nt_xmlrpc/

You can fetch the two files modified 20 hours ago from that link and overwrite your current files. Make sure that if you manualy modified those files earlier because of your PEAR issues to apply those changes again.

You can view the diff on that files pretty easy to spot the modifications I made. (http://cvs.sourceforge.net/viewcvs.py/p ... 1.8&r2=1.9)

Those were:

1. Unset the $entry['properties'] item, as this was causing SQL problems because a field 'properties' didn't exist. Those will prevent mysql_real_escape_string error reports on the setBlogPosts method

2. Fix getcategories dispatch method

3. Insert the createDate iso8601 date conversion for timestamps

I never said it were an ecto bug! It were a s9y plugin bug, of course.

Regards,
Garvin

I meant a cvs checkout login really sorry, getting files via the web interface is clunky i can then run the cvs diff against the files too.

ok it now looks like ecto has a dates problem, even though they said there wasnt. This is on a new post

iElectro:~ root# date
Fri Mar 31 00:26:24 EST 2006

<member>
<name>dateCreated</name>
<value><dateTime.iso8601>20060330T14:25:29Z</dateTime.iso8601></value>
</member>

response

<member><name>dateCreated</name>
<value><dateTime.iso8601>20060330T14:25:29</dateTime.iso8601></value>
</member>

now i run the update

<member>
<name>dateCreated</name>
<value><dateTime.iso8601>20060330T04:25:29Z</dateTime.iso8601></value>
</member>

response

<member><name>dateCreated</name>
<value><dateTime.iso8601>20060330T04:25:29</dateTime.iso8601></value>
</member>

Anonymous CVS to the repository is described here: https://sourceforge.net/cvs/?group_id=75065

At least you can download and diff that way, until Garvin can get you a login.

thanks judebert looks like dilbert LOL

electroteque, I am the ecto/Win developer. What is the timestamp issue you are experiencing with ecto? Are you having issue with ecto always sending post with latest timestamp? If so, you may want to try the 2.0 beta version (http://bb.infinite-sushi.com/viewtopic.php?t=1565) as it has option to control which date/time ecto will send to server (http://bb.infinite-sushi.com/viewtopic.php?p=5797#5797).