One of my clients has a rather popular sports site on based on WordPress. The site is up-to-date and running on DV server. A few weeks ago malicious code starting to appear on the site setting off warnings from anti-virus programs that monitor websites.
Sometimes, entire files are uploaded that contain malicious scripts. Most of the time, however, JavaScripts are appended to existing PHP or HTML files. One of the favorite targets is the WordPress index file (index.php). A self-executing JavaScript is added after the closing ?> tag. How they append the file is a bit of a mystery as permissions are correctly set at 644. The purpose of the malicious code seems to vary. Some code attempts to spread worms/trojans, steal passwords, or re-direct to spam sites (meds).
Server-generated emails on websites requiring registration or verification, often do get not through Hotmail and Yahoo Mail spam filters. Hotmail requires a valid SPF record which is easy to implement. And, Microsoft will whitelist your domain for Hotmail if you request it.
Yahoo filed a patent for the DomainKeys concept in 2003. They still use DomainKeys and require it especially for server-generated emails. Implementing it used to require running a Perl script to generate the key pair for the electronic signature. And, instructions for updating your server DNS are difficult to find.
Plesk 8.6.0 has DomainKeys built into the Plesk CPanel. However, there is one extra step that is critical if you control the DNS externally (for example, with Media Temple’s Account Center). Here’s how to do it:
I recently got the nasty “XML Parsing Error: XML or text declaration not at start of entity Location” error instead of RSS feed on two client WordPress sites.
First, I tried the Fx-RSS-Feed plugin. No luck! it identified several hundred WordPress and theme files with unnecessary whitespace. Most of the files were write-protected. Way too much work for me to change all the permissions, run the plugin, and change them back.
Instead, I used the fix at Wejn’s lair. Scroll down the page and download the file “wejnswpwhitespacefix.php” or get the text version here.
Most common internet browsers only support a limited number of fonts. A client wanted to emulate the look achieved by BBC’s Later site using WordPress. That meant using SEO unfriendly images to replace the headings or dynamic font replacement. The latter is not only SEO friendly; it is also much easier to implement.
I looked at two WordPress plugins: Facelift Image Replacement (FLIR) for WordPress and Dynamic Font Replacement DFR4WP.
“Facelift Image Replacement (FLIR) for WordPress” seemed very promising. It is easy to implement and offers a wide-range of fonts that come with the plugin files. It is limited, however, to a single font replacing one or more tags of your choice. The main reason I abandoned it though, was a strange green highlighting showing up in IE8.
Web developers use dummy text as placeholders when building websites. Dummy text is required when the final text is not yet available from the client. It is used to demonstrate the appearance of different typefaces and layouts. Usually, the dummy text is nonsensical or unreadable my most people as not to distract from it’s purpose.
Lorum Ipsum can be traced back to ‘De finibus bonorum et malorum’ (On the extremes of Good and Evil) by Cicero in 45 BC. The original passage began: Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit (Translation: “Neither is there anyone who loves grief itself since it is grief and thus wants to obtain it”). It is not known exactly when the text acquired its current standard form; it may have been as late as the 1960s. The passage was discovered by Richard McClintock, a Latin scholar who is the publications director at Hampden-Sydney College in Virginia, by searching for citings of the rarely used Latin word “consectetur” in classical literature. source Wikipedia
I just finished helping a friend bring back a Sports Blog after a nasty hacker attack. Luckily, we had a backup of the database. Otherwise, we had little chance to restore the site.
Here are a few tips to keep unwanted visitors from doing damage to your blog.
Set your File Permissions Properly
Use 755 for directories, 644 for plugins and core WordPress PHP files, and 666 for active theme files. You can check and change file permissions with your FTP client.
Use the Login Lockdown Plugin
Hackers know where to find your login page. The basic WordPress installation offers little protection against a brute force attack. Yes, the new WordPress revisions have started using hardened passwords. However, I still recommend giving yourself the added protection you get from the Login Lockdown Plugin. And, check your current or new password with The Password Meter.
Just upload it and activate it. The plugin defaults to a 1 hour lock out of an IP block after 3 failed login attempts within 5 minutes. This can be modified via the Options panel.