FettesPS

Anyone who still works with Visual Basic 6 for legacy applications will inevitably run into an issue where a customer’s computer needs MSWINSOCK.OCX in order to run their application. You could install the entire VB6 runtime files package or you may chose to redistribute this one file with your software. In any case, I wanted to make sure this file was available for those who need it.

Download MSWINSCK.OCX

After you have downloaded the file, you can either place it in your C:\Windows\System32 (or C:\Windows\SysWow64 on an x64 system) and register it there or you may want to put it directly into your application’s directory and create a .local file so that the application does not look beyond it’s own folder for the file.

To register the file, open up command prompt (Win+R then cmd) and enter:

regsvr32 "C:\Windows\System32\MSWINSCK.OCX"

If you are going to use the .local file, just create an empty text file in that directory with the same name as your application but a .local extension appended. So for example if you had a file called “MyApp.exe” you would create an empty text file called “MyApp.exe.local” Make sure if you have hidden extensions that it is not secretely adding “.txt” to the end of the file name.

I’ve been on a bit of a new plugin craze as of lately, started searching for people’s favourites and came up with a few good ones I had not seen. Today I tried out wp-dbmanager, which I may have never noticed due to it’s non flashy name. Despite it’s non flashiness it definitely does what it promised and a whole lot more than what I had expected. In addition to automating database backups and optimizations it also gives me direct access to my WordPress database and a query editor saving me from having to log into phpMyAdmin. But despite all this plugin’s strengths I was a bit peeved by the following error popping up everywhere in my admin panel:

Your backup folder MIGHT be visible to the public

To correct this issue, move the .htaccess file from wp-content/plugins/wp-dbmanager to /wp-content/backup-db

Sounded simple to me, but I got snagged when I found there was no .htaccess file in that folder. I also was stumbling over not noticing that backup-db was two directories down from the wp-dbmanager not one, but that was my own carelessness. What needed to be noticed was that there was an .htaccess file it just was not named .htaccess as the error message indicated. Rather the file was called htaccess.txt, which completely slipped past my scans of the directories looking for it. It wasn’t until I was about to give up that and just deal with the error (as the folder was not visible from the web anyways) and then I noticed it. So the correct line you’d need to run from the wp-dbmanager folder is:

mv htaccess.txt ../../backup-db/.htaccess

Once that’s done, refresh your admin panel and the error should be gone! Now you’re free to use the power of this impressive plugin without being nagged to secure that folder!

Today I used the automated plug-in installer to install W3 Total Cache which resulted in my page doing nothing but spitting out a nasty error. Since I did not want to spend time debugging their plug-in and had immediately lost faith in them for not properly handling their errors I went ahead and nuked the folder in the plugins directory. That left me staring at this nasty error:

W3 Total Cache Error: some files appear to be missing or out of place [...]

Hmmm… “Not cool,” I thought to myself. At least it seemed to be confined to the admin panel and my site was now back up and running from the user’s perspective I still had to try and fix this error without taking down the site again.

The initial suggestion made by the error description was to delete advanced-cache.php from your wp-content folder. I went ahead and renamed it to advanced-cache.php.bak and was then told by the next error that I should delete db.php. At this point I decided to do some more research and see what my best options were, and for hte time being I reinstated the advanced-cache.php file from it’s backup.

My search results on disabling a plug-in through the database all told me to look in the wp_options table and under the active_plugins field. In there was a serialized array containing each of the active plugins. I searched for “w3″ and removed everything between the semi-colons for that plugin:

Remove:

i:12;s:33:"w3-total-cache/w3-total-cache.php";

At the start of the active_plugins field is an a: with a number beside it, this is your total number of enabled plugins. None of the sites I had dug up on disabling a plugin from this table mentioned this and the typically suggested wiping the entire line out to just a:0:{} which is not necessary.

After updating that field I was still presented with a message suggesting I delete the cache file. So I did the same and backed up each file it told me to (instead of deleting, as it suggested). In the end three files needed to be backed up.

Disable and Backup Some Files:

mv advanced-cache.php mv advanced-cache.php.bak
mv db.php db.php.bak
mv object-cache.php object-cache.php.bak

After refreshing my admin panel I once was able to log in to manage the site. Crisis averted! After a few days when I’m confident my site is stable I will delete the backups.