Search options (Page 2 of 3)

http://www.pepak.net/files/punbb/bbcode_size.zip

Supports the same sizes as <FONT SIZE="..."> attribute: 1..7, +1..+3, -1..-3. Rewriting it to other sizes should be trivial, you won't even need the callback (though you can use it).

Remind me by posting the request once more, please. I can't do it now but will be able to do it in a few hours, if I remember.

It is very pretty, but rather hard to read - the background should be darker, IMHO.

Add

define('FORUM_SHOW_QUERIES', 1);

to the end of your config.php. This will display performed queries and you can check what's wrong with them, e.g. in PhpMyAdmin.

Well, I guess - but really, if someone is unfamiliar with both PHP and SQL, how can he ever hope to make meaningful changes to the code?

What's the problem? Building a real query is hardly any more than concatecating all keys and values into one string.

I fail to see how that is relevant - database conversion code will almost certainly need to be hard-coded for every database separately. That is, if you want a reliable code.

Well, my main database is Firebird so I can't really tell you details about PostgreSQL and SQLite.

With MySQL, you don't care what encoding the data is stored in the database. All you need to do to get UTF8 output, regardless of encoding actually used by the database, is:

1) Make sure table structure matches table data. Which is NOT the case with many PunBB 1.2 installations, including mine - PunBB 1.2 did not create the tables correctly.

2) Make sure SET NAMES utf8 is called before any other SQL command.

Even if #1 is not satisfied, this approach will not lead to data loss on old data - old posts will simply display incorrectly, but as soon as table structure is fixed to match the data, everything will be fine.

Upgrade script uses a much more dangerous approach of reading all data, converting it to UTF8 and writing it back.

No wonder the users are losing their data!

What this function does is, it assumes that there is UTF8 data in the table and modifies the structure to match that. If the assumption is wrong - and it will often be wrong - it will simply take data in current encoding and tell MySQL that it is in fact UTF8. Which leads to data loss in itself, and if it just happens that the source data contain sequences not permitted under UTF8, the string will likely get truncated at that point. When I was upgrading to 1.3, for example, my data was in cp1250...

Only if you use them the same way you would use regular queries, which of course completely defeats their purpose and all their advantages.

I would appreciate if you kept to the arguments at hand. We were talking about validation. Now you add sanitization, which is a whole different matter: sanitization cleans data from possible malicious parts (and obviously needs to be done every time), validation only makes sure that it is formatted in a certain way (and experience shows that you will almost always find valid inputs which are formatted differently than you expected).

Is it? Really? There are great many avenues to improve security, but it could be argued that many of them increase it only marginally while increasing costs a lot. Or that some of these approaches would add more security and should be done first - e.g. those prepared queries, or different database account for administrators (EVERY database should have at least three users - owner, who can not login from the web server, admin, who can modify everything but can't e.g. drop tables or databases, and user, who can only read and write what's necessary for him to read). Input validation is nice to have, certainly, but its importance is relatively low if rigorous sanitization is done on output.

I should have said "Validating e-mail properly"

Is it? And if he enters a semantically valid but non-existent ID, or ID belonging to someone else, then what? Should the system complain, too? Why bother?

What if I don't use a domain for my webpage?

I am only guessing now:

- Assume that there are two groups of users, "privileged" (have access to the extra forums) and "regular"
- Only allow "privileged" access to your forum (just as it is now)
- Create a new forum with the same name. Prevent "privileged" from even reading it (so it doesn't appear in their list), allow "regular" to read the forum but not write
- Create one topic in this forum to explain that "All topics are hidden. If you want to see them, do this and that."

This should do the trick: Your regular users will see the "fake" forum with explanatory message, but they won't be able to do anything with it. Your privileged users will not see this fake forum but another forum (with the same name) where they can normally post.

Let me know if it works. It should.

Yes. But if you used the hooks, you could avoid any change in the source files - your modification would hqave a form of extension then.
extensions/HashedIP/manifest.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE extension SYSTEM "ext-1.0.dtd">
    <extension engine="1.0">
    <id>HashedIP</id>
    <title>HashedIP</title>
    <version>0.1</version>
    <description>Don't store IP addresses but their hashes.</description>
    <author>Head_Lice</author>
    <minversion>1.3dev</minversion>
    <maxtestedon>1.3</maxtestedon>
    <hooks>
        <hook id="fn_get_remote_address_start"><![CDATA[
return md5(sha1(gethostbyaddr($_SERVER['REMOTE_ADDR'])));
        ]]></hook>
    </hooks>
</extension>