51 Reply by pepak

(39 replies, posted in PunBB 1.3 bug reports)

Parpalak wrote:

Posts and topics processing is required because 1.3 uses UTF-8. Also its parser works in a different way.

Yes, of course. What I am trying to say is that there is no reason to convert the database during upgrade. MySQL will accept and return data in UTF8 regardless of what encoding is used on the tables, as long as SET NAMES utf8 is used.

As for repeatability, my post should do it just fine.
http://punbb.informer.com/forums/post/125628/#p125628

Go to forum: PunBB 1.3 bug reports

52 Reply by pepak

(39 replies, posted in PunBB 1.3 bug reports)

(Another issue is that there was no point in converting the tables to UTF8. The MySQL server would happily convert them to UTF8 "on the fly". That would not solve the problem of incorrect characters appearing, but it would solve these issues of data loss. Too late to do something about that now if you did do a 1.3 upgrade; the developers could, and IMHO should, release a new version without UTF conversion for those who didn't upgrade yet.)

Go to forum: PunBB 1.3 bug reports

53 Reply by pepak

(39 replies, posted in PunBB 1.3 bug reports)

Once again, developers can't do much if the data in the tables doesn't match table structures - there is very little (if anything) they can do to detect this problem, even less to fix it. This needs to be done manually, e.g. with the help of my script above.

Go to forum: PunBB 1.3 bug reports

54 Reply by pepak

(32 replies, posted in PunBB 1.3 discussion)

1) Wouldn't it be better to simply implement a hook for fn_get_remote_address_start that returns sha1($_SERVER['REMOTE_ADDR'])?

2) As it is now, it is pretty pointless to actually hash the addresses - it does not prevent people from detecting the IP address (IP address space is so small it is quite feasible to simply hash all possible values until you get the right hash). You would need to use either IPv6 or domain names for this modification to have a significant effect.

Go to forum: PunBB 1.3 discussion

55 Reply by pepak

(39 replies, posted in PunBB 1.3 bug reports)

Slavok wrote:

I can't reproduce this data loss. I created a db with latin1_spanish_ci collation, wrote a post with message "123á456", and after the migration I do see it. What did I miss?

1) Create a table:

CREATE TABLE chartest (
  id INTEGER NOT NULL PRIMARY KEY,
  text VARCHAR(50) CHARACTER SET latin1 COLLATION latin1_swedish_ci
);

2) Create a form which accepts data in different encoding than latin1:

<?php
if ($_GET['text'])
  if ($conn = mysql_connect(...))
    if (mysql_select_db(...))
      mysql_query("INSERT INTO chartest VALUES ('".addslashes($_GET['text'])."')";
?>
<html>
<head>
<meta name="Content-type" content="text/html; charset=Windows-1250">
</head>
<body>
<form method="get">
<input type="text" name="text" value="<?php echo htmlspecialchars($_GET['text']); ?>">
<input type="submit">
</form>
</body>
</html>

3) Now submit some texts containing characters that are not present in latin1.

Příliš žluťoučký kůň úpěl ďábelské ódy

4) As long as you keep MySQL's charset to latin1 and page's charset to Windows-1250, the texts read from the table will appear correctly. But you must not perform any conversions - those will lead to data loss. E.g. this is a no-no:

ALTER TABLE chartest
  ALTER text VARCHAR(50) CHARACTER SET utf8;

This, too:

SET NAMES utf8; -- page is now in UTF-8
SELECT * FROM chartest;

Go to forum: PunBB 1.3 bug reports

56 Reply by pepak

(3 replies, posted in PunBB 1.3 troubleshooting)

Convert the database to correct encoding first. Then the upgrade will work fine. http://punbb.informer.com/forums/post/124979/#p124979

Go to forum: PunBB 1.3 troubleshooting

57 Reply by pepak

(1 replies, posted in PunBB 1.3 troubleshooting)

DELETE FROM punbb_users
WHERE num_posts=0 
AND last_visit<$time

Where

$time = time()-60*60*24*365;

Maybe better back up your users table first, too :-)

Go to forum: PunBB 1.3 troubleshooting

