Pretty URLs

Started by SMFHacks.com Team, January 31, 2007, 10:56:43 AM

Previous topic - Next topic

Dannii

QuoteWhat important changes?
The big thing now I'm working on is a maintenance system for fixing up the database of pretty stuff. It's tricky because I need it to work in stages so large forums won't time out.

QuoteI think collisions might be reported when the thread number goes over the millions... I don't mean forums with low thread numbers are safe. Just saying chances to have collisions can only go up.
Why not simply use the topic URLs themselves in the database? Because indexing based on a VARCHAR, TEXT or BLOB field is slower?
I expect it would be slower, and it would make the database far larger too. I'm no MySQL expert though, so if it doesn't actually make it slower that could always be an option.

QuoteI only made one change to the code -- made sure the PrettyURLs stats are shown only when $db_show_debug is set to true. (I don't think it's of any interest to non-admins ;) And my index.php code is modified to set $db_show_debug if the user is an admin.)
Mmm, I find it useful for checking people's forums. And it provides a link back too lol. But removing it's fine, I don't want people to feel they're forced to like other mods.

QuoteWell, re: the topic subject I reckon? I don't know, I'm no better than a rookie PHP coder.
I still think of myself as a rookie too :P Writing mods is a great way to learn. Really what's most important is willingness to try. I only started this mod cause the guys in charge of SMFSEO were losers.

QuoteAnyway, I might just do that (switch to PrettyURLs) if we can add more formatting options for the URLs. What I could do is, try to gather all of the mods I made on my side (keep in mind I didn't make an actual mod--this is really a series of modifications directly on the 1.1.3 source files), and share with you anything that could be of interest to PrettyURLs.
I would like to make more options, however I still want to keep it simple and uncluttered and unbloated, unlike SEO4SMF.

QuoteFor example, here's my URL conversion code. You'll notice it's much shorter than yours ;) My database isn't in UTF-8, though. It basically only converts French accents, well, because I'm French, and my website is French-only. Your mod converts such things as Japanese kana, but it doesn't work on French accents, strangely enough.
I'm pretty sure it does work on the French accents, but possibly only with UTF-8.

QuoteHaving the & sign in the URL is no issue. The .htaccess parser has no problem with it. The only special character I think we have to take care of is "?" because it tells Apache that the rest is $_GET data so it just won't parse it.
Hmmm... & might be okay, but I've prefer to take no chances. Different Apache configs could possibly get it wrong.

QuoteI also added an extra field to the boards table, "shortname" (shall be renamed to "short_name" for SMF 2.0...), which holds the URL name for the boards. Allowing for a long and complicated name in the database (and MessageIndex template) without prejudice in the URL. For instance, board #18 in my website is named "Naologismes", but its "short_name" is set to "nao", hence the URL "/nao/". Actually, I changed the system so it would generate a subdomain instead, so it renders it as "http://nao.cyna.fr/". The .htaccess file then just checks for the presence of a subdomain, and if there is, it sends a flag to SMF, similar to your "pretty;" flag in your .htaccess. I'm surprised at how many things we did the same way, while we weren't aware of each other's attempts to do these modifications ;)
Subdomains is something that should be possible with mine too, however I'm not sure I'd want to add it to the default package. I think it's more suited to be an alternate filter that you could install and use instead of the default one included in Base. And I'm not sure what your flag does, but the pretty in my querystring is only to stop redirects.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Nao 尚

Quote from: eldʌkaː on October 09, 2007, 06:50:53 AM
It's tricky because I need it to work in stages so large forums won't time out.
Ah, yeah... You might want to do something like SMF's installer I suppose!

QuoteI expect it would be slower, and it would make the database far larger too. I'm no MySQL expert though, so if it doesn't actually make it slower that could always be an option.
It'll probably be slower, but not by a large margin. I mean, you also benefit from not converting URLs to MD5 (very slow) or CRC (high chances of URL collisions).
Or you may just want to get rid of the CRC table and just use the topic / topic name table. Well, this is how I would do it. (Actually, I would put the cleaned-up topic name in the {$db_prefix}topics table, but it's probably a better idea to keep these in separate tables.)

QuoteMmm, I find it useful for checking people's forums.
How about putting something like "if (!empty($_GET['check_prettyurls']))" at the beginning of that code? Then you get to see the stats on all forums, by just adding ";check_prettyurls" at the end of the URLs... Just my .2$ of course.

QuoteWriting mods is a great way to learn. Really what's most important is willingness to try. I only started this mod cause the guys in charge of SMFSEO were losers.
:P
Didn't know this one... Just checked it out, it seems to be quite similar to Pretty URLs... Why do you think they're losers?
Also, I see they only use one extra table (for topic subjects), just like I suggested.
They also deal with thread splitting and everything, to update topic names. I don't think your mod does that? (Does it? Does it need to? I don't know it well enough.)

QuoteI would like to make more options, however I still want to keep it simple and uncluttered and unbloated, unlike SEO4SMF.
Unbloated is a good idea... It always makes it easier to update the mod.
Although at some point one has to figure out what they want, of course.
Fact is, on cyna.fr I'm looking into having as much of the website as possible, behave like this new URL format is "native" and not a quick hack.

QuoteI'm pretty sure it does work on the French accents, but possibly only with UTF-8.
This is a problem -- UTF-8, as far as I know, takes twice much space in the database (which can be an issue with huge databases), doesn't add much (I can post in Japanese and French with accents on my boards, without any apparent issue), and is slower to deal with (mb_* functions are known for being slower than regular string functions).

QuoteHmmm... & might be okay, but I've prefer to take no chances. Different Apache configs could possibly get it wrong.
Well I guess it's no big deal, I can always remove the special behavior for & manually.

QuoteSubdomains is something that should be possible with mine too, however I'm not sure I'd want to add it to the default package.
Of course not. But you could as well allow users to specify a URL format such as:

http://mywebsite.com/<board_name>/<topic_name>/

With a pool of dedicated pseudo-variables (board_name, board_short_name, board_id, topic_name, topic_id), users can change it to, for example, my way of doing this:

http://<board_short_name>.mywebsite.com/<topic_id>/<topic_name>/

QuoteI think it's more suited to be an alternate filter that you could install and use instead of the default one included in Base.
Changing URL formats will anyway always force users to update their .htaccess file manually, so it'd be safe to say this is "for power users only".

QuoteAnd I'm not sure what your flag does, but the pretty in my querystring is only to stop redirects.
My flag just tells LoadBoard() to take the board's short name and have a quick lookup at the corresponding board ID in order to fill the $board_info array later. (I'm not sure but IIRC I'm using an existing SQL query so there's no additional query for that.)
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Dannii

