It has several advantages:

1. SSH into a real Linux shell. It's been a while since I used Unix, but the old habits come back fast and I like having all those tools available.
2. SFTP support. More secure and faster (at least it seems that way) than FTP, especially with Notepad++.
3. It sure seems cheap (only $0.01/day for the site, $0.02/day for as many mySQL databases as you want).
4. Lots of languages besides PHP. Maybe I will learn Python someday.
5. Up-to-date versions of the tools, like PHP 5.3 (anonymous functions!) and Apache 2.2 (FallbackResource!). 1and1 was still stuck on the old versions.
6. They enable file URL wrappers, so I can use get_file_contents('http://example.com') and the like, rather than cURL.
7. A general feel that these guys are more hacker-oriented rather than simple, one-click-install-package oriented.

But there are disadvantages as well.

1. It's not nearly as cheap as it seems. A simple site as above is $0.03/day = $10.95/year, but it's all pay for what you use. They charge for server usage based on storage, $0.01 per megabyte-month, so my 100 megabytes of fonts and images is another $12/year. Domain name registration is $9.49/year, plus $0.41/year for DNS. Bandwidth is $0.20 to $1.00/gigabyte, depending on usage. For my relatively popular blog (about 300-600 visits/day) I'm sending about 100 MB/day or $0.07/day or $25.55/year. That adds up to $58.40/year, basically the same price as 1and1. And I feel like I have to watch every byte stored or transferred. I know it's not really much money, but it's an avocation rather than a vocation so I need to justify the cost to myself. The bandwidth I'm going to have to explore to find out what's going on and possibly stop hotlinking and the like. The storage costs I can hack around by putting the big stuff on Amazon S3 at only $0.14/gigabyte.
2. They don't automatically take the money from a credit card. You have to deposit funds in your account, and if it runs dry, the site goes down. They'll send out low-balance warnings but I'd like an automated method. Alos, every payment comes with a $1.00 deposit fee, so making monthly payments is another $12/year.
3. PHP runs in safe mode, so a lot of file and system functions are disabled. This is deprecated in the latest PHP, so I don't know what NearlyFreeSpeech will do, but right now it makes life much more difficult. There are workarounds, notably using CGI scripts rather than straight PHP, but this is the biggest downside.
4. No cron jobs. You can't run any processes on their servers besides the webserver, mySQL and whatever you're doing when SSH'ing in. They promise they're working on a solution, but no update since 2008. You can use hacks like WP-cron but that is exactly that, a hack.

But overall, it looks like a good thing and I'm looking forward to (slowly, as I have the time) moving all of bililite.com over to the new host (then transferring the domain when I'm sure it works).

1. The correct program is /usr/local/bin/php-cgi (or whereever your server puts PHP), not /usr/local/bin/php. That is the command-line interpreter, which does not output the headers. You can manually do echo "Content-type: text/html\n" etc., followed by a blank line, but who wants to try to debug that?
2. The script has to be executable. You get a 500 Server Error otherwise. Do a chmod +x scriptname.cgi.
3. Scripts need the appropriate file and directory permissions to write to the server. Changing the permissions of the server directory is probably too insecure (though for safe mode it's the only way); it's better to set-uid the script, but then keep it under wraps.

So a sample CGI script would be:

#!/usr/local/bin/php-cgi
<?php echo "Hello, world"; ?>

in an executable file with a .cgi extension.

Note that FTP and SFTP can't set the setuid bit, so that if you upload the file (or edit it with an FTP-aware editor like Notepad++), you need to chmod 477 scriptname.cgi again.]]> http://bililite.nfshost.com/blog/2012/01/12/writing-cgi-scripts/feed/ 0 http://bililite.nfshost.com/blog/2012/01/12/things-i-learned-about-htaccess-part-2/ http://bililite.nfshost.com/blog/2012/01/12/things-i-learned-about-htaccess-part-2/#comments Thu, 12 Jan 2012 16:29:48 +0000 Danny http://bililite.nfshost.com/blog/?p=2200 I've learned some things about .htaccess, but mostly I've learned that programming it is deep black magic. The most important thing is "Don't use mod-rewrite unless you absolutely need to". All the fancy stuff is better off done by the PHP (or whatever language you're using) code.

Don't do:

RewriteEngine On
RewriteBase /
RewriteRule ^([^/\.]+)/$ /index.php?main=$1&part=$1 [QSA,L]
RewriteRule ^([^/\.]+)/([^/\.]+)$ /index.php?main=$1&part=$2 [QSA,L]

to map your site to your index page; do:

FallbackResource /index.php

And in index.php parse the $_SERVER['REQUEST_URI'] to get your page/subpage arguments. Much easier to debug!

And to use FallbackResource you need to be running Apache 2.2, so get a good web host.

The subsequent time I learn a blog, I hope that it doesnt disappoint me as much as this one. I imply, I know it was my choice to read, however I truly thought youd have one thing attention-grabbing to say. All I hear is a bunch of whining about one thing that you would repair in the event you werent too busy searching for attention.[links to some construction contractor removed]

I guess they know how humble I am and that I'd take criticism more seriously than praise.

But it's still painful to read something negative and have to take the time to parse it and realize it doesn't say anything at all, so I hope it doesn't become a trend. Thank goodness for Akismet!

<form method="get" action="http://www.bing.com/search" >
	<input name="q" type="text"/>
	<input type="submit" value="Search with Bing"/>
	<input name="q1" value="site:http://bililite.nfshost.com/blog" type="hidden"/>
</form>

And it works, but fails again on the mobile site, just like Google. This may get better as the search engines figure it out, but I'm going to have to write my own search engine portal. What a pain.

Actually, not such a pain. Something like:

header('Location: http://www.bing.com/search?q='.urlencode($_GET['q']).'+'.urlencode($_GET['q1']))

for Bing and

header('Location: http://www.google.com/search?q='.urlencode($_GET['q']).'+site:'.urlencode($_GET['sitesearch']))

for Google. And that's what I did for the Young Israel site

<form method="get" action="http://www.google.com/search" >
	<input name="q" type="text"/>
	<input type="submit" value="Search with Google"/>
	<input name="sitesearch" value="http://bililite.nfshost.com/blog" type="hidden"/>
</form>

is deprecated and doesn't work from Google's mobile site. Google does have an API for custom searches that has all sorts of fancy parameters to manipulate, but it requires signing up for a key and constructing the search ahead of time. However, some experimentation shows that not including a key brings back the old, simple search query (with a new URL and some new parameters), so we're back in business:

<form method="get" action="http://www.google.com/cse" >
	<input name="q" type="text"/>
	<input type="submit" value="Search with Google"/>
	<input name="as_sitesearch" value="http://bililite.nfshost.com/blog" type="hidden"/>
</form>

And there's all sorts of interesting things hidden in there, like sorting by date (Google tries to guess that, but doesn't do so well):

