w-sky

Hi there, I would like to temporarily replace a banner from a campaign with a different motif and have used the delivery rules for this: The normal banner from this campaign is only displayed before and after the special banner time period, the special banner only within this period. So that one banner from this campaign is always visible, but a different one during a certain period. If I now look at the probabilities of the zone, each of the 2 banners from this campaign (supposedly) only has half the probability that it should have: Instead of 25% as there are 4 banners in the zone, both have 12.5% – though one is always inactive due to delivery rules. My big question: Is that correct, or are the shown percentages incorrect due to my delivery rules? What happens when Revive's random generator with a 12.5% probability selects the banner that is not currently displayed: Will the other banner from the campaign then be displayed so that it ends up with 25% probability, or will Revive skip this one and randomly select again from all the banners, so that the campaign is reduced to 12.5% probability?

Hi there. I have many image banners (jpg, png or gif) and a few HTML5 banners. Strangely, the impression count for HTML5 banners is always higher by more than factor 100. The count for image banners is correct, it is close to our page views. But the HTML5 banner count is completely wrong. (The site is https://hanfjournal.de/)

I can not find the part on the page linked above about how to disable the cookie. It says that the cookie is not necessary at all, but then only explains how to rename it. 🤔 PS: I tried what happens when I remove the line "viewerId=OAID" or change it to "viewerId=" or "viewerId=none", but in all those cases, Revive just does not work anymore. It must have a viewerId other than none.

We finally got HTML5 banners working again with Revive. Unfortunately I cannot say what exactly the source of the problem was. My colleague re-created the banners using the latest version of Google Web Designer where he specifically checked the click tag settings before exporting. Important is to use the "export" option of Web Designer, not the "save" option to create the final .zip file. Also we have noticed that there might be problems with the click tag that depend on the browser or browser version. With Chrome based browsers there seem to be the least problems.

PS: This is the clicktag script which Web Designer is using: var clickTag = "{target URL}"; window.open((function(url, param, defVal) { var p = url.split('?'); p = p.length < 2 ? "" : p[1]; var vars = p.split("&"); var res = defVal, v; for (var i = 0; i < vars.length; i++) { v = vars[i].split('='); if (v.length < 2 || v[0] !== param) { continue; } res = decodeURIComponent(v[1]); break; } return res; })(window.location.href, "clickTag", clickTag));

Is it possible that I am the only one having this problem? The effect is clear: The linked URL starts with the actual URL of the image itself then followed by the almost correct delivery URL, but encoded. Somehow the image URL is pushed in front of it. Have the requirements changed for the HTML5 banner file? I am using a .ZIP file which was created with Google Web Designer. I can't see any other options in Revive to control the link behavior and the saved target link in banner settings is correct.

Hello, we were using a few HTML5 banners but as it seems, since updating to Revive 5.2.1 those are not working correctly any more. The banners still display fine, but the link on click is broken, this is an example link: https://www.hanfjournal.de/openx/www/images/5d5132924a96e18d55a541ebe5fa2af0/https%3A%2F%2Fwww.hanfjournal.de%2Fopenx%2Fwww%2Fdelivery%2Fcl.php%3Fbannerid%3D251%26zoneid%3D0%26log%3Dno%26sig%3Ddb36aed1622db195420c0b9c1cbfa7b918d62b0d62f4e65b8bc1779544b44e31%26oadest%3Dhttps%3A%2F%2Fwww.hanfzart.de%2F The actual destination is https://www.hanfzart.de/ How can we fix this?

Question: Is it always necessary to manually add the two code segments above to the HTML5 banner files to make the banner link setting work and enable counting of clicks in Revive? Recently I got a HTML5 banner for the first time and saved a destination URL exactly like shown above, but still the banner was not linked to anything. I asked my graphics colleague if he can add a link with Google Web Designer and so he did. Clicking on the banner does work, but the URL saved at Revive banner settings does not have any effect.

Thanks a lot! I guess I did not search enough, because I did not find those articles. ? Anyway, I have imported the code for the 3 plugins in question and seen from the backend, all seems to be fine. Only at the details of "IAB VAST Video Player Plugin" and "IAB VAST Report Plugin" there is not table at all. (So also not a number in the Group column as a sign of a broken plugin.) But maybe this is normal? Also, the /www/admin/extensions folder and its contents have not been re-created by importing the code … I am not sure if it's really fixed. I did/do not notice any malfunctions, except during update, but I am not using Video ads.

Hello there. I just updated to 4.2.1 and found a problem while importing plugins using the upgrade wizard, which probably was caused during the previous update. The mistake during the previous update was to enter a path containing ~ as path of the previous installation, and because this failed copying the plugins folder manually. From install.log during this update now, with correct full path given, I found that the wizard was unable to find many files in "/www/admin/extensions/" (most in "/www/admin/extensions/videoReport/") and one specific file "/extensions/bannerTypeText/oxText/genericText.delivery.php" I searched the folders of the old (4.2.0) installation and the new, but both "extensions" folders do not exist at all. According to the log, at the end 3 plugins failed to import correctly: Plugin: openXBannerTypes - Unable to locate XML files Plugin: openXDeliveryLimitations - Unable to locate XML files Plugin: openXVideoAds - Unable to locate XML files However, all plugins are shown now in Admin menu, no errors or warnings here, and Revive 4.2.1 is working fine. Note that we are not using Video ads… but I am sure the plugins installation is not valid. How can I check the consistency and how can I fix this? Should I uninstall the plugins and reinstall them?

Hi there, time and again a customer asks us to add a nofollow tag to the banner link, whether it makes sense or not, and because I see there is no way to edit link rel-tags for only one specific banner, I usually unlink the "real" banner from zones, create a second HTML only banner, where I enter the desired code with the banner file as image source, and link this one to the zone(s). Working well, but tracking does not work. If I allow the html code to be changed for tracking (default), this code will end up in the page source: … title="xyz" rel="nofollow noopener"target="_blank"><img … (missing space before target!) while the original code was either one of those (no difference in result): … title="xyz" rel="nofollow noopener" target="_blank"> … title="xyz" target="_blank" rel="nofollow noopener"> … title="xyz" rel="nofollow noopener" > Anyway, my first "Feature Request" is to add a simple option at banner details to enable/disable rel=nofollow. Second request is an option to enable a direct link for a banner instead of the Revive delivery URL, which sadly would disable tracking, but having a direct link is another request from some of our customers. For now I also create a HTML only banner to make this happening. PS: I found there is a way to add rel="nofollow" for all banners, just mentioning, but this does not help me.

Unfortunately I can't. The list of PHP settings in my post above are ALL settings which are available to me (using a "managed server"). For any other changes to PHP settings I will have to open a support ticket at my hoster and ask them to change the configuration, and they might not agree since it is not a PHP error.

Here are all PHP configuration options and their current settings which are available from my hoster: display_errors – off allow_url_fopen – off expose_php – off mbstring.func_overload – 0 memory_limit – 160M max_execution_time – 60 upload_max_filesize – 30M max_file_uploads – 20 max_input_vars – 1000 extensions – none (available: APC, ImageMagick) zend_extensions – none (available: Ioncube Loader, Source Guardian, eAccelerator, Zend Guard, OPcache, XDebug) However I think none of these will help with mail problems. :(

It is not resolved, at least for us. Until August 2017 everything was fine: the "From:" address of all Revive mails was exactly as saved in settings. Since then, it is looking like this: From: a <[email protected]> "server01" is the technical server name (not our domain name) and "our-hoster.com" is the domain name of our hosting service. Where the "a" does come from, I do not know. I am not sure what has happened in August 2017. Maybe it started with PHP updates? We were using 7.0 in 2017, now 7.1, soon 7.2

Hi there, we are using the Revive adserver since many years on our system, even when it was called „openx“, but now of course it is the latest version of Revive. Running perfectly fine and smooth. :) We never changed the local path and URL and so it still is like oursite.com/openx/www/admin and the local path is like …user/web/openx/ for the Revive installation. But „OpenX“ is a commercial service nowadays and it might be confusing for our customers using the address "oursite.com/openx" for our own Revive ad server. How complex and what are the steps to change the local path and URL of Revive without any interruption of function? Apparently I would have to update all Revive code fragments on all pages using our ads too. (Here it is 5 Sites * 5 Banner zones + a few extra zones = ~30 edits to page templates or widget codes.) Considering the work, maybe this is just utterly unimportant. What do you think?