18 pointsStarting to get into this DEV thingI'm new here
gfors
Member
—
10th October 2011 09:25
Hi,
Using Autoblog 3.5.7 on a WP Network 3.2.1.
I can add feeds correctly, and everything gets saved as it should (including schedule). The next scheduled date appears in the "Next check" column, but that date just passes without any update.
Nothing gets updated automatically.
Would really appreciate some help with this, thanks!
I can add feeds correctly, and everything gets saved as it should (including schedule). The next scheduled date appears in the "Next check" column, but that date just passes without any update.
Nothing gets updated automatically.
Would really appreciate some help with this, thanks!
We have an update coming for this today - but in the meantime - are you on a single or multi-site install? What settings do you have in the autoblog configuration file? It's in autoblogincludes/includes/config.php
<?php
// Ensure you keep a backup of this file once you have it set up - in case it is replaced by a plugin upgrade.
// Uses a global table so that all entries can be managed by the network admin as well
if(!defined('AUTOBLOG_GLOBAL')) define( 'AUTOBLOG_GLOBAL', true );
// Processing will stop after 3 seconds (default) so as not to overload your server
if(!defined('AUTOBLOG_PROCESSING_TIMELIMIT')) define( 'AUTOBLOG_PROCESSING_TIMELIMIT', 6);
// Processing will take place every 30 minutes.
if(!defined('AUTOBLOG_PROCESSING_CHECKLIMIT')) define( 'AUTOBLOG_PROCESSING_CHECKLIMIT', 10);
// In a multisite install will attempt to process feeds for all sites rather than just local ones
if(!defined('AUTOBLOG_FORCE_PROCESS_ALL')) define( 'AUTOBLOG_FORCE_PROCESS_ALL', false);
// Will check for feeds to process on every page load rather than using the limit defined above
if(!defined('AUTOBLOG_PROCESS_EVERY_PAGE_LOAD')) define( 'AUTOBLOG_PROCESS_EVERY_PAGE_LOAD', false);
?>
Sorry to chime in.. i'm sensitive to these sorts of issues.. You mentioned "We have an update coming for this today -" .. okay what exactly does that mean?
What are you fixing? is this a scheduling fix for the new version of WordPress with AutoBlog? When will this be out?
The only way to update feeds is still to manually press update for each one (it's not even possible to select them all and update manually at the same time).
Is there any information I could supply you with that would help you guys narrow down the problem any quicker?
I could not get the automatic update to trigger either. Also, interestingly I noted that there is something funny going on with the scheduled times reported on the feed listing. It appears that the time stamp listed is +3 hours off what it should be. I believe the actual time stamps are stored in unix time. As I am on GMT +3 time zone it kind of looked like the conversion to my local time was somehow applied twice. Server clock is GMT and what I saw was not GMT+3 but GMT+6.
And then, just pure speculation, but it could be that the cron job tries to make use of some wordpress function that is not available on the public side and with error checking turned off it could fail silently. This would explain why the manual feed processing works from the admin panel, but nothing happens when wp-cron runs it after a page load on the public side.
Seriously guys, this is a real problem which is causing a lot of trouble at the moment. And it sound like I'm not the only one juding by the other threads in this forum.
I have another identical server which has an older version (3.4.x) installed which works perfectly. I tried uninstalling 3.6 on the current server and installing the older version that works on the other server, still nothing.
I'm guessing it must be something in the settings, since all the settings where kept even though I uninstalled the plugin. All the settings and feeds where still there when I installed the older version of the plugin.
I tried adding a new feed with the older version installed and it still doesn't work.
I had the same issue until I went to the config file in autoblogincludes / includes / config.php and changed AUTOBLOG_FORCE_PROCESS_ALL to true ... might be worth a shot... some of us were stuck for a month or so manually processing until that config option was added .....
Regarding times being off, we've experienced the same issue and have brought it up multiple time with no resolution unfortunately.
Tried the AUTOBLOG_FORCE_PROCESS_ALL, does nothing.
Can you set AUTOBLOG_PROCESS_EVERY_PAGE_LOAD to true as well and see of that helps?
Note: If that doesn't do anything then it's something else that has gone wrong here and we'll have to do a bit more digging to find out.
Also, if you activate the autoblog addon called repair autoblog, and run the repair then that might give it a kick and get it started again.
If I look in under the Autoblog menu in ny "network admin" panel, there is no add-on submenu. If I log in to one of the sites in the network, there is an add-on submenu, but it's empty. Not a single thing regarding any add-on at all.
But apart from the add-on thing, I found what might be causing the problem in the logs.
I'm getting a "Call to undefined function wp_create_category" on line 429 of autoblogprocess.php. So this should be related to me having the settings that the feeds should create categories for the ones that aren't already there?
Ok, it sounds like you have a partially updated / installed autoblog there.
Can you grab the latest version and FTP it up to your server, make sure your FTP client is set to overwrite any existing files (alternatively remove the existing autoblog directory from the plugins directory and then upload the new one in its place).
Do they process if you click the feeds individual process buttons? We've had reports of the bulk process buttons not working on some sites, and I'm currently investigating this.
I am still not able to get feeds to process according to the schedule ever since the last update, it was working correctly before that.
I've tried all the suggestions in this thread installing/reinstalling, making the modifications to the config file that were suggested, wp_cron is otherwise working correctly.
Is there anything else that I can try before abandoning the plugin and looking for another solution.
@JaniceH0125 - I note you haven't posted before, so in order to help the best we can, can you let us know the versions of WP and Autoblog - also can you let us know some details about your feeds (screenshots of the edit pages) and your autoblog config file.
It's a facebook feed, things were working until the last plugin update.
Hi, is it a facebook feed that you need to be logged into facebook to get? What was the previous version you were running, so I can work out the differences?
New install, autoblog 3.6.2. WP single site, 3.3. WP cron works fine for other stuff, but autoblog is MANUALblog. manually doing it works fine, but auto is a non starter, the date/time just passes and appears in red then - but it doesn't do anything. I don't know why this was marked as resolved, as there's lots of people experiencing this issue, and I can;t see any posting of an explanation of why this was happening. I think it also needs a real cron option so people who can't solve this can at least use it. I'm regretting spending the money.
Can you let me know what settings are in your config file? Also is the feed a main blog one, or a sub-blog? If the date goes red and it still doesn't process then there is definitely something up with your set up.
I just set it up on the front side gui like most plugins and didn't mess with the config file at all.
It's WP 3.3, single site mode, Autoblog 3.6.2.
I just added a test feed off yahoo (http://news.search.yahoo.com/news/rss?p=news&ei=UTF-8), set the time to 30 min. when i saved, first processed was null as expected, but the next check field was in red before anything, manual or automatic happened, and displayed a datestamp that didnt correlate with any timezone I use, and was in the past by a few hours.
I did a manual process and it worked fine. I'll know in 30 min what happens with automatic (though I'm not sure how it will handle automatic given it set itself for next check a few hours in the past, one hour west of california). I'll view some pages to kick wp_cron and watch the error logs (debug is on), but so far nothing in logs.
The blog is on pacific time (us), the server is on us central time. date is correct on command line, and server epoch the timestamps correctly correspond to gmt.
I'm starting to suspect time may be a possible reason.
<?php
// Ensure you keep a backup of this file once you have it set up - in case it is replaced by a plugin upgrade.
// Uses a global table so that all entries can be managed by the network admin as well
if(!defined('AUTOBLOG_GLOBAL')) define( 'AUTOBLOG_GLOBAL', true );
// Processing will stop after 3 seconds (default) so as not to overload your server
if(!defined('AUTOBLOG_PROCESSING_TIMELIMIT')) define( 'AUTOBLOG_PROCESSING_TIMELIMIT', 6);
// Processing will take place every 30 minutes.
if(!defined('AUTOBLOG_PROCESSING_CHECKLIMIT')) define( 'AUTOBLOG_PROCESSING_CHECKLIMIT', 10);
// In a multisite install will attempt to process feeds for all sites rather than just local ones
if(!defined('AUTOBLOG_FORCE_PROCESS_ALL')) define( 'AUTOBLOG_FORCE_PROCESS_ALL', false);
// Will check for feeds to process on every page load rather than using the limit defined above
if(!defined('AUTOBLOG_PROCESS_EVERY_PAGE_LOAD')) define( 'AUTOBLOG_PROCESS_EVERY_PAGE_LOAD', false);
// Uses a different, more processing intensive, method of adding tags to a post for sites that have tag based issues
if(!defined('AUTOBLOG_HANDLE_FAKE_TAGS')) define( 'AUTOBLOG_HANDLE_FAKE_TAGS', true);
// To see feeds from older versions of the plugin that have yet to be repaired.
if(!defined('AUTOBLOG_LAZY_ID')) define( 'AUTOBLOG_LAZY_ID', true);
?>
hmm server seemed to be on summer time (winter in the states), fixing and checking if that was an issue.
nothing yet in log files. going to check suhosin's separate log in a min, it can snare any insecure code in a way that doesnt make it to regular error_log
i can see wpcron firing in access logs.
Update - error_log and suhosin logs are clear.
Update: added a bunch more test feeds, will check logs in 30 min. debug on.
ok it's had the 30 min. WP cron is firing and showing up in the access logs, but it is not getting autoblog to fire. Nothing showing in the error logs in debug mode.
WP cron is firing and showing up in the access logs
Autoblog doesn't use WP cron.
Can you try setting AUTOBLOG_FORCE_PROCESS_ALL to true and see if that helps.
Note: your site needs traffic in order for the autoblog process to import, so if it doesn't have any then your need to visit it every now and then for testing.
I'll try AUTOBLOG_FORCE_PROCESS_ALL to test and post results here later on, but force wouldn't be an option for normal use as it would be a load hog.
If autoblog isn't using WP's internal psuedo cron, what does it use? I'm wondering whatever hook it uses to get at website viewers viewing pages may not necessarily then work with all themes then?
I was hitting the site hard to generate traffic to kick lose whatever process was being used to fire it. It did fire WP-cron
I'll try AUTOBLOG_FORCE_PROCESS_ALL to test and post results here later on, but force wouldn't be an option for normal use as it would be a load hog.
No - that would only be the case on a multi-site system, but as you are on a single site system it won't have any load issues.
If autoblog isn't using WP's internal psuedo cron, what does it use? I'm wondering whatever hook it uses to get at website viewers viewing pages may not necessarily then work with all themes then?
It hooks into the init action so that it will work when wp cron is disabled.
Found something. I'd been looking in the error log for php notices from the script, nada there - but I just found autoblog_log_* in the wp_options table.
here's 2 examples
a:2:{s:9:"timestamp";i:1325010077;s:3:"log";a:1:{i:0;s:51:"Notice: Processing stopped due to 6 second timeout.";}}
a:2:{s:9:"timestamp";i:1325007421;s:3:"log";a:1:{i:0;s:51:"Notice: Processing stopped due to 6 second timeout.";}}
Thats odd as this is a pretty powerful dedicated server of mine, running at very low load figures under 0.05 most of the time. and with 2 x 100mbps available.
Also, when I manually fire a feed it completes almost instantly, so i'm really unsure what is going on that could cause a timeout for automated, but not manual runs.
php version 5.3.8
php local
max_execution_time 18000
memory_limit 256M
max_input_time 60
mysql 5.5.17
I also have allocated loads of memory and high limits to php as I don't have any untrusted users.
I'm going to crank the 6 second limit, and see what that does. If it were both manual and auto taking >6s I'd next turn my attention to bind dns resolution for the feed domain, but as I said firing manually is consistently less than one second, even when i pick a feed with a lot of results.
I just tested on a different domain, same server - firing manually is close to instantanteous, but a feed due a run that is in red, with debug switched on wouldn't fire and either deliver posts, or put something in autoblog_log_ . I just don't think init is talking to autoblog. (i'd upped the timeout in config.php to 30)
I just did an extremely aggressive load test by setting up 20 subdomains, a test feed on each, with a unique wp install on each, then i did a windows batch script to open 20 firefox windows directly to the script firing url (same for all except domain). http://sub.domain.tld/wp-admin/admin.php?page=autoblog_admin&process=1&_wpnonce=aUniqueAlphaNumString at the same time i had Top running when all 20 feeds were fired simultaneously (all within about a 10th of a second of each other i think). mysql only made it up half way, server loads soared briefly to 4 or so, but all feeds appeared done within 2 seconds - so definitely not a load issue, and this load included postings, and reruns of xml sitemap.
a:2:{s:9:"timestamp";i:1325116626;s:3:"log";a:1:{i:0;s:52:"Notice: Processing stopped due to 30 second timeout.";}}
appeared well under 30 seconds of me switching the time setting on a stuck feed (I edited the frequency and immediately hit the front end site.)
Definitely some bug or incompatibility that prevents it working on my installation. Anyway I think at this stage its find a way to cron it or a different product.
Responses (48)
Sales & Support Pro — 10th October 2011 13:34 #
Hiya!
Do you have any issues with scheduling posts too? I suspect the problem isn't with Autoblog but with WP-Cron instead.
Try scheduling a post and see if that publishes on time. If not, it's a WP-Cron issue.
Phil
Member — 12th October 2011 12:25 #
Works fine for regular post scheduling. I'ts just Autoblog.
Developer — 12th October 2011 12:35 #
We have an update coming for this today - but in the meantime - are you on a single or multi-site install? What settings do you have in the autoblog configuration file? It's in autoblogincludes/includes/config.php
Member — 12th October 2011 12:36 #
Multisite.
Member — 13th October 2011 01:11 #
Hi,
Sorry to chime in.. i'm sensitive to these sorts of issues.. You mentioned "We have an update coming for this today -" .. okay what exactly does that mean?
What are you fixing? is this a scheduling fix for the new version of WordPress with AutoBlog? When will this be out?
Regards,
...
WPMU DEV Fanatic — 17th October 2011 03:52 #
Hi wpmublog,
You can actually see the changelog and what all was involved with that update right at the following:
http://premium.wpmudev.org/project/autoblog/download
And that latest version should sort any issues you were experiencing here. Could you both let us know how that works for you?
Thanks,
David
Member — 17th October 2011 11:25 #
The update did nothing I'm afraid.
The only way to update feeds is still to manually press update for each one (it's not even possible to select them all and update manually at the same time).
Is there any information I could supply you with that would help you guys narrow down the problem any quicker?
Member — 18th October 2011 16:01 #
I could not get the automatic update to trigger either. Also, interestingly I noted that there is something funny going on with the scheduled times reported on the feed listing. It appears that the time stamp listed is +3 hours off what it should be. I believe the actual time stamps are stored in unix time. As I am on GMT +3 time zone it kind of looked like the conversion to my local time was somehow applied twice. Server clock is GMT and what I saw was not GMT+3 but GMT+6.
And then, just pure speculation, but it could be that the cron job tries to make use of some wordpress function that is not available on the public side and with error checking turned off it could fail silently. This would explain why the manual feed processing works from the admin panel, but nothing happens when wp-cron runs it after a page load on the public side.
Member — 19th October 2011 07:36 #
Seriously guys, this is a real problem which is causing a lot of trouble at the moment. And it sound like I'm not the only one juding by the other threads in this forum.
I have another identical server which has an older version (3.4.x) installed which works perfectly. I tried uninstalling 3.6 on the current server and installing the older version that works on the other server, still nothing.
I'm guessing it must be something in the settings, since all the settings where kept even though I uninstalled the plugin. All the settings and feeds where still there when I installed the older version of the plugin.
I tried adding a new feed with the older version installed and it still doesn't work.
Something is clearly broken.
Member — 19th October 2011 21:55 #
I am experiencing the same issues.
the auto scheduling doesn't work and the times that shown are a few hours off what the actual server time is and the bulk processing does not work.
the only way to process is to manually click the process link below each feed
Member — 20th October 2011 01:47 #
I had the same issue until I went to the config file in autoblogincludes / includes / config.php and changed AUTOBLOG_FORCE_PROCESS_ALL to true ... might be worth a shot... some of us were stuck for a month or so manually processing until that config option was added .....
Regarding times being off, we've experienced the same issue and have brought it up multiple time with no resolution unfortunately.
Member — 20th October 2011 06:01 #
Tried the AUTOBLOG_FORCE_PROCESS_ALL, does nothing.
After a week of my site not working I'm gonna start looking for alternatives to Autoblog...
Sales & Support Lead — 24th October 2011 01:01 #
Hiya guys,
We're still looking into this. Barry's been away this past weekend, but should be back around to get this sorted asap.
Thanks!
Developer — 25th October 2011 21:21 #
Can you set AUTOBLOG_PROCESS_EVERY_PAGE_LOAD to true as well and see of that helps?
Note: If that doesn't do anything then it's something else that has gone wrong here and we'll have to do a bit more digging to find out.
Also, if you activate the autoblog addon called repair autoblog, and run the repair then that might give it a kick and get it started again.
Member — 26th October 2011 08:34 #
AUTOBLOG_PROCESS_EVERY_PAGE_LOAD as 'true' makes the entire server serve a "500 internal server error".
And where would I find this addon?
Developer — 26th October 2011 11:48 #
Ah, that would suggest that it's a different issue than a scheduling one - can you check your php error logs to see what was reported?
Under the Add-ons sub-menu which is under the main Autoblog menu
Member — 26th October 2011 13:00 #
If I look in under the Autoblog menu in ny "network admin" panel, there is no add-on submenu. If I log in to one of the sites in the network, there is an add-on submenu, but it's empty. Not a single thing regarding any add-on at all.
But apart from the add-on thing, I found what might be causing the problem in the logs.
I'm getting a "Call to undefined function wp_create_category" on line 429 of autoblogprocess.php. So this should be related to me having the settings that the feeds should create categories for the ones that aren't already there?
Developer — 26th October 2011 13:08 #
Ok, it sounds like you have a partially updated / installed autoblog there.
Can you grab the latest version and FTP it up to your server, make sure your FTP client is set to overwrite any existing files (alternatively remove the existing autoblog directory from the plugins directory and then upload the new one in its place).
Member — 26th October 2011 14:01 #
I removed the plugin and did a clean install. Then I got the add-ons in the menu. Activated and ran the repair, nothing.
Switched all the feeds to create tags instead of categories, nothing, did another repair, and it works!
Now I just need to see if they're gonna update by themselves, but atleast the mass-update worked (which didn't before).
I'll let you know what happens.
Developer — 26th October 2011 14:11 #
Cool - I'm subscribed on this thread, so just post here and it will message me.
Member — 26th October 2011 14:39 #
Ok, so nothing happened by itself. Had a feed scheduled to update every 30 minutes, nothing.
Tried to select all and process (just process on one has always worked), and nothing.
Tried setting AUTOBLOG_FORCE_PROCESS_ALL to true and process all, and two updated.
My setup is:
Multisite
21 sites, each one get their own feed
Feeds are set to update every 5 hours
Set to create tags from feeds categories
Developer — 26th October 2011 15:39 #
Do they process if you click the feeds individual process buttons? We've had reports of the bulk process buttons not working on some sites, and I'm currently investigating this.
Member — 26th October 2011 15:51 #
Yes, single process (link under title) = ok
Multiprocess, checkbox + process button, or scheduling are all no go.
Developer — 30th October 2011 20:59 #
@gfors - released an update the other day - can you try that version?
Member — 31st October 2011 08:19 #
That did it! Feeds processing correctly, and also the add-ons menu item is now showing in the autoblogs settings page as network admin.
Great job, cheers!
Member — 8th November 2011 20:39 #
I am still not able to get feeds to process according to the schedule ever since the last update, it was working correctly before that.
I've tried all the suggestions in this thread installing/reinstalling, making the modifications to the config file that were suggested, wp_cron is otherwise working correctly.
Is there anything else that I can try before abandoning the plugin and looking for another solution.
Developer — 9th November 2011 17:37 #
@JaniceH0125 - I note you haven't posted before, so in order to help the best we can, can you let us know the versions of WP and Autoblog - also can you let us know some details about your feeds (screenshots of the edit pages) and your autoblog config file.
Member — 16th November 2011 21:01 #
I am running current verions of the plugin and wordpress
Autoblog version 3.6.1
Wordpress Version 3.2.1
It's a facebook feed, things were working until the last plugin update.
Developer — 17th November 2011 13:36 #
Hi, is it a facebook feed that you need to be logged into facebook to get? What was the previous version you were running, so I can work out the differences?
Member — 27th December 2011 19:00 #
New install, autoblog 3.6.2. WP single site, 3.3. WP cron works fine for other stuff, but autoblog is MANUALblog. manually doing it works fine, but auto is a non starter, the date/time just passes and appears in red then - but it doesn't do anything. I don't know why this was marked as resolved, as there's lots of people experiencing this issue, and I can;t see any posting of an explanation of why this was happening. I think it also needs a real cron option so people who can't solve this can at least use it. I'm regretting spending the money.
Developer — 27th December 2011 19:03 #
Can you let me know what settings are in your config file? Also is the feed a main blog one, or a sub-blog? If the date goes red and it still doesn't process then there is definitely something up with your set up.
Member — 27th December 2011 19:44 #
I just set it up on the front side gui like most plugins and didn't mess with the config file at all.
It's WP 3.3, single site mode, Autoblog 3.6.2.
I just added a test feed off yahoo (http://news.search.yahoo.com/news/rss?p=news&ei=UTF-8), set the time to 30 min. when i saved, first processed was null as expected, but the next check field was in red before anything, manual or automatic happened, and displayed a datestamp that didnt correlate with any timezone I use, and was in the past by a few hours.
I did a manual process and it worked fine. I'll know in 30 min what happens with automatic (though I'm not sure how it will handle automatic given it set itself for next check a few hours in the past, one hour west of california). I'll view some pages to kick wp_cron and watch the error logs (debug is on), but so far nothing in logs.
The blog is on pacific time (us), the server is on us central time. date is correct on command line, and server epoch the timestamps correctly correspond to gmt.
I'm starting to suspect time may be a possible reason.
Member — 27th December 2011 19:45 #
here's config.php
Member — 27th December 2011 19:55 #
hmm server seemed to be on summer time (winter in the states), fixing and checking if that was an issue.
nothing yet in log files. going to check suhosin's separate log in a min, it can snare any insecure code in a way that doesnt make it to regular error_log
i can see wpcron firing in access logs.
Update - error_log and suhosin logs are clear.
Update: added a bunch more test feeds, will check logs in 30 min. debug on.
Member — 27th December 2011 21:00 #
ok it's had the 30 min. WP cron is firing and showing up in the access logs, but it is not getting autoblog to fire. Nothing showing in the error logs in debug mode.
Developer — 27th December 2011 22:04 #
Autoblog doesn't use WP cron.
Can you try setting AUTOBLOG_FORCE_PROCESS_ALL to true and see if that helps.
Note: your site needs traffic in order for the autoblog process to import, so if it doesn't have any then your need to visit it every now and then for testing.
Member — 27th December 2011 22:12 #
I'll try AUTOBLOG_FORCE_PROCESS_ALL to test and post results here later on, but force wouldn't be an option for normal use as it would be a load hog.
If autoblog isn't using WP's internal psuedo cron, what does it use? I'm wondering whatever hook it uses to get at website viewers viewing pages may not necessarily then work with all themes then?
I was hitting the site hard to generate traffic to kick lose whatever process was being used to fire it. It did fire WP-cron
Developer — 27th December 2011 22:16 #
No - that would only be the case on a multi-site system, but as you are on a single site system it won't have any load issues.
It hooks into the init action so that it will work when wp cron is disabled.
Member — 28th December 2011 00:40 #
thanks barry, i'm setting up a test now.
Member — 28th December 2011 01:02 #
Should wp_autoblog > active be NULL (its set for 30 min in the gui)? here's my current test feed in the db
feed_id 4
site_id 1
blog_id 1
feed_meta a:31:{s:5:"title";s:5:"TEST1";s:3:"url";s:55:"http://news.search.yahoo.com/news/rss?p=russia&ei=UTF-8";s:4:"blog";s:1:"1";s:8:"posttype";s:4:"post";s:10:"poststatus";s:5:"draft";s:8:"postdate";s:7:"current";s:6:"author";s:1:"1";s:9:"altauthor";s:1:"1";s:8:"category";s:2:"-1";s:11:"feedcatsare";s:4:"tags";s:18:"originalcategories";s:1:"1";s:3:"tag";s:0:"";s:8:"allwords";s:0:"";s:8:"anywords";s:0:"";s:6:"phrase";s:0:"";s:9:"nonewords";s:0:"";s:7:"anytags";s:0:"";s:10:"useexcerpt";s:1:"2";s:13:"excerptnumber";s:2:"33";s:15:"excerptnumberof";s:5:"words";s:6:"source";s:4:"more";s:8:"nofollow";s:1:"1";s:11:"processfeed";s:2:"30";s:12:"startfromday";s:1:"1";s:14:"startfrommonth";s:1:"1";s:13:"startfromyear";s:4:"2010";s:8:"endonday";s:2:"31";s:10:"endonmonth";s:2:"12";s:9:"endonyear";s:4:"2020";s:9:"startfrom";i:1262304000;s:5:"endon";i:1609372800;}
active NULL
nextcheck 1325006723
lastupdated NULL
Member — 28th December 2011 03:26 #
Found something. I'd been looking in the error log for php notices from the script, nada there - but I just found autoblog_log_* in the wp_options table.
here's 2 examples
a:2:{s:9:"timestamp";i:1325010077;s:3:"log";a:1:{i:0;s:51:"Notice: Processing stopped due to 6 second timeout.";}}
a:2:{s:9:"timestamp";i:1325007421;s:3:"log";a:1:{i:0;s:51:"Notice: Processing stopped due to 6 second timeout.";}}
Thats odd as this is a pretty powerful dedicated server of mine, running at very low load figures under 0.05 most of the time. and with 2 x 100mbps available.
Also, when I manually fire a feed it completes almost instantly, so i'm really unsure what is going on that could cause a timeout for automated, but not manual runs.
php version 5.3.8
php local
max_execution_time 18000
memory_limit 256M
max_input_time 60
mysql 5.5.17
I also have allocated loads of memory and high limits to php as I don't have any untrusted users.
I'm going to crank the 6 second limit, and see what that does. If it were both manual and auto taking >6s I'd next turn my attention to bind dns resolution for the feed domain, but as I said firing manually is consistently less than one second, even when i pick a feed with a lot of results.
Member — 28th December 2011 04:11 #
I just tested on a different domain, same server - firing manually is close to instantanteous, but a feed due a run that is in red, with debug switched on wouldn't fire and either deliver posts, or put something in autoblog_log_ . I just don't think init is talking to autoblog. (i'd upped the timeout in config.php to 30)
Member — 28th December 2011 05:14 #
I just did an extremely aggressive load test by setting up 20 subdomains, a test feed on each, with a unique wp install on each, then i did a windows batch script to open 20 firefox windows directly to the script firing url (same for all except domain). http://sub.domain.tld/wp-admin/admin.php?page=autoblog_admin&process=1&_wpnonce=aUniqueAlphaNumString at the same time i had Top running when all 20 feeds were fired simultaneously (all within about a 10th of a second of each other i think). mysql only made it up half way, server loads soared briefly to 4 or so, but all feeds appeared done within 2 seconds - so definitely not a load issue, and this load included postings, and reruns of xml sitemap.
Member — 29th December 2011 06:23 #
Anyone know a way of invoking autoblog via cron or another automated way as it just isn't going to happen for me with it's regular method?
Member — 29th December 2011 07:59 #
a:2:{s:9:"timestamp";i:1325116626;s:3:"log";a:1:{i:0;s:52:"Notice: Processing stopped due to 30 second timeout.";}}
appeared well under 30 seconds of me switching the time setting on a stuck feed (I edited the frequency and immediately hit the front end site.)
Definitely some bug or incompatibility that prevents it working on my installation. Anyway I think at this stage its find a way to cron it or a different product.
Member — 29th December 2011 08:10 #
Here's a truncated view of part of the DB
wp_options where includes autoblog
38 active_plugins a:14:{i:0;s:37:"auto-prune-posts/auto-prune-posts.... yes
369 autoblog_installed 5 yes
396 google_stats_topPages_ga:54067916 a:2:{s:5:"stats";a:10:{i:0;a:4:{s:5:"title";s:126:... yes
460 _site_transient_update_plugins O:8:"stdClass":3:{s:12:"last_checked";i:1325133130... yes
502 autoblog_processing 1325116626 yes
944 _transient_plugin_slugs a:14:{i:0;s:28:"autoblog/autoblogpremium.php";i:1;... no
952 autoblog_log_1325116626 a:2:{s:9:"timestamp";i:1325116626;s:3:"log";a:1:{i... yes
Also fyi, wp_posts is MyISAM for YARPP, in case thats relevant. All other tables except two YARPP tables are InnoDB
Those two bits I bolded, would that imply something is "stuck"?
Member — 29th December 2011 08:36 #
I have a suspicion... switching the server over to GMT, leaving WP with its defined timezone.
Member — 30th December 2011 00:59 #
resolved by uninstalling permanently. It doesn't work for me, and there's only so much time I'm willing to chase bugs on paid software.
Doesn't work (for me).
Become a member