(Updated with code) Internal content page links using IDs

[raoulduke]

I've got an idea or suggestion for a small extension of websitebaker, now that the "moving pages with subpages" issue is solved:
https://www.websitebaker.org/forum/viewtopic.php?t=788

The background: I am currently still testing WebsiteBaker while making a template for my site, and I tend to test things quite a lot before taking them into production use.

The issue: I had made some WYSIWYG pages with links to eachother in the text using the excellent HTMLArea support. These links work fine, until you start moving pages around. Since WebsiteBaker implements the links as hardcoded paths, these links point to nowhere once the target page is moved.

A possible solution: could we use the page ID number to redirect txe links? So the link would look like:
<a href="http://$WBROOT/redirect_page.php?id=$ID">
That page could use a 302 header or a Javascript redirect to point the end-user to the correct, full path. Using 302's would also allow search engines to correctly index the content.

The question: would this be possible, feasible and doable?

[Stefan]

Hmmm... isn't the point of search-engine optimization that the links on the page are SEF? But maybe I'm mistaken here, it's definitely not my area of expertise.

[Ryan]

Hmm, interesting... maybe some SEO masters could give us advice - if any are around.

[rabsaul]

but I really doubt a spider could follow that...

[Hans]

Etomite works that way, with ID's, but you can assign an alias to use SEF URL's. I used it some time ago and it works so maybe it could implemted in WB too

[raoulduke]

A different solution would be to have WebsiteBaker preprocess all pages so we can introduce a kind of meta-tag depicting an internal link, so you'd end up with something like this:

Code:

This is my article content, check out this <wblink id="5">great page</wblink> on writing enterprise class applications.

WebsiteBaker could/should then replace all "wblink" tags with the correct paths.

But to be honest, most webcrawlers do not have a problem with the question-mark URLs, I know that GoogleBot, MSNBot and Slurp! don't have any problems traversing some of my other sites that do use the ?id= approach. And to make it even better, using the 302-header redirect you can force these bots to actually use the redirected, hardcoded path to be indexed instead of the ?id= URL.

So if GoogleBot encounters a link "page.php?id=10" that gives a 302 to "enterprise.php" then Google will index enterprise.php instead of the cryptic page.php link.

[mightofnight]

well any forum i have used works using this method,  And i have had no problems seaching through them using google or other search sites.

That said i like the current system.

[raoulduke]

well any forum i have used works using this method,  And i have had no problems seaching through them using google or other search sites.

That said i like the current system.

Well, the current system is fine for links that never change, but when you start moving pages around the hardcoded links become 404s. So, the issue I'm bringing forward here would only apply to links within user-provided content on larger sites, where moving pages will definitely happen. It's really difficult to keep track of and update links manually when your site grows larger with multiple editors.

[raoulduke]

Stefan, Ryan or any other high-profile Baker up there, here's the code that implements my proposed change.

Place this file called "redirect.php" in the root of the WB installation:

Code:

<?
        /**
                redirect.php

                Simple 302-redirect script for use with websitebaker. Use a GET variable
                called page_id to redirect to a given page.

                (c) 2005 - Frank Schoep, GPL licenced
        */

        // require configuration settings
        require('config.php');
        require_once(WB_PATH.'/framework/functions.php');
        require(WB_PATH.'/framework/class.admin.php');

        // database reference
        global $database;

        // get page_id from GET variables
        $page_id = $_GET['page_id'];

        // build query
        $query = $database->query("SELECT link FROM ".TABLE_PREFIX."pages WHERE page_id = '$page_id'");

        // retrieve page link from database
        $row = $query->fetchRow();
        $url = page_link($row['link']);

        header("Location: $url");
?>

Modify WBROOT/include/htmlarea/popups/link.php lines 85 AND 104 to (why is this code duplicated anyway?)

Code:

$template->set_var('LINK', WB_URL.'/redirect.php?page_id='.$page['page_id']);

It's kinda late, but this is a working PoC code - any thoughts on this?

[Stefan]

How long does a redirect take?

[fienieg]

How long does a redirect take?

As long as the server needs to process it and send you the new page! (so not very long, few milli seconds)

[Ryan]

Ok, I have a very cool idea. I am going to incorporate the 2 idea's in this thread (wblink tag and ?id= redirect).
When you insert a link, it will simply read something like this
<a href="[WBLINK1]">Blah</a>
and then the WYSIWYG module will replace any [WBLINKidgoeshere] tags with the actual URL, for e.g:
<a href="http://www.websitebaker.org/home.html">Blah</a>
What do you guys think? I am definetely thinking about implementing it for 2.5.2

[raoulduke]

Ok, I have a very cool idea. I am going to incorporate the 2 idea's in this thread (wblink tag and ?id= redirect).
When you insert a link, it will simply read something like this
<a href="[WBLINK1]">Blah</a>
and then the WYSIWYG module will replace any [WBLINKidgoeshere] tags with the actual URL, for e.g:
<a href="http://www.websitebaker.org/home.html">Blah</a>
What do you guys think? I am definetely thinking about implementing it for 2.5.2

