The second issue is fixed.

I think the issue is deeper than just increasing the "Visit timeout". It's related not only to the value of the timeout, but to the method of detection if the timeout has expired.

We'll probably delay considering this issue.

453

(6 replies, posted in PunBB 1.3 bug reports)

Fixed.

454

(13 replies, posted in PunBB 1.3 extensions)

There is a script in the pun_antispam directory that generates images. It should have the following URL:
http://www.torvoratings.nl/forum/extens … /image.php

And if you open this URL you'll see an error page. Maybe this file is missing. Try to upload and overwrite pun_antispam files into extensions directory.

455

(1 replies, posted in PunBB 1.3 bug reports)

This issue has already been reported and fixed.

The links jump after IE window resizing to a new place even if the fix you have proposed is applied. Maybe there is a better fix. We'll continue investigating.

Does it work fine?

Oh! Try this fix, please.

We are going to release 1.3.3 after fixing some other bugs.

460

(13 replies, posted in PunBB 1.3 extensions)

pun_antispam displays the text you have to type as an image. Did you mean that image contained question marks? Could you give us the link to your forum, please?

I think PM should be an alternative way of message delivering. We've designed pun_pm this way. The current logic of extension functioning (for example, 'sent' status of messages) does not imply e-mail notifications. But forum still allows sending an e-mail.

Of course, e-mail notifications could be added in future versions, but it requires delivery logic modifications.

Seems like a <fieldset> element of forms shouldn't be placed into an additional <div>.

Try to modify your .htaccess this way:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^forum /forum/rewrite.php [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Of course, DST is a time setting smile
I mean where the issue is: at server side or at client side.

The issue described in that topic is the server issue. Is it so?

As far as I understand the issue described in that topic is connected to the incorrect server time settings. That issue should be solved by a server administrator.

The issue described here is connected to the incorrect client time settings.

Do I miss something?

I didn't get what issue do you have.

db_update.php works fine for me when $db_prefix is set.

Could you describe the issue in detail, please?

Fixed.

Thanks for reporting. We'll increase the "Visit Timeout" value.

We've seen the topic. We are going to test the fix and to include in PunBB 1.3.3 if everything is Ok.

Thanks for reporting.

Yes, the issue is more complicated. It's connected not only to CSS, but to HTML. I've already suggested another fix:
http://punbb.informer.com/trac/changeset/1092

Hope it works fine.

As far as I know there is no converting script for PM.

pun_pm creates its own table for messages. You just have to import the data from the old table to the new one. What kind of problems do you have?

472

(3 replies, posted in PunBB 1.3 extensions)

The PM link is displayed next to the E-mail link under user info on posts. Do you want to move it upper?

pepak wrote:

And if old charset is NOT ISO-8859-1 and neither iconv and mb_convert_encoding exist, leaves the string unchanged but tells MySQL that it is UTF8.

No, a message is displayed in this case:
http://punbb.informer.com/trac/browser/ … e.php#L426

Are you sure that these ALTER queries will work on PostgreSQL and SQLite?

It was not me who designed db_update.php so I can't explain its logic in details. To tell you the truth, I'm still confused a little with all these encodings and collations in databases. But I want to fix bugs if they exists and will continue investigating.

Actually, the update script asks the encoding of the language pack before updating. Then it converts posts to UTF8 by calling this function for every post:
http://punbb.informer.com/trac/browser/ … e.php#L231
And then it tells MySQL that the data encoding is UTF8.

pepak wrote:

You can perform the fixing using a sequence of ALTER TABLE's:
1) Convert all character fields to either BLOB or BINARY without changing charset:
2) Convert all character fields back to the correct type with correct charset:
3) When all fields are converted, change the declaration of the table itself:

As far as I understand the update script works just like you have described:
http://punbb.informer.com/trac/browser/ … e.php#L338

Before 1.3 release we had tested the update process and had added SET NAMES:
http://punbb.informer.com/trac/changese … update.php

Maybe this SET NAMES call is wrong, we'll continue testing.