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.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

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

Remove Search Form from login page?


Go to End


7 Posts   1710 Views

Avatar
jseth

Community Member, 98 Posts

3 February 2010 at 9:24am

I've set up the $Search, but I'd like it to not appear on the login page. I'm not sure how to go about this. Can anyone tell me where to start?

Avatar
Willr

Forum Moderator, 5523 Posts

3 February 2010 at 11:40am

You could use the ClassName of the login page to remove the form. You could also make custom templates etc but the easiest way would be

<% if ClassName != Security %>
$Search
<% end_if %>

Avatar
jseth

Community Member, 98 Posts

4 February 2010 at 2:53am

Edited: 04/02/2010 8:14am

Hi Willr,
It appears that I'm having difficulty finding out the ClassName of the login page. I'm using the auth_external module and I think that the login form is ExternalLoginForm.php, so I am guessing that the class name is ExternalLoginForm, as it says in the file "class ExternalLoginForm extends LoginForm", but that does not seem to be correct, since the SearchForm is still appearing on all pages. Also, it is extending "LoginForm" not "Page".
I tried using a ClassName that I know exists, such as Calendar, and it did make it disappear on the calendar page, so it obviously works, I just need to figure out what the class name of the Login page is.
Also, if I want to remove the search from more than one ClassName type, how would I do that? Entering the code more than once with a different ClassName makes the search form appear again.

Avatar
edk

Community Member, 39 Posts

5 February 2010 at 7:40pm

Edited: 05/02/2010 7:42pm

Hi Jseth,

A down and dirty way to find out the page class is to add $ClassName somewhere in your root Page.ss file. That will echo out the page name for each and every page. I did a quick test on a basic install and it looks like the basic Login page is of Class 'Page'.

To answer your second question: how to go about blocking it from more than one page class. I think the best way would be to create a function in your Page.php file in the "class Page_Controller" section. The code may look something like this.

         function checkClass(){
		$DontDisplay = array('Security', 'AnotherPageClass', 'etc');   
		$currentClass = $this->ClassName;                                                                
		
		if (in_array($currentClass, $DontDisplay)) {                            
		    return false;
		} else {
			return true;
		}
	}

Basically you just add all the Page ClassNames you want to exclude in the $DontDisplay array...and then you just check whether the current Pages ClassName is in that array. If it is we will return false (this now helps trigger our view in the page template)....

In the Page template .ss file you can add a call to this function, something like this:

       <% if checkClass %>
	     <p>Hey there dudes</p>
        <% end_if %>

Now if checkClass returns true this content would display, if false it won't render.

Avatar
jseth

Community Member, 98 Posts

6 February 2010 at 2:31am

Thanks, chingochango! You are good! Now it appears that I will need to make a custom login page and make its classname something other than "page", since it removes the SearchForm from all pages with the classname of page! I was playing around with the tutorials and did create a custom home page with the classname "HomePage", so with your instructions, the searchform does show up on the HomePage (because its classname isn't "page"), so it works very well. Thank you so much. I was afraid that no one was going to be able to help. Thanks to you also, Willr, for getting me started.

Avatar
jseth

Community Member, 98 Posts

6 February 2010 at 3:54am

Edited: 06/02/2010 3:56am

Well, I'm back in "duh" mode. I can create a page with the classname "loginpage", but that doesn't seem to help, or I have no idea what to do next. Ideally, I'd like to find the login page I'm actually using, which I can't seem to find. Where is it? The url is .../staffintranet/Security/login, but I have no "Security" subfolder; looking in the sapphire folder, in the security folder, I see LoginForm, MemberLoginForm.php, MemberAuthenticator.php; I see "class MemberLoginForm extends LoginForm", but I'm not seeing anything that I can use to distinguish the login page from other pages. Can you clarify this?

Avatar
edk

Community Member, 39 Posts

6 February 2010 at 4:25pm

Hi Jseth,

You are getting into some pretty core stuff in there looking for the class. That is beyond my depth of understading in SS...but I can give you alternate solution. Because typcailly "Security" is always the URL for the login page, you could add a clause in the checkClass function which checks $URLSegment. In your case if $URLSegment is equal to 'Security' then don't display...you could also still use Classname for those pages you have more direct control over.

I saw you referenced a URL "/staffintranet/Security/login"...are you using a 2.4 beta? B/c I am not sure that would work in anything earlier. You see SS has a cool URL structure where the first segment in the URL is the Page and the next [optional] segments are actions and parameters. So in the case of Security/login...it is actually saying it is the "Security" page and call the action/function 'login'. If you check the _config.php file in the Sapphire folder you will see one of the first Director Rules it has is the Security URL...so it is doing some stuff from there that I am yet fully understand.

Sorry I could not be of more help, but I think the alternate soultion in paragraph 1 is somewhat viable.

-chango