andrewatfornax

If you are changing the path, you'll also need to change the "[webpath] admin" value in the configuration file. Alternatively, rather than making changes to the code, you could address this by using rewrite rules as appropriate in your web server.

1. Yes. It's definitely possible to have multiple servers with the same Revive Adserver code on them, all using a central DB. 2. It's simply a case of backing up the installed code, and the database.

When you say it now no longer seems to work, but used to, my question is always - what changed, if anything? Was there a system or upgrade change?

Why not use the async tag, instead of trying to change the non-async one? ?

If you're trying to use that option from the report site, is mod_headers installed in your Apache service?

Presumably, this is a Contract campaign that you are talking about. (Screenshot may help here.) Please bear in mind that Revive Adserver does the following to calculate the banner/zone priority for Contract campaigns: How many impressions are left to meet the target? How long until the campaign ends? => Calculate the number of impressions needed for the next hour. How many impressions for the campaign to deliver next hour? How many banners? What relative weights do the banners have? => Calculate the number of impressions for each banner. How many impressions for a banner to deliver next hour? How many zone is the banner linked to? What are the relative forecast inventories of the zones? => Calculate the number of impressions for each banner/zone pair. And then calculate a % of the forecast inventory for the banner in that zone. This is why you may see a Contract campaign's banner with what looks like a low % in a zone, even if the Campaign is running behind on delivery - Revive Adserver is expecting to meet the campaign target via banner delivering occurring on other zones. Rather than looking at zones where the Contract campaign has a small % value, I'd be more interested in zones where there are multiple Contract campaigns all competing for the same inventory, and failing, because they can't all have the inventory. This is a more likely reason for the under-delivery.

Okay, thanks for letting me know - but if you'd like further help, I will need more information from you than a throw away line. I can't disagree with this. In an ideal world, yes, Revive Adserver would be able to perfectly forecast your available inventory, and then perfectly understand how much of your available inventory will be made ineligible for use because of your delivery limitations, and therefore correctly calculate the required percentage of time each ad should be shown to perfectly smoothly deliver the ads over time to meet all campaign targets perfectly. Hopefully, though, you can see why this is never going to be possible to achieve. The over-delivery option exists for users who want to force Revive Adserver to deliver more impressions than the system thinks it will need, so that campaigns deliver above the forecast rate, so that campaigns are "ahead of the game" instead of playing catch up. If that's not a solution for you, fair enough - but that's the solution that we have at the moment. I think we answered that - you DO have rules in place, and this WILL affect Revive Adserver's ability to deliver in any given hour. Each hour, when priorities are calculated, it will recognise that the impressions/hour needed to meet the campaign target has increased, if the previous hour's delivery failed to meet targets (or if you over delivered for an hour, it will recognise that the impressions/hour needed to meet the campaign target has decreased), and so the next hour's priorities that are calculated will take this into account. However, that may not be enough, depending on the percent of impressions that are ineligible. If you want, you can adjust this with the over-delivery option. Not sure how much more I can say about this!

Hi @malmazan, I'm really not sure what more I can say here. 1. When you turn on the over-delivery feature, at a high level (99%), you find that campaigns are over-delivering. 2. When you don't have the feature on at all AND you are using delivery limitations (e.g. country delivery rules), you find that campaigns are under-delivering. Maybe try setting the over-delivery rule to a less aggressive value, and see what level works best for your needs?

Hi @manuel, Sure, ping me a direct message via the forums.

Hi @malmazan, Okay, you seem to not be understanding a basic concept here in this case. Contract campaigns are designed to deliver the contracted number of impressions over the time they are set to run. If you ask for 100,000 impressions to be delivered over a month, and that campaign is linked to a zone that has 200,000 impressions available, then the campaign only needs to deliver 50% of the impressions to meet the target set. If you then ask the campaign to over deliver by 99% in the settings.... Well, that's why it's over-delivering! If you want to stop that over-delivery from happening, turn off the 99% over-delivery setting, and hopefully, the delivery of the campaigns will be about what you need to meet the contracted requirements. If you then have unused inventory that you don't want to "waste" on Remnant campaigns.... Well, the only solution to that is to either get more Contract campaigns to use up the available inventory, or, update the Contract campaigns for more impressions.

Hi @jpm, Thanks, good question! I have added a new page to the Troubleshooting Guide that I hope answers this: https://documentation.revive-adserver.com/display/DOCS/Impressions+Inconsistently+Recorded

I assume that you mean that you need to keep checking to ensure that a specific Contract campaign does not under-deliver? If you mean anything other than a Contract campaign, then please note that Remnant and Override campaigns are not designed to deliver a contracted number of impressions - only Contract campaigns do this. If you mean that your Contract campaigns are over-delivering (apart from not making any sense based on your first sentence), then you need to turn down the over-delivery setting, because that will not be helping! However, if the issue is that your Contract campaigns are under-delivering.... I think that this may actually be your problem - you are describing a zone that has very little traffic, but you have 6 different Contract campaigns linked to the zone, and they are all competing for traffic! As per Step 1 of https://documentation.revive-adserver.com/display/DOCS/Contract+Campaigns+Under-Delivering - do you actually have the inventory in your zones to meet the demands of your Contract campaigns? However, if we assume that you do have enough inventory, please take a look at Step 2 of the above guide, which links through to how the delivery engine works. If you have 6 Contract campaigns banners linked to a zone, with no Override campaign banners present, then Revive Adserver is guaranteed to select one of those banners only if it believes it is required to do so to meet the delivery requirements. It does this based on a forecast of expected impressions in the zone. If the zone traffic varies wildly, then sometimes, it may not make an accurate estimate of inventory for any given hour, and may display a Remnant banner, because it is expecting there to be many more impression occurring that actually happen. However, that forecast should then be updated in the next hour, and the situation should improve. Over a long enough time period, this should even out (roughly) to meet delivery needs. Have a look through that documentation and see if that helps explain the situation?

