No Working Transports Found Error In WordPress


Terminating mvn spring-boot:run & tomcat from eclipse

I’ve been working on a project at work where we used JHipster to generate the barebones of the application and start right off with the development avoiding to go through all the configuration hassle of a regular web application.

Well, since we use Eclipse as the IDE and our project is configured to run using maven from within eclipse, I have noticed that when spring boot starts the embedded tomcat server and I terminate the mvn task by clicking on the terminate red button on the console view, the server container does not get killed and keeps running in the background, so if we run the mvn task again it’ll display something like this:

To solve this problem we will have to configure the spring-boot-maven-plugin in our pom.xml and add the fork optional parameter as follows (highlighted):

This way, according to the spring boot plugin documentation, the plugin does not fork another process to run the embedded tomcat and when the maven process get terminated, so does the tomcat server.

Make WordPress Core

Context Navigation

#11831 reopened defect (bug)

Warning when wp-cron fails


Running 3.0 alpha I sometimes get this warning just at the top of admin pages:

I didn’t notice it in WP reasonable_cron_request_timeout.diff​ ( 603 bytes ) – added by eliotsykes 9 years ago. Patch to give cron http request a reasonable timeout of 1 second rather than 0.01 secs wp-cron.php.patch​ ( 1.1 KB ) – added by Scott Herbert 5 years ago. Added custom error handler to provide more information to site admins

Download all attachments as: .zip

Change History (36)

#1 follow-up: ↓ 2 @ dd32
9 years ago

Thats suppressed if WP_DEBUG is not enabled

#2 in reply to: ↑ 1 @ nacin
9 years ago

Thats suppressed if WP_DEBUG is not enabled

E_NOTICE is supressed, but this looks like an E_WARNING.

#3 @ dd32
9 years ago

Sorry, Maybe i should’ve included a code reference πŸ™‚

The same happens for most other transports: ​ fsockopen, ​ fopen, ​ HTTP Extension

#4 @ nacin
9 years ago

Ahh, completely forgot about that. πŸ™‚ I should have remembered, I’ve patched those lines before.

#5 @ dd32
9 years ago

  • Milestone3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I’m thinking this is a wontfix, Developers need to be aware of failure messages, It shouldnt occur for regular users.

I’m closing as wontfix for that reason for now, If someone feels strongly against that reasoning, feel free to reopen.

#6 @ scribu
9 years ago

Forgot I had WP_DEBUG enabled. Sorry.

#7 @ harrym
9 years ago

  • Resolutionwontfix deleted
  • Status changed from closed to reopened

Well, hang on a minute. I agree it shouldn’t be supressed when WP_DEBUG is on, but that’s not really the point. Why’s it failing in the first place? Can’t we just fix it?

I also get this intermittently and it’s rather irritating. I’ve taken to doing echo "" > wp-cron.php just to make it shut up.

#8 @ holizz
9 years ago

  • Cctom@… added

#9 @ harrym
9 years ago

  • Ccharrym added

#10 @ nacin
9 years ago

Sometimes, HTTP requests fail. In this case, in particular, on localhost. That’s part of the reason why we suppress them.

I’ve personally never seen this. I think it’s isolated to this server configuration.

#11 @ cyberhobo
9 years ago

  • Cccyberhobo@… added

I believe I get this every time wp-cron.php is requested on my local XAMPP install. Usually I just reload whatever I’m looking at and the request isn’t repeated, but it would be nice to know the cause. I’ll post back if I find anything.

#12 @ eliotsykes
9 years ago

  • Cceliotsykes added
  • Version changed from 2.9.1 to 3.0

I get this too in WordPress 3.0-RC1 when running on localhost.

I can replicate it the error message consistently if I delete the cron options after every request by running this SQL:

delete from wp_options where option_name like ‘%cron%’;

My assumption is that doing this causes the cron function to be run on every request. It looks like these options suppress cron from running again for some time.

For me it was happening on line 1045 of class-http.php

I did some research and found that 2 common reasons fopen fails are:

  1. user-agent being the standard PHP one being blocked by web server. I tried a different user-agent, this did not fix the bug
  2. allow_url_fopen being set to false. It is true on my system so this is not the cause for me.

So I’m not sure where to go from here. Perhaps the test() function for WP_Http_Streams needs some extra tests?

#13 @ eliotsykes
9 years ago

Tried out a couple more things, narrowed it down to a problem with Streams.

In class-http.php, if I force WP_Http_Fopen to be used instead of WP_Http_Streams then the error message does not happen.

So the bug happens when fopen is called with a Streams context.

This boils down to the difference between these two lines:

I’m using PHP version 5.2.6-3 and allow_url_fopen is true. Apache version is 2.2.11.

So my guess is that the array options given to create the $context variable is causing problems. Perhaps playing with these options might yield some results for someone who has more experience with PHP streams, for now I’m going to live with this issue.

#14 @ eliotsykes
9 years ago

  • Keywordscronfopen added

Its the timeout.

It defaults to 0.01 seconds on line 234 of wp-includes/cron.php which seems very short.

In class-http.php the timeout default is 5 seconds.

So I increased the timeout to 1.0 seconds and this works fine for me now, no longer get the error message.

wp_remote_post( $cron_url, array(‘timeout’ => 1.0, ‘blocking’ => false, ‘sslverify’ => apply_filters(‘https_local_ssl_verify’, true)) );

I’ve got a patch and will submit it if I can figure out how to.

@ eliotsykes
9 years ago

  • Attachmentreasonable_cron_request_timeout.diff​ added

Patch to give cron http request a reasonable timeout of 1 second rather than 0.01 secs

#15 follow-up: ↓ 16 @ westi
9 years ago

The cron timeout is that short for a good reason.

We don’t care about whether or not the request completes we just want to kick it off and then carry on with the current page load.

If a transport can’t cope with sub 1 second timeouts then we should fix the http transport to have a low end cap (at least one does already I believe)

#16 in reply to: ↑ 15 @ nacin
9 years ago

If a transport can’t cope with sub 1 second timeouts then we should fix the http transport to have a low end cap (at least one does already I believe)

Yep, curl does because it can’t handle floats. See also #8923.

#17 @ hakre
8 years ago

If non-blocking calls could be used (when it’s possible to better check for), then the timeout could be extended a bit: #11613, #14786

#18 @ hakre
8 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Closing as of this discussion. If that’s not pleasing for someone, feel free to re-open.

#19 @ cyberhobo
8 years ago

p.s.: for me (XAMPP on Vista), enabling php_curl in php.ini made the warnings go away.

#20 @ scribu
8 years ago

I also found adding

to wp-config.php makes the notice go away.

#21 @ theozero
6 years ago

  • Keywords changed from cron, fopen to cron fopen

Was running into this problem on a new (ubuntu) server. The problem was php-curl was not installed (and enabled).
This may be the case if you set up a server from scratch and just forgot to include it.

My fix was " apt-get install php5-curl "

hopefully that helps someone else getting this error

#22 @ nico23
6 years ago

Thanks @theozero yes that helped me.

I can confirm this to be working on Ubuntu 12.04 and 13.04. CURL is not installed by default if you install the LAMP stack or just PHP. Usually you’ll need a sudo in front of this command.

"sudo apt-get install php5-curl"

#23 @ chriscct7
6 years ago

WP 3.6, CURL enabled for both Apache and PHP still getting these warnings. Running a WAMPServer stack. Scribu’s solution seems to work.

Leave a Reply

Your email address will not be published. Required fields are marked *