Gone Fishin

In PayPal IPN, there are no IPNs that have hit my site: “No PayPal IPN found”

This is a fresh install. Why would I have IPNs hitting my site before I have the back-end set up to properly handle them?

I had the plugin folder renamed to disable it, so I renamed it again so it would then be picked up by Plugins.

Upgraded from v1.4.0 to v1.4.1 successfully.

I am now able to access the dashboard of the previously ‘troubled’ subdomain site.

The issue appears resolved, for my site anyway.

Thank you very much for such a speedy fix. Good work!

I also got locked out of the only subdomain site (on a multisite network) that uses Better WordPress Google XML Sitemaps after upgrading to v1.4.0.

The error was:
Fatal error: Call to undefined function wp_get_current_user() in /home/user/public_html/domain.com/wp-includes/capabilities.php on line 600

Other threads on the WP support forums suggest that pluggable.php needs to get loaded prior to the plugin … or some such.

The change in settings I made was not related to the whitelist. It was to disable hotlink protection (which is causing a different issue). The settings for the login whitelist, which were already saved in the database, were working with no problem prior to AIOWPS rewriting the .htaccess file.

But to answer your question, the content of the Whitelisted IP Addresses is, “69.128.*.*”.

Thank you for reporting that, Jeriksson. But unfortunately, my db user already had the alter privilege, so it is not a fix for me.

it’s sad cause it’s by far the best related posts plugin!

Not anymore, apparently. I’ve switched to a different ‘contextual related posts’ (hint) and it displays related posts much nicer than YARPP did. I’m glad YARPP failed and prompted me to switch.

I am having the very same issue: “Unfortunately your table seems to be using the 1 engine.” Engine is MyISAM. And as far as I know, there is no such thing as a “1” database engine.

On the table I executed, “ALTER TABLE wvgabj_posts ADD FULLTEXT post_content , post_title )”, but it did not fix it.

I decided to use a ‘real’ cron job. But, that was not without its own set of frustrations.

First, “@$1php” at the start of the second line in the ‘start script’ (“BackWPup_cmd_start_job_1.sh”) caused an error:
“@php: command not found”

After fixing that, PHP gave me another error (“option not found r”), because the webhost has disabled the ‘run’ (“-r”) option for php.

So, I converted the shell script to a PHP script and launched it with php. That produced:

“Set-Cookie: bb2_screener_=1422648002+23.28.34.110; path=/
Set-Cookie: PHPSESSID=cff583bedd412c851906aa7318c608a3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-type: text/html”

And, the job did not run. Probably because of this line in BackWPup_Job::start_cli(): if ( php_sapi_name() != 'cli' ) return;

The webhost’s PHP_SAPI is “cgi-fcgi”.

I ended up having to use lynx -dump with the appropriate (“Start job”) link to get automated backups working.

After more testing, I have discovered that:

1. wp-cron.php is indeed firing the ‘backwpup_cron’ event by calling do_action_ref_array() with that tag, but …

2. do_action_ref_array() is simply returning without calling the user function, because $wp_filter['backwpup_cron'] is not set.

I have gone as far as I can to help diagnose the problem.

Come to find out, this is not caused by an invalid date being stored in the database, because WP-Cron does not store dates (timestamps) directly but serializes the data to a string before storing.

I have determined that the particular issue I am experiencing is caused by two things:

1. Line 212 of class-page-jobs.php has faulty logic. With a ‘gmt_offset’ option value of anything other than zero, the test will always return True even if wp_next_scheduled() returns False. This causes date_i18n(), on line 213, to return “December 31, 1969” if the job is not scheduled; instead of correctly reporting that the job is, ‘Not scheduled!’

2. When it comes time to run the single event, the event is removed from the WP-Cron schedule. But, it does not get rescheduled, because the BackWpup job (which would also reschedule the single event), as far as I have been able to determine so far, never runs.

I tried instituting some event logging in the Cron and WPBackup systems to try and see where the disconnect might be. But, it must be getting late, because I’m sure what took the site offline was a 500 Internal Server Error. I’ll try again later after I’ve had some rest to clear my bleary eyes.

To help determine the cause of #2, where would be the best place(s) to put some event logging:
BackWPup_Job::start_http(),
BackWPup_Job::start_wp_cron(),
BackWPup_Job::run(),
BackWPup_Cron::run(), and/or
BackWPup_Cron::cron_active()?

Lee

There is no caching plugin installed. I am using iThemes Security, Wordfence Security, WordPress SEO, and WP-SpamShield (plus others I can list if needed) if that makes any difference.

The schedule is set with:
Start job: with WordPress cron
Scheduler type: basic
Scheduler: daily 3:0 (3am)

The issue still persists.

The job that got correctly scheduled by my re-saving it has had its Next Run date reset to December 31, 1969. And, the job did not run. It is a daily job, and the last time it ran was six days ago when I ran it manually.

Is there something I need to do to help you resolve this?

Lee

Thank you for the response, Daniel.

I keep the plugins up to date, so I assumed it is the latest version. It is version 3.1.4.

Manually going to Jobs -> Edit -> Schedule and clicking the Save Changes button did indeed reset the next scheduled run time correctly. One job is set to run daily, so I’ll know tomorrow if it automatically schedules the next run correctly.

Wow, what a fast response!

I had actually been meaning to move the subscription form out from the back-end of the quiz, and this issue spurred me into doing that. So, I cannot test your solution on my live site.

But I did test it on my localhost with v1.3.7, and disabling the WordPress filters on quiz content did indeed allow a form to be shown with its input tags intact.

Great job!

My original thought, that started this thread, was that is was cp-crontrol.php causing the error, because it stopped when I deactivated WP Crontrol.

Now I think it may have been a dummy PHP cron I created with WP Crontrol while debugging a non-working wp-cron.php. I had set it to run once, and it is gone now — along with the error. (Do they need to be encapsulated with “<?php ?>”?)

So… I think this was a false alarm.

BTW, WP Crontrol helped me immensely in determining whether or not wp-cron had run. Good support response time too. Rated 5 stars ??

Duh! There is actually a very simple way to modify the CSS without hacking on the theme’s style.css file and without creating a child theme.

I had overlooked this previously as I do not usually use the custom CSS feature that some themes have; like zeeDynamic.

Go to Appearance -> Theme Options, then select the General tab and scroll down to the Custom CSS box. Enter:

#sidebar {
	overflow: hidden;
}

#footer-wrap {
	clear: both;
}

And save your changes. Done ??