Espi

no problem. Glad it helped.

have you tried to view the page from a different browser that is not logged into your site?

it appears that you have two different wordpress installs running on that domain. one is located at https://acfpittsburgh.org, and one is located at https://acfpittsburgh.org/wordpress.

Can you verify that you are trying to login to the correct wordpress install?

the one located at https://acfpittsburgh.org should be logged in at:
https://acfpittsburgh.org/wp-login.php

the one located at ttp://acfpittsburgh.org/wordpress should be logged in at:
https://acfpittsburgh.org/wordpress/wp-login.php

Could you go to the IP address of your old site? If you’re not sure where that is could you get that information from wherever it is being hosted?

I was able to resolve my issue. I found that I was having a jquery library conflict.

• This reply was modified 7 years, 10 months ago by Espi.

ok, I’ve discovered that the chat box is actually being created on the page, however it appears that the style switching that hides the original form and pops up the chatbox does not appear to be working.

Getting this same error.

I noticed that once I activated the curl mod in apache everything started working again for me.

I’m not sure about individual staff pages, but if you separate the people into different groups you could then just make a page and pull whichever group is appropriate for that page.

I’m actually working on adding an additional field for my personal use. I’ll let you know if I’m successful.

I recently had luck getting this plugin working again with the latest 1.11.2 plugin. I’m also using WordPress 4.7.2 and PHP7.

The reason It was not working was because I did not have the cURL mod enabled in PHP. Once I enabled that mod everything started working again.

I have made all the changes in the settings. Updated to php7, wp4.7.3. All of my links still show as broken with this plugin.

Other sites on the same server that have not been switched to HTTPS are not having this problem. The plugin is still working flawless on those sites.

this feature would be super helpful.

It should still continue to check those HTTP requests if you use one of the other APIs. the difference is that Youtubes API for example is checking both protocols where as the basic http API is only checking http.

I tested this by going through links on my site that are external http links and having them rechecked. they are still coming back as 200 OK

Greetings!

I ran across this same problem today when we made the switch to complete HTTPS on our site. I found a solution to our problem, and I hope it will also help you.

Since we are HTTPS everywhere and we no longer allow HTTP traffic. we actually just redirected over to HTTPS. by default this plugin uses a basic http API(I’m not actually sure what one) to check links. If you are switching to 100% https you’ll want to go disable that.

To disable that API you will go into the broken link checker settings > Protocols & APIs tab > uncheck the box that says Basic HTTP. Then his save.

This solved our problem and I hope it solves yours as well.

Thanks

Greetings!

I found a solution to our problem, and I hope it will also help you.

Since we are HTTPS everywhere and we no longer allow HTTP traffic. we actually just redirected over to HTTPS. by default this plugin uses a basic http API(I’m not actually sure what one) to check links. If you are switching to 100% https you’ll want to go disable that.

To disable that API you will go into the broken link checker settings > Protocols & APIs tab > uncheck the box that says Basic HTTP. Then his save.

This solved our problem and I hope it solves yours aswell.

Thanks