Matteo Beccati

Revive only supports the main clickTag. They should also be using the JS variable thereafter, not an <a href

I'm sorry, magic macros aren't supported in HTML5 banners. You should stick to the default, which is using clickTAGs. You should kindly ask your client to comply.

Hi @tkat https://support.google.com/dcm/partner/answer/3145300?hl=en Look for Simple ClickTag insertion.

@andrewatfornax maybe the plugin requires the revive-id field used in the async tags? @melamoccicata If so, just generate an asynchronous invocation code and copy the revive-id html attiribute value.

The setting is in the webserver hosting Revive Adserver.

@Maro Sorry, I can't possibly know how your servers are configured. Wordpress is not involved in that though.

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

@Maro withCredentials is required, as some features use cookies. Your webserver must be overwriting the Access-Control-Allow-Origin header sent by Revive.

Every delivery scripts, except async JS, sends the Access-Control-Allow-Origin: * header, but not Access-Control-Allow-Credentials. I wasn't aware of VAST1 compatible JS HTML5 video players, but it seems like there are some?

@Tomislav An easy fix is to comment out the check itself (lib/OX/Admin/UI/SessionStorage.php ), but my suggestion would be to move to another hosting provider.

@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.

@jhrockers Sorry it's not. document.getElementById("clickTag").addEventListener("click", clickthrough); is not what has been suggested to you.

Nginx is listening on port 80, yet you talk about 8080.

Sorry, that's very little information for us to help. Is this a brand new install? Are you trying to install it right now? Do you have a config file for the domain you're using? Anything in the nginx or fpm log files? Anything in Revive's own var/debug.log?

@tobean I understand, but I think you can easily do that using :after CSS rules or something else on your website. It doesn't seem to me that AdSense prints a line of text below the banners at all.

The technical reason is that the banner text is appended to the HTML of the ad itself, which is then rendered inside an iframe that cannot account for the extra height. To be fair, text below banner seems to me a legacy feature that I haven't seen on any website since the early 2000s and I'd be more than happy to see it going.

@realites Thanks for your report. Could you please send over the zip file via PM or email? I have created an issue on github: https://github.com/revive-adserver/revive-adserver/issues/924

I'm afraid that this is currently not possible out of the box. Possible solutions could be writing a custom plugin or some custom JS interacting with the async delivery events (4.1.x only).

@rpijlman Thanks for your report. We'll look into it.

@clnsdev The field type definition should be "text NOT NULL", that's why Revive is complaining. It is possible that varchar(0) is wrongly treated as being a text field, and if so that would be a bug.

@clnsdev Could you please post here just the definition of the append/prepend fields in the banner and zones table? I.e. from SHOW CREATE TABLE ox_zones

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

@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.

@mibert @Richard Cook Do you remember which was the first version of Revive / OpenX Source / OpenAds / phpAdsNew you installed?