Hi @manuel, The idea situation for me would be access to a zip or tar file, containing a backup of your database, and a full copy of your Revive Adserver directory code. This will allow me to set things up as you have it, and then run through the upgrade process to check what is happening.

Hi @scott001, If you are not running a proxy server that is intercepting HTTPS traffic, and then forwarding the traffic on to Revive Adserver over HTTP, then all that discussion about ensuring that your proxy includes an appropriate header is not relevant. Based on your comment on February 5, where you responded to someone saying that they had an issue with this kind of setup, I had assumed that you had the same kind of setup as well. However, if that's not the case, then we need to go back to square one, I'm afraid. (Clear details of the problem and the set up from the outset are always helpful!) Can I please refer you back to my comment on November 12, where I ask for more details on your setup. You say that you are running a secure HTTPS site. Do you mean that the site you are putting advertising on is running on HTTPS? Do you mean that your Revive Adserver site is running on HTTPS? Do you mean that both are? If your Revive Adserver site can be accessed via HTTPS, can it also be accessed via HTTP? What kind of tag are you using to deliver banners with? Have you modified the tags to set the required HTTPS settings before inserting them into your HTTPS enabled site on which the advertising is being shown? Thanks.

Hi @scott001, Yes, that what @Artistan is talking about. So, for example, if you have a proxy server in front of Revive Adserver, and the proxy server is doing all the SSL, and then forwarding requests on to Revive Adserver over HTTP, then you could get your proxy server to inform Revive Adserver that it should act as though it's really operating on HTTPS (and not HTTP), by setting up your proxy server to send in an extra header in the request to Revive Adserver. This could be, for example, by sending the HTTP_X_FORWARDED_PROTO header with value "https". Or you could send the HTTP_X_FORWARDED_SSL header with value "on". etc.

Hi @Genum, If you do not have the required database tables present, then something has gone wrong during the installation process. I would recommend removing the installation completely, and re-installing from scratch, and carefully double check both the requirements for running Revive Adserver and the installation process.

Hi @Brian Cronin, Revive Adserver is not an extension to Joomla, it is a completely separate and stand alone product. You will not be able to upload Revive Adserver via Joomla - it is a completely separate installation process. You will find the installation instructions on our website.

Glad you managed to find the root cause. My experiences with the OWASP WAF ruleset is that it's great if you're doing something simple, but once you move into more complex web applications or services, it's not always going to be compatible with a working service.

I agree, this appears to be a file permission issue - the web server appears to be unable to modify a number of files that it needs to. This may be a directory permission issue, rather than a file issue - perhaps review the upgrade instructions and double check the recommended process & permissions?

It depends if you want to purchase a SaaS model of Revive Adserver, where you just have to worry about using the system, or if you want to do all the administration/upgrades, and worry about capacity planning and performance monitoring of your server yourself. You say that you have 100k unique visitors per month, but you will note that Hosted Edition is based on the number of requests/month - see https://www.revive-adserver.net/pricing/ So, it depends on how many ads you plan to serve - roughly, that's going to be the number of page views times the number of ads per page. That should help you set an initial view for the plan to choose, if you decided to go down that path. HTH.

I said it above, but it's probably worth saying again - an HTTP 403 error is a a permission error - your web server is not allowing the request. You will need to look at your web server configuration for this, it's not a Revive Adserver issue.

Hi @lpa, Correct - if you set the "Don't show a banner from the same campaign again on the same page" option for a zone, then the banner that is shown in that zone will have its parent campaign added to an exclusion list, and banners from that campaign will not be shown again on the same page - no matter what the setting is for any other zones. See: https://documentation.revive-adserver.com/display/DOCS/Banner+Selection+Mechanism (Otherwise, the option would be "Don't show a banner from the same campaign again in this zone, if the zone is displayed on the page more than once" - but it's not - it's don't show a banner from the same campaign again on the same page, which is what is happening!) Note that you could technically work around this, though, but using a zone invocation type that doesn't support this setting for the zone placements where you don't want this feature to work.

Sure, no worries at all - happy to have a stripped down DB, if you could please verify that the upgrade issue still exists after sanitising the data.

This error is, I believe, indicating that it cannot access the plugin files in your PREVIOUS installation's directory. It looks at your previous installation's plugins, because it's possible to install 3rd party plugins that won't be included in the Revive Adserver release package, but which you would want to have included in your installation after an upgrade - so it looks there and copies them over. I suspect the issue is the new installer is either being given an incorrect path to your previous install location, or it doesn't have permission to access the previous install.

Not knowing what the issue is, other than not meeting the PHP requirements, I can't really say if that's likely to be successful or even possible.