andrewatfornax

We don't log this in Revive Adserver for performance reasons.

I was pretty sure comma would work - maybe try space separated? Things like full stop, plus and minus won't work, they are valid characters in an email address. It may depends on your SMTP server. The other option would be to create a distribution list, and email the reports to there.

You would need to review your webserver logs for suspicious activity.

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

Hi @fenbox, Revive Adserver displays (at most) one banner in each zone on a website. So, if you want to display multiple banners, you need to add more zones to the website (either different zones, or multiple instances of the same zone, as meets your needs).

Not sure what you mean. If you've checked the logs, where are the extra clicks coming from, and have you blocked them? Otherwise, have you considered the IAB spiders/bots list?

https://documentation.revive-adserver.com/display/DOCS/Clicks+are+Too+High

No ETA yet, but we are working on the next release currently.

Hi @ajotadmin, It would be very difficult to take a clean install, and then, later on, try and merge in specific stats from an older, different instance, because the statistics are all stored relative to the IDs of the entities. This means that with your clean install having been used, the IDs are likely to be different, so merging things in would be pretty much impossible to do. It might be better to use your pre-upgrade backup of the database and code base to simply restore the old instance in a separate location, so that you can historically access the stats there via a different URL, to allow your advertisers to get the stats they need from before the migration to the clean install?

Hi @Adam, To the best of my knowledge, Revive Adserver does not modify the images uploaded for banners in any way. Therefore, I can only assume that either: 1. The JPEG banners you are uploading are already are already compressed; or 2. Your web server + PHP configuration is set to perform compression when delivering images, which is causing the issue. If not #1, then take a look at #2. HTH.

https://github.com/revive-adserver/revive-adserver/issues/943 ?

Hi @w-sky, Luckily, you can change the URL, and still have your old tags work. The process would be something like: 1. Move the Revive Adserver code base to the new desired location on disk, if that is changing. 2. Update your web server to deal with the new location on disk (if changed in #1 above). 3. Update your web server (if required) to ensure that Revive Adserver is served using the path as required, if not already performed via the change made in #1 / #2 above. 4. Check that everything is now working using the new URL. 5. Finally, update your web server to add in an either an alias, or an HTTP re-direct (as per your preference) so that requests to the old URL continue to work as well. Obviously, in an ideal world, set up a test environment that replicates your current environment first, and test the process there, to make sure you know what you are doing before you take things down!

No. It might make more sense to start a new topic, as this doesn't seem to be related, and put some more details in (e.g. screenshots of what you are seeing).

https://documentation.revive-adserver.com/display/DOCS/No+Statistics

Hi, If you transferred the code base to a new server, but not the database, then if everything was still working, then either: 1. The URL was still pointing at the old server (and the code base was still in place there); or 2. The URL was pointing at the new server, but the new server was talking to the database on the old server. Assuming it's the latter, then I would put the code base back that was there before you did a fresh install, and then migrate your DB over to the new server, and update your configuration file to point to the DB on the new server.

I think the closest that we have to this is https://github.com/revive-adserver/revive-adserver/issues/370 in the backlog. I did take a look at this at one point, but didn't make much progress unfortunately.

https://documentation.revive-adserver.com/display/DOCS/No+Statistics

Should work just fine. As always, take a backup of your database (and check that it's a good backup that you can use to restore from if required) before you convert, but I've run Revive Adserver against InnoDB tables before.

What time was it? It's not just that the hourly maintenance hasn't run yet?

The plugin is bundled in the release package itself, so just check what version is included in the 4.1.1 package.

Correct!

Rename the configuration file to match the new domain name, and check the "default" configuration file contents as well. https://documentation.revive-adserver.com/display/DOCS/Managing+Configuration+Files

Works fine for me.

Looks to me from the error message like it's a performance issue, not CORS. That's what the message says after all.

Ech. Outside of the advice on that link above, it's a pretty thankless task trying to clean up a hacked server. You can try the usual places (here on the forums, UpWork, etc.) but I don't often see people wanting to pick up those kinds of jobs. Best thing I would do is start with a fresh server, and a fresh install, and create the campaigns etc. you need from scratch. It's a lot of boring work, but it's not really any less boring that trying to clean out a hacked instance, and will probably be faster and give a safer, more reliable result.