Matteo Beccati

To everyone else that I haven't already contacted, if you are interested to help pls PM me. I'll send you my IP and SSH key to see if I can find any more clues.

data-revive-id is a hash calculated using the delivery and deliverySSL config values.
@Adi The old one had "www" in the path while the new one doesn't, that's why you're getting a different id.

What you're looking for is not IAB VAST compliant video ads provided by the bundled plugin, as they are more like what you see on YouTube: commercials before/after actual content videos and overlays. That's also what our VidiX plugin is about.
 
What you're looking for is a regular banner that shows a video, which is something we can also provide by means of the In-Banner Video Ads plugin.
 
Otherwise, a quick (and free) solution would be to put your HTML5 video code in a regular HTML banner and serve it on the website like any other banner.

It's a known incompatibility with the utf8mb4 charset: https://github.com/revive-adserver/revive-adserver/issues/740

@olabre See my original reply. Testing upgrades from 2.0.11-pr1 is now part of the release process. Tags should also be compatible, as long as you are not using functionalities that have been removed.

@OMG I believe you just need to make sure that This banner can be safely displayed inside an iframe (e.g. is not expandable) is checked in the banner-edit screen.

Your Apache or nginx is most likely configured to set the wildcard header, as Revive uses the Origin domain for async calls.

The setting is in the webserver hosting Revive Adserver.

@jhrockers I'm sorry, I can't possibly debug and fix the banners for all the Revive Adserver users. My suggestion would be to hire someone with basic JS / HTML5 skills who should be able to fix the code for you.

Hello everyone!
Chances are that we won't be able to release a 4.1.1 final next week, but in the meantime it would be great if you could test on your staging environment this pre-release package that should fix the upgrade problems that you reported (along with the actual upgrade from phpAdsNew itself, which was broken since 3.2).
You can download the beta packages here:
revive-adserver-4.1.1-beta.tar.bz2 (sha256: bf515eb36f6fc00fef0ee919e9ff50e612e31b5e54d10dff7f3726db8f7d6653) revive-adserver-4.1.1-beta.tar.gz (sha256: 4315a107d5459492994c7097268ed2f10b91b0bcaf5498ff18e557f126eb81a9) revive-adserver-4.1.1-beta.zip (sha256: 4111dc824175b98833c516e57a188951d34337d93fc171ca51101329955e47b5)

Hello everyone!
Chances are that we won't be able to release a 4.1.1 final next week, but in the meantime it would be great if you could test on your staging environment this pre-release package that should fix the upgrade problems that you reported (along with the actual upgrade from phpAdsNew itself, which was broken since 3.2).
You can download the beta packages here:
revive-adserver-4.1.1-beta.tar.bz2 (sha256: bf515eb36f6fc00fef0ee919e9ff50e612e31b5e54d10dff7f3726db8f7d6653) revive-adserver-4.1.1-beta.tar.gz (sha256: 4315a107d5459492994c7097268ed2f10b91b0bcaf5498ff18e557f126eb81a9) revive-adserver-4.1.1-beta.zip (sha256: 4111dc824175b98833c516e57a188951d34337d93fc171ca51101329955e47b5)

For reference, I've created the issue on github: https://github.com/revive-adserver/revive-adserver/issues/900

For reference, I've created the issue on github: https://github.com/revive-adserver/revive-adserver/issues/900

@mibert Thanks, that should be enough. That makes two of you having the issue using a database that was originally created during the phpAdsNew era.
I'd suggest to keep using 4.0.2 until a fix or workaround is found.

FYI, I've created an issue on github: https://github.com/revive-adserver/revive-adserver/issues/872

FYI, I've created an issue on github: https://github.com/revive-adserver/revive-adserver/issues/872

Hi @netvillage,
yes, it is normal. It is a generated value that should be unique for each Revive Adserver instance.

@Sperber Please upgrade to the latest version. The issue has been fixed in 4.0.1.

Plugin installation / upgrade has been designed to be run unattended. I'm not really sure it would be wise to add a hook for what you have in mind.
 
What I did with a plugin that requires some action is adding a warning on the left bar to tell the admin user that some additional configuration is required, e.g.
 

 
Feel free to have a look: https://github.com/adserverplugins/apLoader/blob/master/www/admin/plugins/apLoader/apLoader.class.php#L37

Then you've found your problem. PHP 5.4.4 doesn't match the requirements:

 
 
Because:
 

For reference, this has been fixed in 3.1.0.

This might be related to required functions being disabled, e.g. parse_ini_file.
 
Please replace your pre-check.php file with the one available here and you might see a nice error screen instead of all those error messages.

Yes, that's pretty unfortunate. We were hoping that this kind of bugs could be identified and reported during the beta period. For now, I've created a bug report: https://github.com/revive-adserver/revive-adserver/issues/529

@andrewatfornax I believe the original poster just put
OA_show(2); multiple times on the same page...

If you are serving 3rd party content, then the malware might be coming from them.