live site access

Site Access Guidelines

Why Are We Asking For Access? Feature-Testing and Issue-Checking

The two main reasons we will ask for access to your installation are:

• To install a requested feature, and test that it does what you want
• To investigate a reported issue

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 don't you want to check it on my live site? Are you going to break it?!"

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.

Guidelines to Granting Developer Access

Even if you're not giving us access to your live site, it's worth following these guidelines:

Backup

• Backup the database.
• Backup the files (specifically the /app folder, but worth doing the Magento folder anyway).
• Really, make a backup :)
• When you make a backup, don't make the only copy on the same server as your Magento install. I've seen situations where hacked sites have had all backups deleted.

Access Credentials

• Make a specific login for each specific team, both on Magento and FTP/SSH. Don't be tempted to share details between teams.
• Once the task is complete, delete or disable the access.
• If providing SSH access, don't give out root user access.
• If providing FTP access, limit the path root usually to the folder Magento is in, and not above.
• Use a firewall to limit SSH and/or admin access only to specific IP addresses.
• When providing Magento access details, it sometimes makes sense to limit access to relevant areas.
• If you do limit Magento access, don't include the ability to edit User Role in the granted privileges (otherwise the user can grant themselves access to everything).
• In general our team will need access to a few specific areas - an easy way to deal with this is to make a User Role (System>Permissions>Roles) that you can assign dev team access to.
• We specifically usually need access to:
  • Orders Page & Order Detail Page
  • Catalog Page & Product Detail Page
  • SystemToolsCompilation
  • SystemCache
  • SystemIndex
  • SystemConfiguration -> All Moogento Sections
  • SystemToolsConfiguration -> All relevant 3rd Party Extension sections
  • SystemScheduler (if you haven't installed AOE Scheduler, it's a good idea to keep track of cron status)
  • (Sometimes) CatalogAttributes

Potential Issues

As part of our install/test process, the extension may stop working, or throw strange outputs, until we have completed all steps.

If you insist that we check your issue (or test new 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 : a live site is... live!

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/Catalog 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, and disable compilation and caching (if enabled).

   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.

   Please let us know if you don't want us to make test orders

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.

You might see short-lived issues

If you see strange output, try not to panic! Same goes if you see any issues with your site (please see the list of what could happen at the top of the page).

It's important to not 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.

Feel free to send us an email if you see something strange, it may help our work, but please be aware that we may be in a different timezone to you. Quite often the support crew may be on a different timezone to the team of developers and bug squashers - ie. your email may not always be read at the same time.

Success!

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

We will get in touch and ask you to run your own tests, but we will have checked that the core functionality is working.