Jump to content

w-sky

Approved members
  • Posts

    34
  • Joined

  • Last visited

About w-sky

Recent Profile Visitors

3556 profile views

w-sky's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. 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.
  2. 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.
  3. 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));
  4. 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.
  5. 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?
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. 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.
  11. 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. :(
  12. 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
  13. 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?
  14. I too found this user and deleted it. But nothing suspicious seems to be going on on our server. How do I make sure? Currently using Revive Adserver v4.0.2 running on Apache, PHP 7.1.15 and MySQL 5.7.21-1.
  15. Hi there. I joined this discussion earlier, before you guys started to get really into technical details. Which is great. :) Unfortunately I can not contribute very much, but might I suggest something: I really think, especially considering the problems with more complex or unique banner codes etc., two simple and elegant solutions while using the same simple banner code for email banners as now: Make revive swap the banner & link which are returned for this email zone. Maybe a) on a timely basis, trying to make it equally shared for all campaigns in that zone according to their probability or b) swap on each delivery, or each 10th/100th delivery again equally shared for all campaigns. What do you think?
×
×
  • Create New...