http://www.dind.com/blog/web-hosting/ en-us Fri, 18 May 2012 20:05:09 PDT Fri, 18 May 2012 20:05:09 PDT SiteCrafting.com GearBox 1.1 (beta) http://www.sitecrafting.com/blog/master-domain/ It begins with a letter or maybe even an "invoice". It ends with the transfer of your domain to another registrar and in some cases even the loss of your domain entirely.  The term for this is Domain Slamming.The practice preys upon unsuspecting people who want to pay their bills and keep their domain names current. After all, we have our domain name printed on every invoice, business cards, painted on our trucks, and we advertise with Google Adwords, we don't want our domain to expire. This is exactly what they count on.  We at SiteCrafting have noticed a growing number of domains that are either being hijacked by these scam artists or are trying to be hijacked. So what can you do?Investigate the source of the letter or invoice, a quick Google search on Domain Registry of America will highlight it as a scam.Check your domain status - Free tools like www.allwhois.com can give you your domain information and more importantly expiration information.  If we host your domain or provide registration services for you, know that we automatically renew your domains for you each year to insure they are renewed.If you have paid one of these companies or agreed to a transfer your domain, you can file a complaint with your state's attorney general office and the FTC. SiteCrafting is committed to providing our customers transparent service when it comes to domain hosting, web development, and regsitration services. If you ever have any questions on the process please don't hesitate to contact us. As an added precaution, SiteCrafting has enabled Registrar-Lock on all domains to insure that they must be unlocked prior to transfer.  This addition saved one of our valued clients from losing nine domains to Domain Registry of America this morning.Related Links:http://www.ftc.gov/opa/2003/12/domainreg.htmhttp://www.domainavenue.com/scam_domain_registry_of_america.htmhttp://www.theregister.co.uk/2004/01/06/court_bars_canadian_domain_slammer/http://support.easydns.com/domain.slammers/droa.php Wed, 15 Nov 2006 21:12:00 PST http://www.sitecrafting.com/blog/adventures-in-database-migration-pt/ SiteCrafting is in the process of phasing out some of our older servers, and as an added bonus, the clients hosted on those servers are getting a MySQL jumpstart, leapfrogging over 4.1 to go straight from 4.0.24 to 5.0.32. Tragically, it's not quite as simple as dump | import. This is what I get for bothering my bosses for a few weeks not long after coming aboard about how nice stored procedures, updatable views, and triggers could be."The wonderful thing about standards," a wiser person than me once said, "is that there are so many of them." That's not the whole of it, though. One good thing about standards is that there are certain features one can generally rely upon to work, translate, port, etc. Assuming one works within them, rather than taking advantage of loopholes allowed by their not-entirely-compliant-but-we're-getting-there-and-anyway-isn't-this-way- easier-and-faster software. When people don't (and I'm not entirely innocent here), you run the risk of turning your simple upgrade into a serious project when your favorite software decides it's time to comply a bit more.The list of incompatible changes between these versions is actually pleasantly short. Many are in realms that don't affect the migration. Others, such as the clipping of oversized numbers (nowadays when you specify that a NUMERIC or similar column is to have no more than two digits left of the decimal, MySQL will actually enforce this and clip 100 down to the nearest 99), can be reviewed with a quick glance at column definitions. However, one has stuck us with a bit more trouble:The precedence of the comma operator also now is lower compared to JOIN, LEFT JOIN, and so forth.Pretty innocuous, eh? Not so much. One of the key aspects of the ON clause in a JOIN statement is that it must compare to a column that is already a part of the output table. This is perfectly reasonable. Consider: SELECT * FROM a INNER JOIN b ON b.key = c.key. Where did c come from? Before you JOIN to b, a constitutes the entirety of the output table. The column c.key is nowhere to be found, and as such has no place in the ON clause.This is all well and good; that query is patently ridiculous anyway. You JOIN tables based on the columns in the tables you've referenced already. Order is of minimal importance: SELECT * FROM a INNER JOIN b ON b.key = a.key INNER JOIN c ON c.key = b.key returns the same information as SELECT * FROM a INNER JOIN c ON c.key = b.key INNER JOIN b ON b.key = a.key. Column order is mixed up, but as a skilled query author, you're no doubt avoiding * and only specifying the columns you need. And as a writer of readable code I bet you're using an associative array rather than numerical indices to refer to your columns anyway (if not reading from the result directly into stand-alone variables).This is all grand as long as all your operators retain the same precedence. And thus we come to the dreaded comma join. I've been avoiding commas in my FROM clauses for as long as I've understood how to use INNER and LEFT JOIN effectively. Standards aside, I think it makes a query more readable. Take these two examples: SELECT * FROM a, b, c, dWHERE a.key = c.key1 AND c.key2 = b.keyAND d.key = a.keyvs.SELECT * FROM a INNER JOIN c ON c.key1 = a.keyINNER JOIN b ON b.key = c.key2INNER JOIN d ON d.key = a.keyBoth convey the same data, and in either it's easy enough to which tables are being referenced: either all in a row or down a column (assuming you put line breaks in your queries). In the second, however, it is much easier to see just how a given table is included: the joining criteria is right there on the same line. Using commas, you're stuck digging through a WHERE clause to figure out just how that piece of info got in there (it may not seem so bad looking at these queries, but as they get bigger, and as query design gets sloppier, things just get unpleasant).However, now the problems are much bigger. With the comma precedence lowering, nothing linked in via this method is recognized as even existing while the parser sorts out the JOIN statements. So you'd better not be using commas and LEFT JOINs in the same WHERE clause, or you're in for an adventure.Where does this leave me? Searching through the code of two dozen clients for the word "JOIN", and madly wiping out the comma scourge with a massive influx of INNER JOIN. Exciting stuff, really. Personally, I'd recommend avoiding this altogether. Stick with the JOINs, people. The JOINs. Thu, 06 Sep 2007 16:45:00 PDT http://www.sitecrafting.com/blog/dns-propagation-explained/ There's always plenty of tech-speak flying around among developers in the office. I certainly try to keep such language at a minimum when working with clients but sometimes it just works its way in there. DNS and other domain-related processes can be pretty confusing, period, let alone to someone anxious for their website to go live. So how to explain DNS propagation? I overheard a co-worker use the best explanation of DNS propagation ever in the world. It went something like this:When a new phonebook comes out, I may already have the new one while yours has yet to be delivered. So when dialing the same number we might have two different expectations for who picks up on the other end.And that's definitely it. When a new domain name is pointed at the place a website is being hosted it can easily take up to a day or more for every corner of the web to get updated with that new information. The internet is certainly a strange beast but with solid analogies like that no one has to be left in the dark. Thu, 15 Nov 2007 06:50:00 PST http://www.sitecrafting.com/blog/quick-lost-content-recovery-option/ No matter how protected your website may be, sometimes you still need a helping hand when an accident happens. Delete a page while fumbling with FTP? Someone else in your office write over your work on a webpage? Heck, maybe your entire site is down! Google Cache may be able to help. Even with offerings like distributed server environments, backups, content versioning, etc. that we're proud to offer clients here at SiteCrafting, sometimes a quick, self-serve fix can be just the answer. Enter Google cache. Most webpages that Google indexes are stored temporarily to allow searchers options for viewing content results. This feature can also be used to recover written content (not images and other rich media) in a bind. Here's what you do:Enter the web URL of the page you want to recover into Google's search boxorSearch for some content on the afflicted page in quotes with the domain name after it (e.g. "brief timeline" sitecrafting.com)Click on the "Cached" link when find the right result pageCopy and Paste and re-format the content into your webpage editor to save and re-post on your siteI've recommended this method a few times to folks that haven't thought of Google's cached pages in this way. Your mileage may vary, of course, depending on how often Google crawls your website and how long it's been since your content r-u-n-n-o-f-t. In the meantime, happy cache spelunking! Mon, 18 Aug 2008 14:48:00 PDT http://www.sitecrafting.com/blog/hiding-maintenance-wall/ A common task in web development is updating a live server. There are many ways to do it, but some of them require downtime. Rather then turn users away, it is best practice to put up a maintenance page. But what if you still need access to the site while you are updating it? .htaccess and Cookies to the rescue!Most people use .htaccess for simple mod-rewrites (is there such a thing?). Usually, this follows some regex pattern that forwards off to a PHP page to give the user some pretty URLs. You can use this same .htaccess to create a wall between your users and the site, allowing you to put up a maintenance page while still giving you access. To do this, add the following lines of code to the top of your .htaccess file:RewriteCond %{HTTP_COOKIE} !^.*maintenance.*$ [NC]RewriteRule ^.*$ maintenance.html [QSA,L]What this does is check your cookies for one called maintenance. If you have this cookie, it will continue with your session like normal. If you are missing the cookie, you are simply forwarded to a friendly maintenance message.There are several ways to get the cookie setup. Personally, I just use a bookmarklet to inject the cookie into my browser. If your clients need access, then add a get variable to the url and have the maintenance page add the cookie. Enter Maintenance Tue, 10 Nov 2009 11:02:00 PST