search

revive-adserver / revive-adserver

The world's most popular free, open source ad serving system. You can download the latest release at:
http://www.revive-adserver.com/download/
GNU General Public License v2.0
1.24k stars 564 forks source link

Rebranding - Update sync server #17

Closed andrewatfornax closed 11 years ago

andrewatfornax commented 11 years ago

Update the details of the sync server that is contacted for upgrade messages.

andrewatfornax commented 11 years ago

Slowly making progress on this issue; there have been quite a few issues to resolve with the sync server code to get things operational on a new server. New server is not deployed yet, but code is just about there. Screenshot attached from local development instance, showing that it can do the job. demo_sync

andrewatfornax commented 11 years ago

Looks like there's no existing system for enforcing a configuration setting change at a specific upgrade point? On upgrade to Revive Adserver 3.0.0, we'll need to change the sync server settings, but so far I haven't seen a system in the code to do this. Looks like the last item on the list to change along with updating the default server info for new installations.

andrewatfornax commented 11 years ago

Oh, tests are broken too: https://revive.beccati.com/bamboo/browse/REV-AD3-4

I will need to fix those.

mbeccati commented 11 years ago

We can build a migration package (e.g. at version 2.99) that removes unnecessary configuration entries and updates the sync server settings.

mbeccati commented 11 years ago

Ideally that same package could/should remove m2m/adnetwork/advsignup database fields

andrewatfornax commented 11 years ago

Deprecated configuration entries are now already being removed (in the #17 branch) as a result of https://github.com/openx/openx-source/commit/bcd55fc850ae323bef13370648bd6c36bdfd7ad0 - once it is merged into master, we can update and extend to remove other fields. I will ticket that so we don't forget. Still need a migration for changing the sync server settings, though. Thanks for the suggestion, will do.

andrewatfornax commented 11 years ago

Oh, wait, no - those database fields need to actually be removed, not just dropped from the configuration. I've created a correct ticket for this!

andrewatfornax commented 11 years ago

Tests fixed - new methods needed to be mocked.

mbeccati commented 11 years ago

Any specific reason why we need to provide a full deprecated.conf.php config file with values as well?

I'm just thinking out loud here, but providing a method and calling it from the migration package would probably be more future proof (e.g. plugins could benefit from it as well).

andrewatfornax commented 11 years ago

Yeah, you're right - I created the deprecated config file to subconsciously avoid having to re-learn the upgrade package system, I bet :-) I'll remove that system, and move the changes to the upgrade package.