Here are the steps that I’ve used to move some Windows Server EC2 instances to a different AWS account. This method should work for any OS, but I’ve only tested with Server 2008 R2.
The simple version:
- In the source account, stop the instance
- Make a snapshot of the instance’s system volume
- Share the snapshot with the destination account number
- In the destination account, make a volume from the snapshot
- Create an instance with the same OS as the source instance
- Detach and delete the new instance’s system volume
- Attach the volume from step 4
- Start the instance
The detailed version:
The Google Spreadsheets API allows you to send simple queries to retrieve subsets of the rows in your sheet – it’s as easy as appending the query to the end of the URL.
For example, if I have a column called “Quantity” and want rows with Quantity greater than 9, I would append ?sq=quantity>9 to the end of the URL and issue the GET request (don’t forget that column names are always converted to lowercase and spaces are removed).
The other method is to add the sq query parameter to the Guzzle $httpClient. I’ve illustrated this in my example code.
See this page for more info.
The Rackspace web dashboard allows you to attach a certificate and private key to a cloud load balancer for ssl offloading. But even though the load balancers support SNI and multiple certificates, neither the web console nor the “rack” command line scripts expose this functionality.
If you want to attach additional certificates to a load balancer from the command line, check out racklb.sh at https://github.com/karlkranich/racklb. The script doesn’t do a lot yet, but does the two things that I miss most from the web console:
- Expose the private (ServiceNet) address of a load balancer
- Manipulate the certificate mappings
To get started with it, clone the repo and check out the readme and “racklb.sh -h”
Thanks to Adam Bull at www.haxed.me.uk for the inspiration and sed magic in this script!
It turns out that my Google Sheets API instructions don’t work right away on Windows. People running WAMP or XAMPP have been reporting “cURL error 60: SSL certificate problem: unable to get local issuer certificate”.
For some reason, cURL on Windows doesn’t come with a certificate bundle, so it can’t verify Google’s certificate to establish a TLS/SSL connection. There are many articles out there making it sound really simple — just
- download a cacert.pem file
- add a line to your php.ini file: “curl.cainfo = path to cacert file“
But it took me hours to work out the details. First, the cacert.pem file that most people point you to (at curl.haxx.se/docs/caextract.html) didn’t work for me. After a while, I found that the cacert.pem from Shane Stebner at flwebsites.biz/posts/how-fix-curl-error-60-ssl-issue made all the difference. I haven’t figured out why.
Second, note that there are at least two php.info files on your system: one for running php from the command line (mine is C:\wamp\bin\php\php5.5.12\php.ini), and another for when php is called by Apache (for me, that’s C:\wamp\bin\apache\apache2.4.9\bin\php.ini). Since I’m running php from the command line, I only edited the first one.
I saved the cacert.pem file in c:\wamp and added this to my php.ini: curl.cainfo = c:\wamp\cacert.pem. It didn’t matter which kind of slashes I used.
Hope this helps a few people start accessing Google Sheets with PHP!
Here’s how to get up to speed with the Google Sheets cell-based feed and PHP.
My previous posts have illustrated the use of Google’s PHP API client to interact with Google Sheets using list-based feeds. This method is ideal for reading from and writing to spreadsheets that have a single header row, but isn’t useful for more complicated sheets.
The cell-based feed allows individual cells to be read and written. I’ve written some example PHP code that implements the cell-based feed methods to help get you up to speed a little quicker. Google documentation is here.
To start, follow the steps in this post to set up your service account, share a spreadsheet, and install the API client. Then you should be able to adapt my example code to interact with your spreadsheet.
Please let me know if you have any comments or questions!
AKA: Sheets API access with PHP part 3
Continuing my series on using PHP to manipulate Google Spreadsheets, I’ve added a section to my code that reads the XML representation of a spreadsheet and then parses out the rows and columns. Note that whenever you’re working with list-based feeds, we’re assuming that the first row contains column headings.
Using SimpleXML, it wasn’t difficult to parse out the cell data. The biggest hurdle was learning about XML namespaces — at first, I thought that the XML had tags like “gd:etag” or “gsx:quantity” and had to learn that gd and gsx were namespaces. In SimpleXML, several of the methods take a namespace as a parameter. You can specify the prefix or namespace URL as described in the doc for the children method here.
I think it’s also possible to get the spreadsheet data as json, but I haven’t tried that yet.
My previous Sheets API post demonstrated how to add rows to Google Sheets with PHP. Some readers were interested in editing or deleting rows.
Google has a very informative reference here that describes the list-based feed for manipulating sheets. All of my scripts have been using this method, which requires the sheet to have a single header row (I’d been lucky to use that format without knowing the requirement). I use the example HTTP code from Google’s reference pages to give me guidance for my PHP.
I’ve added a file to the gist demonstrating how to edit a row. Here’s what you need to know:
- When you get the sheet list feed (Section 3 of the first file in the gist), you need to add a header (“GData-Version” => “3.0”) to the GET request so that the Etag is returned for each line.
- Once you have a list of entries and find the one that you want to edit, you need to grab its Etag, Id, and the edit URL (see lines 1, 2, and 9 in the image above, and click on the image to see the whole entry).
- Now you just need to issue a PUT request to the edit URL and include the XML with the Etag, Id, and updated sheet data.
Hope this helps a few people!
People who use my Insert and Delete Cell Add-on for Google Sheets have been reporting this error. I was unable to recreate the error until someone shared a spreadsheet with me and I found the culprit: merged cells.
What’s going on?
When you insert cells and shift the existing contents down, my Add-on selects the range of cells from your selection to the bottom of the sheet and moves it down. But if there are merged cells below your selection, the new range doesn’t make sense and an error is generated. The same thing happens if you try to delete and shift up, or if you try to shift left or right with merged cells to the right of your selection.
Why not catch the error and generate a friendly error message?
I’ve been trying, but this error isn’t triggering the try – catch section of my code. There also isn’t a way to detect merged cells without trying some strange tricks that would take a lot more time than I have. I’ve opened a bug report with Google about this.
This error seems to be Google’s version of “We’re not sure what happened, and hope that if the customer tries again it might go away”.
Note on 8 February 2017: Google has released the Sheets API v4 and is now providing PHP sample code and improved PHP support for Sheets in the PHP API client. My series of articles is now largely obsolete. See https://developers.google.com/sheets/api/quickstart/php
Google has been sending out messages saying that several of their APIs are going to be discontinued (for example, the Document List API). As a result, I tried to modify my custom Google Spreadsheet-populating PHP script to use the new Drive API. After way too much wasted time, I discovered that the Drive API can create sheets and read their metadata, but can’t add rows — for that we can keep using the Spreadsheets API.
I was successful at converting the authentication portion of my script from the old ClientLogin to OAuth with a Service Account (the script runs behind the scenes of a web site and populates a Google spreadsheet that the web site user has no knowledge of).
It wasn’t as simple as I’d hoped because the Google-provided PHP client for the Drive API doesn’t know about the Spreadsheets API. I had to dig around the PHP libraries to piece together authentication codes and Google_Http_Requests. Then Google changed the PHP client to use Guzzle, so I recently made that change.
So, if anyone else out there is interested in the combination of PHP, the Spreadsheets API, and OAuth with Service Accounts, this could save you some time.
The code is available in a public Gist at https://gist.github.com/karlkranich/de225928665dc6b83667
Here are the step-by-step instructions to get this to work:
I love finding the forum or blog posts that have titles like “Problem I Have – Solved”. This is not like that.
I installed Joomla 3.2.3 on my web host where I’ve been running Joomla 1.5.26. The Joomla 3 installation can send mass email, but its contact forms don’t send. On the 1.5 install, both mass emails and contact forms send fine.
- It can’t be the mail settings, since the mass emailer works fine.
- It can’t be the mail program on the host, since the 1.5 install sends fine and the mass mailer on the v 3 install works.
- It can’t be an issue with the domain of the web host vs domain of my From: address for the same reasons.
- It could be contact form options, but I’ve tried everything I can find.
- I’ve tried the tips from blog posts regarding copying libraries from a new install – no luck.
I finally had to admit defeat and installed the free version of the Flexi Contact extension. I hate to give up, but installing that extension got me a working contact form in a few minutes.