Matteo Beccati

@gabrielt Oh yes, I saw the nice phpads_ prefix. Fond memories! Anyway, I see two possibilities at the moment: Hold off on the upgrade, until we figure out where the issue comes from and see if we can fix it. 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.

@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?

@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.

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

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

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

@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.

@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.

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

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.

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

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.

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.

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

@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.

@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.

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

Please try to switch off your ad blocker.

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

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

@Bikas Gurung just disable mod_security.

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".

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

Correct. But only if A and B belong to the same campaign. Correct. 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.

I think you got zone chaining and weights wrong. Zone chaining means that if a zone can't deliver any banner, the chained one will be tried as a fallback. 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.