The situation I was finding was that PHP apps would run, but only if you explicitly call the script (ie index.php) rather than just the directory. If you called the directory, passenger would take over and give me a rails routing error.

The issue was to do with the passenger vhosts configuration. On my machine I have an number of ruby on rails apps configured with the passenger preferences pane (creating vhost entries within /private/etc/apache2/passenger_pane_vhosts/. I have enabled user_dirs, so that the users of my machine’s pages (and other apps) are served from their ~username/Sites directory.

My users configuration info for apache is installed in /private/etc/apache2/users/, and the instructions to load the configuration from that directory is stored within /private/etc/apache2/extra/httpd-userdir.conf (content below).

# Settings for user home directories
#
# Required module: mod_userdir
#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites
#
# Users might not be in /Users/*/Sites, so use user-specific config files.
#
Include /private/etc/apache2/users/*.conf

To get everything working together nicely, I merely wrapped this inside a vhosts configuration directive, and gave it a ServerName of localhost – so that this vhost would be the one that responds to requests for localhost, rather than some random passenger vhost assuming it was the boss of everything. New /private/etc/apache2/extra/httpd-userdir.conf below.

<VirtualHost *:80>
  ServerName localhost
  UserDir Sites
  Include /private/etc/apache2/users/*.conf
</VirtualHost>

Thanks to this, all of my rails apps are served under passenger, and I can have static HTML, PHP and camping apps (previously configured – nothing to do with the above) all served from within my ~username/Sites directory.

Hope this helps someone.

In Safari the form upload worked. Even in Internet Explorer 6 the form upload worked (after I fixed the dodgy MIME-type that IE passes through for JPG images – image/pjpeg for those interested).

The form I was trying to submit had the multipart attribute set correctly, and also had some javascript to disable the file selection, form submission button, and show a spinner to indicate that something is happening, and they don’t try and submit the file twice if they’re sending in a large image.

My submit tag orginally looked like this (Ruby on Rails)

<%= submit_tag 'Upload Photo', :class => "formbutton", :id => "submit-button",  nClick => "$('upload-form').submit();Form.disable('upload-form');Effect.toggle('footnote', 'appear', {duration: 0});Effect.toggle('spinner', 'appear', {duration: 0});" %>

I was very confused as it did work in those other browsers, but not in Firefox.

The key to fixing this was to add return false; to the end of the javascript statement…

<%= submit_tag 'Upload Photo', :class => "formbutton", :id => "submit-button",  nClick => "$('upload-form').submit();Form.disable('upload-form');Effect.toggle('footnote', 'appear', {duration: 0});Effect.toggle('spinner', 'appear', {duration: 0});return false;" %>

What I find particularly confusing about this is that everything I read on the “return false;” statement leads me to believe that this form should not be submitted – however – return true does not work (500 Internal Server Error returned). But what the hey – it works.

Putting in a country that they can’t check the actual account number for causes their little javascript application to unleash a serious dissing.

Ouch!

BTW – Sorry for the Rodney Dangerfield knock-off quote. He’s awful.

someone else: You have to put it in there?

me: Yes, I have to tell them about it.

someone else: Don’t they just find it?

me: How would they find it?

someone else: Google.

 

 

BTW – check out countees.co.uk – wear your UK county on your chest.  More about this soon.

Oh well, no spending at that particular store tonight.

http://code.google.com/apis/ajaxlibs/

The service supports either programmatic inclusion using the google jsapi library, or linking directly to their hosted copies.

Good things about this

• You save bandwidth costs, as your users download the libraries from google
• Your users get faster browsing ON OTHER DOMAINS, because the more people that use a single source, the more caching should happen

Bad things about this

• Google have more opportunity to don’t be evil – the biggest concern for me is their increased ability to understanding which users use your application, and propensity for understanding how they use it.  A malicious individual within the company could put some nasty code in the js to screw with your site, or monitor and transmit back to googlebase what the user is up to.  It’s very unlikely, but it could happen.

Come on Twitter, what’s going on?

(and if you want, follow me on Twitter!)

Explanation (kind of) is available here. Short answer is that the phrase “wget” (minus the quotes) followed by a space is not allowed. Crazy, huh?