I received a bit of a nasty shock when by sheer chance, one of the project managers updated their machines and got Internet Explorer 9 installed in the process, only to instantly come back to me and announce that the drag and drop features on our web project no longer worked – at all.
A quick look around, and indeed all the draggable, droppable and sortable interfaces that come with our use of the awesome jQuery and jQuery UI libraries were all of a sudden not working under IE 9. The other browsers, IE 8 included, still worked fine, but not this new beast of a browser.
Thankfully though, a quick look about on the jQuery UI support forums yielded the fact that a) this was indeed a bug that has long been identified, and b) that the bug fix ticket around it has since been resolved and closed.
So how do you sort out the problem then? Well if you can, you need to upgrade to the latest version of the jQuery UI library. The fix has now been in since version 1.8.6, so anything higher will resolve the issue.
And now for a big sigh of relief :)
Related Link: http://forum.jquery.com/topic/jquery-ui-does-not-work-on-ie9
When handling file uploads via enctype=”multipart/form-data” forms in PHP, you’ll be pleased to know that PHP doesn’t just leave you high and dry but instead returns some pretty helpful error codes to let you know when something goes wrong.
The following is a comprehensive listing of the error codes returned by the upload process:
(Note, these can be access from $_FILES[‘#inputname#’][‘error’])
Error code: 1153 – Got a packet bigger than ‘max_allowed_packet’ bytes
So of course I looked it up.
It turns out that MySQL views a single SQL statement as a communication packet, with a built in limit of 1GB. However, servers usually have a set maximum packet size they are allowed to accept and clients a maximum packet size they are allowed to send, both of which is controlled by a variable called max_allowed_packet. If it receives a packet bigger than this limit, the server will spit back a 1153 error and close the connection.
If you wish to check what your current maximum packet size is, run the following query:
SHOW VARIABLES LIKE ‘max_allowed_packet’
Of course, you would also want to increase these limits at some point in time, something which is easily achieved like so:
To increase a client program’s default, run: shell> mysql –max_allowed_packet=32MB.
To increase a server’s default, run: shell> mysqld –max_allowed_packet=16M.
Note that this is fairly safe to increase this value as memory is allocated only when needed. So now you know! :)
Well the answer lies in how the two different methods handle failures. If a file is not found by require(), it will trigger a fatal error and thus kill the main script, preventing any further execution. Include() however will simply trigger a non-fatal warning and then continue with the main script execution.
Obviously it then lies with you as to which one you choose to use for your project. If for example your script is pulling in multiple bits of data and can continue pulling data even if one of the included bits of data can’t be found, then make use of include(). If however the included file contains an important function crucial to the page loading in the first place, then rather opt for a require()!
Simple, but an important distinction to take into consideration! :)
Listening to it and plugging it into various other display sources, I concluded that the onboard graphics must have gone and so looked around on the Internet before settling on a new graphics card which I subsequently ordered from Take 2 for around R500.
A short wait and the card arrived, which I eagerly plugged into the board, proclaimed “There, that should fix it” and hit the power switch, only to see… well nothing. The new graphics card had not solved the problem, meaning that my diagnosis had obviousy been wrong. Doh!
So anyway, this weekend I made some time to try and sort out the issue, taking the machine completely apart and giving it a good dust out, as well as checking and tightening all the connectors and screws that I can find!
With a “Well, maybe this will sort it out”, I hit the power switch and lo and behold, all of a sudden I had video out again – awesome except for the fact that it only lasted a minute or two before the machine without warning simply lost power.
Booting it up again, it became apparent that this was now the new problem and that the video outage had most likely simply been symptom of this new problem.
The losing power thing seems to happen completely at random – it can happen as the machine is still booting up, it can happen while Ubuntu is still busy starting up, or it can strike just as you start thinking that the problem has sorted itself out and open a website to check what might be causing the problem.
At first I thought that maybe the power supply wasn’t pushing out enough power and that the devices were too much for it to handle, so I systematically began unplugging components but to no avail.
So out came the screwdriver and back into the box I dove, giving everything another good dust-over before removing the Power Supply Unit (PSU) and completely taking that apart, cleaning every bit and piece as I came across it.
Slapping everything back together again and hitting the power button proved to be completely… futile.
Sigh. So the power was still coming and going sporadically so I had to make the call as to whether I thought it the PSU or motherboard which is the problem child. Looking at the board I couldn’t see any problem, no popped capacitors or anything like that and so hopped into my car and drove through to Computer Mania at Somerset Mall where I slapped down R600 and bought a nice and shiny 600W power supply that comes with a giant fan and looks pretty damn spiffy.
Back home I installed the new PSU, booted the machine up and yay, “Seems like that sorted it out” – until the machine shut itself down again just ten minutes later.
So the problem still isn’t solved and my ability to diagnose hardware issues lies in complete tatters. Chantelle keeps urging me just to take it in and have it fixed, but my pride as a man simply won’t allow me to do that.
It’s now a personal challenge for me, and one that is bringing no end of frustration. The question now of course is – should I look at the RAM as being faulty or is it the whole damn motherboard itself?
SQLyog is an absolutely brilliant GUI front-end for MySQL databases. Delivering all functionality you could ever want to apply to a database, MySQL makes database administration a breeze and more importantly, a snap.
Have you ever come across the following error dialog when trying to connect to a MySQL database?
Error No. 1045: Connection denied for ‘someuser@somehost’ (using password: YES/NO)
Basically what this is, is a user authentication error. In other words, the user details specified does not “match” the user tables on the specified MySQL server.
Reasons for this could include the user account simply not existing, the wrong password for that particular user, or lastly, the user specified may not actually be able to connect from the host you are currently using.
The last one is the interesting one and usually the most common cause of throwing up the error when trying to use SQLyog to administer an external database.
Typically MySQL only allows connection from ‘localhost’ by default. If you want to allow an user to connect from a different host, you’ll need to edit the privileges for that user on the native machine and specify that the host.
Wildcard characters do of course make our lives much easier and as an example using phpMyAdmin on the MySQL server machine, you can see from the picture below that I’ve changed a user account’s privileges to allow him to connect from any host by using the value of % in the host field.
So make sure you have the right user password and user name, make double sure that your user can access from any host and blam, your connection denied error should soon be a thing of history! :)
We currently use snom 300 VoIP phones here in the office and the other day I was asked to troubleshoot a phone that had all of a sudden stopped working. The error that it was coming up with was NR and every number that you tried to dial would result in a ‘forbidden’ error message showing up on the phone.
Now NR stands for Not Registered in snom language and so logging onto the phone’s web interface configuration utility (simply point your browser to the IP address listed on your phone <- grab it by going to the Information -> IPAdr menu option on the phone), I was able to see from the System Information page that the Identity 1 Status was yielding an authentication error.
The next step was to access the Identity 1 menu option and on loading up the page, I could immediately see that the password field for the Login Information had been cleared, meaning that in order to fix the problem I simply needed to re-enter the secret set on the server for that particular extension.
Easy as pie really.
Do you make use of the nifty little trash feature recently introduced in WordPress 2.9 that allows you to “delete” or “trash” posts to a recycle bin from which you can then choose to permanently delete or restore at a later date?
Well if the answer is yes then it is probably a good idea to quickly update your installation version to the newly released 2.9.2 version in order to protect yourself against a nasty little bug introduced with this great new bit of functionality!
The problem is that in introducing this new core bit of functionality, developers somehow forgot to properly integrate it within WordPress’ security framework and as such were left with a situation whereby any authenticated user, no matter what rights they have (e.g. they could even be a simple subscriber), can access the trash of any other user – meaning that if you have any sensitive posts that you previously trashed, they would have in fact still pretty much been open for anyone to see.
If you still aren’t on the same page with me as to why you need to upgrade to this patched version ASAP, let me put it to you a little differently. Let us say for example you work for a boss, but being a disgruntled employee, you type up a post on the company blog revealing to the world all the naughty kinkiness you got up to your boss’ daughter. Thankfully though, a moment of sanity prevailed and you trashed the post before publishing it, so it never saw the light of day – whew! However, if the bug was still active and your boss entered the blog to add a new post or such, he would be able to read what you had previously trashed and make no doubt about it – you would now be standing out there in the cold in the unemployment line.
So do yourself a favour. Upgrade to WordPress 2.9.2 today! :)
Related Link: http://wordpress.org/development/2010/02/wordpress-2-9-2/
Anyone using an automatically installed copy of GroupWise as their mail client (like us here at UCT) might occasionally come across the following error message on startup:
This application has failed to start because ccsw32.dll was not found. Re-installing the application may fix this problem.
Of course, re-installing GroupWise achieves squat, so I had to look up the cause and solution for this error before it drove me nuts. Thankfully though, the guys at Novell Technical Support have pinpointed the problem and let us in on the fix.
Firstly, the problem crops up with Novell GroupWise 6.5 and Novell Client v4.91 for Windows 2000/XP. The problem appears to be that the NMAS component is only partially installed by the NW Client, which means that not all the files were correctly assigned on install. The solution? Pretty simple actually.
Rename the C:\WindowsSystem32
wsso.dll to C:\WindowsSystem32ccsw32.dll.
That’s it. Simply start up GroupWise once more and you’ll be happy to find that the annoying error message is now lost forever.