So cache the width/height then? You'll just have to recache it when you upload a new avatar, and that's it.

Yes. That's caching the entire HTML tag. And as I said, that comes with some downsides (increases complexity of the uploading process, leads to duplication of data, leads to PunBB using possibly incorrect data). The only real impetus to use that method would be if the benefits in terms of reduced I/O really speed up pageviews, which I don't think it will. smile

Btw, viewtopic needs keys on $pun_page['user_ident'] and $pun_page['user_info'], or you'll just have to assume the key for the avatar, and all the other info. Especially if you're using some other extension which adds links/info/whatever.

It's something we need to investigate to see if we can improve on. Obviously non-numeric keys would make finding elements of the array simpler (instead of needing to traverse the array). On the other hand, we need to see how easy it would then be to insert elements in the middle. Thanks for pointing it out though, I'll look into it now.

intedinmamma: The idea is to completely avoid file I/O. So you can't just store the path, since we also check the image to get the proper width/height. wink

As for file_exists vs db fields go, there is some upsides to db fields. One is external avatars, and avatars from different systems. File_exists requires workarounds or editing the code, while a db field can be changed by an extensions quite easily.

Except that an external avatar system, if properly implemented, is always going to suffer from performance issues. That's because avatars need to be validated for width/height/size restrictions on every pageview, which is much worse when the images aren't actually on the server.
And the hook system should really make developing such an extension easier anyway (although you would need an extra database column).

I'm glad you're liking it so much smile

You can't run 1.2 using 1.3's schema. There are tables missing (specifically, search), configuration values changed, configuration settings removed/renamed, etc.

No, the "final decision" (I put it in quotes because it's not the final decision, it's my opinion) is that an avatar cache like the signature cache is a good idea to cut down on unnecessary I/O, while caching the HTML in the users table is something we should do only if the reduced number of calls still slows down viewtopic.php a great deal.

If it turns out that the file operations are actually significantly slowing down viewtopic.php, then it might be worth looking at. However, I have a feeling that they're not. Thus, reducing unnecessary repetition of them has all the upsides of actually caching the HTML in the users table without any of the downsides. smile

Currently, uploading an avatar in 1.3 just involves moving files around. We removed use_avatar from the schema, since it really served no purpose. Storing avatar information (be it the entire img tag, just the filename, etc) doesn't help much, since we're just duplicating information that already exists (and our information may be out of date, since an administrator could delete an avatar manually via shell or FTP).

Bah, I knew I remembered something like that. tongue
Most of the admin files are doing it the other way though.

I thought about that, and I remember that there was a discussion before about whether we should be concatenating language files entries: I can't remember what the result of that discussion was.
I'll just split it up.

sleep?

I haven't ever looked at the code, I was going based on my understanding from the topic, which was that you were sending out emails to every member of the site. If that's not what's going on here, feel free to ignore me. smile

What exactly do you mean?

I mean what I said tongue
If you're sending out large numbers of emails to various domains outside of your control, putting a couple seconds between each email helps to keep you from being deemed spammy (I mean, who else would send hundreds of emails over the course of 10 seconds?): plus, it's just nicer to the SMTP servers.

And those are the three lines wink
It's not a cache in the same sense as the cache PHP files, it just saves the already parsed signature for use later, so we don't have the overhead of parsing the same signature more than once.
In the same way, an avatar cache would save the already found correct img tag so that we don't have to check for file size, etc more than once.

Probably: reducing unnecessary I/O is always a good thing.

rewrite.php: we can't, because we have no language files loaded at that point. That was a conscious decision made because we don't have any information about the logged in user at the point of redirecting.

190

(21 replies, posted in PunBB 1.2 troubleshooting)

OK, we're not getting this into an offtopic discussion too.
Topic done? Closed

191

(3 replies, posted in PunBB 1.2 troubleshooting)

"upgraded version"? This sounds like some silly thing made up by your host. We would have to know what the differences between the "versions" are to figure out why it's not working like that (if it's generating a page like that your host is doing something, not PunBB).

192

(11 replies, posted in PunBB 1.3 troubleshooting)

Mmm, how does Wordpress manage to do it? They have a somewhat similar design and I just tested resizing, which very nicely broke the submenu items into two lines.

Use it a lot tongue
It's better than doing BCC, to be honest. Just try to offer some rate-limiting options (eg: x second(s) between emails (allow decimals), x emails max, what user ID to start from, etc).

194

(7 replies, posted in PunBB 1.3 troubleshooting)

Yup, thanks

195

(11 replies, posted in PunBB 1.3 troubleshooting)

lol, when I read your post that was all I thought you were talking about. tongue
I'll change it if Rickard says it's OK.

196

(4 replies, posted in PunBB 1.3 troubleshooting)

That would be the purpose of the shop mod, also for 1.2 wink
Developing them separately makes sense, since not every forum that needs the cash mod needs a shop mod (eg: if cash is manually redeemed for some prize outside the scope of PunBB). For 1.3, I expect both modifications will become even better extensions.

197

(7 replies, posted in PunBB 1.3 troubleshooting)

Not array_walk, sys_getloadavg. That's the argument referred to in the warning wink

198

(4 replies, posted in PunBB 1.3 troubleshooting)

Yes, the cash mod for 1.2.

199

(11 replies, posted in PunBB 1.3 troubleshooting)

Mmm, feel free to revert if you want

200

(2 replies, posted in General discussion)

You could alter the code to change the style based on the hostname I suppose, if that's what you're talking about,