acquia / acquia-sdk-php Goto Github PK

For some reason downloading a component via composer downloads the entire SDK. This is a similar symptom to what the Zend Framework was going through, might be something we can learn from that.

Working hypothesis is that every sub-component will require the PEAR repository.

Follow php-fig/fig-standards#169

Fatal error when calling AcquiaNetworkClient::checkSubscription().

See lstrojny/fxmlrpc#8.

For the time being, we should pin to 0.8.* since we know that works.

The base path in this method is inconsistent with the API function documentation at
http://cloudapi.acquia.com/#GET__sites__site_svnusers__svnuserid-instance_route

We need to check if the problem is with the method or the source documentation.

From @webbj74:

I'm curious if you've thought about how you might extend the current package or object model to support future versioning of cloudapi.

Guzzle's service builder stuff is awesome, however for applications like Drupal configs are likely to be stored elsewhere. Therefore we should provide a pluggable mechanism that reads and writes the service builder definition to alternate locations.

We can use the technique outlined at https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repository. See all the acquia-sdk-php-* repositories.

Although the code is in a good state, we should rebuild the acquia-sdk-php-* to remove the -n from the commit messages. As per dflydev/git-subsplit#12, this is an issue with Git, and the workaround is specified there.

See comments from @timhilliard at #42 (comment)

Dead repository at https://github.com/cpliakas/Acquia-Cloud-Utilities, but similar concept. The value is that it would allow PHP apps in general to connect to Acquia's database.

The Environment class (and future interface) should be separated out to it's own component.

As awesome as the https://github.com/lstrojny/fxmlrpc library is, systems like Drupal have their own XMLRPC libraries which we should be able to use if available. The default should be https://github.com/lstrojny/fxmlrpc, but systems should have the option to opt-in and use their own.

Issuing requests to the update handler return a 403.

Currently it does not handle the API function's two required query parameters

Via @jfarrell: In the Database component, we should be a little more defensive than usual and check that the variables are set prior to generating the string. This will prevent malformed connection strings and will allow developers to catch errors on the off chance that the server returns malformed data.

The creds.json file also contains the info for the memcache servers, so it seems like the Cloud Environment class is a good place to store the credential parsing code since it is environment specific and can be reused.

There have been some requests to separate out the JSON component for independent use. Adding the feature request here.

After setting up the Acquia SDK for our use our SSO, I have found a few errors popping up around calls to PHP's getenv() for the Acquia environment variables which end up not being available and they fall back to 'local' in most cases.

Consider the following:

$ drush php-eval "var_dump(getenv('AH_SITE_ENVIRONMENT'))"
bool(false)

$ drush php-eval "var_dump(\$_ENV['AH_SITE_ENVIRONMENT'])"
string(3) "dev"

Happy to provide you with the patch that we have rolled for our installation if you're happy to take this.

As a follow-up to https://github.com/cpliakas/acquia-sdk-php/pull/17, we should explore adding logic that only calls Acquia\Common\Json::prettyPrint() when the native options are not present. The method is smart enough not to pretty print JSON that is already formatted through the if (strpos($json, $newline)) { condition, however Acquia\Common\Json::encode() could be optimized to eliminate a method call when the native options are present.

This is more-or-less a micro-optimization.

See the https://docs.acquia.com/cloud/configure/env-variable, we can auto-detect the site group.

Makes it easier to develop locally and port to Acquia Cloud

The version is now needed outside of just the Network component, so we should add a global version class in the Common component.

The CloudEnvironment class should implement a method that reads the AH_CURRENT_REGION environment variable.

No longer needed or used.

As-per PHP Project Starter, it is also a more permissive license.

Currently we have send*() methods in CloudApiClient that wrap the request sending. We should explore removing these methods in favor of passing a request to the constructor of the response objects and having the response execute the request and get the format that it expects.

See the https://github.com/cpliakas/bigoven-php repository, specifically https://github.com/cpliakas/bigoven-php/blob/master/src/BigOven/Response/Response.php#L30 for an example.

As per #24, we need to deprecate the installDistroByName() function.

Take what you need strategy.

The CloudApiClient class is missing methods for the following API functions

• List a site’s tasks. [See #11]
  • GET /sites/:site/tasks
• Copy files from one site environment to another.
  • POST /sites/:site/files-copy/:source/:target
• Deploy code from one site environment to another.
  • POST /sites/:site/code-deploy/:source/:target
• Add a database.
  • POST /sites/:site/dbs
• Copy a database from one site environment to another.
  • POST /sites/:site/dbs/:db/db-copy/:source/:target
• Delete a database.
  • DELETE /sites/:site/dbs/:db
• Move domain(s) from one site environment to another.
  • POST /sites/:site/domain-move/:source/:target
• Deploy a specific VCS branch or tag to an environment.
  • POST /sites/:site/envs/:env/code-deploy
• Delete a site environment database instance backup.
  • DELETE /sites/:site/envs/:env/dbs/:db/backups/:backup
• Restore a site environment database instance backup.
  • POST /sites/:site/envs/:env/dbs/:db/backups/:backup/restore
• Configure Live Development on an environment.
  • POST /sites/:site/envs/:env/livedev/:action
• List an environment’s domains.
  • GET /sites/:site/envs/:env/domains
• Get a domain record.
  • GET /sites/:site/envs/:env/domains/:domain
• Delete a domain.
  • DELETE /sites/:site/envs/:env/domains/:domain
• Add a domain name.
  • POST /sites/:site/envs/:env/domains/:domain
• Purge the Varnish cache for a domain
  • DELETE /sites/:site/envs/:env/domains/:domain/cache

The service manager is fairly isolated, and it could potentially be it's own component independent of the SDK.

Having to require PEAR as a repository kills the performance of Composer package updates, and we are only using a small subset of the functionality. We should evaluate whether rolling our own thing would be a better options or whether we should continue to build on the package to be lock-step with the Acquia Cloud codebase.

The install distro methods currently aren't working.

The Acquia\Rest\Collection class allows developers to set which property the collection is contained in. There are some API's that will use a different property for the collection but iterate over the same set of elements. In order to facilitate not having to create different classes, the SDK should have a system that allows you to define a list of possible elements that contain the collection.

Similar to the Amazon SDK for PHP, people should be able to download the SDK as a PHAR archive to get up and running.

From a technical perspective the Box project like PHP Project Starter does.

The items in "require" have trailing commas.

The Response and Object classes are generic enough to be used elsewhere. The classes should also be named "Collection" and "Element" respectively to be consistent with REST API nomenclature.

Currently the class assumes that the response is an array of objects, but there are instances where a collection is contained within a property.