-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cron jobs don't work, either can modify files. Internal networking problem #8
Comments
@macr1408 - Some ideas. Not knowing your full topology, there could be a couple things to look at. Where is cron running?
Are your ports open to the world, or are they internal to the docker network only?
Will update this issue as I think of other things, but a more thorough description of your topology would be useful. |
@mjstealey Thanks for your reply. The wordpress site is running inside the wordpress container. I'm not using anything outside Docker, I just downloaded this repo and started using wordpress with No, I'm not remapping the ports. As far as I know, they are internal to the docker network only. This is what I get from
This is my
And this is the
|
@macr1408 - Okay, figured out what is going on, and it is not what I suggested earlier. Basically the WP-Crontrol plugin is using general settings values to do it's probe, and in docker we're confusing it's notion of what is running where. I can provide an example using macOS Docker values (reference) which would need to be modified to fit your environment.
You'll notice that your site has also change from http://127.0.0.1 to http://docker.for.mac.localhost Here is why - Your site is exposed to the "world" from the nginx container's port 80, not the wordpress container's port 80. Wordpress is actually running on port 9000 using a different protocol. So, in order for WP Crontrol to work, it needs to "speak to" port 80 on the nginx container which is mapped to port 80 of the host, so if we interact with port 80 of the host (docker.for.mac.localhost:80) then things should work. If you were deploying this onto a host that had a DNS resolvable fully qualified domain name (FQDN), this wouldn't be an issue as the setting for Wordpress Address (URL) and Site Address (URL) would be that FQDN. |
Thanks a lot! for the solution and for teaching. I'm using Linux so I had to use http://172.17.0.1 instead http://docker.for.mac.localhost Cron jobs work perfectly fine now. Plugins/Theme editor still doesn't work, but I can edit those directly from my machine, so I don't care about that. Thanks again @mjstealey :) |
I was having a similar problem with all my cron jobs/scheduled tasks not running in a production environment. I wrote to UpdraftPlus about this and they provided an answer that perfectly works: "Could you try adding the following line of code to your wp-config.php file (above the ‘stop editing’ line): This will enable the alternative WordPress Cron system. This is designed to allow scheduled tasks to be processed when the main WP Cron is not able to run." For context, see ticket: Thought I would post this as everything else that @mjstealey has configured and documented works great - thanks so much for this work! |
For those who are using Docker Desktop on linux:
|
I'm having a problem, my Wordpress site cannot connect to itself when using cron jobs. I'm using the plugin WP Crontrol to test it, and the post call to my own site doesn't work. I get this error:
cURL error 7: Failed to connect to 127.0.0.1 port 80: Connection refused
And the same error occurs with port 447 when I'm using SSL (self-signed).
I found this solution and it worked the first time I tried it, but later I deleted my containers, re deployed them and I can't get it working again, I guess i'm editing the host file incorrectly (inside the nginx container), I don't understand what does that solution do exactly and how it should be applied.
Also, I cannot edit files from the theme/plugin editor, It says that the site couldn't connect and I should upload the files using SFTP. Again, the site cannot connect to itself.
I'm using the default compose.yml, no changes applied.
The text was updated successfully, but these errors were encountered: