Support » Plugin: AdRotate - Ad manager & AdSense Ads » Adverts revert to 1970 expiry date

  • Resolved Cognisant_2000



    We had this issue before and fixed it in the previous versions, but of course as the fix was not done by the author, it was overwritten when the customer updated the the plugin to the latest version.

    The problem is as following:

    1. All existing ads work fine.
    2. If you create a new advert, the exipry date reverts to 1970 after saving the ad.
    3. If we edit an existing advert, the exipry date reverts to 1970 after saving the ad.

    WordPress version 5.5.1
    AdRotate Version 5.8.11

    We probably can fix this again, but the next update will overwrite it again.


    The page I need help with: [log in to see the link]

Viewing 8 replies - 16 through 23 (of 23 total)
  • Hi Arnan

    We have downloaded and updated the site but still the same problem (see my post this morning)


    Plugin Author Arnan de Gans


    Please remove the double plugin folder, you don’t need it.

    And for the issue, it makes no sense 🙁
    If there are no errors in the log, no faulty files and the values exists (as you’ve shown it does)… It should work. As I said, I can’t reproduce it anywhere. And nobody else is reporting an issue like this.

    Did you try this with all adverts? Or just the one?
    If it’s just the one, replace it with a new new advert.

    There are 2 errors we see that may be causing this issue but we are not sure. They are the following:

    Creating a New Advert:
    WordPress database error: [Unknown column ‘daystarttime’ in ‘field list’]
    INSERT INTO gits_adrotate_schedule (name, starttime, stoptime, maxclicks, maximpressions, spread, daystarttime, daystoptime, day_mon, day_tue, day_wed, day_thu, day_fri, day_sat, day_sun, autodelete) VALUES (‘Schedule for ad 69’, ‘1604353102’, ‘1611610702’, ‘0’, ‘0’, ‘N’, ‘0000’, ‘0000’, ‘Y’, ‘Y’, ‘Y’, ‘Y’, ‘Y’, ‘Y’, ‘Y’, ‘N’)

    This does not show if we amend an existing advert, but it does show if we try to create a new advert

    Site Status Error
    PHP default timezone was changed after WordPress loading by a date_default_timezone_set() function call. This interferes with correct calculations of dates and times.

    We have tried different time and date formats in WordPress settings but the error is still showing in the Site Status no matter what time & date format we use.

    Plugin Author Arnan de Gans


    If that column is missing then that would interfere with saving schedules yes. Caysing that error.

    Your database is not updated.

    Please check Settings > Maintenance, near the bottom.
    There are a few version numbers, all should be green.
    Click the “run updater” button if they’re not.


    I have run the updater:

    1. The “Run Updater” is still showing Blue and not Green and shows the following AdRotate version
    Current: 399
    Previous: 395

    Database version
    Current: 66
    Previous: 65

    2. When I set up a new advert the error message no longer shows, however, the start and end dates are set a 01-01-1970 and when I change and save them the “Manage Add” shows the correct dates but when I click on the ad to view the settings, the dates are shown as 01-01-1970.

    The ad is in the “Adverts that need attention”, the same as the old verion rather than Ads running.

    Do you want me to set you up with a Admin level user so that you can see the settings, etc directly rather than being in a relay mode? I may be not giving the full information you need.


    Plugin Author Arnan de Gans


    Assuming just that one column is missing:

    ALTER TABLE gits_adrotate_schedule ADD daystarttime char(4) NOT NULL default ‘0000’ AFTER spread;

    You can run this query from the SQL or Query field in PHPMyAdmin.
    Of-course make a backup before doing any SQL edits.

    OK. I have spoken with client and given him costs for either fixing the MySQL database or installing a new plugin and recreating the adverts from fresh.

    He has decided to go for a fresh install as I could not guarantee the database option will resolve the problem, where as a fresh plugin should kill the old database and create a new database without carrying over any errors.


    Plugin Author Arnan de Gans


    It only wasn’t guaranteed because you only gave me one error that shouldn’t happen in the first place.

    With a more clear picture of which errors were occurring a database fix would have been faster and perfectly fine.

    ANyway, things are working now?

Viewing 8 replies - 16 through 23 (of 23 total)
  • You must be logged in to reply to this topic.