andrewatfornax

Hi @stapel_eliz, No, sorry - while our Patreon page is slowly getting better, we're still some way of me being able to start dedicating time to the developer docs on a regular basis... I do what I can, when I can! Thanks.

Hi @420, Sorry for the break - been busy with my main earning money job, as Revive Adserver doesn't pay all the bills yet! Looks like my colleague @Matteo Beccati has found the issue, and we'll work to get a fix into the next release if we can!

Hi! In short - no, Revive Adserver doesn't automatically support that. Best you could do would be to run two campaigns/banners side by side, and then turn one off after you'd decided which had the best yield.

Error 1: Take parse_ini_file out of the disable_fuctions list from your php.ini file! Error 2: Fix error 1 first, and then also check the documentation for the requirements for Revive Adserver.

Not sure if there is - Revive Adserver has an XML-RPC API out of the box, and there's an add-on REST API that a 3rd party sells, but I can't comment on either of them re: functionality, sorry. The documentation for the XML-RPC API is still on my todo list.

Hi, I don't think there's a way to support this with Revive Adserver, as such, but some ideas: Write some JS code that will determine if the HTML code matches, and then dynamically modify the Revive Adserver tags to pass an appropriate targeting option through (e.g. keyword); or If that's too complex (and it sounds like it), try doing that keyword setting when the HTML code is generated.

Hi Michael, What's the impression tracking link look like - specifically, if you load the link in a banner, what does it return in the browser? Revive Adserver doesn't have support for call-back impression tracking, so you might need to load this link as an image or via JS or something, which would involve turning that GIF banner into an HTML banner, with the appropriate bits around it to make it all work...

There's no specific documentation that I'm aware of, but, you should be able to deliver an iFrame as an HTML banner. Just don't expect tracking to work! ?

Hi @420, Can you please raise a bug in GitHub for this, if you haven't already? The date formatting should be consistent across all pages. (Of course, I'll argue that YYYY-MM-DD is the only acceptable date format to ever use, but that's beside the point... :-))

Hey @gabrielt, No, no news unfortunately - I've got a 3 week stretch coming up soon in which I hope to really bash out some stuff for Revive, but then again, I might be flat out with some consulting gigs I have going on at the moment... We need to find a way to push our Patreon numbers up, so I don't need to do so much consulting! ?

That's good! It is recommended that you do. That's not quite correct. If you are using MyISAM tables, then table level locking always occurs. Every single write to the table results in the whole table being locked, so only one write can happen at a time. What you really mean is that when you get heavy traffic, the table level locking starts to become a problem, and things don't work, because processes start to have to wait too long for their turn to lock the table, and things break. Running maintenance will delete rows from the data bucket tables - but that's irrelevant. Revive Adserver is quite efficient in how it records impression data, so there's not really any limit to the number of rows it can have (other than what MySQL or PostgreSQL impose). The real issue with running out of connections to the database is (probably) because connections are staying around for so long, because they have to wait for so long to complete their writes, because you are using MyISAM, which uses table level locking. The solution is to move to InnoDB tables (or PostgreSQL).

Well, the error you are seeing seems pretty clear: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'https://imasdk.googleapis.com' is therefore not allowed access. Seems like setting something other than the wildcard might help?

Hi @Jim, No, this is not something I have done before. However, at a general level, an MRAID banner is just HTML5/JavaScript, right? If so, then I would try delivering one as an HTML5 banner type, and see how that goes?

Does this help? https://documentation.revive-adserver.com/display/DOCS/Server+Cross+Domain+Policy

Ah, thank you. I did not know about that one. I will look into getting this changed. What you should be doing is setting appropriate read/write permissions for your system. Yes, Revive Adserver is our software - but it's not a complete solution. It needs a webserver, and an operating system underneath it as well, and those things vary greatly, and you can set things up there in a huge number of ways. It's like getting a new car radio, and the manual says before you install the new radio, make sure your car is switched off, and the handbrake is on, but then complaining that the car radio manual doesn't give you exact details on how to switch off your car and apply the handbrake for your exact car. Would you really expect the manual to document every single possible car model in the world, and describe how to do those things? No, you'd expect that the general information is sufficient, because if you're not sure how to do those things with your car, then it's reasonable to expect you to go away and look in the car's manual on how to do that. We expect the same thing - we tell you that you need to set read/write permissions on certain files and directories, and we expect you to look at your webserver/operating system manual, and do so in an appropriate way for your needs. And that's kind of the point - what you would do may or may not be suitable for everyone. Well, we do, in a way - we say what files and directories need to have read/write permissions by the webserver that's delivering the site. That's the minimum required, and if you do this in a way that's appropriate for your setup, then you will be good.

