Style sheet does not load for wp-admin

It seems to me that you have set something wrong on the server. Because the REST API is also not accessible. Since you have not yet set your permalinks to “Pretty”, this URL should actually lead to a result: /?rest_route= but instead you get the start page.

Under the URL you could see the siteURL and Home you have set. These should be identical for most installations. If not, they could also lead to such a problem. How you can also adjust the two entries is described here: https://developer.www.ads-software.com/advanced-administration/upgrade/migrating/#changing-the-site-url

Hi threadi,

It seems to me that you have set something wrong on the server. Because the REST API is also not accessible. Since you have not yet set your permalinks to “Pretty”, this URL should actually lead to a result: /?rest_route= but instead you get the start page.

Do you have any idea what might be wrong or how it got to be wrong or, more importantly, how I fix it?

Under the URL you could see the siteURL and Home you have set. These should be identical for most installations. If not, they could also lead to such a problem. How you can also adjust the two entries is described here: https://developer.www.ads-software.com/advanced-administration/upgrade/migrating/#changing-the-site-url

I had edited wp-config.php earlier today, before I posted my problem:

define('WP_HOME', 'https://wp.tryx.org');
define('WP_SITEURL', 'https://wp.tryx.org');

So, unless this is a misunderstanding of the instruction in the link you gave me, this in not a solution, but hang tough because I have a bunch of questions you might be able to answer:

• Did you look at the developer tools (<F12> on Firefox) analysis of the response to “https://wp.tryx.org/wp-admin&#8221;? Do you have any thoughts? How many of these problems would be explained by jQuery not being loaded?
• Can you advise why the site-editor tells me that javascript is required when Firefox tells me that javescript is enabled?
• Do you have any thoughts on the initial failure of the tool bar to appear?

Thanks for the help,

Chris.

In the meantime you have changed the permalinks to pretty links. They cannot be called up at all. Check whether the .htaccess file exists in the root directory and was created by WordPress. Also check whether the Apache module mod_rewrite is activated. Both are necessary for these URLs to work.

Your problems in the backend are only the result of something missing on the server. mod_rewrite would definitely be one aspect. Also check the permissions of your folders in the vhost.

Also check the error log from the server to see if any errors appear there, and if possible there should be nothing in the WordPress debug.log.

Hi threadi,

In the meantime you have changed the permalinks to pretty links. They cannot be called up at all.

Yes. You mentioned “Pretty” links, so I thought it was worth probing that area to see if it changed anything. It didn’t. The failure to see anything is more likely a collision with me and xdebug. Do you have any experience debugging WordPress with xdebug?

Check whether the .htaccess file exists in the root directory and was created by WordPress. … Also check the permissions of your folders in the vhost.

It is, but changing the Permalinks did expose one problem. WordPress likes to install into sub-directory “wordpress”, which works out well. Setting DocumentRoot makes a place above wordpress to store things like the .tar.gz I had file permissions correct:

• chown apache:apache -R wordpress
• chmod 755 for directories
• chmod 644 for files
• chcon -t httpd_sys_content_t for everything except wp-content
• chcon -t httpd_sys_rw_content_t for wp-content.

I had to change “wordpress” to httpd_sys_rw_content so .httaccess could be written. I did so, and found no difference. It was clearly a misconfiguration, although one of very little consequence, generally, and of no consequence for this particular problem.

Also check whether the Apache module mod_rewrite is activated.

Done. Is and was.

Also check the error log from the server to see if any errors appear there, and if possible there should be nothing in the WordPress debug.log.

Much to my disappointment, I have never been able to find anything in wp-content/debug.log despite my efforts:

• define( ‘WP_DEBUG’, true );
• define( ‘WP_DEBUG_LOG’, true );
• define( ‘WP_DEBUG_DISPLAY’, false );
• error_reporting(-1);

I really wish I could get this working, as a further step toward diagnosing the style-sheet problem.

So, all of this could be explained by jQuery failing to load. I want to set break point there and watch what happens.

Thanks for the help,

Chris.

I know xdebug, but I don’t even use it for plugin development. In my opinion, it is rather unsuitable for investigating server configuration problems.

WordPress does not want to be installed in a subdirectory. Just because the ZIP comes with it, you don’t have to do it.

In some cases when the backup would not load properly, this entry in the wp-config.php helped:

define('CONCATENATE_SCRIPTS', false );

Hi threadi,

I got distracted by who know what and I never tried your suggestion. I have since tried it and it works. It seems to me like there is a clear bug there somewhere.

As posted in the aborted and re-directed thread I did discover that setting SCRIPT_DEBUG true also corrected what ever this problem is, much to your surprise because semantically it should not do anything absent other configurations changes. Well, it does. So, it seems tome that there is clearly a bug around here somewhere.

Thanks for the help,

Chris.