akshatjiwan

Sorry to hear that…Unfortunately I have no solution to offer. What has worked for me however is that I was able to back up my database and do a fresh install for wp. If you backup wp database and files downgrading might help….

Also have you managed to replicate the issues on a dev server? If nothing else it could give you an idea of where things are broken. On my fresh install at least I don’t have any issues related to admin user so its quite possible that the problem might be related to some plugin that you have.

BTW you can also delete plugins with the help of wp cli command line tool. Have you tired that? It can come in handy in times like this.

Best,
Akshat

Thanks for asking @edzuslv. The problem is not fixed for me on the production. I’ll report back if I see any fixes on the test setup I created. Is it fixed for you?

EDIT: I can confirm that the problem is also not fixed for the test deployment on 4.9.1

• This reply was modified 6 years, 11 months ago by akshatjiwan.
• This reply was modified 6 years, 11 months ago by akshatjiwan.

I can confirm that this issue occurs on a fresh wp install. It might be a bug. Can you guys please confirm this? Also do you think that this is an extension of the bug linked here or this should be a separate issue altogether?

Regarding the plugins. I had that problem as well. Didn’t report it here because I didn’t think that they were relevant to this issue. Also I managed to delete them manually using wp-cli. Right now I’m trying to set up a wp 4.9 container to see if I can replicate the issues on my dev machine.

But its good to know that I’m not the only one facing these problems ?? BTW have you tried to check if these issues persist in a fresh 4.9 install?

Thank you @joemcgill for the pointers!

Unfortunately I get no server errors. At least nothing is logged into my nginx error log files. The issue only happens on the grid view. The list view works fine for the most part but when I click on “attach image” link the resulting dialog window is empty. That is nothing actually happens. I get no list of posts to attach the image to.

I have inspected the network requests in my console and it seems that the server returns the results. The admin-ajax.php request successfully executes. I can see 200 Ok status code as well as the JSON data returned for all my images. But nothing is rendered on the screen and the spinner in the grid view keeps on spinning.

A similar problem occurs when I’m uploading images. The response from the UI is that image can’t be uploaded but the image is actually uploaded to the server.

Thanks @edzuslv for linking to the issue. But I’m not getting any error in the console. Are you also getting errors in the console?

I don’t see any images being loaded in my media library. Although when I switch to the table view I can see all the images.

Also there is no error in the console, no error in the logs. Another strange thing that is happening is that when I upload images the media player gives me an error even though the upload completes successfully.

Similarly when I delete the plugins the media player gives me more errors even though the plugin is deleted successfully.

Hi Vince

Apologies for the delayed response. The issue was with nginx configuration. To verify that I simply replaced my nginx configuration with Ashley Rich’s configuration on github and the problems disappeared. Although I didn’t try to debug what was wrong with the original configuration I have a couple of ideas on what might have went wrong. [Please note that they are just theories. I have not been able to test them successfully]

1. There is no need for proxying wrodpress when you are using nginx as the webserver. It needlessly complicates things. Not only you have to set appropriate headers to the proxy but also in wordpress configuration files. This is simple enough to do in practice but it makes it extremely hard to debug errors. The number of places where things can go wrong increases dramatically. With so many pieces you can’t really say where things are going wrong.

2. I was not clearing the cache when moving from one scheme to the other. It is quite possible that the session that the cache contained was invalid. Furthermore I had no idea how the proxy cache actually interacts with wordpress. What invalidates the cache? What adds new items to the cache? I could also not find any documentation that explained this well.

Anyway using a better configuration file has solved my issue. For any one else seeing this thread my recommendation would be to use configuration files that have been tested in a variety of situations rather than writing your own even if it is simple enough to do so.

Thanks once more for all your help!

Best,
Akshat

Thank you once more Vince! You’re right I’ll have to do some experimentation with multiple parameters in order to find out the root cause. But thank you for pointing me in the right direction. I’ve managed to recreate the “bug” on my dev server so making some of these changes has become a lot easier now that I don’t have to worry about permanently breaking anything on production. Its a start I guess ??

>what is the behavior when you try to load HTTPS without those lines present?

Well the behavior is exactly like you pointed out. I get infinite redirects when I go to wp_login.php page.

>Does that behavior change when you try to load interior links versus the home page, or when you try to log into wp-admin?

