andrewatfornax

Probably! And no, unfortunately, we don't yet.

The directory that appears to be unable to be written to is /var/www/vhosts/domain.tld/httpdocs/adserver/www/images - but in your case, that's not a permission error, but a restriction of the host. You'll need to address that with your PHP config.

Interesting point! We'll want to look into that report and make sure it's 100% accurate before we move forward, and if it's true, then of course documentation will be updated. Thanks!

I'm afraid I can't reproduce this - they are all working fine for me in 3.2.1.

In the campaign, under the Linked Trackers tab, just set a click conversion window, and not an impression conversion window. I'm pretty sure that's all you need to do.

That suggests Revive Adserver is deliberately trying to delete a cookie by setting the date in the past. However, I'd have to know more about when you're seeing this to try to understand it...

I'm not aware of anyone that has actually reported they have done this - but that doesn't mean it can't be done. I suspect the most likely way of having this work is using a geofence system that can detect the region someone is in, and trigger a request to Revive Adserver for the appropriate content. But as to recommendations for the technology to do that, sorry - it's not something I've had a chance to look into yet.

So, to me, if it works sometimes and not other times, that suggests a transient network issue, or a load/capacity/threading issue with your server...

Hi Mark, What do you mean by "dynamic" ad serving in emails? Can Revive Adserver display ads in emails? Yes, there's a zone type specifically designed for putting banners into emails. Or do you mean something different?

Never seen that before. Can you capture the page source when you do see it?

Do your SPC tags that you've generated work if you put then into a completely plain HTML file?

So, this is what the database schema should be if your version of Revive Adserver is saying that you're running schema version 613: https://github.com/revive-adserver/revive-adserver/blob/master/etc/changes/schema_tables_core_613.xml So, when it says something like: index missing from table: data_intermediate_ad_variable_value.data_intermediate_ad_con I would be looking here for the full table definition: https://github.com/revive-adserver/revive-adserver/blob/master/etc/changes/schema_tables_core_613.xml#L2404 And then scrolling down to here, where the indexes for that table are defined: https://github.com/revive-adserver/revive-adserver/blob/master/etc/changes/schema_tables_core_613.xml#L2790 Hopefully, that's reasonably clear, and you can see the 6 indexes that this table has, and you can compare that with your database to see what's been added/removed.

No, it should be fine to hack the source of Revive Adserver if you want to / have a need to. Just be aware that you may have to repeat that with every upgrade, so offload as much of your custom work as you can into new files that you can just copy over when it's time to upgrade, and keep the changes to the core files as small as you can, to make life easier later on.

Yes, you probably need to make the banner itself responsive via scripts that are hosted externally, and just deliver the HTML to load up the banner & script via Revive Adserver?

I am indeed - and working my way though the usual backlog of emails and posts. Will try to get to it soon!

To answer the other question: PHP 5.3 *is* required. You cannot upgrade without it. http://www.revive-adserver.com/support/requirements/ PHP 5.2 stopped being supported back in 2011. Your hosting provider should upgrade your server for you if that's what they are still providing.

Absolutely, we would never deprecate anything without a big note in the release notes. And it's not a decision to be taken lightly. Feel free to join in the decision making process, everyone! https://github.com/revive-adserver/revive-adserver/issues/588

Yes, from memory, you can do this with a site variable. Should be documented here: http://documentation.revive-adserver.com/display/DOCS/Site+delivery+limitations but is not at the time of posting :-) But in short, give each banner a keyword or something that will prevent it from delivering, and then pass in that site variable whenever you want to block that banner.

Ah, sorry, didn't understand that! As above, basically, though. JS needs JavaScript, and is more flexible and adaptable to deal with more situations. Image is just image, and needs programming on your behalf to do cache busting.

Option 1 won't work - there's no bracketing of the AND logic unfortunately, so you're effectively limiting to display only between 2pm and 8pm on the relevant dates. Option 2 seems the better approach (although your final day start/end times don't match the stated original desired end time!). As a general rule, most people tend to avoid those kind of start/stop times, and just use dates, so it can be done at the campaign level, and use the limitations to block out certain days or times where the banners should not run.

You say "priority", but then talk about not waiting a "priority" of zero, because that defeats the purpose of limiting daily views. So, I suspect you're actually talking about capping limitations, not priority? Either way, though - if you're using direct selection for banners, then the whole concept of priorities and/or limits is completely irrelevant, unfortunately. If you ask for a specific banner, you get that specific banner. If you ask for banners of a given keyword, you get a banner. I don't think direct selection pays any attention to things like priorities and limitations.... Or, perhaps it just causes DS to fail when they are set up. DS wasn't really built to work for these kinds of things, from memory - and almost certainly hasn't been well maintained. We pretty much feel here at Revive Adserver that we don't want to document DS, and that we'll eventually deprecate the functionality... Doing it through zones is the preferred way.

I wonder if you can do this already with a responsive HTML banner, linked to a * x * zone?

I was going to suggest checking the advance DB features in the upgrade UI to make sure the correct DB table prefix was being picked up from your old config file (and that you were copying your config file over). Was that it?

Can you provide more details on how the campaign is set up, what it's linked to, what kind of limitations are in place, etc? Seeing the numbers go down like that makes me think that Revive Adserver is desperately and continuously scaling back the priority of the campaign because it thinks that the campaign is going to over deliver - so I have a feeling it's perhaps not set up to deliver how you want it?

The capping is either being hit very quickly, or, the capping you have set is completely blocking delivery - or the capping is not compatible with the tag type you're using. Can you provide more info about the setup please?