<form action="index.php" method="post" name="searchForm" id="searchForm">
...
<a onclick="changeAction();">Export File</a>
<input type="hidden" name="action" value="1" />
...
</form>

Where the changeAction function is defined as

<script>
function changeAction(){
 var x = document.getElementById("searchForm");
 alert("original action: "+x.action);
 x.action = 'export_csv.php';
 alert("new action: "+x.action);
 x.submit();
}
</script>

I found this function on w3schools, and I was trying to figure out why it wouldn’t work for me. It worked fine in Firefox, but not IE. It finally occurred to me that in IE, document.getElementById(“searchForm”).action was the same as document.getElementById(“action”) — that is to say the .action was not the form’s action property, it was actually pointing to the input HTML element instead. I would argue that this is a bug with IE, that any input named ‘action’ would overwrite any direct access to the action form property.

This made it seemingly impossible for me to dynamically change the action of a form with the conflicting named input item.

The obvious solution is to change the name of the input. For most that would probably work OK, but I didn’t like that solution. I HAD to get it .

Solutions:
The first thing I tried was removing the input, then submitting the form. This would work for most. So that involved:

1. Enclosing the input with a span with an ID I could reference — ‘action_input’.
2. Changing the changeAction function to clear the innerHTML of ‘action_input’, then submit.

This works fine for most. However, for me the new action I am setting retains the current page, it does not do a new page load. This means that I need to be able to reset the action value after submitting, and it appears as though setting the innerHTML after a submit() does not work so well cross browser.

I asked for help on efnet’s #javascript (IRC), and I was directed to the javascript function setAttribute. After some searching, I found that this doesn’t work; in IE the getAttribute(“action”)/setAttribute(“action”, “newVal”) functions STILL reference the HTML input element, not the action property of the form.

Upon more searching, I was directed to the changelog for AjaxAnywhere:

1.1.0.2 – evolution : form “action” attribute is accessed by DOM to prevent collision with <input name=”action” .. >

(Hey, at least someone else had this same issue!)

I perused their source code, and found this snippet (aa.js, line 130):

var actionAttrNode = form.attributes["action"];

So I tried that, and it worked beautifully in IE6, IE7 and Firefox 2. The adjusted javascript function:

function changeAction(){
 var x = document.getElementById("searchForm");
 x.attributes["action"].value = 'export_csv.php';
 x.submit();
 x.attributes["action"].value = 'index.php';
}

Update: makk on efnet #javascript says that this doesn’t work with Safari. There’s a workaround which makes it work, which I applied. Here’s the final version of the function:

function changeAction(){
 var x = document.getElementById("searchForm");
 x.attributes.getNamedItem('action').value = 'export_csv.php';
 x.submit();
 x.attributes.getNamedItem('action').value = 'index.php';
}

Problem solved!

My client would like to access and change files via Subversion instead of what they were currently using, FTP. Moreover, they would like the files to exist in their webroot of their domain. Their project is a web project, after all.

After some research and discussion with peers, I found out how to do this. First, I had to add their directory as accessible via subversion. I used Subversion’s FAQ about in-place import to do what I needed. My exact commands were:
# svn mkdir file:///home/svn/rep/{repname}/domain.com -m "Initial create"
# cd /home/{user}
# svn checkout file:///home/svn/rep/{repname}/domain.com
# svn add *
# svn commit -m "Initial version of files"

That seemed to work great, the repository was setup! My client had access to read and write files to their repository, which is their webroot. However, the webroot doesn’t auto-update, so any changes won’t take effect unless it’s manually updated.

Reading further in the Subversion FAQ, I found a way to auto update the files on the website.
I created a “Tiny C” app with the following code
#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
execl("/usr/local/bin/svn", "svn", "update", "/home/{user}/domain.com",
(const char *) NULL);
return(EXIT_FAILURE);
}

Then compiled it

cc -o updaterepo postcommit.c

Then made updaterepo executable and gave it chmod +s, as suggested by the FAQ. Of course I made it owned by {user} as well. Then I created /home/svn/rep/{repname}/hooks/post-commit with the following content

#!/bin/sh
/home/{user}/updaterepo

I tested a commit, and it worked!

Hat tip: Phil.

Country: UNITED STATES (US)
City: Sugar Grove, IL
Latitude: 41.7696
Longitude: -88.4588


And more. This is cool, thanks Andrew.

In your .htaccess file
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.domain\.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

Where instead of domain.com, you put your domain.

This page is accessing information that is not under its control. This is a security risk. Do you want to continue?

The problem was caused by doing an http.open on a domain that was other than that which the script was being run. This wasn’t my intention, so to avoid this issue, I added some server-side host checking, and inserted it into the javascript where necessary:

function getSite(){
var host=<?php echo "'http://".$_SERVER["HTTP_HOST"]."'"; ?>;
if(host != 'http://host1'){
host+='/subdir';
}
return host;
}


I’m sure there’s an easier way, but this worked for me to utilize a “public” and “private” copy of this script without manually editing that value.

This might be a feature, but has caused me many a headache. So, since I doubt I’ll be changing my permalink structure anytime soon, I made it unwriteable.

Edit 7/5/05:
I used this to convert a site I was making for my uncle from a “tabled” design to a “table-less” design. It worked great.