andrewatfornax

That's just fine as a solution, and thanks for the quick response Matteo.

Plugin installation / upgrade has been designed to be run unattended. I'm not really sure it would be wise to add a hook for what you have in mind.
 
What I did with a plugin that requires some action is adding a warning on the left bar to tell the admin user that some additional configuration is required, e.g.
 

 
Feel free to have a look: https://github.com/adserverplugins/apLoader/blob/master/www/admin/plugins/apLoader/apLoader.class.php#L37

Indeed, many users implement htaccess password protection on the Revive admin folder.

Had to upgrade PHP  . . . we were just a hair's breath below requirements. Once we did that, we were good. Make sure you meet all requirements on this list.
 
http://www.revive-adserver.com/support/requirements/

I had to deactivate my iThemes Security plugin in Wordpress for it to work.
I have to do that every time I update Revive-Adserver. 

Ah, it was cache. APC. 

By default revive didn't have this feature. We have to write some custom code to achieve this functionality.    

The link that you  are shared in "http://clip2net.com/s/3g107Yi" is admin panel. Here we can able to see the advertiser, campaigns & banners.

But the link you are shared in "http://clip2net.com/s/3g0ZiCf "is publisher panel. By default we don't have permission to see the advertisers inventory details.

"http://clip2net.com/s/3g11nwB" in this page, we can able to see the linked banners details with your zones. These are default functionality followed in revive adserver.

I'd wanted to rename the Revive directory, while leaving it in the same location on the same server under the same domain name.
 
I'm not sure what the change (noted in the quote above) in the "default.conf.php" file is meant to accomplish; I left this file unchanged, as it already contained my domain name.
 
However, I did make the changes in the "domain_name.conf.php" file, which meant the following lines were adjusted in the highlighted ways:
 
old:
 
[webpath]
admin="www.domain_name.com/old_name/www/admin"
delivery="www.domain_name.com/old_name/www/delivery"
deliverySSL="www.domain_name.com/old_name/www/delivery"
images="www.domain_name.com/old_name/www/images"
imagesSSL="www.domain_name.com/old_name/www/images"
 
[store]
mode=0
webDir="/home/account_name/public_html/old_name/www/images"
 
new:
 
[webpath]
admin="www.domain_name.com/new_name/www/admin"
delivery="www.domain_name.com/new_name/www/delivery"
deliverySSL="www.domain_name.com/new_name/www/delivery"
images="www.domain_name.com/new_name/www/images"
imagesSSL="www.domain_name.com/new_name/www/images"
 
[store]
mode=0
webDir="/home/account_name/public_html/new_name/www/images"
 
I can confirm that this appears to work. Ads have continued to be served on the pages, and statistics are being logged.
 
Thank you!
 
Eliz.

In case of a 500 Internal Server Error, there should be more detailed information in your Apache error log. Your hosting provider or system administrator should be able to look up this information and fix the cause.

Then you've found your problem. PHP 5.4.4 doesn't match the requirements:

 
 
Because:
 

This has now been resolved I went through the stages on this  http://www.openxtips.com/2009/06/tip-14-troubleshooting-banner-delivery/   and it was my ad blocker when i disabled it the banners showed straight away. ;-( 

nevermind the problem was on our side not revive

Something has to be able to make that decision, perhaps the apache(?) webserver proxy(?), or some other code run by the server on which the banner is run, or another intermediary. I suggest this is outside of Revive scope.

Hi hoimingw,
How can you access from your local address ? Is that possible?
 
Just have a try at "domainname.conf.php" file,
[webpath]
admin="provide  your IP address/....." following your path. I am not sure this might work. Just a try !

NEvermind!  Just found the duplicate Action!

Hi @Maksim,
There are no restrictions on where you can use a zone invocation tag. The website level in the Revive Adserver URL is simply a way to categorise the tags for reporting purposes. 

FYI for those who might encounter this, selinux was in enforcing mode and the default Apache user doesn't get write access regardless of linux permissions.  
 
Access needs to be managed through selinux for the default Apache user

When i was usign xmlrcp api v2 i had the same problem, I resolved using pear Date instead a String Date.

This is solved now. I've used solution provided here: 
 
https://github.com/revive-adserver/revive-adserver/issues/402

I'll quickly note the solution to the problem.
 
For some reason, the upgrade process created new entries in the accounts table for the Administrator and the Default Manager, but did not successfully finish updating all the relevant keys.
 
In fact it didn't seem to update any of them: the account_preference_assoc table in particular still referred exclusively to account_id values of 1 and 2 (the original accounts for Administrator and Default Manager). There were no preferences set up at all for the new accounts.
 
However, the admin_account_id value in the application_variable table was set to the value for the new entry in the accounts table.
 
As soon as I set this value back to 1, all the problems disappeared.
 
The problems we were seeing were that statistics did not show, that in My Account the language was set to Albanian, that User Interface preferences had no columns specified to show any statistics (which is why none were showing), and that no changes to any of the My Account settings took effect (even though the system reported that the changes had been saved, and no error messages appeared anywhere in the debug log).

I just ran into this issue after upgrading from an earlier version of Revive. You have to pass a hostname as an additional parameter when you're calling the script from the command line. If you have this set up as a cron job, you need to change it there.
 
So, change this:
php /path/to/revive/maintenance/maintenance.php
 
To this:
php /path/to/revive/maintenance/maintenance.php localhost
 
There was apparently a bug in earlier versions that allowed you to call the script without the hostname parameter, which I didn't realize when I originally set up the cron. It was tricky to track down because there were no errors in debug.log.

It's amazing.
 
Thank you.

For reference, this has been fixed in 3.1.0.

Hi, 
 
You can skip your ads to deliver from specific pages. To set this, Edit the banner you want to skip and Click "Delivery Options", in this page, select "delivery limitation" as "Site-Page URL" and click "Add" button. Then choose the option and set the page you want to skip. Finally click "Save Changes" button.
 
Banner delivered based on the setting you have set up.