problem with login to admin page

[mus.aqeel]

i used to login to my admin page. everything was good.
after some time i can not login. the page is redirected to

http://site/admin/index.php?redirect=/admin/pages.php

i tried to login from another laptop. the login was successful.
then again i tried to login from my laptop. same problem.
then i tried to login from anonymous proxy server. login was successful.
GS 3.1.2
PHP 5.2.11.

What can be the problem?

[n00dles101]

try clearing your cache on your laptop and see if that fixes the problem.

[mus.aqeel]

i use google chrome.
i tried to clean everything. but it does not help.

[shawn_a]

And what happens on this page you redirect to?
Is it white ?

Or is this a login loop ?
Delete your cookie, it most certainly is the problem.

[mus.aqeel]

no, it is not white. it is login loop.

i deleted cookie from google chrome.
history->clear history
i selected everything. i cleared for all time.

it does not help.
should i use another way?

[MattiasM]

This happend to me too and I have no idea why

on my laptop everything works fine but on my other computer the loop keeps coming all the time..
I even tried to login simultaneously and the laptop works but the other loops...

Ive tried to clear all cookies and tried using different browsers with no luck..

Whats the problem!

[mus.aqeel]

after some time login works again. i do not why. i have not done more than i have wrote.
it seems than GS engine keeps somewhere something, which prevents from login. and this something is been cleared automatically after some time.
And i think the problem have occured because entrance was from different computers.

[MattiasM]

Ive solved it (i think anyway)

Its probably a space somewhere in the code.. probably inside a plugin or in the theme file..

Check the last row in each file after ?> <--is there a space here?


Some browsers/computers can handle the redirect with a space before the header is sent... but some can not handle that.. maybe thats why the problem appears and disappears without any changes!

Good luck spacehunting

[shawn_a]

are you using the multi user plugin ?

[mus.aqeel]

Some browsers/computers can handle the redirect with a space before the header is sent... but some can not handle that.. maybe thats why the problem appears and disappears without any changes!

i do not think so. because in my case everything same. laptop one, browser one.
sometimes work, sometimes not.

are you using the multi user plugin ?

if question for me
i do not use this plugin.
i am using following plugins:

faq
hitcount
i18n_base
i18n_common
i18n_navigation
i18n_search
theme_highlighter
dynpages

[gwcheck]

i can confirm putting a space behind the ?> at the last line of the gconfig.php makes it turn in to .../pages.php and no login.

[shawn_a]

It might not be a space but a BOM, byte order mark also.

I bet if you had debug on, you would see cannot modify headers, headers already sent errors.

I always forget this issue exists in php.

Let us know what version, so we can make sure this isnt in the svn and is something you edited or installed.

[Joel_MMCC]

Why do GetSimple code-only .php files even have “?>” PHP-block closing tags at the end in the first place!? Those’re not only not required, they’re actually strongly recommended against by the official PHP.net manual, and outright forbidden by the Zend PHP-code-formatting standards!

PHP code blocks must indeed begin with “<?php ”, but they only need to end with “?>” if and only if there is any HTML or other non-PHP code in the file following that PHP code block! If the .php file ends with a PHP code block, or, more importantly, if the entire .php file is nothing but a single PHP code block (as is generally the case for includes and other code modules), it really should not have “?>” at the end (or anywhere else, really, in the case of a single-PHP-block .php file)!

For the next release, you should go through and remove all “?>”s from the end of each and every .php file that currently has them at the end. All plugin writers need to do this as well. This will prevent such problems from happening in the future.

Anyway, I, too, am having this login problem. I’ve cleared all caches, removed the “?>” from the end of “gsconfig.php,” requested and received a new password, etc., and it still won’t let me in. It does not say that the login failed or password mismatch or some such. It simply re-displays the login screen with the same URL that everyone else here is seeing.

[shovenose]

Joel, thank you for sharing that. I didn't know that and it's quite interesting!

[sal]

A good practice with PHP in general is ommiting the closing PHP tag if it's the last line in a file. This prevents the possibility of any whitespace messing things up.

[Joel_MMCC]

Joel, thank you for sharing that. I didn't know that and it's quite interesting!

Be sure to click the two links that I included. They take you right to the relevant pages of the official PHP.net manual and Zend code-formatting standards, respectively.

While researching this, I came across a blog post from some guy railing about this, saying that eliminating the closing “?>” is just a “band-aid” to what the blogger claims is some underlying technical problem, and that doing so violates the basic coding philosophy of properly ending each coding block structure.

This blogger misses the point. While “<?php ” and “?>” may look like the beginning and ending of a coding block structure (similar to braces in C-based languages including PHP, “Sub / End Sub” etc. in BASIC-type languages, etc.), that is not what they actually are. They’re not part of any language (not even PHP nor HTML), let alone the beginning and ending of a structure in a langauge. They’re server processing flags! They’re simply instructions to the PHP processor itself!

• “<?php ” tells the PHP processor, “Everything that follows, up to either the next ‘?>’ (if any) or the EOF (End Of the File), whichever comes first, is for you, the PHP language interpreter. You are to process this as PHP source code. You are not to output any of it downstream to the HTTP server, nor output anything at all (other than error messages if php.ini settings are set to do so) unless the PHP code itself tells you to do so (e.g. via ‘echo …;’)
  
