live site access

Live Site Access

We're always happy to fix bugs and co-fund developing new features (inside a current support period) - don't worry, you can never reach our maximum 'number of questions asked' limit!

But, for us to check a potential bug, or add a feature that you've requested, we'll usually need access to one of your servers, so that we can see how the code interacts with your unique setup.

Are you giving us details for a live site of a dev/staging site?

We highly recommend giving us access to your staging or dev server and not your live site.

If you don't have one, it can be surprisingly easy to make a dev site, with the same code but a different database

"Why? Are you going to break my site?!"

Probably not, but this is an inherent problem with complex code no matter what the platform, in that we are adding new code into a complicated (and likely unique) mix of files and settings.

If you insist that we check your issue or install requested features on a live site, you agree that, while we are investigating your issue and/or installing code changes, and/or testing functionality :

• The site (frontend and backend) may be unreachable
• Customers may not be able to complete an order
• Live connections to external sites may stop working
• Scheduled emails may not be sent
• Some features of the site may stop functioning

Ie: We'd much prefer to check issues on your dev/staging server than the live server.

We don't mind working on your live server, as long as you're aware of the risks.

• Usually any site downtime would be short-lived, as we perform a series of tests on every site that we work on, before passing it back - but this may extend up to an hour in some cases.

This will be exactly the same for any developer working on a live site, not just us, but we like to be super clear!

Our usual install/test process

1. Check connection details are correct.

   If they are not then we will put the issue on hold and email back

2. Make some screenshots of the Orders Grid, and if you have pickPack installed, make some sample outputs.

3. If we're checking a bug report :
   1. Confirm the issue.
   2. Try to replicate at our end.
   3. Develop a fix.

   We then upload the new code to your site :

4. Disable the extension on your server.

   We'll try to not do this at critical times of your day but this won't always be possible - you may lose functionality at this point

5. Upload the changed files to your server.
6. Enable the extension.
7. Enable error logging if not already enabled.
8. Run tests to verify the issue is fixed.
9. Run tests to verify your store checkout still works : we make a test frontend order and a test backend order.

   Let us know if you don't want us to make test orders please

10. Check error logs for issues.

11. If there are issues, or the fix/feature doesn't work, we will :
    1. Roll back to the previous version
    2. Run tests to verify your store checkout still works : we make a test frontend order and a test backend order.

       Let us know if you don't want us to make test orders please

    3. Check error logs for issues.

Potential issues

As part of this process the extension may stop working, or throw strange outputs, until we have completed all steps. (Also see the list of potential issues at the top of the page.)

If you see strange output and cut our FTP and/or Magento access at that point - we'll be unable to complete our tests and your site will be stuck in a half-tested state.

We will never normally leave a site without having done these tests so try to be patient if you see some issues.

No problem at all to send us an email if you see something strange ! Please do realise though that we may be in a different timezone to you, and the support crew may be on a different timezone to the team of developers and bug squashers!

If everything goes to plan then your issue will have been fixed, and your site flying along :)