Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

lots of 404 errors with relative pathing with the blog widget

Go to End



Community Member, 8 Posts

21 January 2008 at 1:40pm

Edited: 21/01/2008 1:43pm

Hey all.

I've noticed over the past month using SilverStripe that my error_log is filling up with 404 errors, mostly associated with things like this:

(I should mention that SilverStripe is installed at the root level of my web site, ie: right in public_html, not a subfolder like /cms/)

So I added the following rules to my .htaccess, and the errors went away:

RewriteRule (.*)/jsparty/(.*)$2 [L]
RewriteRule (.*)/blog/(.*)$2 [L]
RewriteRule (.*)/themes/(.*)$2 [L]

Obviously, if you installed SilverStripe under a root folder like /cms/ you'd change the rules to be something more like:

RewriteRule cms/(.*)/jsparty/(.*)$2 [L]
RewriteRule cms/(.*)/blog/(.*)$2 [L]
RewriteRule cms/(.*)/themes/(.*)$2 [L]

After tracing through much of the code, I see where a few calls to the Requirements class are using a variable like this:

Requirements::css($_CSS_MANIFEST[$name]['unthemed'], $media);
but most times not:

It seems the code that inserts the filename into the output HTML does a check if the file exists, likely using file_exists(), since prepending a '/' on these calls caused huge issues (file_exists() uses relative pathing, so prepending a '/' would start looking at the root level of your filesystem, not from a web-relative path). I know this because prepending a '/' made those javascript/css elements disappear completely from the output HTML, telling me that if the file_exists() call failed that the css/javascript wasn't injected into the output HTML.

So it seemed the only way to correct this behavior was via .htaccess, and my fix as mentioned above seems to be working quite well.

Still, it raises the issue of why the blog widget doesn't account for the article name when looking for the /jsparty/ or /blog/ paths for other elements.

Can anyone think of a non-htaccess way to solve this in the code?