gabrielt

Thanks @andrewatfornax! I didn't realize that you have a Patreon account. I've been using your software since phpAdsNew. I wanted to make a single donation, but it seems Patreon requires a monthly donation... ?

Hi guys, The RTB networks we use are all moving to header bidding, which, AFAIK, Revive doesn't support. Any news or update on this? I really don't like DFP, but it seems we will need to migrate to it... :( Cheers, Gabe.

@andrewatfornax Yep, it was a zone configuration error, as the banners were linked to the wrong zones. Therefore, no need for this topic, as it was my mistake, and you can delete it. Thanks.

Update: I think I found the culprit: It was a zone linking issue. I had the campaigns linked to certain zones but the banners linked to different zones... It seems this mismatch caused the issue when Revive tried to obey both configurations. I will have a definitive answer after lettting it run for a couple of days, but I am pretty confident that this was the issue indeed.

Hi, Everything was working fine in the previous months, but today when collecting data and generating our monthly reports to our advertisers, a noticed a big mismatch in numbers, which I started to investigate because the numbers where much lower than those from previous numbers. Here is what I found. A campaign configured as "Override", i.e. to be displayed 100% of the time in two zones. The number of views reported by the campaign stats page is completely different from the number of views reported by the zone stats page. See below. Interesting enough, the number of views reported for the campaigns is around half of the number of views reported for the zone. This campaign has a total of six banners, three of which configured to show if the OS is either Windows, OS X or Linux, and the other three is the OS is Android, Blackberry, iOS or Windows Phone. Maybe the problem is with this configuration? I wanted a way to select three banners for desktop and three for mobile, and this was the only workaround I could think of. There were also a bunch of old disabled banners that I deleted today to see if it helps (I will have to check if that worked after a few days). Another weird behavior was for a ROS (Run of Site) campaign, which was underdelivered according to the campaign stats. We configured it to be displayed 500,000 times, and we have plenty of impressions in the selected zones to fulfill this order. But see how Revive was delivering too few impressions at the beginning of the month and then tried to speed up. It ended up being delivered only around 420,000 times. I have no idea as how to start debbuging this. Please advise! Thank you in advance, Gabriel.

@Matteo Beccati Just to confirm that the new 4.1.1 version solved the issue. Many thanks for fixing this promptly. PS: on the downloads page, the link to the 4.1.1 tar.gz version is pointing to the 4.1.0 version. I am not facing the issue mentioned by @Richard Cook above. For me opening /www/admin/updates-product.php shows: You are currently using Revive Adserver v4.1.1 running on nginx 1.12.1, PHP 7.1.11 and MySQL 5.6.37-82.2-log. Cheers.

@Matteo Beccati Thank you so much for the amazing support.

@Matteo Beccati Thanks for all your help. I will wait until an official solution is released, as clearly this is happening with other people as well, and the common thing is that we are all using Revive since it was phpAdsNew...

How do I do that?

Hi @Matteo Beccati, I really appreciate your help. This might be due to either Percona or a legacy upgrade -- we've been using Revive since it was called phpAdsNew. I've never manipulated the database directly. Either way, I need instructions on how to fix this.

PHP 7.1.10 MySQL: Percona 5.6.37 Extension: MySQLi schema-only database dump Note: it would be nice if we could attach files here... :-/ PS: I noticed that on the above dump the engine is set to MyISAM while we use InnoDB.

@andrewatfornax MySQL

Hi there, I am getting this error while trying to upgrade: Errors were found when detecting previous installations of Revive Adserver We have detected integrity issues with your database. This means that the layout of your database differs from what we expect it to be. This could be due to customization of your database. The install.log shows that there are 107 errors. See below. I haven't customized anything, and I don't know how to fix these issues. Please advise. Gabriel. ---- ========================================================================= Attempting to detect an existing Openads (aka. phpAdsNew) installation... PAN not detected Attempting to detect an existing Openads (aka. Max Media Manager 0.1) installation... MMM v0.1 not detected Attempting to detect an existing Openads (aka. Max Media Manager 0.3) installation... MMM v0.3 not detected Attempting to detect an existing Revive Adserver installation... schema file found: [redacted]/etc/changes/schema_tables_core_621.xml schema definition from cache TRUE successfully parsed the schema schema name: openads schema version: 621 schema status: final running integrity check comparing database [redacted] with schema [redacted]/etc/changes/schema_tables_core_621.xml column definition does not match: account_preference_assoc.account_id column definition does not match: account_user_assoc.account_id column definition does not match: account_user_permission_assoc.account_id column definition does not match: ad_category_assoc.category_id column definition does not match: affiliates.updated column definition does not match: affiliates_extra.affiliateid column definition does not match: agency.updated column definition does not match: audit.actionid column definition does not match: banners.acl_plugins column definition does not match: campaigns.updated [... snip ...] checking field: phpads_zones updated found field updated #! database integrity check detected problems with the database #! 107 fields to change

Fixed sizes have to do the way the web traditionally works. You have to keep in mind that "responsive" is a somewhat new concept. The web is about 20 years old and we've only seen responsive layouts in the past 2-3 years. That said, it would be great to have a built-in mechanism to detect the maximum width supported and display a banner that fits that space. For example, today we can setup a campaign with, say, two banner sizes, 728x90 and 300x250, at the same time. Revive will display the 728x90 banner when this campaign is assigned to a 728x90 zone, and will display the 300x250 banner when this campaign is assigned to a 300x250 zone. One step further would be the Revive tag to detect the width, and this particular zone would display (for example) the 728x90 banner when the resolution is high enough and the 300x250 banner at lower resolutions. Currently, there are a few known workarounds to that. You can define zones without a width and height (it is possible, just enter * x *), in this case, both banners (728x90 and 300x250) will be displayed at the zone. Then you can set up banner limitation to display the 300x250 for mobile browsers and the 728x90 banner for non-mobile browsers. I hope I have helped.

Edit: I've just noticed that when trying to open the adserver, it redirects me to /www/admin/install.php, so it thinks it is not installed. Probably a flag somewhere that I need to fix... Note: INSTALLED is present at /var

Hi, Moved my Revive Adserver installation to a new server, and we are seeing the following errors: MESSAGE: Redefining already defined constructor for class XML_Parser TYPE: Strict FILE: /www/hsads/lib/pear/XML/Parser.php LINE: 204 DEBUG INFO: 199 * @param string $mode how this parser object should work, "event" for 200 * startelement/endelement-type events, "func" 201 * to have it call functions named after elements 202 * @param string $tgenc a valid target encoding 203 */ 204 function __construct($srcenc = null, $mode = 'event', $tgtenc = null) 205 { 206 parent::__construct('XML_Parser_Error'); 207 208 $this->mode = $mode; 209 $this->srcenc = $srcenc; MESSAGE: Non-static method Date_TimeZone::isValidID() should not be called statically TYPE: Strict FILE: /www/hsads/lib/pear/Date/TimeZone.php LINE: 3642 DEBUG INFO: 3637 Date_TimeZone::setDefault($_DATE_TIMEZONE_DEFAULT); 3638 } elseif (getenv('PHP_TZ') && Date_TimeZone::isValidID(getenv('PHP_TZ'))) { 3639 Date_TimeZone::setDefault(getenv('PHP_TZ')); 3640 } elseif (getenv('TZ') && Date_TimeZone::isValidID(getenv('TZ'))) { 3641 Date_TimeZone::setDefault(getenv('TZ')); 3642 } elseif (Date_TimeZone::isValidID(date('T'))) { 3643 Date_TimeZone::setDefault(date('T')); 3644 } else { 3645 Date_TimeZone::setDefault('UTC'); 3646 } 3647 // MESSAGE: Non-static method Date_TimeZone::setDefault() should not be called statically TYPE: Strict FILE: /www/hsads/lib/pear/Date/TimeZone.php LINE: 3645 DEBUG INFO: 3640 } elseif (getenv('TZ') && Date_TimeZone::isValidID(getenv('TZ'))) { 3641 Date_TimeZone::setDefault(getenv('TZ')); 3642 } elseif (Date_TimeZone::isValidID(date('T'))) { 3643 Date_TimeZone::setDefault(date('T')); 3644 } else { 3645 Date_TimeZone::setDefault('UTC'); 3646 } 3647 // 3648 // END 3649 ?> 3650 MESSAGE: Non-static method Date_TimeZone::isValidID() should not be called statically TYPE: Strict FILE: /www/hsads/lib/pear/Date/TimeZone.php LINE: 153 DEBUG INFO: 148 * @param string $id the time zone id to use 149 */ 150 function setDefault($id) 151 { 152 global $_DATE_TIMEZONE_DEFAULT; 153 if(Date_TimeZone::isValidID($id)) { 154 $_DATE_TIMEZONE_DEFAULT = $id; 155 } 156 } 157 158 /** MESSAGE: Non-static method Language_Loader::load() should not be called statically TYPE: Strict FILE: /www/hsads/lib/OX/Extension/authentication/authentication.php LINE: 18 DEBUG INFO: 13 require_once MAX_PATH . '/lib/max/Plugin/Translation.php'; 14 require_once LIB_PATH . '/Plugin/Component.php'; 15 require_once 'Date.php'; 16 require_once MAX_PATH . '/lib/max/language/Loader.php'; 17 18 Language_Loader::load('settings'); 19 20 /** 21 * Plugins_Authentication is an parent class for Authentication plugins 22 * 23 * @package OpenXPlugin MESSAGE: Undefined index: action TYPE: Notice FILE: /www/hsads/lib/OX/Admin/UI/Install/InstallController.php LINE: 80 DEBUG INFO: 75 * Called before any action gets executed 76 */ 77 protected function init() 78 { 79 // No upgrade file? No installer! Unless the user is in the last step 80 if (!file_exists(MAX_PATH . '/var/UPGRADE') && 'finish' != $_REQUEST['action']) { 81 header("Location: index.php"); 82 exit(); 83 } 84 @set_time_limit(0); 85 MESSAGE: Cannot modify header information - headers already sent by (output started at /www/hsads/lib/max/ErrorHandler.php:130) TYPE: Warning FILE: /www/hsads/lib/OX/Admin/UI/Install/InstallController.php LINE: 81 DEBUG INFO: 76 */ 77 protected function init() 78 { 79 // No upgrade file? No installer! Unless the user is in the last step 80 if (!file_exists(MAX_PATH . '/var/UPGRADE') && 'finish' != $_REQUEST['action']) { 81 header("Location: index.php"); 82 exit(); 83 } 84 @set_time_limit(0); 85 86 // load translations for installer

That would involve hacking our CMS, and I don't have the time to play with this at the moment. But thanks for the suggestion, though.

andrewatfornax, your line of thought is correct. As the page is available must faster, the user will move to a different page or leave the website before all banners have loaded, hence the drop in adviews. If all banners were stored locally, I doubt that we would see any drop at all, as they would be loaded super-fast. The issue here is with the latency of RTB networks, which can't do much about it. As you probably know, with RTB networks we have a cascading stream of networks that check if the network has a banner to serve to that user, otherwise the network moves on to the next network in the pipeline, and so on. Something like this: Revive -> Network #1 -> Network #2 -> Network #3 -> Google AdSense These networks pay way more than Google AdSense, so removing them is not an option. So, for the time being, I reverted back to the single-page call method. Unfortunately, most our inventory goes unsold and we have to use such networks...

After one week of using the new async code, I am having mixed feelings. At one hand, pagespeed improved considerably. On the other hand, we are serving much less ads. In fact, we are serving about 25% of what we used to. Note that our banners are basically RTB networks. Please see attached screenshots.

Wondering on how to work that out with the new async invocation code... I played with height: 0px and display: hidden. These tricks work but I am afraid of using them as I am using banners from networks such as Google AdSense, and they might complain that we are rendering banners in a hidden <div>. I saw somewhere that we might add a data-field that would "activate" the correct code depending on the resolution, so the banner that won't be displayed won't be rendered/loaded. Still researching: http://christianheilmann.com/2012/12/19/conditional-loading-of-resources-with-mediaqueries/ Please take a look under "Matchmedia to the rescue". I played with it but couldn't get it to work. I don't know where and how to "trigger" the JavaScript code. I'd appreciate any help.

Please take a look at this other topic where this is discussed http://forum.revive-adserver.com/topic/27-how-to-serve-responsive-ads/

Just implemented and I can only say: WOW. Loading of my website is MUCH FASTER now. This should increase the number of pageviews, lower our PageSpeed and, indirectly, improve our Google rankings.

Ciao Matteo, Grazzie The information you provided already gives me some hints on how to implement the new tags. I will play around with them, and am anxiously waiting for the documentation! Gabriel.

My question is whether the hash data-revive-id is fixed or varies according to the zoneid, and if it varies, how to calculate it? Because our CMS generate the tags inserting the zoneid according to the location the user is loading from our website. Thank you!

I see that the async loading code uses the following format: <!--/* * * Revive Adserver Asynchronous JS Tag * - Generated with Revive Adserver v3.2.0 * */--> <ins data-revive-zoneid="1" data-revive-id="7813b56809490348166b3701f410dbbc"></ins> <script async src="//xxxxxxxxx.com/www/delivery/asyncjs.php"></script>