QuoteDidn't know this one... Just checked it out, it seems to be quite similar to Pretty URLs... Why do you think they're losers?
The way the interacted with people using the mod. It's development stalled anyways...

QuoteOr you may just want to get rid of the CRC table and just use the topic / topic name table. Well, this is how I would do it. (Actually, I would put the cleaned-up topic name in the {$db_prefix}topics table, but it's probably a better idea to keep these in separate tables.)
If you do this you have to query the topic table every page view, and the profiles table and the whatever-else table. By using a cache table ideally only one extra query needs to be made to get all the URLs.

QuoteThey also deal with thread splitting and everything, to update topic names. I don't think your mod does that? (Does it? Does it need to? I don't know it well enough.)
It doesn't yet. It's something that needs to be fixed before version 1.0, but it's not a high priority. Those are actually the sorts of things I want help with lol.

QuoteThis is a problem -- UTF-8, as far as I know, takes twice much space in the database (which can be an issue with huge databases), doesn't add much (I can post in Japanese and French with accents on my boards, without any apparent issue), and is slower to deal with (mb_* functions are known for being slower than regular string functions).
It is true that for accented characters two bytes are needed, however it's a lot less than the entities needed for other scripts. The mb functions don't usually need to be used... SMF doesn't do too much string processing.

QuoteOf course not. But you could as well allow users to specify a URL format such as:

http://mywebsite.com/<board_name>/<topic_name>/

With a pool of dedicated pseudo-variables (board_name, board_short_name, board_id, topic_name, topic_id), users can change it to, for example, my way of doing this:

http://<board_short_name>.mywebsite.com/<topic_id>/<topic_name>/
Hmmm, that's an interesting idea. I'll think about that some more.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Nao 尚

#823
Quote from: eldʌkaː on October 09, 2007, 08:18:32 AM
If you do this you have to query the topic table every page view, and the profiles table and the whatever-else table. By using a cache table ideally only one extra query needs to be made to get all the URLs.
Oh, you mean I can also rewrite the profile URLs? :)
I didn't notice that. No option for that, at least ;)

Yeah, in that case... It'd be best to keep that table, I suppose.