58 Reply by pepak

(3 replies, posted in PunBB 1.3 additions)

Yes, it is possible. I adapted PunBB for use with our (rather prehistoric and heavily modified) version of PHP Nuke. You can use my extension as an example on doing it (basically, you need to rewrite all accesses to punbb_users table and all user-login functions).

http://punbb.informer.com/forums/topic/ … neric-cms/

Go to forum: PunBB 1.3 additions

59 Reply by pepak

(5 replies, posted in PunBB 1.3 troubleshooting)

Define FORUM_SHOW_QUERIES in your config.php and try the built SQL command directly. My guess is that $forum_user['access_time'] is in wrong format.

Also, check whether $bb_new_values is set. Because if it isn't, $bb_query will not be defined and query_build will fail.

Go to forum: PunBB 1.3 troubleshooting

60 Reply by pepak

(39 replies, posted in PunBB 1.3 bug reports)

oliversl wrote:

have you done this all manually? There are many many columns in each table.

Semi-manually. I wrote a script that can generate the sequence of SQL commands, as long as you take care to set up its content correctly.

Should't the "upgrade" script have error checking in such a case?

The main problem is finding which character set is actually used for the data. I can't really imagine how a script would do that - it really has precious little information to work with.

You can have my script, but YOU MUST HAVE A BACKUP OF YOUR DATA BEFORE YOU USE IT and it is your responsibility to find the correct character sets. If you fuck up your data because you didn't back up your table and didn't find out the correct character set, don't ask me to help you - in all probability your data will have been lost already.

http://www.studna.net/temp/convertmysql.zip

Go to forum: PunBB 1.3 bug reports

61 Reply by pepak

(39 replies, posted in PunBB 1.3 bug reports)

Actually, the problem is almost certainly caused by non-matching charset in your table definition and your tables - your tables use latin1_spanish_ci but your actual data is something else (e.g. cp1250). I had a problem with that myself, had to fix that first. After I made sure the definition and the data match, the upgrade went just fine.

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:

ALTER TABLE table MODIFY fieldname BLOB

2) Convert all character fields back to the correct type with correct charset:

ALTER TABLE table MODIFY fieldname VARCHAR(100) CHARACTER SET real_charset COLLATE real_collation NOT NULL

3) When all fields are converted, change the declaration of the table itself:

ALTER TABLE table CHARACTER SET real_charset COLLATE real_collation NOT NULL

Also, you may prefer to try it out on a copy of your data - just copy all tables to a new name using this sequence:

CREATE TABLE xyz_posts LIKE punbb_posts;
INSERT INTO xyz_posts SELECT * FROM punbb_posts;

Then just rewrite $db_prefix in your config.php from punbb_ to xyz_

Go to forum: PunBB 1.3 bug reports

62 Reply by pepak

(3 replies, posted in Discussions)

Actually, PunBB 1.3 does a surprisingly good work here. When integrating it to my site, I managed to do it all through hooks, with two exceptions. Upgrades should be a breeze - I can simply do a file compare on old and new files and modify my hooks accordingly.

Go to forum: Discussions

63 Topic by pepak

(1 replies, posted in PunBB 1.3 troubleshooting)

I can't help but wonder, why were the group IDs changed between versions 1.2 and 1.3: In 1.2, Members were 2, Moderators 3. In 1.3, Moderators are 4, Members are 3. Why on Earth didn't you keep the IDs unchanged???

Go to forum: PunBB 1.3 troubleshooting

64 Reply by pepak

(21 replies, posted in PunBB 1.3 extensions)

Pun Admin Manage Extensions Improved v1.3 has a few incorrect language references. The updated manifest is here: http://www.pepak.net/tmp/manifest.zip

Go to forum: PunBB 1.3 extensions

65 Reply by pepak

(6 replies, posted in PunBB 1.3 discussion)

Don't expect an easy and effortless plugin - you will have to do a lot of work. The point is that you no longer need to search the whole source code to find the places that need to be changed.

Download it here: http://www.pepak.net/tmp/studna_punbb.zip

