It's because it always uses the same filenames for avatars (same filenames after changes, so the browser just uses the image with the same name from its cache). My possible solution would be to hack the code to always make a random filename, delete the old one and reassign the new avatar URL to the new filename.

I attempted to create a sort of fix... it basically adds a "timestamp" in the form of C-style time in between the user ID and extension, and well... see for yourselves. It's certainly not the nicest solution, and I'm rather novice to PHP, but it works for me. Apparently. Except that the old image deleting thing isn't working so well, and if you re-upload something it seems to somehow use the old upload.

profile.php diff:

1195a1196,1199
>                             // Set up so-called ctime thing
>                             // 11 digits (a few zeros followed by Unix time?)
>                             $ctime = sprintf('.%\'011u',time());
> 
1197c1201
<                             @rename($avatar_tmp_file, $forum_config['o_avatars_dir'].'/'.$id.$extension);
---
>                             @rename($avatar_tmp_file, $forum_config['o_avatars_dir'].'/'.$id.$ctime.$extension);

include/functions.php diff:

40c40
<     if ($return != null)
---
>     if ($return != null) 
543c543
<     $avatar_markup = $avatar_filename = '';
---
>     $avatar_markup = $avatar_filename = $avatar_ext = '';
549,550c549
< 
<     // Create avatar filename
---
>     // Create avatar extension
554c553
<             $avatar_filename = $user_id.'.gif';
---
>             $avatar_ext = '.gif';
558c557
<             $avatar_filename = $user_id.'.jpg';
---
>             $avatar_ext = '.jpg';
562c561
<             $avatar_filename = $user_id.'.png';
---
>             $avatar_ext = '.png';
571c570
<     if ($avatar_filename && $avatar_width > 0 && $avatar_height > 0)
---
>     if ($avatar_ext && $avatar_width > 0 && $avatar_height > 0)
573c572,578
<         $path = $forum_config['o_avatars_dir'].'/'.$avatar_filename;
---
>         $glob_stuff = FORUM_ROOT.$forum_config['o_avatars_dir'].'/'.$user_id.'.'.'[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'.$avatar_ext;
>         $avatars = glob($glob_stuff);
>         if ($avatars == null)
>             return;
> 
>         //$path = $forum_config['o_avatars_dir'].'/'.$avatar_filename;
>         $path = $avatars[0];
2044c2049
<     $filetypes = array('jpg', 'gif', 'png');
---
>     $filetypes = array('.jpg', '.gif', '.png');
2053,2054c2058,2067
<         $avatar = FORUM_ROOT.$forum_config['o_avatars_dir'].'/'.$user_id.'.'.$cur_type;
<         if (file_exists($avatar))
---
>         $glob_stuff = FORUM_ROOT.$forum_config['o_avatars_dir'].'/'.$user_id.'.'.'[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'.$cur_type;
>         $avatars = glob($glob_stuff);
> 
>         if ($avatars == null && $cur_type != '.png')
>             next;
>         elseif ($avatars == null && $cur_type == '.png')
>             return;
> 
> 
>         foreach ($avatars as $avatar)
2056c2069,2072
<             @unlink($avatar);
---
>             if (file_exists($avatar))
>             {
>                 @unlink($avatar);
>             }

2

(1 replies, posted in PunBB 1.4 bug reports)

I just forgot to update the sequences for all the tables that needed them; that's why stuff didn't work.

I still get the "strict standard" errors; however, everything else is fixed.

These are the queries I had to do to solve the EXTENSION problems: (with voting and PMs):

SELECT pg_catalog.setval('voting_id_seq', (SELECT MAX(id) FROM voting), true);
SELECT pg_catalog.setval('answers_id_seq', (SELECT MAX(id) FROM answers), true);
SELECT pg_catalog.setval('pun_pm_messages_id_seq', (SELECT MAX(id) FROM pun_pm_messages), true);

I suppose it wouldn't hurt to repeat this for every table that has an id_seq "counterpart" (on the psql client the "command" \d lists tables), but I just did it for every table that caused problems, besides doing it originally for the ones shown in a tutorial.

I guess this thread could be moved to troubleshooting, except I still get the resource ID errors, which also seem to be unrelated to the post count at the bottom front page, which still updates (although not immediately).

3

(1 replies, posted in PunBB 1.4 bug reports)

I tried making a new installation using PostgreSQL 9.2RC1... first by creating an UTF-8 formatted database.

I get many variations of this error on the PHP logs:

[03-Sep-2012 05:51:03 UTC] PHP Strict Standards:  Resource ID#41 used as offset, casting to integer (41) in ...../punbb/include/dblayer/pgsql.php on line 123 

...and the post and topic counter at the bottom of the forum front page doesn't change even when I post or make new threads.

The above was part of a test. For my forum, I converted the database from MySQL and also got all of the above problems, as well as these:

After importing the pun_pm_messages table from my old MySQL database to Postgres, this error appeared whenever someone tries to send a PM:

Sorry! The page could not be loaded.

This is probably a temporary error. Just refresh the page and retry. If problem continues, please check back in 5-10 minutes.

...but it seemed to disappear after I deleted everything from the table, and worked fine again... but I couldn't see anything really wrong with the imported table.

I also got this "temporary" error once while trying to create a topic with a poll.

There are no apparently relevant PHP errors for these last two problems, or I've missed them. I'll try increasing database logging verbosity and see if I find anything else of use there.