Admin on wordpress went blank, why?

Have you looked for PHP errors?

Your host probably has a way to check the PHP error logs, it may be files on the server or they may have something in their admin panel. If there’s a problem with the files running, something will be there

If that’s not it, possibly permissions on the wp-admin folder? A fresh install should take care of permissions, but always good to double check and might be a different user depending on how you did the install.

well, I installed a previous version, 3.8.2, in a fresh new folder, but this time, I entirely deleted the database and created a new one. Installed and the same problem again. cookies. And I cheked the error log, it only marks the times when I mistype the url to a new install… Im seriously considering, as my dad said, ‘go grab an axe…’

Just try turning on debugging in wp-config.php

define( ‘WP_DEBUG’, true );

If that doesn’t give any info I would look into a .htaccess problem. I would at least make sure you at least have the base one installed. Here is what it is.

# 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]
</IfModule>
# END WordPress

nope. .htaccess file, as i said, makes no difference in this case.
And I tried debugging the first time, only to end up running in circles.

The only info I get when I hit wp-login.php is:
“Warning: Cannot modify header information – headers already sent by (output started at /home/seteadoc/public_html/museo/wp-config.php:1) in /home/seteadoc/public_html/museo/wp-login.php on line 415”

what I see here is complaining about line 1 in wp-config; believe me, there’s no spaces in that file, I checked and double-checked that. Besides, this is the fourth clean install. And then complains about line 415 in login, that refers to the blog info.

When I hit /wp-admin the error says:
“headers already sent by (output started at /home/seteadoc/public_html/museo/wp-config.php:1) in /home/seteadoc/public_html/museo/wp-includes/pluggable.php on line 896”

that refers to the header’s location. And please don’t say its because there’s blank spaces in the code, this is a fresh install, and I’ve been checking all those files above and none has spaces…

New line type or encoding for the config file maybe?

Have you tried just opening it in a basic editor (notepad/TextEdit) and doing your work there?

Edit to add: have you been through here How do I solve headers already sent

@funkdaddy that’s what I’ve been doing for years, for configurations always go for sure using notepad. I even opened wp-congif with the editor that CPanel has. Got me puzzled.
but the coding… I even checked the database, and everything looks fine. the database is utf8_general_ci, the wp-config is UTF-8 Unicode English text (as CPanel’s File Manager says) and I dont know where else to look…. and by the way, the site runs perfect on my local PC. Maybe I should try migrating the whole site as is and change only the database data as the first 20 times… again.. sighs

I always develop locally and then migrate to my online server, and only change the wp-config DB data and two records in the database, the ones pointing to the home in the options table, those have been my rule always and I never had any trouble.

@funkdaddy Its a fresh install! all the scenarios described in the solutions start from an already data populated blog, this is not the case.
By the way, I migrated my local WP to the online server, only to find the same result: blank admin.
So, I checked my local blog, deleting some suspicious plugins; suspicious like, the ones I don’t usually work with… truncated and then deleted the tables on the online database (just in case the record’s ID didn’t match… just making sure there), and uploaded the database, assuming this would cut any link to the deleted plugin files,... and the same result.
It seems I have to make all changes locally, and then upload the blog to my testing server, and when the blog is Ok, publish it to the final server and pray it works as it does on my local server…
About that, you may think its a configuration on my local server that messes with the online server, but I tried several times with fresh installs directly into the online server and migrating the actual blog from my PC; so again, I really don’t know what may be happening here. (a bad sector on the HDD in the online server?? wrath of the gods??)

Are you saying an install with no plugins and themes is a “fresh install”, or are you including those things?

If you’re including those things (even if they’re deactivated), then that’s the likely the problem. Literally just twentythirteen or one of those and nothing else should be on the server. Not the files, not the db tables, nothing.

If the bare install works, then just put them up one at at time until you have a problem.

If you’re not uploading any plugins/themes and not using a “one click install” or anything like that, I’d call/write my hosting company and have them hack on the server. If it’s your bare box, check all the version and requirements and make sure something like a PHP version isn’t keeping you from working.

@funkdaddy yes, a right-out-of the-wp-server install. Playing safe, the versions I tested (3.9.1, 3.8.2, 3,6) were downloaded directly from WP, unzipped and uploaded into a folder into the server, and activated online. So, I can’t deactivate the plugins and activate them one by one, because after installing, everything works ok, but when I hit wp-admin/ nothing happens.
The other sites I have on the server started from WP 3.6, and I’ve been upgrading them with no problem, to 3.9.1. Is this particular site that doesn’t want to work. So, if the other sites in the same server run 3.9.1, maybe its not a PHP version problem. The DB limit is set to 10, I only have 5; the PHP version running is 5.4.26, the MySql version is 5.1.73-cll.
So, write to the hosting company it is. I’ll keep this updated…

You can deactivate plugins/themes by renaming their folders via FTP. So I’d just rename the plugins directory “plugins-off” or something you won’t forget the purpose for. Same with all themes except one base theme.

If they’re not found, they just don’t work, wordpress should handle it cleanly without an error.

Guys, It seems I’ve found the solution! or at least, one solution: One guy in a forum said that a plugin was causing a glitch, the askimet plugin, so it had to be removed. I dont really know the value of that plugin, so I’ve deleted it. Maybe later I’ll install it again. But the real deal was that this guy had the problem days later, so he found out that the wp-admin.php file had different coding! how? I dont know… maybe the editor changed the coding when entering the database settings, I guess. So, It changed to UTF-8, if you change it back to ANSI It will all be ok.