I provided a short readme file with details on what needs to be done. I would definitely suggest trying it out on your local copy of your site first, and do consider it an alpha code - I am sure I missed a parenthesis or a semicolon here and there... The important parts of the forum seem to work, though.

If you find any errors or improvements, I would appreciate hearing about them.

(The extension is called "Studna" because it is intended for our horror-movie site Studna.)

Go to forum: PunBB 1.3 discussion

66 Reply by pepak

(6 replies, posted in PunBB 1.3 discussion)

OK, my merging of PunBB 1.3 with a generic CMS is almost complete. It turns out the two changes above are the only ones that need to be done - other than that, everything can be handled with hooks.

I'll need to do some more testing (at the moment it seems everything is working fine, but of course the users will surely find some missing brackets or semicolons). After that, I will see about releasing the extension; of course it will be useless on its own, but it should be reasonably simple to adapt it to your particular CMS.

Go to forum: PunBB 1.3 discussion

67 Reply by pepak

(2 replies, posted in PunBB 1.3 discussion)

Will do, thanks.

Go to forum: PunBB 1.3 discussion

68 Topic by pepak

(2 replies, posted in PunBB 1.3 discussion)

I am not sure if I overlooked something: Is it possible to refresh an extension (rebuild its hooks in the database and delete its cache file) without deleting and readding it?

Go to forum: PunBB 1.3 discussion

69 Topic by pepak

(6 replies, posted in PunBB 1.3 discussion)

I am currently writing an extension that will let me integrate PunBB to a content management system I use - basically, I want to use _my_ table of users, not PunBB's. Most of the stuff is easily done using hooks, but there are several changes that need to be done to the PunBB itself:

1) Database abstraction layer classes need to have a more detailed query_build parameters. Specifically, it is important to be able to use different prefixes for different tables, even within the same SELECT. As of now, there is only choice between all prefixes or no prefixes. I propose a change from:

if (isset($query['SELECT']))
{
    $sql = 'SELECT '.$query['SELECT'].' FROM '.((isset($query['PARAMS']['NO_PREFIX'])||(isset($query['PARAMS']['FROM_NO_PREFIX'])) ? '' : $this->prefix).$query['FROM'];

    if (isset($query['JOINS']))
    {
        foreach ($query['JOINS'] as $cur_join)
            $sql .= ' '.key($cur_join).' '.((isset($query['PARAMS']['NO_PREFIX'])||isset($cur_join['PARAMS']['NO_PREFIX'])) ? '' : $this->prefix).current($cur_join).' ON '.$cur_join['ON'];
    }

to

if (isset($query['SELECT']))
{
    $sql = 'SELECT '.$query['SELECT'].' FROM '.(isset($query['PARAMS']['NO_PREFIX']) ? '' : $this->prefix).$query['FROM'];

    if (isset($query['JOINS']))
    {
        foreach ($query['JOINS'] as $cur_join)
            $sql .= ' '.key($cur_join).' '.(isset($query['PARAMS']['NO_PREFIX']) ? '' : $this->prefix).current($cur_join).' ON '.$cur_join['ON'];
    }

2) User authentication functions in include/functions.php need a lot more hooks than they have now. The following parts should be optional, based on a hook response:
- Cookie expiration
- Cookie hash validation
E.g. something like:

$check_expiration = TRUE;
$validate_expiration_hash = TRUE;
($hook = get_hook('fn_cookie_login_validations')) ? eval($hook) : null;
if ($check_expiration) ...

I will post more if (when) I find them.

Go to forum: PunBB 1.3 discussion

70 Topic by pepak

(0 replies, posted in PunBB 1.3 discussion)

I would appreciate if the standard startup code for any PunBB got tightened up. The code:

if (!defined('FORUM_ROOT'))
    define('FORUM_ROOT', './');

would be much more reliable if rewritten to:

if (!defined('FORUM_ROOT'))
    define('FORUM_ROOT', dirname(__FILE__).'./');

That way a developer could call the forum from any directory, not just from its own directory (it's important for integration into various content management engines).

Go to forum: PunBB 1.3 discussion