Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Webapp upgrade

Options
  • 24-07-2009 11:52am
    #1
    Registered Users Posts: 4,475 ✭✭✭


    Im trying to determine the best way to handle a webapp upgrade that I'm working on. The situation is that www.domain.com/index.php currently holds v1 of the app. I'm working on v2, based on the same database (some new fields) but a complete rewrite of the php. I'm going to make it a paid upgrade, so clients can choose with v1 or pay to move to v2. All well and good, but I want the process to be as non intrusive as possible.

    My initial idea was to create a dummy index.php on www.domain.com that works out the user's version (based on their login) and redirect to www.domain.com/v1/index.php or www.domain.com/v2/index.php as appropriate. I would also have to add the same check to the header files in v1 and v2 to stop v1 clients using v2 and vice versa. I would also have to deal with links that are linking directly to www.domain.com/index.php?q1=a&q2=b, etc, but that should be easy to deal with.

    Is this the best/most graceful way to deal with this? I was hoping originally just to include the v1/index.php or v2/index.php in the root folder index.php, but the paths are then screwed up and I don't want to make any other changes to v1 at this point. Is there a better way to do it that wouldn't involve a redirect maybe?

    Ideally www.domain.com/index.php would be v1 or v2 depending on your user version, and v1 users would not be aware of v2 and vice versa.


Comments

  • Registered Users Posts: 569 ✭✭✭none


    corblimey wrote: »
    Im trying to determine the best way to handle a webapp upgrade that I'm working on. The situation is that www.domain.com/index.php currently holds v1 of the app. I'm working on v2, based on the same database (some new fields) but a complete rewrite of the php. I'm going to make it a paid upgrade, so clients can choose with v1 or pay to move to v2. All well and good, but I want the process to be as non intrusive as possible.

    My initial idea was to create a dummy index.php on www.domain.com that works out the user's version (based on their login) and redirect to www.domain.com/v1/index.php or www.domain.com/v2/index.php as appropriate. I would also have to add the same check to the header files in v1 and v2 to stop v1 clients using v2 and vice versa. I would also have to deal with links that are linking directly to www.domain.com/index.php?q1=a&q2=b, etc, but that should be easy to deal with.

    Is this the best/most graceful way to deal with this? I was hoping originally just to include the v1/index.php or v2/index.php in the root folder index.php, but the paths are then screwed up and I don't want to make any other changes to v1 at this point. Is there a better way to do it that wouldn't involve a redirect maybe?

    Ideally www.domain.com/index.php would be v1 or v2 depending on your user version, and v1 users would not be aware of v2 and vice versa.

    If that's a paid for application, I guess users must login to be able to avail of it. If so, keep the old version as is and put a new version in a new subfolder or subdomain and redirect the users there based on their account credentials.


  • Registered Users Posts: 4,475 ✭✭✭corblimey


    none wrote: »
    If that's a paid for application, I guess users must login to be able to avail of it. If so, keep the old version as is and put a new version in a new subfolder or subdomain and redirect the users there based on their account credentials.

    Yeah, but there's no easy way (using php or a url rewrite) to "disguise" the fact they've been redirected?


  • Registered Users Posts: 569 ✭✭✭none


    If you're concerned about them seeing a different URL, I guess you can prevent them from noticing any changes in URL. But why hide it? Make it known and make it an attractive option so people want to pay to upgrade to new version.

    Another option would be to make your app decide what functionality to offer based on user credentials. I mean, all versions get installed at the same path but they dynamically decide what behaviour the users are getting based on their profiles. Like the same software can be unlocked to provide more features when users pay.


Advertisement