QuoteIt doesn't yet. It's something that needs to be fixed before version 1.0, but it's not a high priority. Those are actually the sorts of things I want help with lol.
Ah ah :)
Why don't you just get inspiration from the SEOSMF mod? I realize you don't like the guy, but it's open source, we might as well enjoy the benefits of sharing source code ;)
(Well, at least I don't mind sharing my own code.)

QuoteIt is true that for accented characters two bytes are needed,
As far as I know, all characters (even non-accented ones) take at least two bytes (I've read somewhere that they take up to 3 bytes, oops).

Quotehowever it's a lot less than the entities needed for other scripts.
I don't think so.

On a non-related note, my clean_name code has a neat thing I believe: turning &#digit; sequences into chr(digit), which will obviously reduce the number of entities that need to be converted manually. Non-occidental characters can be put into an URL without any consequence, have a look at Wikipedia for instance.
桜庭統

QuoteHmmm, that's an interesting idea. I'll think about that some more.
Thanks :D
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Dannii

QuoteWhy don't you just get inspiration from the SEOSMF mod? I realize you don't like the guy, but it's open source, we might as well enjoy the benefits of sharing source code ;)
Not SEO4SMF, SMFSEO. It wasn't open source. I haven't seen any problems with sacx, I just think his mod is too filled with bloat :P

QuoteAs far as I know, all characters (even non-accented ones) take at least two bytes (I've read somewhere that they take up to 3 bytes, oops).
ASCII characters take 1 byte. The others take a differing number of bytes depending on the 'plane' they're in, some up to 4 bytes for the asian scripts.

QuoteOn a non-related note, my clean_name code has a neat thing I believe: turning &#digit; sequences into chr(digit), which will obviously reduce the number of entities that need to be converted manually. Non-occidental characters can be put into an URL without any consequence, have a look at Wikipedia for instance.
桜庭統
You mean this? http://ja.wikipedia.org/wiki/%E6%A1%9C%E5%BA%AD%E7%B5%B1 It's a bit more messy :P
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Nao 尚

Quote from: eldʌkaː on October 09, 2007, 09:44:53 AM
ASCII characters take 1 byte. The others take a differing number of bytes depending on the 'plane' they're in, some up to 4 bytes for the asian scripts.
Okay... I assumed they all took 2 bytes but "UTF-8" probably means "8 bits or more". That's logical. It would be nice to be able to find benchmarks comparing ISO and UTF performances, though.

QuoteYou mean this? http://ja.wikipedia.org/wiki/%E6%A1%9C%E5%BA%AD%E7%B5%B1 It's a bit more messy :P
I don't get it--how did you get this garbage?

Anyway... I took some time to rewrite your mod to use full URLs instead of CRCs. Performance-wise, I'm a bit surprised: it's the exact same thing. Your mod takes around 0.07 to 0.1s to execute on a test page of mine, and my version of the mod takes around 0.07 to 0.12s to execute, with a similar average (~0.09s). So, basically, it would probably be a good idea to get rid of the CRCs altogether and just use plain URLs. The field format I used was "VARCHAR(255)" (I don't think URLs generated by SMF would take more than 255 characters anyway), although it could probably be set to "VARBINARY(255)", which is case-sensitive (i.e. a bit faster).

What do you think?
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Nao 尚

PS--
1/ I noticed the Subs-PrettyURLs.php file I sent you by PM is corrupted. I edited it with an editor that doesn't support Unicode, so it destroyed the UTF-8 data. The second half of the file is fine, though... (This is where the changes are.)
2/ I don't know why, but even a clean install of the converted mod on SMF 2.0 will call your rewriting functions twice. I tried to edit the $buffer variable to add debug data but it behaves just like it's been called only once. However, the query list does show that the SELECT query on urls_cache is repeated twice. This might be a bug within SMF 2.0 instead.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

metallica48423

i would be interested in seeing a 2.0 version of this :o

But i won't count on it lol
Justin O'Leary
Ex-Project Manager
Ex-Lead Support Specialist

QuoteMicrosoft wants us to "Imagine life without walls"...
I say, "If there are no walls, who needs Windows?"


Useful Links:
Online Manual!
How to Help us Help you
Search
Settings Repair Tool

Nao 尚

Quote from: metallica48423 on October 09, 2007, 03:52:59 PM
But i won't count on it lol
Why not count on it?
You can just ask nicely :)

I sent the files to the author, he's free to release them if he likes.
I can also send them by PM.

Also, I figured out why there were extra queries in my board. It's because $db_show_debug will call ob_sessrewrite a second time, discarding the first attempt. This is apparently needed for XHTML compliance. Since I don't care about such compliance for now, I just disabled the lines and it's working.

Still, it's saying "2q" (instead of 3), which is one more than what view_query actually allows me to see (SELECT url_crc, replacement
FROM {$db_pretty}pretty_urls_cache). I have no idea where the other one is...
Oh yes, and while I'm at it, {$db_pretty} doesn't work when selecting url_crc if url_crc is a varchar field. I don't know why... Probably something to do with escape characters or something. Not a real problem, I just changed the code there (".$db_pretty.")
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

metallica48423

if eldacar has no arguments, i wouldn't mind testing out the 2.0 version.  it won't be on a live site for quite some time, however, just in a dev/test board :)
Justin O'Leary
Ex-Project Manager
Ex-Lead Support Specialist

QuoteMicrosoft wants us to "Imagine life without walls"...
I say, "If there are no walls, who needs Windows?"


Useful Links:
Online Manual!
How to Help us Help you
Search
Settings Repair Tool

Dannii

QuoteI don't get it--how did you get this garbage?
Aside from unaccented latin characters, numerals and few punctuation characters, all other characters get URL encoded. I'm not sure how reliable this is, nor whether the search engines like it. I am planning to add an option to use URL encoding for boards and topics, but I think the default will be to remove the accents and romanise other scripts.

QuoteAnyway... I took some time to rewrite your mod to use full URLs instead of CRCs. Performance-wise, I'm a bit surprised: it's the exact same thing. Your mod takes around 0.07 to 0.1s to execute on a test page of mine, and my version of the mod takes around 0.07 to 0.12s to execute, with a similar average (~0.09s). So, basically, it would probably be a good idea to get rid of the CRCs altogether and just use plain URLs. The field format I used was "VARCHAR(255)" (I don't think URLs generated by SMF would take more than 255 characters anyway), although it could probably be set to "VARBINARY(255)", which is case-sensitive (i.e. a bit faster).
I've thought of more advantages of using the full urls. However remember it caches ALL URLs, so some URLs posted by users possibly might be longer. To make them shorter we could cut out the protocol and also the scripturl if they are SMF URLs.

Quote2/ I don't know why, but even a clean install of the converted mod on SMF 2.0 will call your rewriting functions twice. I tried to edit the $buffer variable to add debug data but it behaves just like it's been called only once. However, the query list does show that the SELECT query on urls_cache is repeated twice. This might be a bug within SMF 2.0 instead.
Does it do the queries twice without the debug data? It does messy stuff I think.

Quote from: metallica48423 on October 09, 2007, 03:52:59 PMi would be interested in seeing a 2.0 version of this :o

But i won't count on it lol
I'll get there eventually, after I've made the 1.1 version more stable. I also want to see it installed on the SMF docs :P

Quote from: metallica48423 on October 09, 2007, 04:24:09 PMif eldacar has no arguments, i wouldn't mind testing out the 2.0 version.  it won't be on a live site for quite some time, however, just in a dev/test board :)
Go for it.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

arabiancoder

It would be a nice mod if it works fine,
after [apply mod]
eventhough 17 [ Test successful ] as a result

The following msg shown



when clicked Back
Now this message is in every page!

Notice: Undefined index: pretty_board_urls in /home/aswatgro/public_html/forum/index.php on line 77

Notice: unserialize() [function.unserialize]: Argument is not a string in /home/aswatgro/public_html/forum/index.php on line 77

Nao 尚

Quote from: eldʌkaː on October 09, 2007, 08:57:57 PM
Aside from unaccented latin characters, numerals and few punctuation characters, all other characters get URL encoded.
This doesn't answer my question sorry ;)
(I think I don't get the whole encoding thing at all...)

QuoteI've thought of more advantages of using the full urls.
Cool :)

QuoteHowever remember it caches ALL URLs, so some URLs posted by users possibly might be longer. To make them shorter we could cut out the protocol and also the scripturl if they are SMF URLs.
Yeah...
First of all, use array_unique($crc_query) instead of $crc_query. It will remove the many many links that are posted several times on a board page.
Then, you might want to check for the domain name in the URLs, and drop them if they're external.
And, yes, dropping the whole $scripturl part would make for shorter URLs. :)

