(21 replies, posted in General discussion)

Je viens de faire la migration totale... smile

(manque juste "membre en ligne aujourd'hui")

IIMarckus wrote:

If that's the case, it's not a big deal. The only solution I can think of is making the qjump redirect to a specific redir page that then redirects to the forum based on the URL options -- but that may or may not be a good idea. What do you think?

I think this is indeed a good solution (and probably the only one).

Smartys wrote:

I guess that's possible, but I don't think that would be a part of the core. Someone could write an extension for it though.

Hmm.. Too bad to leave only ONE part of the "core" (as i can see) not rewritten.
More, even if i'm not fluent with the extension system yet, it seems to me that such a thing would be rather difficult to be made as an extension : it needs to modify the qjump form, create a new "switching" page, adding this page in the url rewritting tab (for consistency)..


(13 replies, posted in General discussion)

Well, forgive me to appear "devil's avocate" on this, but still..
How would hoster can react on this ?
- ok, maybe not suspended account AT ONCE, without talking to owner.
- but then : as nick thrusting said, HE DOESN'T KNOW how the problem occured, and sincerely said he doesn't see ways to resolve himself the problem.. (which is consistent, as he doesn't know how it occured..)
So, as a hoster, how can i manage this case ?
Maybe, give him a second chance...

Now, MAYBE hoster is a bad one, i don't know...

SuperMAG wrote:

well the 1.3 is still in construction and it will be impossible to convert my old forum to 1.3 and there are no extensions of 1.3 right now ... at lease some one make a subforum extension ....

but cammon how much time it will take ... 10 15 min for a person who knows php ....

1.3 is true beta, but url scheme (AND functions associated) were (almost) finished at least nine months ago (and maybe more)...
Have migrated my own 1.2.x forum with full url_rewriting at these times.

But SORRY : NO, IT DOESN'T TAKE 10-15 MINS (!!!)
The fact of knowing php or not doesn't matter, it's pretty easy (no trick involved), but IT DOES takes time..
What u have to do : change ALL (i mean ALL) links in ALL (i mean ALL php files) files in order to use a function which will rewrite the link (take a look at 1.3 files if u don't see precisely..).
So, it's EASY... but IT TAKES TIME (as ALL files are concerned).
(refer to corresponding 'SimplePunRewrite' subject, it has NOTHING to be in common, SimpleRewrite was a tip, what i'm talking about is a real url_rewriting...).

But maybe the best choice (if u can..) is : just wait 1.3 and migrate, u will have it without effort.. wink


(13 replies, posted in General discussion)

Just my 2 coins : seeing the logs, i can understand in a way the reaction from hoster, especially if the price was not high...
U didn't manage to explain him (neither us) WHY all these mails were sent..

<mode "non-constructive, but tho.." on> wink
If u want to have a full rewrite mod, just take it from PunBB 1.3, and put it on 1.2 branch.
It DOES work perfectly, as the implementation of url_rewriting is pretty good in 1.3 (thx devs, maybe just a little lack of localization's possibility in sef_friendly() function..).
It's a far better way (IMO) that trying to deal with old mods (which were good as the time they have been published, but now out of date).

As for 'B' (the query builder), it's just a conventional way of writing requests in punbb 1.3.
Just have a look at any file from punbb 1.3, and inspire from it (basically, u just have to split ur requests in an array..)

For the other points ('A' & 'C'), maybe we didn't understand what u really want to do (based on the subject).

As extern.php DOES ALREADY support the 'fid=nnn' parameter, i don't see why u whould need a redirection for calling it.
Just link to "extern.php?action=active&fid=XXX&type=rss", and it should work....

Smartys wrote:

Probably because of the fulltext index.

Of course it is.. wink

@others : in 1.3 the search index is included in topics and posts tables (as it is now managed internally by MySql), in 1.2.x the search index is in separate PunBB's managed tables (search_*).

Basically, indexes still take (approx.) same place in 1.3 than in 1.2, but they're just located in different places.
So, u can't really compare sizes of tables 'topics' and 'posts' from 1.2.x to 1.3 ones (or u have to keep off the indexes sizes).


This is not the way for doing that..
As ur 'new to punbb' (and probably 'new to internet dev'), it's a common error, let's try to help u :
First, what do u want ? a general background image ? or a more soffisticated thing ?

Basically, applying a background can be done WITH CSS ONLY (so u don't need to modify main.tpl).
For example, just try to apply a 'background' property at #punwrap in ur css style and see if it fits to u.

Things which are BAD :
- duplicate 'DOCTYPE' or 'html' or 'body' or 'head' (which comes from ur actual code..)
- 'img' not well closed (since we're in xhtml)

U should first try to resolve ur multiple validation errors..
(and php ones).
Sincerally, the code is just awful (and it's not punbb's fault.. wink)
Then, maybe we can check something..

Jérémie wrote:

Less forums/sites to check on a single topic would be better for everyone, in my humble opinion.

Agree with Jérémie on that point.
I didn't really understand what is ur objective lie2815... and furthermore what will distinguish ur site from punbb.org.
When the extension system would be on, ALL the support will tend towards extensions only, and so will punbb.org, i guess.
Then, having a separate site dealing with extensions only is useless.
What u described is just what punbb.org WILL BE IN THE FUTURE (i.m.o.)...

elbekko wrote:

You cannot access the database, nor can you access the config file. How would you suggest these error messages be localised? Through magic?

Just add a "select language" box at the beginning of install, then load the appropriate lang pack.

Well, as install.php NOW exists in lang pack, it should exactly serve this purpose : localizing installation.
So the hardcoded strings mentioned by Alex007 should be in the '$lang_install[XXX]' form, in order for us to translate these messages in the lang pack.

However, it's also true that this would not solve totally the problem (cause use of exit()).
So, maybe the simple 'error()' function should also be used as 'error()' do sends correct headers.

Then it wouldn't be anymore SimpleRewrite... smile

What u have to do is to adapt url_rewriting in 1.3 for 1.2 branch.
Which means changing ALL the links (call a function for rewrite them) and code a complete .htaccess

This takes a long time (and modifies all the php files).


(12 replies, posted in PunBB 1.3 troubleshooting)

Homeboy wrote:

Smartys, sure it's simpler but you shouldn't expect everyone to know how to create extensions.

Smartys wrote:

When the final version is released, I fully expect someone will have coded an extension to generate a full-blown 404 page.
Meanwhile, you shouldn't expect beta software to be as fully supported as the stable version, for obvious reasons

Ur both right.. lol
Smartys, how could Homeboy code an extension if he doesn't know HOW to do it ?
Mean, it would be a GOOD IDEA (imo) to release the doc on extensions asap (i know the doc is often pushed last on the planning), even in a basic form.


(151 replies, posted in PunBB 1.3 extensions)

I've already stated in another thread than "eval" function is one of SLOWEST call in php (and in other languages as well..).
Seeing the reacts at that time, i've stopped "informing" (as it was somehow considered as "complaining", which obviously was not).
The conclusion for me : let's "wait and see"...
Basically, it's obvious that an 'extension' will be slower than its corresponding 'mod'. But, is this really noticeable (or become a problem), we don't know as today.
And is the 'extension' system in a whole worth the slowdown, we don't know either, even if i'm tempted to think YES (before having testing any extension..), for the simplicity of extensions against mods.


(69 replies, posted in News)

Regarding hdiff, in include/common.php, you added a test :

if (version_compare(PHP_VERSION, '4.2.0', '<'))

But in the next file (of the hdiff), include/functions.php, u use a function (sha1) which is ONLY AVAILABLE in PHP 4.3.0 and sup. (dixit manual).
What's the logical out there ?
(note: and sha1 is used in install.php whereas a strict test is done at beginning of the same file for assuring we're using at least 4.1 version, not 4.3).

I know future 1.3 will require at least PHP 4.3, but was thinking this applies ONLY to 1.3 branch.
So :
- is this a mistake ?
- or has this "1.2.17 update" raised the requirements for 1.2 branch ? (and in this case, u should mention it on the changelog, and modify the initial test in install.php)

Smartys wrote:

For anyone curious, the issue was not with the conversion process but with the MySQL dblayer. smile

Thanks for the info (as i searched a long time, without figuring it could be there...).

So, IT (refer posts #5 and #21 of this topic) now works well.. (at least on my primary tests)


(3 replies, posted in PunBB 1.3 troubleshooting)

Dr.Jeckyl wrote:

Did this answer your question?

Guess it will not... wink
I assume the right answer would be : "just have a look at include/url/*.php" and u could understand how it works...

Smartys wrote:
Mpok wrote:

And for the other 'database changes', let's think about the 'New forum' string in install.php : this HAS to be localized also...

How wonderful for you then that Paul created lang/English/install.php wink

But in rev. 1478, this string has not been taken in it..

Smartys wrote:

No, unless Guest was translated the three times it was used (username, password, email), in which case I really think this is an issue for PunBB.fr to deal with.

Thanks to suppose we're THE ONLY ones to attempt to get a REAL localization (means got translated EVEN the hardcoded values), but i'm not sure we're the only ones..
And ur not sincere (as a developer) : u encounter 3 times in a row the same word u have to translate, and u just translate the first one ? (note: u didn't give me the answer at "Are these values being used somewhere ?")

Once more, this WOULD'NT HAVE HAPPENED IF ONLY THE SCRIPT WAS "localizing" (mean used lang files, which WAS NOT THE CASE). So please, don't reproach us things we're not responsible.

Smartys wrote:

Everyone: But yeah, seriously, we can't help people who want to localize PunBB if they don't tell us when they have trouble doing so. If you find a hardcoded string, point it out so we can fix it.

I DID pointed u in my previous message at least 2 of these 'hardcoded values'...

And in install.php, maybe "Paul created lang/English/install.php", but NONE of the actual strings are taken from the lang file.

Smartys wrote:

And even if we tweaked db_update.php to convert the guest user (which requires changing one line, not adding eight)

??? You mean changing '2' to '1' ? The conversion made in the general loop is not neither applicable nor sufficient for guest user. The fields needed to be converted ARE different from common users. So u need a special treatment, and then, more lines (only thing is that the three fields are likely to be the same, so the code can be reduced from the one i've provided, but not in lines, counting commentary one).

@Smartys : what u seem not to understand (sry), is that the only reason of changing things in php files (and therefor in the database) is the lack of using lang files in several occasions..
If everything IS based on lang files, we won't have to change things we're "not supposing to.." smile

For the 'Guest' thing, let's take post.php :

    if (($pun_user['is_guest'] && $_POST['form_user'] != 'Guest') || (!$pun_user['is_guest'] && $_POST['form_user'] != $pun_user['username']))

should be :

    if (($pun_user['is_guest'] && $_POST['form_user'] != $lang_common['Guest']) || (!$pun_user['is_guest'] && $_POST['form_user'] != $pun_user['username']))

and several lines after :

    '<input type="hidden" name="form_user" value="'.((!$pun_user['is_guest']) ? htmlspecialchars($pun_user['username']) : 'Guest').'" />'

should be :

    '<input type="hidden" name="form_user" value="'.((!$pun_user['is_guest']) ? htmlspecialchars($pun_user['username']) : $lang_common['Guest']).'" />'

I let u check other files for same stuff..

And for the other 'database changes', let's think about the 'New forum' string in install.php : this HAS to be localized also...

Smartys wrote:

I will say this again: making those changes exposes your site to security risks. Do not do that.

+1 Smartys... (even +10,000 smile)
But you have to admit that this needed change in 1.2.16 has raised a lots of pbms for users like dolbex, who don't understand the "security" point, but are focused on the "visibility" point.. ("it worked, it doesn't work anymore").
This change of redirect() should have been more documented, providing examples of pbms it can occurs, and the way to resolve them.
When the user is lost, he generally chooses the 'easy/bad way', like dolbex did... sad

elbekko wrote:

Then that should be localised, not changed in the database.

Don't understand ur point.. : it's the localization of install.php which RESULTED as a change in the database.

Can u (developers) precise me if these values in the database are NEVER USED in the soft ? (it could be the case, haven't checked..).
If so, i aggree, that change in install.php is useless... (and shoudn't be done).

This said, i don't understand why adding 8 lines to db_update.php (to deal with eventual 'badly converted' databases) is such a pbm...

There still are a lot of places where 'Guest' is used hardcoded (see post.php for obvious example), when it should rather use a lang file.
And so it uses the hardcoded form, we still have to translate these php files..