25 Mar 2010I've been using SWFUploadfor quite a long time now. Put simply, it's a Flash/Javascript plugin allowing a file upload to be done without having to submit the page.
Basically it uses the streaming upload capacity of flash to fire javascript events to tell the developer the upload percentage, do some filesize and filetype checks, etc.
If you've ever seen an upload progress bar on any website, it most surely was done using SWFUpload.
Anyway, today I spotted a strange behavior in one of my pages, heavily using SWFUpload
(more or less 20 upload fields). Using the Net panel of Firebug, I saw some strange GET requests being made to my website.
After digging into my code, I could isolate the problem. I was coming from SWFUpload
itself. I even found record of a bug report mentionning it.
In a nutshell, SWFUpload always make a request to the url specified in the button_image_url
parameter, even if you haven't specified one (in this case it made a request to your webroot).
I'm not using any image for my button, or should I say, I take care of that in CSS already, my SWFUpload button is just an invisible Flash element, positionned on top of my existing button.
I tried setting the value to null
, false
or an empty string, but it would continue to do the request.
Anyway, I upgraded to the latest version (2.5.0 Beta 3), and it solves my problem. Now I'm just hoping that all the retro-compatibility will be kept.
18 Mar 2010I don't usually change MX resolving, but when I do, it always almost is using my registrar or host admin panel.
When I have to manually do it, (because the website is hosted on a dedicated server where I have to manually edit almost everything), I always waste a lot of time understanding where to find the configuration files.
Today I had to change the MX record of an existing website to use those of Google. The server hosting the website was also defined as nameserver, so I had to update the /var/named/domain.tld.hosts
file (the file may not be in the same directory in your own server).
I remove the line relative to the MX records and added those instead
domain.tld. IN MX 10 ASPMX.L.GOOGLE.COM.
domain.tld. IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
domain.tld. IN MX 20 ALT2.ASPMX.L.GOOGLE.COM.
domain.tld. IN MX 30 ASPMX2.L.GOOGLE.COM.
domain.tld. IN MX 30 ASPMX3.L.GOOGLE.COM.
domain.tld. IN MX 30 ASPMX4.L.GOOGLE.COM.
domain.tld. IN MX 30 ASPMX5.L.GOOGLE.COM.
It worked well.
I also wanted to use a simple address for the webmail, like mail.domain.tld.
So I added the following line
mail.domain.tld IN CNAME ghs.google.com.
I also updated the serial at the start of the file and rebooted my server. I know there must be a less savage way that rebooting the server but I still haven't find it.
P.S : I used this google / DNS Stuff page to help me test my records all along the way
11 Mar 2010When writing my image plugin for tinyMCE today I came accross the mceRemoveNode
command that one can use to alter the tinyMCE editor content.
It has to be used with editor.execCommand('mceRemoveNode', true/false, node)
.
I don't really get what the true
/false
argument was about, setting either one or the other didn't change anything (that I could tell) in my case. The node argument is the DOM node you want to remove from the editor.
At first I thought that the command would allow me to remove a node from the editor area. I needed it in my plugin. But it was not exactly what it really does.
In fact it only removes the wrapping node, but keep the content intact. In other words if you have
<a href="http://www.domain.com/"><img src="http://www.domain.com/picture.jpg" /></a>
And you remove the <a>
node using mceRemoveNode
, you'll end up with
<img src="http://www.domain.com/picture.jpg" />
in place of your link.
I had to manually (well, with the great help of jQuery) remove the content of the link before removing it. I could have remove the node itself using jQuery but I thought that sticking to the tinyMCE methods would be a better approach, I don't want to mess all this stuff up, maybe "simply" removing html nodes like this could interfere with the textarea
value update, I don't know. And in doubt, I prefer to use the methods and command exposed by the API
11 Mar 2010Reading a comment on AlsacrĂŠations, I've discovered that there is a type attribute defined in the link section of the HTML 4.01 spec.
In a nutshell, it's an optional attribute that one can add to a tag to tell the browser the content type it is supposed to receive if following the link.
Unfortunatly, no browser seems to be using it, but I added this support to Caracole anyway.
10 Mar 2010As this is the second time I encounter this "issue", I think it may be clever to post it here. At least, I won't have to debug it all the down again next time.
In a nutshell, I was working on a complex UI that involve several layers of dialog boxes, each one on top of the previous one. Each new dialog box is supposed to offer the user something to do, and once it is done, the dialog box disapear and the user can get back to the previous one.
The "issues" I was having was after closing a specific window, I wasn't able to focus the previous one. I mean, the window was there, I was even able to update its fields using jQuery, but I couldn't focus it either using keyboard or mouse.
After some digging, it appears that I wasn't correctly "closing" the previous window. I was actually doing a .dialog('destroy')
instead of a .dialog('close')
and this was causing my issue.
Calling close
hides the dialog box, but keep it in the DOM. That way if I ever need the same dialog box again, jQuery is smart enough to re-use it.
Calling destroy
on the other hand actually remove the dialog box from the DOM, forcing jQuery to recreate it from scrath.
It appears that calling destroy
in my case caused a strange lose of focus, so I reverted to close instead.