I will send you my updated Sources.xml later when I'm satisfied with it.

QuoteDoes it do the queries twice without the debug data?
I didn't try that.
(You may have seen I managed to fix the thing by not calling ob_sessrewrite from within the db_debug_junk function, BTW. But I have yet to find out why there are 2 queries shown in your stats, while view_query shows only one query. With the db_debug_junk, it did show the repeated query in that page!)

As for metallica, I sent him the link by PM :)
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Dannii

#833
QuoteIt would be a nice mod if it works fine,
after [apply mod]
eventhough 17 [ Test successful ] as a result
I'm guessing your forum has a lot of Arabic, and it's having problems with the quotes. This is a problem that I have fixed in the development SVN, so try again once I have released 0.8. Uninstalling the mod should remove the error.

Quote(I think I don't get the whole encoding thing at all...)
Basically only a-zA-Z0-9,.;?!()* and maybe a few other characters can actually be used in URLs. Our browsers are nice and convert other characters for us, but they're not really used.

QuoteFirst of all, use array_unique($crc_query) instead of $crc_query. It will remove the many many links that are posted several times on a board page.
Does this provide much of a difference? I suppose it might make queries a lot smaller, and if we changed to using the full urls that would make an even larger difference.

QuoteThen, you might want to check for the domain name in the URLs, and drop them if they're external.
I think that all URLs still need to be kept in the system. One possible use for this is that external pages could be put through a 'gateway' page saying "these pages are not part of this site and we don't endorse them" type of thing. Another possibility is that email links could be obfuscated. If we limit the mod to only work on SMF URLs it becomes less useful.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Nao 尚

Quote from: eldʌkaː on October 10, 2007, 04:56:11 AM
Basically only a-zA-Z0-9,.;?!()* and maybe a few other characters can actually be used in URLs. Our browsers are nice and convert other characters for us, but they're not really used.
Oh, yes of course...... IE  :'(
I had the feeling IE7 would support oriental text in the URLs. Well, turns out I was wrong...
Still, I'm entitled to believe that the Japanese versions of IE support Japanese text in the URLs. (I'd love not to be proven wrong ;))
And this is what matters most. Plus, Wikipedia is one of the most visited websites in the world. IE is poised to end up supporting non-ASCII URLs in the future if they don't want to look bad...
After all they did fix most of their CSS issues didn't they? ;)

QuoteDoes this provide much of a difference? I suppose it might make queries a lot smaller, and if we changed to using the full urls that would make an even larger difference.
I'm not sure the query size matters much, but having less entries in the query itself is always a good thing to try. I don't think array_unique uses a lot of resources. When I get to fix the multiple query issue, I will then try to benchmark my calls with and without array_unique().

QuoteI think that all URLs still need to be kept in the system. One possible use for this is that external pages could be put through a 'gateway' page saying "these pages are not part of this site and we don't endorse them" type of thing.
I somehow do that already, in Javascript though ;)
Just have a look at http://nao.cyna.fr and check the external URLs in the lower bottom corner.

function setHref()
{
	
var 
iahre;
	
for(
i=0; (document.getElementsByTagName("a")[i]); i++)
	
{
	
	
if (
a.getAttribute("title") && (a.getAttribute("title") == '-'))
	
	
	
continue;

	
	
hre a.getAttribute("href");
	
	
if (
typeof hre == "string" && hre.length 0) {
	
	
	
if ((
hre.indexOf("<?=$_SERVER['SERVER_NAME'] ?>") == -1) && (hre.indexOf("://") != -1))
	
	
	
{
	
	
	
	
a.setAttribute("class""xt");
	
	
	
	
a.setAttribute("className""xt");
	
	
	
}
	
	
}
	
}
}

window.onload = function(e)
{
	
setHref();
}


Then followed by this CSS code:

a.xt:link {
	
backgroundurl(/ext2.gifno-repeat 1000;
	
padding0 15px 0 0;
}

a.xt:visited {
	
colorpurple;
	
backgroundurl(/ext2.gifno-repeat 100% -27px;
	
padding0 15px 0 0;
}

a.xt:hover {
	
colorred;
	
backgroundurl(/ext2.gifno-repeat 100% -54px;
	
padding0 15px 0 0;
}


The picture itself is at http://cyna.fr/ext2.gif
This method has a few issues, though. It doesn't work well with external pictures, for example, and sometimes has issues with justified text. It may be a good idea to look into doing this from inside PrettyURLs indeed. The only problem is that it's quite out of context. But it shouldn't stop you from thinking about an implementation idea.

QuoteAnother possibility is that email links could be obfuscated.
Hmm yes indeed. Another out of context thing, but isn't QueryString just a fantastic piece of code? :)

You could also remove from the process any "javascript:" link. (It's just a matter of using "substr", it takes less resources than strpos... And it's not UTF-8 so it's just plain old substr.)
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Dannii

QuoteI had the feeling IE7 would support oriental text in the URLs. Well, turns out I was wrong...
Still, I'm entitled to believe that the Japanese versions of IE support Japanese text in the URLs. (I'd love not to be proven wrong ;))
And this is what matters most. Plus, Wikipedia is one of the most visited websites in the world. IE is poised to end up supporting non-ASCII URLs in the future if they don't want to look bad...
It's not IE, it's the HTTP standard. Although most browsers these days can automatically URL-encode stuff, not all will, so I don't consider it completely reliable.

QuoteI somehow do that already, in Javascript though
No, not just an icon, but a full gateway page, which would transform <a href="http://somedomain.com"> into <a href="http://mydomain.com/external.php?page=somedomain.com"> or whatever.

QuoteAnother out of context thing, but isn't QueryString just a fantastic piece of code?
Well I'm actually wondering if it might be better to move my processing code out of QueryString.php to a new file. However that would mean we'd have to load an extra file whereas QueryString.php is already being loaded, so it's probably not worth it.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Nao 尚

Quote from: eldʌkaː on October 10, 2007, 05:48:19 AM
It's not IE, it's the HTTP standard. Although most browsers these days can automatically URL-encode stuff, not all will, so I don't consider it completely reliable.
Maybe you (we?) should just leave the choice up to the user...

Quote
QuoteI somehow do that already, in Javascript though
No, not just an icon, but a full gateway page, which would transform <a href="http://somedomain.com"> into <a href="http://mydomain.com/external.php?page=somedomain.com"> or whatever.
I see. Well, if I were you, I would not change the link, and I would add an icon that points to a special popup saying it's an external page blah blah blah. Something like <a href="javascript:ext_link()"><img src="..." alt="" /></a> with ext_link() being declared in script.js (it will just open that pop-up... The goal being to have the shortest possible link to that pop-up.)

QuoteWell I'm actually wondering if it might be better to move my processing code out of QueryString.php to a new file. However that would mean we'd have to load an extra file whereas QueryString.php is already being loaded, so it's probably not worth it.
Yup...

As for QueryString.php, I only discovered what it actually does *after* I started my own pretty-urls mod. Which explains why I went the queryless way. Still, it works great, but it adds a ton more code.
I checked the other day, and I have approx. 170 occurrences of the word "url(" in my Sources and Themes source files. (This is the function that builds my own URLs based on parameters retrieved at the same time as the board & topic ID, of course.)

If you want to give up on the QueryString.php pollution, then you might want to look into doing things the way I'm doing them currently. It is a lot of extra work, though. But my options are open, too.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Dannii

QuoteI see. Well, if I were you, I would not change the link, and I would add an icon that points to a special popup saying it's an external page blah blah blah. Something like <a href="javascript:ext_link()"><img src="..." alt="" /></a> with ext_link() being declared in script.js (it will just open that pop-up... The goal being to have the shortest possible link to that pop-up.)
I wouldn't want to do anything, but other people have gateway pages and it's something that could easily be made with this mod, so I want to keep it easy.

QuoteIf you want to give up on the QueryString.php pollution, then you might want to look into doing things the way I'm doing them currently. It is a lot of extra work, though. But my options are open, too.
If you're working on replacing the URLs in all the source files, that's what I originally did. I had a 60kb mod file hehe. The current way is a lot more reliable.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Nao 尚

Quote from: eldʌkaː on October 10, 2007, 06:24:49 AM
I wouldn't want to do anything, but other people have gateway pages and it's something that could easily be made with this mod, so I want to keep it easy.
Well it's such a good idea that I might be adding it to my custom version of the mod anyway ;) (I want to get rid of the Javascript code as much of possible so I won't put an external link warning, though.)

QuoteIf you're working on replacing the URLs in all the source files,
Yes that's what I did...

Quotethat's what I originally did. I had a 60kb mod file hehe.
Oh, my!!

QuoteThe current way is a lot more reliable.
Yes but on the other hand, it adds extra queries and buffer manipulations. But I must admit I like the idea of being able to update my SMF easily ;)
(Originally, I planned to stick to v1.1.3 and never ever upgrade. Well, some of the new things in v2.0 made me change my mind.)

Ooops, I'm sorry to see we're reaching the end of our conversation :(
We should make a list of what we learned in it, and what we should focus on ;)
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Dannii

QuoteWe should make a list of what we learned in it, and what we should focus on
Lol.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Advertisement: