Jason Wong

Tried it. But sadly after logging in, the user is automatically directly to ‘wp-admin’.
Not sure what is causing this to happen. Any ideas?

The new release of v2.0.3 has fixed the problem, permanently. Thank you very much.

Beautiful … Just Perfecto =)

On the contrary, the “nginx” webserver ISN’T the cause of this problem. Apparently, as far as I noticed, the wp-config.php file DIDN’T end with a PHP closure, i.e. “?>”, which could have resulted in a HACK.

I’ve closed the wp-config.php file with “?>”, and added a security level listed in .htaccess (see, https://www.wpsecuritylock.com/wordpress-security-tip-how-to-protect-the-wp-config-php-file/).

As for the “Warning: Cannot modify header information …”, in my case, WP had a conflict with one of the cached files in my web-hosting ‘tmp’ folder. That was immediately resolved by clearing out those unwanted cached files.

I’m feeling relieved that these are sorted. New problems = New solutions = New experiences learned

=)

Hi esmi,

I doubt it’s a hack. Instead, I suspect that my hosting provider has installed the “nginx” webserver recently, which resulted in this. The strange thing is that some of my clients’ website aren’t affected.

Would you have any other guesses to this issue?

Cheers,
Jason

p.s.: By the way, I notice that one of my client’s website wp-config.php often has an ‘insertion’ of base64 codes at the beginning of the file. Removing it solved the problem.

p.p.s.: I’m puzzled if wp-config.php ends with “?>” or not. My guess without “?>”, hacks might occur. Correct me if I’m wrong =)

Hi Peter,

Curious …
I wonder if the following lines of code in my website’s .htaccess file could be the cause of this problem:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteCond %{REQUEST_URI} !/under_construction.jpg$
RewriteCond %{REMOTE_ADDR} !^124\.13\.3\.142
RewriteRule $ /maintenance.html [R=302,L]
</IfModule>

# END WordPress

# Protect WP-Config.php
<files wp-config.php>
order allow,deny
deny from all
</files>

# Disable directory browsing
Options All -Indexes

# Protect .htaccess file
<files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</files>

Kindly give your comments =)

Hi esmi,

Thanks for the link. Apparently I found that my website’s wp-config.php had a lengthy base64 codes at the top, and I removed it completely after referring to the link’s information and cross-referencing with other of my websites’ wp-config.php. Strange that this occurred. I’m puzzled …

Unfortunately, this solution still doesn’t work, whenever I key-in a ‘www’ versus a ‘non-www’ domain name =(

The ‘www’ and ‘non-www’ domain name has resulted in the following error:

403 Forbidden
nginx
—–

Warning: Cannot modify header information – headers already sent by (output started at /tmp/.f13da4b0a6b796bcdb7a2e6c84830d83:8) in /home/cosmospa/public_html/wp-includes/pluggable.php on line 890

Please advise on how to resolve this ‘glitch’ soon. Thank you in advance.

Unfortunately, the 403 error with nginx kept popping up, and blamed the pluggable.php in the wp-includes folder.

I noticed that this happens whenever between the ‘www’ and ‘non-www’ domain names. Not sure why this happening? Please advise.

Cheers,
Jason

Using the latest WP 3.0.4.

Hi Lee,

‘transaction_result_functions.php’ isn’t used in showing the details in sales-logs. I’m unsure if there’s any relation to the variables in sales-logs. Anyway, ‘/wpsc-admin/display-sales-logs.php’ is the one being used.

As for ‘wpsc-admin/ajax-and-init.php’ contains previous functions (now remarked out) that might be irrelevant. Anyhow, looking back at ‘transaction_result_functions.php’, will it be right to force the chosen region’s value to, say, the shippingstate variable?

I’ve tried the getshopped forums, but to no luck =(

You’ve a point there. Thanks for the advice =)

It’ll be best to incorporate the “time based” failed attempt reset with a successful attempt. For example, 3 attempts are given and the first 2 attempts failed but the last attempt succeeded, which should reset the number of failed attempts to zero.

I hope that this could be included in the next release. We’re only human, and mistakes are bound to happen whenever we type in our passwords …

Cheers,
Jason

Hi pabile,

Thanks for responding. It’s good that brought up that question. Apparently, it’s the theme that I’m using (besides the TwentyTen default theme of WP 3.0) with WP e-Commerce, which comprises of multiple sidebar configurations. It’s rather confusing to say the least.

I hope to discuss this issue with the theme developer, so as to generalise (or rather standardise) the sidebar configuration for both WP and plugin widgets (WP e-Commerce included).

Cheers,
Jason

Perhaps there’s another half of the solution to this incomplete problem. I found the following link that might do the trick.

https://www.redips.net/firefox/disable-image-dragging/

Hope that this can be integrated into the next update, soon.

It lacked another feature in dealing with Private pages. I hope that the next release would allow Private pages to be added into the nav menu, and smart enough to know when to hide (for non-login users) and show (for login users).

Try using the User Role Editor plugin. It works for WP 3.0.