Error from async-upload.php – redirect 302 – with SSL enabled

Not the part I was referring to earlier, to be honest.

I tried visiting my local site with /wp-admin/async-upload.php apended and it gave me “Are you sure you want to do this?” once I had logged in, so it’s definitely not something that should be visited directly.

At this point, I’m curious if this ajax upload abilities is something that Realocation set up and it happened to use CMB2 to help collect information. Is this the theme in question? https://themeforest.net/item/realocation-modern-real-estate-wordpress-theme/7605274 Curious if the latest version may have helped fix some issues as well.

Any changes to this one @bohemme ?

I’m afraid not. I gave up trying to use SSL in my client’s site. My client seems to be ok with that, so I won’t try anything more unless I’m told so, or have another chance to try again, though I must admit that I’ve only used a SSL site this time.

Hi!

I have the same problem, I can upload photo when my domain is https:// but y can’t upload when using https://.

Any idea?

Thank you so much!!

No changes that I’m aware of on this one, and I haven’t stumbled onto anything since.

Are you experiencing the same 302 error messages?

Yes, is the same error, In the console I get the error 302 in the file async-upload.php, if I use http: no problem, and if I pass from dashboard to frond end it works…. it’s a very rare thing.

Not sure what to advise in this case, as it definitely feels like it’s an issue coming from the server config, more than CMB2 itself, I just don’t have an answer to say “go check on X, Y, and Z” things.

Hi!

I already found the problem, the problem was not of the plugin CMB2, the problem was: when the client logging from the frond-end not generated the cookie wordpress_login_in ….

If the login is from back-end, (wp-login) there was no problem, finally I fixed the frond-end login and everything worked great.

Thanks for your time.

• This reply was modified 7 years, 11 months ago by vicentemanzano84.

Bohemme perhaps a similar situation for you?

I don’t think so. I think it has definetively something to do with user privileges. If the logged user is an “admin”, there’s no problem at all (nor that I recall). But if the user is a “subscriber”, the same error happened. I don’t have the time to try newer updates, and my client gave up on using ssl, so maybe in a near future I’ll give it a try.
@vicentemanzano84 could make it work because he was identifying (as admin, I guess) so it’s the same case than me.

Just checking, thanks for the swift response bohemme ??

I tried as admin and as subcriber and both ways works well. In my case it was the evil cookie!

Now it works with SSL or without SSL as administrator or as a subscriber.

Mmmm, that looks promising. But I had my users to be logged via back-end login (though customized).
Maybe something has changed since last summer as my development is now severals months old.

I definitely will give that a try. Regards Vicente! (from Spain too? I’m from Madrid) ??
And thanks to Michael for his great work.

I was having same problem see below my fix

• This reply was modified 7 years, 11 months ago by asif132.

I was having same problem

the issue was in my front end login function

wp_signon( $login_data, false);
$secure_cookie by default is none.

I set that to true and it worked great.

wp_signon( $login_data, true);