flicker177

One last thing: My cron setup is nothing unusual. All it does is use curl to hit the file wp-cron.php which runs cron processes when they’re due. If I use my WordPress cron manager I can run each item in the schedule manually with no error, If I manually run wp-cron.php it always generates the error. Anyway, the fix works so I’m happy 😉

–Bill

• This reply was modified 1 month ago by flicker177.

I’m getting closer. The problem is indeed at line 56 of the file wppa-wpdb-insert.php. Specifically this section:

if ( $bret ) { setcookie( ‘wppa_session_id’, $sid, time() + 3600 ); return $wpdb->insert_id; }

If I comment this out the error message stops. I don’t see any adverse effect on wppa as I’m using it. I read that the setcookie function can cause this issue but I don’t know enough about it to understand. The whole issue as I understand it is when php is outputting an html page it can send headers with meta info to the server before the body of the page. Once you’ve sent any of the body you can’t send a header again.

Anyway hope this helps. Thanks!

–Bill

I looked at this a bunch more, its really strange. I doubt it’s WPPA’s fault. I tried de-activating all the plugins in the site except WPPA. That made no difference. I noticed that the error occurred every time my WordPress cron ran (cron job) but that nothing related to WPPA ran every 15 minutes.

The file referenced in the error message and line 56 don’t look like they have any relation to the error.

The cron job used curl to access the file wp-cron.php by https every 15 minutes. I found that if I used php to access the wp-cron.php file it ran fine and the error didn’t occur.

On a local staging machine running a setup pretty similar to my host, the cron job with curl runs fine and generates no errors. I don’t know what’s different from my host. Interestingly I can’t get the cron to work on that machine using php but the version using curl works fine. Maybe that’s a permission issue, I haven’t spent much time on it.

Anyway I hope this helps and I seem to be error free now.

–Bill

OK, that’s fine. I didn’t know that message came right from your plugin. I doubt I can have my host change php configurations, I’m on a cheap shared host. Just to be clear, I assume that the only impact would be speed, not a data failure?

Thanks for all the work and the great support!

–Bill

I hope I can still post, I’m still working on this. I did look at the log files from the problem installs and don’t see any entries that show anything wrong. I’m not sure when the file deletion happens in the process. The first indication of trouble is right after the “Final WordPress Tests” screen when Duplicator’s Installer can’t find wp-login.php. When I exit the Installer and look at the root folder that file and a bunch of others are missing. None of this seems to be captured in the log.

–Bill

Will do, thanks again!

Hi Ollie,

Yes, I understand that and deactivating the plugin before making the duplicator package is easy. The part that stumped me was that after migrating the site and reactivating the plugin broke everything again.

The key was in deleting the files .ht.object-cache.-a.sqlite and object-cache.php before reactivating the plugin on the new site. This wasn’t obvious to me at all but it fixed the problem.

Again, if the plugin deleted these files when activating, deactivating, or deleting the plugin I think we’d avoid the issue.

Thanks,

–Bill

Hi Jacob,

I tried the pre-release and it now seems to work fine. Thanks much!

–Bill