AdRotate Advert Schedules Wiped Out

Not one for queueing up? Get faster support with AdRotate Pro!
The forum is checked a few times per week. With AdRotate Pro you can get answers faster using email support.
More private, more direct and usually a solution within a day! Learn more »

Home Forums AdRotate for WordPress Bug Reports AdRotate Advert Schedules Wiped Out

This topic contains 3 replies, has 2 voices, and was last updated by  Arnan 1 month ago.

  • #44423


    All advert schedules have reset to Start and End on 1/1/1970. This has been occurring periodically for the last 6 months or so. I believe this is occurring when WordPress auto-updates. I reviewed my error logs for the last week and found nothing related to AdRotate.

    I am running WordPress v4.9.4, with AdRotate (free) version 4.9. I am not using %tags% in my ad code. None of my adverts are set to auto-delete. This is a single site installation, and I use the WP Super Cache plugin.

    Edit: I checked the wp_adrotate_schedule values and all starttime and stoptime values are intact.

    I suspect this is related to the fact that my database collations are mixed, due to this database being carried forward since around 2007. My AdRotate tables have the following collations:
    utf8_general_ci (all except stats_archive, tracker, and transactions tables)
    utf8mb4_unicode_ci (stats_archive)
    utf8mb4_unicode_520_ci (tracker and transactions)

    My WP database uses a mix of utf8_general_ci, utf8mb4_unicode_ci, and latin1_swedish_ci (for some unknown reason!).

    A further issue (which may or may not be related) is the appearance of errors when deleting expired adverts. These began to appear around the same time that I began to experience schedule resets:
    Warning: mysqli_real_escape_string() expects parameter 2 to be string, object given in /home/brattle/brattleblog/wp-includes/wp-db.php on line 1102

    Warning: Cannot modify header information – headers already sent by (output started at /home/brattle/brattleblog/wp-includes/wp-db.php:1102) in /home/brattle/brattleblog/wp-includes/pluggable.php on line 1216

    Warning: Cannot modify header information – headers already sent by (output started at /home/brattle/brattleblog/wp-includes/wp-db.php:1102) in /home/brattle/brattleblog/wp-admin/includes/misc.php on line 1114



    Collation shouldn’t really matter for this kind of thing, but personally I prefer all tables to be the same – Just to eliminate the slight chance of discrepencies.

    If all schedules are intact, but the adverts won’t use them. Then there is likely something going on with the *_adrotate_linkmeta table. That’s how schedules are linked to adverts. Errors related to that should show up in the error_log.

    If there aren’t any errors, simply re-saving the adverts with the schedules may just solve the issue.

    You may want to match up all collations just to be sure. But since they’re all using utf8 in one form or another I don’t think it’s the issue. Doing some database maintenance, such as optimising and repairing tables may help more. You can do that from AdRotate > Settings > Maintenance, or via PHPMyAdmin.



    Thanks for getting back to me so quickly.

    I appreciate the advice on updating table collations. I’ve been reluctant to do it because I have limited server overhead, but will see if there are some other options.

    Unfortunately, I was not able to simply change the scheduled dates. The new dates don’t stick when saving, and there is no option to remove the start/stop dates of 1/1/1970 when editing (like you would normally be able to do when changing a schedule). I ended up just re-creating the ads and deleting the broken ones.

    I run the maintenance routines in AdRotate every 2 weeks, prior to running optimize routines in pypMyAdmin. I have not run Repair Tables in some time, but will give that a try on the next maintenance date.

    Thanks again, and I will let you know if I run into further info that may be of use.



    If dates and stuff don’t save, that suggests a issue with the database.
    Errors about that, missing columns or whatever, will be in the servers error_log.

    Did this start after an update? If so, make sure the database is up-to-date.
    You can see version numbers in Settings > Maintenance, near the bottom.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.