Correct - which is why I have not said that you should use chmod 777. I think my previous reply was quite correct - read/write access is required (for full Revive Adserver functionality - you can prevent write access to your configuration files if you want to lock down changes to the files via the admin UI, but that's a separate issue), and chmod 777 is a convenient way for users to do that - but it not what I recommend, and it's not what the documentation says. I think I have been precise - what is required is read/write access from the web server. There are several ways to achieve that, and chmod 777 is the worst way, which is why we don't say that in the docs, and say (more precisely) what read/write permissions are needed. No, I don't believe that at any point have I said in the forums, or in the documentation, that you should chmod 777 anything. If you do see that written somewhere, especially in the documentation, though, please let me know, and I will happily fix it. I respectfully disagree with you here. I do not believe that our documentation should advise anyone to use chmod 777 for anything. It is an overly permissive approach that I do not recommend. Sometimes, for some users, it's the right way to get the job done - but there are better approaches. However, as always, what is important to some users is not relevant to others, so, we leave it to the user to decide the best approach of assigning the read/write permissions required for their individual circumstances. (For example, if you have a physically secure server, that has no general user access to it, then chmod 777 may well be a perfectly acceptable approach for you. But I'm not going to recommend chmod 777 in our docs.)

Hi @Rob, It depends what you mean by "possible to instead implement". If you mean "is there a setting in Revive Adserver that I can flip, and it works on IP, rather than cookies", then the answer is no. If you mean "is it possible to alter the code base so that it works a different way", then the answer is yes.

Patience my friend. No, the conf files don't have to have 777 permissions. The various conf files only need to be writable by the web server user, if you want to update the configuration via the web UI. If you don't want to do that, then you don't need to have any write permissions on the config files - so long as the web server can read them, then you are good. However, under Revive Adserver's var directory, there are a number of subdirectories, and both var and all of the subdirectories, and their subdirectories, etc. are where Revive stores and caches all kinds of data. All of these directories and their files must be able to be read and written by the web server user. 777 is not needed, but you will need an approach that allows the correct level of access - for many users with limited Unix experience, 777 is therefore a convenient approach.

Hi, Please remember that MyISAM tables implement table-level locking. So, during delivery of banners, only one banner can be logged at a time. The use of InnoDB may be more appropriate, given that it supports row level locking. While general database support is somewhat beyond the scope of this forum, please remember to always back up your database before making any changes!

No, you can't. Data is inserted into the table in real time as delivery happens (which cannot be changed), and is read from the table every time maintenance runs and the data needs to be summarised. This should happen hourly when maintenance runs - it should not be a single, massive update once a day that takes a couple of hours. It sounds to me more like the issue is that you are having database issues under delivery load, rather than because of maintenance. What database are you using? MySQL? Are you using MyISAM tables? What monitoring do you have in place on your server? How many DB connections are permitted? Can you add more? Have you checked if your setup is leaving database connections open that could be closed, and if so, have you tried tuning that?

Yes.

Hi, The domain that is passed in as the parameter to the crontab entry to run maintenance should match the domain that the Admin UI runs on. As you are talking about a single install of Revive Adserver, with multiple URLs in use, you only need one crontab entry, as it doesn't matter what URL is used to access the UI or deliver banners, it's all the same database & set of statistics. See also https://documentation.revive-adserver.com/display/DOCS/Managing+Configuration+Files

Maybe have a look at https://documentation.revive-adserver.com/display/DOCS/Impressions+are+Too+Low and https://www.revive-adserver.com/faq/troubleshooting-banner-delivery/ for starters...

On my list for https://documentation.revive-adserver.com/display/DOCS/Site+Delivery+Rules#SiteDeliveryRules-Site-Source and I will document as soon as I can.

The data_bkt_m table is updated in real time as impressions for delivery are logged. The maintenance process will read from, and delete rows, from that table - but not insert anything.