Archive for January, 2009
Google site protection goes nuts
I don’t know what the deal was today but Google was flagging every web site with the “This site may harm your computer” warning, include Mozilla, Yahoo, Experts Exchange and even Wikipedia. Then I logged into the Google Webmaster tools site and it said my website was flagged as well. Weird, somebody must have hit the panic button today, but it seems to be fixed now.
Update: Yep, it was a glitch.
Here is what the search results looked like earlier today:
Howto: Reapply default NTFS permissions
I recently installed some software on my PC (Windows XP sp 3) and part of the installation process required changes to NTFS disk permissions. The installer somehow got confused (it was actually a bug in the installer) and it managed to foul up all the permissions on my disk. I mean all of them, disk-wide. I couldn’t even open my control panels. After hours of research (using another computer) I finally found this article at MS Technet.
The final command line I issued was this:
-
secedit /configure /CFG "%windir%\Security\Templates\Setup security.inf" /areas FILESTORE /DB "%windir%\Security\Templates\sec-filestore.sdb" /verbose
PHP class function for screen scraping
I’ve updated my simple PHP function (the one to replace fopen()) for grabbing URLs using cURL. I’ve added some features and made it a class instead of a straight PHP function. One improvement is the ability to normalize URLs so you can use relative URLs. It also has more error checking and uses a standard user-agent by default.
The syntax is a little different from the previous version. To use it, you create an instance of the object then call the proper method:
-
$urlScoop = new UrlGrabber;
-
$rawhtml=$urlScoop->_get($urlScoop->_normalize("https://www.simmonsconsulting.com/"));
Fetching a relative url would look like this:
-
$urlScoop = new UrlGrabber;
-
$rawhtml=$urlScoop->_get($urlScoop->_normalize("../../Photos/"));
The function is included in the jump.
(more…)
If your sIFR quit working … time to upgrade
Maybe you have noticed that the headlines on my site look slightly different than a normal Times New Roman font (at least if you are using a modern browser.) That is because I am using a web technique known as Scalable Inman Flash Replacement (or sIFR for short). This is, essentially, a way to substitute plain text with font-embedded flash objects to enhance their appearance. The nice thing about using sIFR is that your site remains accessible to search engines and older browsers that do not understand this technique.
I recently noticed, however, that on my new laptop Firefox didn’t show the sIFRized fonts. Since it worked fine in all my other browsers (including Firefox on my desktop unit), I assumed my local install of Firefox or the Adobe Flash player were messed up. After a few uninstalls/reinstalls, it still didn’t work. After a little investigation, I found this article that revealed the version of sIFR I originally installed on my site (2.0.4) was using a single digit to determine a browser’s Flash version/capability before replacing the text with flash objects. Guess what version of the Flash player I had installed on my new laptop? That would be the latest, version 10 (note the two-digit version number!)
After a quick upgrade to the latest version of sIFR (including merging some modifications I made to the script and Flash files) I’m back up and running!
