macgeekgab

Ahh! That makes sense. Along those lines: any advice you’d offer, in general, about what to do (and what to have all contributors do), after updating plugins like this to ensure a lingering issue doesn’t hold itself over?

Ok, so… “time heals all wounds” — I can’t seen to get the error to re-appear now.

I’ll do more testing, of course, but… yeah, it seems fixed. Sorry about the false alarm!

• This reply was modified 5 years, 5 months ago by macgeekgab.

Thanks, @kevinfodness. I just tried it here and I get the same error, unfortunately.

It’s been a while since I looked at Apple’s guidelines, but when we migrated from RSS to “direct” publishing (via this plugin) I seem to remember there being a policy against just publishing a “teaser” like you both describe.

We updated our test server to 2.0.2 this morning and are seeing the same exact problem as @djosephdesign. Copy Error yields this:

parse@[native code]
value@https://[our-test-server].com/wp-content/plugins/publish-to-apple-news/build/pluginSidebar.js:1:32834
ce@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:98:142
Qg@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:144:219
Rg@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:145:78
Sc@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:158:111
Kc@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:155:18
ya@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:153:161
bh@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:160:257
https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:215:412
https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:164:142
$g@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:159:72
Wc@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:164:71
ao@https://[our-test-server].com/wp-includes/js/dist/edit-post.min.js:12:76423
ao@[native code]
value@https://[our-test-server].com/wp-includes/js/dist/editor.min.js:17:60961
value@[native code]
sh@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:164:415
rh@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:13:434
uh@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:13:488
Ge@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:15:160
vh@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:165:252
ad@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:15:447
cd@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:17:18
Uh@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:39:337
Zg@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:158:507
Xe@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:23:324
oc@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:40:306
unstable_runWithPriority@https://[our-test-server].com/wp-includes/js/dist/vendor/react.min.js:27:37
ah@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:159:178
xf@https://[our-test-server].com/wp-includes/js/dist/vendor/react-dom.min.js:40:47
xf@[native code]

Hi @vmarko @joe9663 — Sorry, I didn’t see the original notification last week. We migrated servers about 3 weeks ago, but in looking at the old logs on the old server, I _think_ this has been going on for a very long time and wasn’t introduced in a new update.

I’m happy to help troubleshoot more!

Thanks, @vmarko — I appreciate the help. How would I know which one is firing?

For years we’ve found that Jetpack’s Photon a.k.a. Site Accelerator breaks RSS on HTTPS sites because it adds URL variables to image tags, which is disallowed in RSS.

Is there a way to tell WordPress/Jetpack/Photon just to serve images directly in RSS?

I don’t think this is a race condition, given that we have this in our wp-config.php:

/** Disable WP Cron */
define('DISABLE_WP_CRON', true);

In theory that should mean that wp-cron isn’t being triggered by visitors to the site, right?

But, still, running with wget should work, no? Is there any way to look at a log and see why wp-cron fails?

Again, I’m just curious why it would fail even after WordPress *knows* it’s failed (back “why display Missed Schedule instead of just publishing?”).

Thanks, @jnashhawkins — That plug-in is pretty old, so I’m not sure it’s something we’d want to be integrating into our environment.

The weird part is that plugins like this even exist. I’m just not sure what WordPress is/isn’t doing to cause this problem to happen. Why would a command-line cron fail to trigger the very tasks that it’s supposed to trigger? Or have they already been put in “failed, never try again” state by the time that cronjob runs?

And, if so, why?

Anyone know?

Thanks, Steve! We are (currently) using Cloudflare, BUT… we also have our /etc/hosts file set to point at our server, not Cloudflare, for local requests. Command-line tests with curl confirm this is working, at least with curl. ??

And… this issue predates us starting to use Cloudflare a month ago. But yes, we are using W3TC for some additional caching.

We’ve had this cron job in place for years, with seemingly no impact:

# 2017-06-21 WordPress Manual Cron
*/3	*	*	*	*	wget -q -O - "https://www.[example].com/wp-cron.php?doing_wp_cron" > /dev/null 2>&1

I can certainly change that to yours, but it seems like we’re doing everything except setting =1 there. Would that potentially make the difference?

Thanks, @joe9663 — are you saying this is a bug in W3TC and I should look for an update? I’m not thinking a newline would cause this issue.

We have no other updates for our existing plugins, and especially nothing for the two that seem to point to this issue.

Great, thanks @ryanhungate! I’m assuming I just put that in wp-config.php, right?

Just want to make sure I’m not missing something obvious elsewhere! ??

@ryanhungate Thanks for the details on this. We’re finding that /wp-json/mailchimp-for-woocommerce/v1/queue/work is our *most* requested page, right at the top of our varnish lists. And, indeed, it beats on MySQL quite a bit. It’s not necessarily a current problem for us, but in the interest of efficiency I’d love to not have this happening hundreds of times per minute.

With that in mind, is it possible to disable this somehow and perhaps cron a call to that on a more reasonable schedule?

I had to manually create a log file (for a plugin) that was trying to be read but didn’t exist. Once I did that, then this failure ended.