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've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Forum Module /

Discuss the Forum Module.

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

Server error on register and some profile pages


Go to End


1926 Views

Avatar
bo

Community Member, 10 Posts

16 February 2013 at 3:48am

Edited: 16/02/2013 3:49am

I have an odd issue, or rather two issues that look the same but may have different causes. Navigating to /ForumMemberProfile/register as well as to some profiles (/ForumMemberProfile/show/xx where xx of course is the ID of the profile) gives me an internal server error and nothing is shown. This happens with my profile and with one of my colleague's, while others' seem fine (have not tested all of them).

While no page is displayed, I can still use some of the debugging tools. The only difference visible through debug_request is that SSViewer never goes out looking for SearchForm.ss when loading these pages (both register and said profile pages). I suppose this could ruin the structure of the page (would this create a server error though?), and in any case I'd like to repair it.

The "debug" URL variable shows no differences between working and failing pages.

It's been a long time since I tinkered with this, but when I implemented the forum I made a couple of changes to the structure. Quite possible that this is the source of the problems, but since I have looked all over the place without getting much wiser I figured I'd see if anyone here spots the fault.

Side note: Me and my colleague are also set apart by our db records, which are the only ones containing AutoLoginHash and -Expired values. Can't see a connection, but perhaps there's something (else?) in our records that messes up some part of the call.

Any help and pointing in directions greatly appreciated.