[Issue upgrading from 4.0.2 to 4.1.0]

@gabrielt Oh yes, I saw the nice phpads_ prefix. Fond memories! Anyway, I see two possibilities at the moment:

1. Hold off on the upgrade, until we figure out where the issue comes from and see if we can fix it.
2. Remove the defaults from all the listed fields.

Option 1 could take some time, though.

We had tested upgrades from OpenX Source 2.8.11 and various Revive Adserver versions with both MySQL and Postgres and never hit this issue. I've also performed a fresh install on Percona with default settings, but the defaults weren't added.

[Issue upgrading from 4.0.2 to 4.1.0]

@gabrielt Thanks. So, apparently the mentioned database fields all have some sort of DEFAULT '0' or DEFAULT '0000-00-00 00:00:00', where they shouldn't. Is it something you added, or possibly something that Percona added?

[Issue upgrading from 4.0.2 to 4.1.0]

@gabrielt Could you please share more info on the system? I.e. php version, database extension, database server version, and possibly send a schema-only database dump. Thanks.

[Update to php 7.1 video ads error 500]

FYI, I've created an issue on github: https://github.com/revive-adserver/revive-adserver/issues/872

[How to use campaignId within Js Tag for Ad Delivery]

I'm sorry, async delivery is only compatible with zones, not direct selection.

["data-revive-id" not changing]

Hi @netvillage,

yes, it is normal. It is a generated value that should be unique for each Revive Adserver instance.

[Manually Change data-revive-id in DB]

@neoounix I was taking about the hash in data-revive-id. That is used by the async JS code to fill only the slots owned by a particular instance of Revive Adserver, in case there are more on the same page.

[Manually Change data-revive-id in DB]

@neoounix The revive-id is simply an identifier generated using the delivery URLs. If you switch DNSes and change the delivery URLs of the new server to match the old one, the upgrade will be seamless.

[Blank pages in Banner pages after PHP 7.1 x upgrade]

@Sperber Please upgrade to the latest version. The issue has been fixed in 4.0.1.

[Installation Error Message "session save path ..."]

The session save path has a format I had never seen before and something we don't support yet. I'd suggest commenting out the check for the time being and adding an issue on github so that the "N;/path/" format is properly recognized.

[Flagged as malware by Google DFP]

If you are serving 3rd party content, then the malware might be coming from them.

[The session save path '/var/lib/php/session' is not writable.]

For reference, just delete or comment out the if block in the __construct method of lib/OX/Admin/UI/SessionStorage.php in order to bypass the check.

[The session save path '/var/lib/php/session' is not writable.]

Turns out the PHP setup was correct and the error message was wrongly triggered. It's a Revive Adserver bug that will be fixed in 4.0.1.

[The session save path '/var/lib/php/session' is not writable.]

@Tommaso could you please send me a link to a phpinfo() page via direct message?

[Version 4 still does not run with PHP7?]

@Matija1506 I'm sorry, but it's fairly hard to help someone who "doesn't know anything". A little googling might help understanding what the config file could be. If you've changed host it is also likely that your database credentials have changed, so you need to update such config file.

[Version 4 still does not run with PHP7?]

@Matija1506 Did you follow the very same suggestion I wrote above?

Normally an errore like the above means that Revive couldn't connect to the database.

[Version 4 still does not run with PHP7?]

If you don't have the legacy mysql extension installed, just edit the config file and use "mysqli" as database type instead.

[login_focus is not defined]

Please try to switch off your ad blocker.

[Geotargeting and MaxMind .dat files]

@Reid are you accessing the interface from a private IP address?

[php7 and mysql]

13 hours ago, bdamage said:

Is there something I missed? 

 

I'm afraid so. The phpize you're using is not coming from PHP7.

[404 Errors On Revive Adserver Admin Panel]

@Bikas Gurung just disable mod_security.

[Campaign/Banner Probability in Chained Zones]

The test setup was:

• Campaign A, weight 99, single text banner, banner weight irrelevant
• Campaign B, weight 1, single text banner, banner weight irrelevant
• Text Zone 1, linked to both campaigns, chained to Zone B
• Text Zone 2, empty
• Test page with two async tags with the "do not show the same banner" flag.

Zone 1 was pretty much always showing A, while Zone 2 was showing B. To be fair you don't even need chained zones: just repeat the tag for zone 1, unless you need to keep track of the "positions".

[Campaign/Banner Probability in Chained Zones]

I've also tested a similar setup using campaign weights. Worked pretty consistently for me.

[Campaign/Banner Probability in Chained Zones]

14 minutes ago, sikjoy said:

I think that I understand weights and probability: Let's call the banner from your example with weight 3, Banner A, and the banner with weight 1, Banner B. Both banners are linked to Zone 1 from my example. For any given page view Banner A should be in Zone 1 75% of the time, correct?

Correct. But only if A and B belong to the same campaign.

14 minutes ago, sikjoy said:

I also think that I understand chaining: Let's say that for a certain page view Banner A is shown in Zone 1. Banner B should be shown in Zone 2, since Zone 2 was empty and chained to Zone 1.

Correct.

14 minutes ago, sikjoy said:

Correct me if I am wrong. Are you saying that chaining and weights are incompatible with each other?

No. Now that I have a clearer idea of what you're trying to do, I just think you didn't take campaign weights into account.

[Campaign/Banner Probability in Chained Zones]

I think you got zone chaining and weights wrong.

1. Zone chaining means that if a zone can't deliver any banner, the chained one will be tried as a fallback.
2. Weights for remnants are simple proportions. If there are two campaigns with weights 1 and 3, they will have respectively 25% and 75% probability of being displayed. Once a campaign is picked a similar math applies to the banners in a single campaign.