• “?>” tells the PHP processor, “Everything that follows, up to either the next ‘<?php’’ (if any) or the EOF, whichever comes first, is to be ignored by the PHP language processor and is intended for the downstream HTTP server (Apache or whatever) to be sent over the wire to the user’s browser. Simply pass it on as-is, as if this were an ordinary .html or .css* or whatever instead of a .php file.
  

Of course, the Apache and other servers are designed to send out the HTTP headers when they see the very first character of a requested .html file sent to them, even if that character is just a space or newline or any other whitespace of any kind! So, if you have the “?>” at the end of a .php file and anything at all follows that, whatever follows it will be passed on downstream to the HTTP server, and if it’s the first thing passed to it from that file, it will trigger the generation and transmission of HTTP headers!

Only if such a file is completely empty (immediate EOF or nothing at all) as seen by the HTTP server will the headers not be sent! A .php file that consists solely of a single PHP code block without an ending “?>” or that has one but with absolutely nothing after it (not even whitespace of any kind), and that does not itself output anything to the HTTP stream (no “echo …” nor any other such thing) will not output anything, and so will not trigger HTTP headers.

This is the way it’s supposed to work. It is not some underlying technical problem, nor a violation of coding structure philosophy, nor any other such thing.

* Yes, you can use PHP with .css files, as well as CSS <style> sheets within .html files! The file name does have to end with .php, but you can use “.css.php” to let you know what they are.

There have been several preprocessor language methods (less, etc.) for making CSS more into a programming language with variables, conditionals, loops, etc., but why bother with these when we have the power of PHP and are already using it anyway?

[wakh]

what are you talking about?
problems not in plugins, not in ?> tag
TS (and I) can't login from computer but can from other
if you have delvelopers in Moscow welcome to my computer to solve it

[Joel_MMCC]

Okay, I solved the problem on my end. I can now log in, and everything’s hunky-dory!

What I did was use a tool that lets me easily do global Find/Replace using Regular Expressions (RegEx). For the “Find” RegEx, I used “\n\s*\?>\s*$” and told it to Replace with “\n”.

For those who don’t know RegEx syntax and want to know what that means:

• “\n” = line feed, the Unix line-separating character for text files, including .html and .php files (normally “^” would be used for “beginning of line,” but I’m doing the RegEx in full-file mode, not per-line mode, so “^” would only match the beginning of the whole file)
  
• “\s” = any single white-space character (space, tab, line feed, etc.), followed by “*” which means “the preceding character or other RegEx entity repeated zero or more times, so the combination “\s*” means “zero or more white-space characters (any combination of zero or more spaces, tabs, and/or line feeds, etc.)
  
• “\?” = since “?” is a RegEx syntax character itself (it means “repeat the previous character or other entity zero or one times” which you can think of as “the preceding character may or may not be there, but if so, would only be there once”), if we really want to search for a question mark as itself, we have to “escape” it with a backslash
  
• “>” = just the right angle bracket (HTML closing tag-closing) character itself — need not be “escaped” — together with the previous, this forms the “?>” that we’re trying to eliminate at the ends of .php files
  
• “\s*” = as before, means zero or more white-space characters
  
• “$” = when RegEx is in line mode, this refers to the end of the line, but since we’re using full-file mode, it means the end of the file.
  

So, we’re telling it to Find all files where the last line of the file that does not itself consist entirely of white-space characters does consist of zero or more white-space characters followed by “?>” followed by zero or more white-space characters followed by the end of the file itself. All of that last line is to be selected for replacement.

The Replace of “\n” simply means to replace all of that selected stuff with a single Unix line-ending, an ordinary line feed character (for Windows servers, you’d use “\r\n” instead to do a carriage return followed by a line feed).

In short, it completely erases the last non-blank line if and only if it contains only “?>” with or without white space before and/or after the “?>” and replaces it with a single completely blank line (not even a space) at the end of the file.

When I did this today on Version 3.1.2 with a few useful Plugins installed, I found only one file in the 3.1.2 “core” that actually had some white space after the “?>” (which is what can cause problems by forcing the transmission of HTTP headers into a new HTTP Response prematurely): ironically enough, it was “admin/template/error_checking.php” (at line 87). There had been lots more than that in the previous version I was using, namely, 3.1B.

In the Plugins that we use, there were two more files that had white space after the “?>”:

• plugins/DM_contactable/mail.php (line 26)
  
• plugins/user-management/ckeditor.php (this one ended [at line 40] in an empty “<?php
  ?>” code block, with white space after the “?>”, so I deleted the entire empty and useless code block — it has actual HTML in it, mainly a “<script>” tag section.
  

Of course, there are other Plugins that I did not check. But at the very least, edit those files and remove all white space after the “?>”.

Better yet, use the RegEx above (with a Find/Replace that allows you to preview each change before actually changing it, just in case) to find and replace <em>all</em> “?>” that occur at the ends of .php files, whether or not there is white space after or even before them. They’re not needed for reasons I gave above, and their presence makes it all too easy that in some subsequent edit white space could accidentally wind up after them, triggering false HTTP Responses.

I highly recommend that GetSimple release a Version 3.1.2a or 3.1.3 that has all file-terminating “?>” removed from all files in core. All plugin developers should be notified to do likewise, and, like the Zend people, you may want to make it an official coding standard for GetSimple plugins that no .PHP files can end in “?>” (especially not with white space following, but preferably not at all).