The home page and other blog posts work perfectly fine (except in the case when I don’t change all the urls in the database the browser blocks mixed content served over http) The issues that I’m talking about only occur when I try to login to access admin pages. And since I haven’t managed to get past the login screen I can’t really say what happens when the admin pages show up.

>What about point #3 in my earlier reply – have you tried loading the browser’s developer tools and watching the Network tab to view all HTTP/HTTPS requests and see any errors in the console? If so, what have you seen?

I tired your suggestion after typing my response previously and although there were no errors on the console I discovered something else that raised more questions. A lot of 302 responses were being returned. In the nginx configuration a proxy cache is being used. I’m not able to actually query the items in the cache but it might very well be possible that when I move from one scheme to the other the cached objects are returned and they somehow cause an error? So that is one more line to investigate.

Another idea that I have stumbled upon is to use wp rest api. I want to see how things change when I try to login using the api vs the on screen UI. Maybe I’ll uncover something new that will help me solve the main problem.

Looks like this one is going to take some time ?? But I’ll keep this thread open and update you on any new things I discover.

As a last resort there is always an option of changing the configuration files themselves. I’ve ashley rich’s nginx configuration files on github (https://github.com/A5hleyRich/wordpress-nginx) and they look quite good. I’ll try to see if the problem resolves itself with that configuration.

Once more thank you so much for your responses. It gave me ideas on how to attack the problem.

Thanks,
Akshat

Thank you Vince for the detailed reply! It was very helpful ??

I can say with certainty that points #1 and #2 are not causing this issue. Because the user exists in the database and my nginx configuration files are pointing to the same location in both the cases. BTW you can check out the nginx files on github if it helps(https://github.com/ellobd/wp-eb/tree/master/nginx)

I do have a couple of follow-ups on point #4

>The wp-config.php code appears to be fine at first glance, but it isn’t strictly necessary to make HTTPS work; it’s only there to force HTTP attempts to be loaded as HTTPS. Have you tried removing this code and testing HTTPS again specifically? (I assume you have to remove the code when you test HTTP and login successfully.)

Yes I have to change the configuration files during http and https tests. The real problem is that I’m unable to identify the true cause of this issue. These are the steps that I take when moving from one scheme to another

– I have to change configuration files (wordpress)
– I have to update the urls in the database

So these are the questions I have

1. Is there anything that I might be missing when moving from http to https? Perhaps setting a parameter somewhere that I could have forgotten?
2. You say that config code is not necessary but that has not been my observation. I can not make https code work at all if the following lines are not present

if (strpos($_SERVER[‘HTTP_X_FORWARDED_PROTO’], ‘https’) !== false)
$_SERVER[‘HTTPS’]=’on’;

Could it mean that there might be something wrong somewhere else?

Thanks,
Akshat

Many thanks Jacob for the reply! I have a followup. Lets say that I want to use a single html widget with assets in multiple places. On my sidebar, in my footer etc. In that case are the assets downloaded multiple times? I understand that en queuing the scripts and links is the best course of action but there is another use-case that I might need to handle. Should I still be en-queuing?

Best,
Akshat

Thanks @bcworkz. It seems that would be best way.

Thanks Jacob. I’ve written a few plugins for my wordpress site and thought that it would be a good idea to run it through the tests that the core wordpress devs have already created.

Even if I have to write a couple of additional tests I can probably build upon the framework that has already been created. As far as I understand there is a way that you can run tests individually as well. So in case I don’t want to run the whole test suite I can always pick the test cases to run. At least that is the intention.

What would be the best way to achieve my goal? Is there a better way to test custom wordpress setup?

Thanks,
Akshat

Thanks @amibe and @nnikolov for the links! I didn’t know about the must use plugins feature of wp and now that I can see lots of cases where an mu plugin would solve the issue.

I guess a good start would be to create a very small plugin using the hooks mentioned and put it in an mu directory?

Beyond Multisite looks sweet ?? I’ll keep it in mind.

Thank you @bcworkz for your response. I also asked this question on github and the reply I got there, along with your answer, gives me a clearer picture of what the library can do.

I also found out about wordpress node api which has built in support for authentication and can be used on the client side. Although you’d need to install the basic auth plugin on the server side.

Thanks,
Akshat