Draven, let me take some time to digest your posts. I think you are on to something.

At first glance, based on the examples we are developing, I suspect that we can come up with a way to write a set of examples... say six lines of rules... that should work for "all" modules. We can do this by writing them in a way that is not module specific.

In our examples above, we try to match /library/.

However, if we didn't specify library and simply passed that through with the rest of the URL, it could indicate the module. This would handle the search engine spider issue... though it would not handle directories with user-defined names. Having said that, there may be a way to chain the commands together so user-defined directory names can also be handled in a painless way.

I am pressed for time the next 60 hours, and I need to put this out of my head. But, I look forward to picking up this thread next week.

I am glad this thread is moving in a useful direction.

(Also, while I like the idea of taking advantage of mod_rewrite, it may be that there is a PHP-centric way of handling this that wouldn't exclude non-Apache users. I believe Onokazu mentioned symlink. Still, I think keeping in mind that "URLs are part of the user interface" is still a good thing.)

I'm still in the midst of fixing up my site and pounding out some content, so no detailed reply yet. However, in looking at the templates for the blocks for the News module, it seems like they are written in a way that would make it very easy to modify them to generate the links to make use of mod_rewrite.

I'm going to test it and then I will provide a sample template and the remaining .htaccess file.

I also wanted to update this thread to make a correction. In the original post in this thread, the RewriteRule lines dealing with wfchannel pointed to page= instead of pagenum= ... so I have corrected the original post in this thread with the change to pagenum=

Keep me posted. I'm very intersted in this (incase you didn't already know )

I'd be very, very interested in this solution as well. There is already a solution for postnuke, and they have worked it out nicely here:

Postnuke search engine friendly URL's.

OK, I've had some time to work on this a bit more. First, I started with the generic example that Draven proposed. It works fine. However, since I'm interested in "friendly" URLs as much (more than) "spiderable" URLs, I took this to the next step and eliminated extra "subdirectories" being passed in the URL. My next post includes discussion of editing templates.

(Note: these examples do not touch the core. At most, you edit templates. If one were going to play with the core, it might be worthwhile to look into pulling up a story by a munged version of the <storytitle> which is a more friendly, memorable URL and (I think) improves the spider's index rank. Or, if concerned with duplicates, perhaps <dateyyyymmdd>/<storytitle> )

First, the generic example:

This first example works fine, creating spiderable URLs.
/news/article/storyid/44
maps to
/modules/news/article.php?storyid=44

However, I figured since I'm going to be editing the templates anyways, why not shorten it further. In the next example, you will see that:
Line 1 handles a trailing slash or anything else that shouldn't be there.
Line 2 is the URL for News we are shooting for
Line 3 is the catchall so existing functions continue to work properly.
/news/44
maps to
/modules/news/article.php?storyid=44



The next message will be a couple example edited templates.

Next, I will tackle WFSections and see if I can keep the URL as generic and flexible as possible.

Changing the templates for the above example...

Editing templates may be an optional step (with the exception of pointing to image files) but, I figure the whole point is to use the easier URLs so it makes sense to edit the templates since they control how the URL is presented to the user. The lines that have changed are in bold. Basically, this is just making the URLs relative from root instead of from within the directory, so that the page works regardless of the virtual URL you are using. These examples should give you an idea of the edits one should make to the templates. (See note at the bottom... it seems not all templates are as easy to change. Some are pulling a complete URL from the db. Adjusting that will require more investigation).

news_block_top.html
[size=x-small]
<div align="left">
<ul>
<{foreach item=news from=$block.stories}>
<li><a href="<{$xoops_url}>/news/<{$news.id}>"><{$news.title}></a> (<{$news.hits}>)</li>
<{/foreach}>
</ul>
</div>
[/size]



news_article.html
[size=x-small]
<div style="padding: 3px; margin-right:3px;">
<{include file="db:news_item.html" story=$story}>
</div>

<div style="padding: 5px; text-align: right; margin-right:3px;">
<a href="/modules/news/print.php?storyid=<{$story.id}>"><img src="/modules/news/images/print.gif" border="0" alt="<{$lang_printerpage}>" /></a> <a target="_top" href="<{$mail_link}>"><img src="/modules/news/images/friend.gif" border="0" alt="<{$lang_sendstory}>" /></a>
</div>

<div style="text-align: center; padding: 3px; margin:3px;">
<{$commentsnav}>
<{$lang_notice}>
</div>

<div style="margin:3px; padding: 3px;">
<!-- start comments loop -->
<{if $comment_mode == "flat"}>
<{include file="db:system_comments_flat.html"}>
<{elseif $comment_mode == "thread"}>
<{include file="db:system_comments_thread.html"}>
<{elseif $comment_mode == "nest"}>
<{include file="db:system_comments_nest.html"}>
<{/if}>
<!-- end comments loop -->
</div>
[/size]


news_block_new.html
is also easy to edit like the above examples. However, the other templates seem to pulling URLs from the db, so I'll need to investigate those further. Probably required editing the module to take this further, and I'm not sure I'm ready to go there. So, I guess we can consider this a downpayment on a more full blown solution.

have you guys gotten any further yet? any established *final* routine that you would recommend hacking into our Xoops?

Hi,

As my eyes almost popped out reading about the accomplishments made already...

It may be interesting to test the possibility of using the .htaccessfunctionality in just one module to see if it can be used to add meaningfull dynamic information for visitors but the information has no impact on the content that is shown.

For example:
http://www.mysite.com/news/cat/431/News-about-Japan.html

In the above example you could simply use 431 for the news category id and display the contents of:
http://www.mysite.com/modules/news/index.php?catid=431

While creating the link in your latest news section you can add the "name of the category" plus the dashes and the .html extension so that the visitor is lead to the example url.

I think this would be another option of making the pages more visitor friendly, while at the same time the page is search engine friendly.

Do you think this is also a good possibility?

Regards,
Martijn

Hey Sun, have you checked out the new Mambo yet? Seems they have a solution we may be able to emulate.

http://www.mamboserver.com/content/MOS_FAQs/Installing_Mambo_Open_Source/How_do_I_enable_Search_Engine_Friendly_URLs%3F/

Draven, that Mambo technique is interesting, and as you point out it does not seem to be a Mambo-specific concept.

The best I can tell, they are using a PHP routine to convert all the URLs presented in templates to their new format. To the best I can determine, it also appears that they are simply passing everything in the URL to index and then letting the PHP routine in index sort it out from there.

This seems like a reasonable short-term solution, though I do wonder about the overhead of the on-the-fly-PHP-conversion vs. simply using "search engine friendly" links in the template. Since one needs to go into the template to add the "SEF call" code to each link, it seems just as easy to put the actual link there (at least for Xoops, which seems to have URLs that are more straight forward than the Mambo URLs.)

What do you think of the PHP overhead issue? I guess I lean towards saddling Apache with the mod_rewrite overhead, since it handles it very well... and leaving PHP out of it as much as possible. Particularly if we can get it to 5 or 6 mod_rewrite lines, as we have discussed in this thread. I am optimistic that can be made to work as we develop our understanding of it further.

Over the next 4 days, I hope to make another post or two to this thread with (at least) final mod_rewrite rules and (hopefully) a final set of templates.

WTravel, I'll take a stab at making a mod_rewrite rule that accomodates your comment as well. I am sure it is possible, I am just not sure it is possible by me...

Happy to see the XOOPS team and community are still excited about this and developing it to the next level.