Sounds good to me, that way you still send the "nice" URLs to the browser instead of using a redirect and you can still shuffle pages around without getting 404s. The downside is that the preprocessing for these links must be done in almost every piece of code that sends something to the client to make sure no "raw" links get passed. On top of that - can the preprocessing be done as quick as the 302-redirect?

[fienieg]

I certainly like the idea...
Here is my view...

You insert a link in the WYSIWYG editor
And you get <a href="WBLINK-??">lafsdlfj</a>, the ?? stands for page ID. (that isn't going to change, or the page must be deleted)

The WYSIWHG editor, just leaves the a href="WBLINK-??"> intact.
And in the index.php the path to the link get read out of the SQL DB, WHERE PAGE_ID = those ??... etc..

And if a page_id does point to a no excisting page, you could get a custom error message. Saying that the page doesn't excist. Something like that...
Yes i know, you can do that with custom error pages and the htaccess file. But most of the people that use WB, just want/need to keep it simple. Adding such a feature, removes there need to either f*ck up there server. Or them getting all "Loco"...

[evets]

Might be nice to use page names instead of id numbers.

[mightofnight]

Might be nice to use page names instead of id numbers.

This might make sence but then you can't have multiple pages with the same name

[Ryan]

@fienieg: good to see you understand my ideas
@raoulduke: speed isn't always king - I think this outweighs speed in a lot more areas. First, it doesn't require any extra scripts, second it looks nice, third it works.
@evets: I agree with mightofnight with the page names vs page id's
I will implement this ASAP unless someone proves it to be a bad idea.
 

[raoulduke]

@fienieg: good to see you understand my ideas
@raoulduke: speed isn't always king - I think this outweighs speed in a lot more areas. First, it doesn't require any extra scripts, second it looks nice, third it works.
@evets: I agree with mightofnight with the page names vs page id's
I will implement this ASAP unless someone proves it to be a bad idea.
 

Ryan, have you taken into account that you might need to update code in more than one place? I mean: the links you suggest need to be preprocessed so you can't really pass unprocessed links to a client since they won't work. How can you be sure that all content in which links can be added using WYSIWYG are parsed and processed before sending them over? I think I just answered my own question: since you're going to implement this in the WYSIWYG module, the content will always be parsed by the WYSIWYG module before it reaches the client so you always rewrite links that are in the <WBLINK> format, right?

Other than that I think it's still a really good idea (I even suggested it in the first place), it should definitely make it into the next version. Too bad you can't reuse any of my code, well - maybe you can use the line numbers as a guide

[Stefan]

I think this should be implemented together with the switch to Smarty when all pages are preprocessed anyway.

[fienieg]

@Stefan
Yes it would be an compatiblity issue with previous versions!
But for only for pages created before this WBlink-ID...
So the first way, the way they are processed now, should also still be supported!!!!

So i don't see why is should be implented in WB 3 and not now  

@Ryan
Your not so hard to understand... You think simple thaught, i think simple thaughts. All very logical    

You go and have fun working out this new feature  

[mightofnight]

i don't get excited for much but i think that version 3 just might be one of thes things..

[Ryan]

Wow, I thought this would be extremely hard, but it turns out to be quite easy and very quick and simple. Here is a simplified version of what the implementation should look like:

Code:

<?php

$links[1&#93; = 'http&#58;//www.google.com/';
$links[2&#93; = 'http&#58;//www.yahoo.com/';

$text = 'Click <a href="[wblink1&#93;">HERE</a> or <a href="[wblink2&#93;">HERE</a>';
$pattern = '/\[wblink&#40;.+?&#41;\&#93;/s';
preg_match_all&#40;$pattern,$text,$ids&#41;;

foreach&#40;$ids[1&#93; AS $page_id&#41; &#123;
$pattern = '/\[wblink'.$page_id.'\&#93;/s';
$text = preg_replace&#40;$pattern,$links[$page_id&#93;,$text&#41;;
&#125;

print $text;

?>

Try running the above code as a file on your webserver, as see how this:

Code:

Click <a href="[wblink1]">HERE</a> or <a href="[wblink2]">HERE</a>

Is replaced with this:

Code:

Click <a href="http://www.google.com/">HERE</a> or <a href="http://www.yahoo.com/">HERE</a>

Nice

[Ryan]

Wow, only a few minutes later and the above code has been implemented! How exciting! I only had to modify 2 files - I for HTMLArea and one in the WYSIWYG module. Now all I have to do is update the other modules.

[mightofnight]

Good Job, i look forward to seeing this!

[Ryan]

Me too, but my computer died while I was in the middle of commiting to CVS! I am now working off my laptop, and am about to go to the computer store to see if I can get my comp fixed. Man, I definetely hope that I don't lose my data, as that was a lot of work chasing up all those bugs! I will let you guys know if my comp gets fixed.