error in ads import

Trouble updating AdRotate Professional to the latest version?

If your license is not expired and you are having trouble with updates for AdRotate Professional I want to hear from you!
Known issues; The update will not install or no update is visible in your dashboard.
Affected versions; Most versions of AdRotate Professional since December 2019.

Click here for the solution - AdRotate Pro update not working or not offered.

Home Forums AdRotate for WordPress General Support error in ads import

  • #95047

    Darren Huber

    Was trying to import some ads from one site to another (both using adrotate pro) and they would not import. Got the message that they were imported but nothing appeared.

    Soooo…. did some debugging and found an issue in your import program.
    On line 39 you have:
    if($_FILES[“adrotate_file”][“type”] == “text/csv”)

    I think this is a problem as this info is provided by the client and can’t be relied upon:

    In my case, the value sent was “application/”. As a quick hack, I changed the program to test for that string and the import worked fine.

    But got another error:

    Schedule start/end did not import correctly. startdate was entered as nov 2025. Not sure if that was because of my ‘hack’.

    Also, Export/Import does not appear to include geo targeting data 🙁


    Arnan de Gans

    But application/ are spreadsheet files like xls. AdRotate Pro only supports csv files, which do not have the MIME type application/

    The import may very well import wrong values if you use incompatible files. But that’s a bit hard to tell at this point.


    Darren Huber

    Mime type is sent from the client’s browser and can’t be trusted, that was my point. Anyone with Excel installed on their system (at least in Windows), will report a csv as application/

    Here is some info from ten years ago on how the mime type is determined, apparently they have never changed this:

    Chrome (version 38 as of writing) has 3 ways to determine the MIME type and does so in a certain order. The snippet below is from file src/net/base/, method MimeUtil::GetMimeTypeFromExtensionHelper.

    // We implement the same algorithm as Mozilla for mapping a file extension to
    // a mime type. That is, we first check a hard-coded list (that cannot be
    // overridden), and then if not found there, we defer to the system registry.
    // Finally, we scan a secondary hard-coded list to catch types that we can
    // deduce but that we also want to allow the OS to override.
    The hard-coded lists come a bit earlier in the file: (kPrimaryMappings and kSecondaryMappings).

    An example: when uploading a CSV file from a Windows system with Microsoft Excel installed, Chrome will report this as application/ This is because .csv is not specified in the first hard-coded list, so the browser falls back to the system registry. HKEY_CLASSES_ROOT\.csv has a value named Content Type that is set to application/


    Arnan de Gans

    I doubt that if you create a csv file in excel and save it as something.csv it still has the mime type of a xls file. That’s not how files work. But if it does, that’s an excel issue.
    If Chrome changes the mime type, that’s a Chrome issue.

    I’ve never heard of either being an issue – Tons of people use Chrome and Excel and nobody ever reported this kind of issue. Logically this would mean that the file you got sent is not an actual csv file.


    Darren Huber


    I handed you the information on a silver platter. You are incorrect. READ what I posted. My browser (and any Firefox/Chrome browser where the client has Excel installed will send mime type as application/ Would be simple enough to just test the file contents but I guess you know what you’re doing 🙂

    I tested it with a csv file and it worked fine by changing the mime type in your import routine.

    I really don’t care if you look into it or fix it. I think it’s time for me to find another software option as your support absolutely _sucks_.

    p.s. – you skipped element #5 in your import routine so the last 3/4 of the data imported is incorrect.


    Arnan de Gans

    I see. Then we’re done here.

    But, as I mentioned earlier nobody ever reported this or a similar issue other than you.
    With that in mind logic dictates that your csv file simply has the wrong mime-type or is a one in a thousand (million?) that’s not working the way you’d expect. If this were a common issue other people would have reported this or something similar years ago. Excel is a very common thing to have installed… I’ll keep an eye on it though, if others report a similar problem I’ll revise the mime-types if that makes sense.

    I’ll look into the 5th element being skipped – I think that’s by design though. Some columns are no longer supported. But I’ll check to make sure.

    Have a nice day.


    Darren Huber

    In an ideal world, your logic would be great, but that’s just not how things work in this case. I do have a degree in computer science (although admittedly have not actively worked in that field for 15 years). So I do have a basis of knowledge here. And it is super frustrating to have you _always_ assume it is user error without taking even 1 minute to look into the issue. I took a fair amount of my own time debugging this problem. A normal person would think you’d be thanking me instead of brushing it off.

    So here you go, the final (and relatively complete compilation and proof of this issue) :

    Take a look at how Chrome gets it’s mime type here:
    You will see that text/csv is not in the list of standard mime types so they revert to getting that data from the registry.

    Here is a link to the code in Chrome that pulls from registry:

    And here is a link to an open bug report on this issue, with discussion dates going from 2012 – 2019:

    So if that isn’t enough to get you to realize this is a problem…. well…. hmmmm……

    As for the missing offset: No, it is not by design, it is an error. There are 20 columns in the import and you are referencing up to 21 (20 as it’s zero based). And since you say this hasn’t been reported I’m guessing this isn’t a much used function. Which would explain why the mime issue hasn’t been reported either.

    And back to the mime/csv issue: EVEN if you were right, the import routine is still slightly flawed as you are reporting valid import (status 216) if filetype is incorrect, it should be going to error notification instead.

    I have done tech support in the past so I know how frustrating and thankless it can be but to brush off all your customers by saying it’s not a problem because it hasn’t been reported before really isn’t helping you or anyone else. Seems to be a common theme. Mistakes happen, just fix them and move on.

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

The topic ‘error in ads import’ is closed to new replies.

You may be interested in