Matteo Beccati

I'm sorry, CSRF tokens have a very different purpose: session based, one-consumption-only tokens won't help for this use case.

What kind of invocation are you using?

As everyone else is saying, you're not giving the browser a chance to load the impression tracking pixel that is sent along with the meta tag. I'd suggest increasing the timeout to e.g. 3 seconds and also displaying something like "Redirecting..."

I had a look at the site and I'm sorry to say that you might not using the right tool for the job. A custom application or wordpress/drupal/etc module would probably serve your purpose better than a proper adserver can do. That said, try to disable the cookie based fatures (e.g. delivery capping/blocking) and see if that helps.

I'm afraid the developer documentation is gone during the project move to Revive Adserver. So there's no relevant URLs to link to just yet.

If you see strict standards error messages there's something wrong with your setup, as they should be hidden. Also, judging by the output above an extension (xdebug?) is messing up with error messages. Finally, RevMax is a 3rd party product and you shouldn't be searching for support about it here

https://github.com/revive-adserver/revive-adserver/issues/466

https://github.com/revive-adserver/revive-adserver/issues/466

For reference, this has been fixed in 3.1.0.

For reference, this has been fixed in 3.1.0.

If you comment this line out, you might be able to run: ant minify-delivery which copies the files from www/delivery_dev to www/delivery, minifying them with YUI compressor.

Stay tuned

Thanks for the report. It is a known issue, since many years actually. The problem is that the oadest parameter is required for certain functionalities to work, and to this day no solution has been found that allows it while making it safer. I have spent myself numerous hours on it but I couldn't come up with anything good enough. If you have a working solution, we'd be happy to review it and apply it.

Upgrade from phpAdsNew should be working from 2.0.11. If you're running 2.0.7, you might first need to upgrade to 2.0.11-pr1. I would suggest doing that with an old enough version of PHP (on a staging server, possibly). From there, it should be possible to upgrade directly to the latest Revive, but to be honest I haven't tested that in a while.

Your PHP setup might not allow Revive to redifine the include path. Maybe set_include_path is disabled via your php.ini?

This might be related to required functions being disabled, e.g. parse_ini_file. Please replace your pre-check.php file with the one available here and you might see a nice error screen instead of all those error messages.

@al_bullit Did you apply both the patch files? DId you properly recompile/upgrade your packages and restart the webserver/php-fpm? If so, I'm afraid I don't know what else to suggest. @msellers Whatever works for you. If you're able to fix the adserver and influence garbage collection so that it doesn't trigger the GC bug, I'll be very happy to apply your changes and lift the ban for the PHP versions affected by such bug.

Some blank pages (PHP segfaulting) is the result of the bug. Please make sure to apply both the commits related to the bug made by laruence (going from memory here).

Hi Mark, thanks for the report. To be honest I wasn't aware of it as my knowledge of RPM-based distros is quite limited. I made a search a while ago and I thought that RHEL/Centos 7 had PHP 5.5 out of the box, which sadly isn't actually true. The fact here is that, even if we wanted to, we can't make Revive Adserver compatible with PHP 5.4.16 as it is affected by a bug that causes segmentation faults when running it. Such bug has been fixed in PHP 5.5.2 and PHP 5.4.20. Debian had the fix backported at some point to their Wheezy (going from memory) php package, but RedHat didn't yet. It would probably take some RH customer to submit a ticket for them to think about backporting the fix. The only suggestion I have (thanks Remi) would be to use PHP 5.5 from RHSCL: https://www.softwarecollections.org/en/scls/rhscl/php55/ I hope this helps.

A few years after my initial investigations I've been finally able to understand what was wrong. I'll commit a fix shortly. Thanks for the persistence

"Temporary vs permanent" is only a trick that Revive uses to "pack" cookies in order to avoid hitting the limits on cookie number per domain. I.e. the content of a temporary cookie is appended to the permanent one on the next request.

Yes, in theory. Cookies beginning with an underscore are "temporary" cookies that get merged to the permanent ones. Capping should be set when the impression is recorded, not when the request is made, so it is techincally wrong.

The cookies are sent when the impression beacon is loaded, but my experience was that the Flash video player in use didn't actually set them.

I'm afraid your instance has been compromised. I've seen a similar screen 1-2 years ago.

I'm afraid it's not a free plugin, but we haven't been able to create a product page yet. Please use the contact form on the website if you are interested.