<form method="get" action="http://www.google.com/cse" >
	<input name="q" type="text"/>
	<input type="submit" value="Search with Google"/>
	<input name="as_sitesearch" value="http://bililite.nfshost.com/blog" type="hidden"/>
	<input name="sort" value="date:d" type="hidden"/>
</form>

And the entire Web Search API is deprecated, so I'll have to change the googleSearch widget to use the JSON Custom Search API eventually.

Overall, sweet. At least until Google changes things again.

Addendum: it looks as though the mobile site does require the cx parameter to limit the search to a specific site. Oh, well. It's not that hard to create a custom search.

Addendum, later the same day: It looks as though Google isn't supporting the sitesearch query at all; it was deprecated a few months ago. The fact that it still sometimes works is just a lucky coincidence. They use "Custom Searches" now, and this wise person figured out how to use it with forms rather than javascript. So that's what I'm using now. It serves ads at the top of the page, but I'm too cheap to pay for the ad-free version.

The documentation for the query parameters is pretty complete, and it looks as though you could create a "generic" all-web custom search then use the parameters to limit it programmatically. Unfortunately, it looks as though the XML/JSON data is only available to paying customers.

The big gotcha from the official CSS3 documentation: @media (max-device-width: 480px) doesn't work (in either Safari or Firefox), even though the documentation says it's legal. You have to have a media type in there: @media screen and (max-device-width: 480px). Took me forever to find that bug.

I would also use max-device-width rather than max-width; the user on a big screen may shrink the window and it would be confusing for the layout of the site to suddenly change. I would also not use the only screen hack that Apple suggests; there doesn't seem to be any reason to use CSS hacks (shades of the 1990's!) to target only iPhones.

The other gotcha is with my CSS parser: the javascript is run in the order that it is seen, so if you want to remove a widget for the small screen you have to explicitly destroy it:

#q {
  -jquery-googleSearch: /* default */;
}
@media screen and (max-device-width: 480px){
  #q {
    -jquery-googleSearch: destroy;
  }
}

Hope this helps somebody avoid a miserable morning.

Everyone seems to use Alex Gorbatchev's syntaxhighlighter but it uses nonstandard name attributes and only works on pre and textarea elements, so I haven't tried that. I tried Benjamin Lupton's jQuery syntaxhighlighter based on Google's prettify. It insisted on making all elements display: block but a little CSS manipulation fixed that.

Then I tried snippet, which only works on pre elements but was easily modifiable to get around that, then also needed some stylesheet changes to keep the results from being display: block. Adding new languages however looks far too complicated; it uses shjs which uses language definitions from GNU Source-highlight, which is a whole different language.

jush does things right (working on code elements and not forcing them to be block) but it's hardwired for a limited number of languages and the CSS is pretty ugly. That could be fixed, though, and it does a cool trick of turning keywords into links to the documentation. Too limited a language selection, though, but it would be a nice base for working on.

In the end, I'm going to stick with chili. It's simple enough for me to modify to suit my needs, it's easy to add new languages and it works. Creating new "themes" is impossible; the styles are hard-coded into the javascript files, but I can live with that. I may sometime write my own highlighter, but for now, I'll stick with what works.