andrewatfornax

Hi @scott.huish, Not as core feature with no additional effort, no. The override campaign type is ideal for setting up banners that are shown to users, no matter what else is going on - but then, naturally, you need to set such campaigns up so that they stop showing (stop overriding everything else) once your initial "new visitor" stage is "over". It's possible to use capping to limit the number of times a banner is seen - which can be once, of course, but that doesn't relate to any specific location (e.g. page). You could, of course, then set up a separate banner for every page, and use delivery rules to limit the banner to only appear on the specific page, and then cap the banner to once per viewer - but that's a rather cumbersome way of achieving the outcome! Probably the most efficient solution that comes to mind would be to track the "new visitor" stage externally from Revive Adserver (e.g. as part of your website code), and to then pass in this information as a paramter with each call to Revive Adserver, and then use delivery rules based on that in your override campaign's banner(s), so that they only deliver when the visitor is "new" to the page. HTH.

Hi @Sari, There's a core option in the advance zones tab that provides an option to waterfall to another zone, in the event that a blank impression would otherwise be delivered. No core RTB or retargeting options at this stage, but I am aware of at least of a couple of 3rd parties offering commercial plugins for these.

Hi @ZISSA, Sorry, no updates yet. The legacy GeoIP databases are still the only ones supported.

Hi @femdom, That depends on the type of user. Are we talking about an advertiser account level user?

Hi @adhero, Yes, I read the topics, and do my best to answer them all, when I can! No, you can't create an advertiser-level account that has ONLY statistics access. Even if you don't allow the user all of the optional permissions at the advertiser level, there are still certain actions that they are allowed to perform beyond just viewing statistics.

Not the full path to the maintenance file, the full path to the PHP CLI executable.

Hi @DougW, To me, that sounds like the CLI version of PHP that is being used by default is a different (lower) version of PHP than the one that's set up for the web server. Try specifying the full path to the correct version of the PHP CLI executable.

Hi @tobean, Does this happen with a clean banner in an otherwise empty HTML page? Just checking if it's CSS or similar on the target site that is hiding the text under the banner. Thanks.

Thanks for the update @gabrielt, let us know what you find, and if that was the issue, it would be interesting to see if the overall stats were correct given the way things were linked.

Hi @alexei lavrov, In your examples, it looks to me like the images are being loaded over HTTPS, not HTTP - but I agree that the logging pixel is initially called over HTTP (and then is being re-directed to HTTPS). Is this a problem? The page & banners load in your example without any warning in my browser...

https://documentation.revive-adserver.com/display/DOCS/Revive+Adserver+Broken ?

Hi @benwinton, I'm not an expert in the delivery side of things (I focus more on the back end of Revive Adserver), but does it work if you pick a default size for the banner, and let it re-size from there anyway? If not, I have a feeling that we have discussed the idea of allowing "*" as a size for banners in the future (although I cannot seem to find a ticket in GitHub for this, so perhaps it never got that far).

Hi @Geoffrey, Great, glad you got it fixed, and very happy to hear of a Revive Adserver user using proper tools like Puppet for configuration management!

Hi @sleah, Revive Adserver doesn't have anything built in for this, but it should not be difficult to use standard O/S tools to schedule a backup of the database (using the native database tools) and the Revive Adserver/banner assets from the filesystem.

Hi @Geoffrey, Sounds like a permission issue with the config file (e.g. special mount permissions overriding what the file permissions say), or possibly an issue with the upgrade process. Can you roll back to 4.0.1 in your staging environment to check the behavior prior to upgrading?

Hi @tritone11, I think you'd have to modify the code for this - there's no built-in option to modify the headers AFAIK.

What version of Revive Adserver?

Hi @benwinton, Well, if the permissions are 644, and the file is owned by the user that the web server runs as, then the warning is correct. There is no way to turn off the warning message - if you want to leave the configuration file open to allow changes at any time, then the warning message will always show.

Hi @soufiane, I don't think the answer changes - yes, I don't see why you cannot do that.

https://documentation.revive-adserver.com/display/DOCS/Banners+Not+Delivering+over+SSL ?

https://documentation.revive-adserver.com/display/DOCS/Unable+to+Link+Banner+and+Zone ?

Hi @mibert, Have a look through the recent posts - this has been discussed only yesterday I think?

No, sorry, not at this stage - users and accounts are on my todo list for the documentation. Please consider signing up to our Patreon account to help support us in this!

I'm not 100% clear on what you are asking, but I think the answer is yes, you can.

Hi @Richard Cook, Looks to me like it _does_ find your 4.0.1 installation and attempts to upgrade it. You would not be seeing this issue if it wasn't attempting an upgrade. The issue appears to be that some databases do not have the expected database schema to match their version (and 4.1.0 fixes some issues to ensure that Revive Adserver now correctly detects those mismatches in expected database schema). Hi @gabrielt, https://stackoverflow.com/questions/41810796/mysql-remove-default-value-for-datetime-field Looks like that should work for other columns where the default is not expected.