removing the /pages/ from the address

[crnogorac081]

I see that new WB site is not using /pages folder so I am not worried about security holes..

I belive that problems may appear in modules where links are formated as WB_URL.'/pages' , but if they are formated as WB_URL.PAGES there will be no problem.. (so far I experienced none..)

[sky writer]

I haven't experienced any problems either.  Just reading what seemed like warnings earlier in this thread, I did get concerned.  Sometimes feeling safe is not the same as being safe.  Just wanted to make sure I wasn't putting myself and other clients at risk by my actions.

[WebBird]

"Safe" may mean "Security".
But "safe" may also mean "no problems caused by modules using hardcoded paths" and/or "problems caused by access permissions".
 

So, setting the pages folder to WB root may be "safe" by the meaning of "security risks", but I'm not sure that it is really "safe" by the meaning of hardcoded paths and/or access permissions.

[crnogorac081]

Well, we can try and see As I said, I experienced no problems so far... And I see that new WB site is not using pages either I hope that if anyone experience the problem with pages in root to report, so we can fix

[Paul - Westhouse IT]

Why not just clear-out /pages/ from the "Pages Directory" under settings. Then use mod_rewrite to add /pages/ to all non-existing files?

Well, that was a dumb idea of mine. /facepalm

Works great until you actually try to create new pages, then they end up stored in root. I'll see if I can come up with a better solution.

[Paul - Westhouse IT]

I definitely want /pages/ removed from the address, but my requirements are a little more difficult. Here are all of them:

1. No /pages/ in URLs provided to the user.
2. All pages physically stored under /pages/
3. No effect on the normal operation of WB.
4. Minimal, or no, effect on site performance.
5. Minimal, or no, changes to the core WB code.

So the first idea that came to mind failed on point 3. So on to plan B:

It seems I need to leave "Pages Directory" as /pages otherwise I'll break #2 or #3. So let's try getting WB to output links without /pages but still store pages there. The key is line 161 of /framework/class.wb.php. If we remove reference to the PAGES_DIRECTORY constant then show_menu2 and others should get the right URLs. Note that this doesn't affect some parts of the framework, like class.admin.php that directly uses PAGES_DIRECTORY to create the "View" link under Admin. Hopefully I'll have time to test this idea soon.

[Paul - Westhouse IT]

Great! That appears to work. Quite a simple change that will work for the most of the core app.

Well-written modules should, in most cases, use $wb->page-link rather than directly using PAGES_DIRECTORY, but any that use the constant directly won't work with this method.

But we're not left with much else  to try.

Edit:
Unfortunately some core modules (Form & News) and the Admin class use $_SERVER['PHP_SELF'], which will equal the file path above the DocumentRoot. This is definitely not desirable when working with rewrites. $_SERVER['REQUEST_URI'] would be preferrable, but is not supported by IIS (directly), though there are ways to make it work.


It looks like a change to core code would be desirable. I would suggest a new option in settings - Pages URL - that defaults to the same as Pages Directory and sets the constant PAGES_URL. Then no existing code or modules will be broken, and modifications on code can be made to support URL rewriting. Any of the WB developers care to comment?


Since this was turning out to be complicated than first expected I've compiled my findings as an article:
http://westhouseit.co.uk/topics/websitebaker-remove-pages-from-url.php

Let me know what you think and I'll make any changes needed to get it working properly.