>devblog_

Is your website error free?

My site  has grown over the years and uses a lot of PHP code. It’s difficult to test each and every aspect of it. Here are 3 simple tricks that can help you test your website. They don’t replace a real test (that you should do after a each change), but they’re a nice addition.

Trick 1:

Use Google to search your website for “error” or “warning”. You can use the format:
site:yourdomain.com (warning or error )

This of course has a terrible lag, since Google crawls your website only every few days or weeks, but on the other hand Google may use different parameters or aspects that you use in your own tests.

The real fun comes with combination of trick 2.

Trick 2:

Use Google alerts to automatically search your website for problems. You can create a free Google alerts account and use the search mentioned above to have Google automatically check your site every day. If something breaks, Google will send you an e-mail.

Trick 3:

Same as above, but use your Google to watch your site for hacked pages. A hacker might have exploited a weakness in your server and created a new page for whatever product he promotes with his spam mails. You probably don’t want to become involved with this. So instead of using “warning or error” in the search. use a list of the usual phrases and medical products that the spam mails usually contain.

It’s a one-time work of a few minutes. The rest of the work is done automatically by Google and can save you a lot of trouble.

There are thousands of classes, structure, functions and constants in the Windows library and it’s often hard to remember the right spelling. Here’s a simple trick to use the usertype.dat as a very simple spell checker.

Usertype.dat?
First, usertype.dat is a file which can be configured in the MS IDE (see help file, because it differs with the versions). Simply activate it and use my usertype.dat as a start. It contains almost 4000 key words from the libraries.

When you now type one of these key words right, it will be displayed in a different color (I prefer gray – to emphasize that I don’t have to pay attention here). Here’s how it can look like.

Example:

Note that all the common things like HICON, LoadImage or LR_DEFAULTCOLOR are written in gray because they’re spelled correct. And other words (variables in this case) like hIcon and IconId1 a printed in white because they’re not predefined. If I had written Load_Image (instead of LoadImage), it would have been printed in white, too, and I know that it might be incorrect.