vicos

-------------- Solved my own problem. Basically it worked the first time, but it left a lot of old crap in the plugins folder. I just started fresh and did NOT upload the old plugins folder. The install failed to install any plugins. So, I just did InstallNewPlugin-->Import Code Only and I think we have a nice clean install with the old data/config.

My revive is installed on a dedicated domain at the root level. It was time to migrate to a newer server, so took the opportunity to upgrade Revive from 3.2.1 to 4.1.4. The upgrade completed, but with some errors, all involving plug-ins. Before I show the errors, a note about the upgrade process. Since your instructions are set up for revive being in a folder and not at the root, I just did it this way: -- Setup new clean domain -- Created database and imported data -- Did not copy all files over, just the ones I thought were unique: --- banner images --- config files --- plugins folder I didn't realize there were some plug-in files in /www/admin, so none of those got copied. So, the install completes, but says there are errors and says it is ok to proceed. I login and everything looks OK. So, here a few of the key errors. They most involve Plugin: openXVideoAds /home/mysite/public_html/www/admin/extensions/videoReport/lib/ofc2/ofc_y_legend.php Plugin: openXVideoAds - Unable to locate file: One immediate problem is that there is NO www/admin/extensions on the old server. But, there is a www/admin/plugins folder where the respective file is located. So, even if I had copied the www/admin/plugins files to the new server, the script still would have an error, I guess?! Anyway, there is NO showing in the admin control panel under plugins. Finally, it complains: #! openXDeliveryLog(): Problems found with components in group oxDeliveryDataPrepare. The openXDeliveryLog plugin has been disabled. Go to the Configuration->Plugins page for details #! openXDeliveryLog(): Task failed _verifyDataObjects But, when I look in the admin CP under Plugins, I see Banner Delivery Logging Plugin enabled. This is the only plugin on the new system that has the same version (1.1.2) as the old system. All other plugins have a newer version. Bottom Line: is there a problem, or I am safe to proceed with using the new install? Appreciate you insights! I confirmed that all of the standard Plugins are there (the same ones as on the old server) Also ran thru the troubleshooting at: https://documentation.revive-adserver.com/display/DOCS/Plugins+Incorrectly+Upgraded and it all looks good. I would feel better if that plugin had a newer version number so I knew for sure.

Scott001, How are you making out with Revive and mariaDB? Did you have to disable strict mode? Any other feedback on mariaDB overall? I'm trying to decide if I should convert from mySQL on a new server setup.

I believe it relies upon your config file to determine if it is an existing installation. i.e. does the config file exist and does it have an existing database specified in the parameters. the config file is in the 'var' directory: yourdomain.com.conf.php where "yourdomain.com" is your domain name. Maybe you overwrote this when you uploaded the new files... Also, if you originally accessed the domain as mydomain.com and are trying the upgrade via www.mydomain.com, this might cause it to look for a differently named config file from the one that exists.

1) Did you grant full SQL privs to the mysql user you specified 2) are the username, password, and database name you specified correct. Open a shell and try connecting to the database from the command line to test your parameters: mysql -umyusername -pmypassword mydatabasename 3) The host is usually 'localhost.' If you specify a remote host, your host needs to be specified in that server's remotehosts for mysql or it will not be allowed to connect.

In the var directory for revive you will find a file called mydomain.com.conf.php where "mydomain.com" will be your domain name. This file must be writable by the webserver in order to change the settings via the revive admin. If your webserver is running as user nobody, then the file will need '666' If your webserver is running as the account owner, the default 644 should be fine. You could also edit this file using nano from a shell if you feel confident. Always make a backup of any file before you change it just in case... The developer recommends that the config file be set so that it is not writable by the webserver after you have finished making your changes for security reasons. Check the install guide for details...

The above link does not work. I believe this is the correct one:

OK, I'm out of tricks... I purged all hourly data pre-2013 and optimized the database. The script runs up to a point and stops, not timeout, just stops. If I view source of the page, there is just a "1". Here are the last few lines of the install.log: Then, if I reload the install page, it starts all over and complains: There is nothing I'm doing wrong at this point.

I have the data imported properly. The problem is the way the upgrade is written is causing constant timeouts. It would be nice if this could run via shell so web server timeouts are not an issue. I just ran it again on a brand new server with PHP memory limit=128M and execution timeout of 300 and it just timed out again leaving the database in an unrecoverable state. This is the point where it keeps dieing because the table is so large. I guess I will set the execution time to a zillion years and try again. task found: doAddIndex__data_summary_ad_hourly__hour I have almost 16M rows in this table. Does the new version of Revive have an automatic mechanism to keep these tables trimmed to the last xx years or do I still need to goin there and manually delete records ??

I started over. Apparently there was a problem importing the backup from the dump the first time. Anyway, it ALMOST worked. The PHP script timed out because mysql was taking so long because of the size of the DB (only 3GB) Can you put something in the code to prevent the timeouts and/or break the upgrade process into multi-steps so a different URL is called each time to reduce chance of timeout?

Do the developers offer paid consulting to fix this type of thing? If yes, can we get a rough estimate to see if it is worth it?

Hello. Will anyone be able to look at this or am I on my own? thank you.

No, we started with PHPAdsNew way back when and have never made any customizations that I recall. The only thing I ever did to the database was manually purge the stats tables because they were becoming huge over the years and there was no way to do it via the program. I have debug and install log files if there is some way I can transmit them privately. It looks like it failed with the 2.5.42 upgrade.

Hi, I setup a testbed to see what happens when I upgrade from 2.4.6 to 3.0.2. The first image shows the first failure upgrading the schema. The second image shows what I get as soon as I try to start over. The database is close to 3GB. This is on a shared Hostgator account. So, I have no control over timeouts or anything like that, if that is perhaps the root cause. P.S. Neither the "documentation" or "FAQs" links on that last image are correct.

Excellent! Thanks for the fast response Chinnu.

Greetings, We are upgrading from OpenX v2.4.6. Is our current invocation code compatible with Revive?