andrewatfornax

Hi @Maik,
Glad to hear you resolve the issue. 
Website user logins are pretty basic in Revive Adserver - there are not really any options to control what the users can or cannot see - so, in short, what they see is what they see. There's no way to reduce the level of access that they have.

Just want to follow up on this issue and say that I decided to upgrade Revive, thinking that maybe a fresh install would solve some of these issues.  While I was upgrading Revive from version 3.x to 4.0.2, I hit an issue with not being able to access the admin dashboard due to Varnish cache.  I jumped on a chat with Dreamhost about the limitations of their DreamPress product and found out that since it's a managed WordPress type thing, they don't allow any 3rd party tools or software to be installed in a subdirectory, which is why my statistics stopped reporting after the server switch.  Thankfully my old shared server is still accessible, so I plopped a new instance of Revive on there and the migration/upgrade process went swimmingly and now I'm back up serving ads as good as new.

Hi @drew_atx,
https://documentation.revive-adserver.com/display/DOCS/Only+One+Active+Banner+in+Email-Newsletter+Zones ?

Thanks. We moved application to the another server. Next, we updated it to the latest version (4.01). The problem solved.

Terribly sorry, just after I posted this I found that I can download a .DAT file from Maxmind which I've just installed, updated the plug and voila! it works!
Thanks
Russ.

Yes!

Thank you for your quick response! I'm glad to hear that 3.0.6 should function OK with PHP 5.4. It's a delicate dance trying to upgrade from this far back in the PHP lifespan. Fingers crossed that I can do it without having to roll back.
Thanks again,
Kim

Hello Everybody,

Can anybody make some suggestions on fixing this?
http://forum.revive-adserver.com/topic/1940-login-popup-error-but-no-error-in-debuglog-please-help-me/
I'm stuck on this error & I can't go any farther, until I correct this error.
Thank You for Your time!
Rube

I found (my) problem .. the test file (http://goo.gl/e1bvIk) works fine now.
My mistake, apologies to programmers.
In the /rv-ads/www/delivery/ folder, i added this line of code: MAX_header( 'X-Robots-Tag: noindex, nofollow', true); to some of the files there, in order to exclude the robots.txt and return ads with header checker 'noindex, nofollow'. The error was to add such code into asyncjs.php, which was useless and was the cause of the error.
I can now exclude the robots restriction. If i check the header of the ads url/path, it returns: X-Robots-Tag: noindex, nofollow.

Good job for finding the problem, Luna :) (y)

A premium rate, that's a fine idea :)
 

helo, i hosted on hostgator, i canot switch typoe account, i using cloud flare, i dontknow why this.

Please don't post the same question twice.

There's a few threads on here which might be worth reading through:
http://forum.revive-adserver.com/topic/1385-using-ssl-for-serving-ads/?hl=https http://forum.revive-adserver.com/topic/322-serving-ads-over-https-fails/?hl=https http://forum.revive-adserver.com/topic/1404-serving-ads-from-https-not-working/?hl=https HTH.

Since this is a third party plugin, I suggest you contact the vendor for support on their product.

One of the more frequently asked questions that we see about Revive Adserver is about VAST support. People want to know why Revive Adserver doesn’t support VAST 2.0 or VAST 3.0 out of the box.
Well, here’s why.
When we took over what was OpenX Source and re-named it Revive Adserver back in 2013, all we hoped for was the chance to allow the project to grow once again – and it has done so, beyond all expectations. We now have over 6,000 users of Revive Adserver, we’ve released 10 updates to the software, and closed 337 issues in GitHub, including numerous security fixes.
We’ve also been extremely proud to introduce a number of brand new features to the software that users have wanted for years – such as asynchronous JavaScript delivery tags, logging of blank impressions and improvements to the delivery algorithm for better campaign delivery.
The amazing team of developers who volunteer their time to Revive Adserver are dedicated to making as much happen as possible, as soon as possible – but the truth is that there is always going to be more work than time, so there will always be some users who are disappointed that the feature they want the most isn’t included out of the box.
You may be aware that VAST 2.0 support is available for Revive Adserver via the (commercial) Advanced Video Ads plugin for Revive Adserver. This plugin was developed by two of the volunteer members of the Revive Adserver team before Revive Adserver was formed. Given their time and effort to create this commercial plugin, it would be unfair to ask them to open source this plugin.
However, in the event that anyone else chooses to develop or otherwise open source a VAST plugin for Revive Adserver that is suitable, then as a project, we would not hesitate to include such a plugin in the core product.
So, to everyone who feels that VAST 2.0 or 3.0 support should be in the core of Revive Adserver, we’re sorry that it’s not there already. We’d love it to be there as much as you – but as a project based on the goodwill of its members to create code for free and release it as open source, we can only deliver what the community puts in. If something suitable is donated, then we’ll absolutely include it.
Until that day, however, I hope that you’ll understand, and appreciate everything that Revive Adserver does, completely freely and openly.
Sincerely,
Andrew Hill


View the full article

Hi,
 
Thanks for your reply.
 
Sorry I wasn't actually clear - my fill rate from my ad server is 100%.
 
I'm partnered with Blinkx Media (http://www.blinkxmedia.com/) and now that I'm serving ads in friendly iframes my fill rate of paying ads has dropped to 20% and Blinkx Media are passing the ad requests over to my in-house passback ads - I hope that makes sense.
 
According to this blog post from monitize more - they've experienced a similar problem as well (http://www.monetizemore.com/blog/are-the-new-dfp-ad-tags-gpts-decreasing-your-ad-revenue/).
 
For some reason, even though the iframes are on the same domain as my website (i.e. firendly iframes) they are still affecting real time bidding ad revenue. Maybe advertising are not getting the info they need or something - I'm not sure.
 
It's really hard to balance performance with ad revenue.
 
I realise this is a tricky issue, but I'm really not sure how to proceed - its amazing to have a community like this to turn to.
 
Thank you for all your help and thoughts.
 
Ben

Hi,
 
I've just got off the phone with my ad network and they have confirmed that their adserver AdConductor can not handle asynchronous tags so the issue was on their end.
 
Thank you for your help.
 
Cheers,
 
Ben 

Async tags use a friendly iframe, so RTB systems shouldn't mind. Most likely cause is that your pages are loading faster now, but the async tags mean the visitors never see the ads because your own ad server is slow.

I use Version 3.1.0
When i create overlay ad, I can't find the box to fill the link when click banner.
Help me

Please do not double post the same question.

This is a known issue in v3.1.0 which has been fixed in v3.2.0.

This has now been resolved I went through the stages on this  http://www.openxtips.com/2009/06/tip-14-troubleshooting-banner-delivery/   and it was my ad blocker when i disabled it the banners showed straight away. ;-(  

Had exactly the same problem.
In the end the problem was that if you supply an HTML banner, and the zone is rendered under SSL, Revive performs a check if there is any SSL-unsafe code in the banner. If it does detect that kind of code, the the banner is simply not delivered.
In my case, I have added banner with the following type of code: <iframe src=http://...></iframe>
The snippet that loaded from SSL URL of Revive did not serve that banner, while non-SSL version of snippet did.

Hey Snoork,   I have now switched from suPHP to PHP5-FPM/Fastcgi and the only caching I have is OPCache which is part of PHP5.5, which I have disabled via .user.ini.   I have also disabled the mod_expires config for that virtualhost and it's working correctly now, thanks!