Search options (Page 1 of 2)

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

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)..

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..

<mode "non-constructive, but tho.." on>
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).
</mode>

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....

Hello,

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)

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.)...

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.

Ur both right..
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.

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

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

Ok.
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)

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

??? 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).

+1 Smartys... (even +10,000 )
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...