Nope. Talk to your host. That's a MySQL issue.

77

(5 replies, posted in PunBB 1.3 extensions)

Yeah, we've discussed a priority system in the past and it just hasn't had a whole lot of support and has been forgotten. We'll see. smile

78

(6 replies, posted in PunBB 1.2 troubleshooting)

Yes

79

(6 replies, posted in PunBB 1.2 troubleshooting)

It sounds like you haven't uploaded all of the files.

80

(5 replies, posted in PunBB 1.3 extensions)

Currently it's determined by installation order.

The db_update.php script exists. However, again, 1.3 is a beta and should not be run in production.

82

(1 replies, posted in PunBB 1.2 troubleshooting)

This sounds like a very old problem that was fixed a while ago with conversions.
Try seeing if the group ID for user ID 1 (the guest user) is set incorrectly.

The problem is that PunBB 1.2 doesn't have full UTF-8 support. If you can, you should avoid using any UTF-8 related stuff at all.

Enable debug mode, paste the full errro

check_cookie is already run when you load include/common.php.
You'll need to fix the paths to styles, etc to use PUN_ROOT at the beginning.

86

(2 replies, posted in PunBB 1.2 discussion)

You want to change all of the forum permissions to category permissions? If so, you'll need to rewrite all of the queries that reference the forum_perms table (and admin_forums.php).

If you're including common.php, shouldn't check_bans be called, showing the message if the user is banned?

Yes, by editing viewforum.php to have the query only return topics with last post times in the last x days. You would also want to add an index to the topics table on that column.

If it works, yes. Otherwise, I would suggest just creating a "super group" for that user with all the correct permissions.
The only case that doesn't work for is moderator groups, in which case I would suggest using the mod or waiting for 1.3.

90

(17 replies, posted in PunBB 1.2 troubleshooting)

And again, that doesn't make sense. I don't know about the whole "nonstandard" thing, I know MySQL and SQLite do it. However, it doesn't address the issue of how to escape a character if there are no longer escape sequences. For example:
foo="this is a string"
lets say that string is created by user input. Without an escape character, how do I prevent this?
foo="this is a string" or 1=1 or foo=""

- I can't post. It says: "*  At least 0 seconds have to pass between posts. Please wait a little while and try posting again."

That's due to the timestamps in the database being "in the future" with respect to the current time. Likely due to an incorrectly set clock on one of the two servers.

- I had a few unread topics before the move, these are not marked "unread" now. They always stay on top of the other topics.

Probably the same deal, their last post times are in the future.

92

(12 replies, posted in PunBB 1.2 troubleshooting)

That's probably correct

93

(6 replies, posted in PunBB 1.3 extensions)

SuperMAG: Not the same thing at all. He's talking about upgrading extensions when a new version comes out, not about rapidly refreshing hooks for development purposes.

94

(2 replies, posted in PunBB 1.3 troubleshooting)

That is what happens for normal users in general, I believe.

95

(3 replies, posted in Programming)

Huh? There's no need to do that validation when you have check_date...

96

(2 replies, posted in PunBB 1.2 discussion)

Yes. Disable registration and use the User Management plugin to manually create accounts.

Yes, there's a define in include/essentials.php that disables hooks that is commented out by default.

As Vovochka said, if extension authors want to use variables for storage, they can create variables with their own names based on extension ID. There will be developer documentation at some point that explains more of these kinds of things. Essentially, there is no way to keep extension authors from stepping on each others toes deliberately. The method we use here for extensions is good in that it gives access to variables that you can't necessarily get otherwise (eg: a hook like what we have in a function lets you globalize a variable and use it: other systems would have to resort to using $_GLOBALS because of scope issues). On the other hand, it also means that your code is executed like regular code, which means it can overwrite variables unintentionally if you don't follow naming standards, etc. No different than a modification.
In the words of Spiderman: "With great power comes great responsibility." smile

99

(17 replies, posted in PunBB 1.2 troubleshooting)

This isn't making much sense to me. Either backslashes can be used as an escape character or they can't. If they can't, we need another escape character, since we need them to prevent SQL injects.
Unless someone can shed more light on this (and provide a solution other than "add E before every time you escape something properly", which isn't cross database compatible), I'm afraid there's nothing much we can do.

100

(2 replies, posted in PunBB 1.2 discussion)

I would research how Microsoft's Passport and other similar systems work. I believe you can do something similar/more secure using iframes (of course, some browsers may reject the cookies).