Displaying 1 To 6 Of 6 Comments Thanks for all you’ve done Jeff! You’ve really helped forward the movement. It’s much appreciated! » Posted By Brian Layman On May 18, 2011 @ 11:05 AM @Danny Freebie caching of whole pages is right out, but you can still manually build caching into your theme. Things like the current list of posts on the front page doesn’t change. The tag clouds can be cached. Caching doesn’t have to be an all or nothing thing. It just means you have to do some work to put it in place. » Posted By Brian Layman On April 23, 2011 @ 4:10 PM 2.8.6 is there for all who need it. http://wordpress.org/download/release-archive/ Problem solved. » Posted By Brian Layman On April 22, 2011 @ 4:25 PM Multi-Site Is Just A Feature Set “My whole site is down” just became all the more misleading… » Posted By Brian Layman On January 19, 2010 @ 2:09 PM There’s even more confusion. I would almost guarantee that the “I run my 6 sites on WordPress.” commenter was thinking of 6 blogs, and not a single mu install with six mu “sites” each running a single “blog”. In mu a site and a blog are two different things. Each blog is under the control of a specific site. Each Site can control many many blogs. A user can be an admin on a blog, several blogs or a site admin for one or more of the sites in the mu install. That’s gonna help keep the confusion level high. Especially when you consider tossing the word Domain in there which is a completely independent topic. » Posted By Brian Layman On January 19, 2010 @ 1:45 PM Top 5 WordPress Security Tips You Most Likely Don’t Follow Simple steps that eliminate groups of common attacks are real security steps that should be taken, “Security Through obscurity” or not. OK they don’t address the security holes that let the people who really know what they are doing in, but let’s face it: most bloggers are not going to do a code review to see if a plugin adds slashes to data retrieved from the users or even an rss feed. So, these steps help most simple sites block most simple attacks. That’s a good thing. #1, for example, eliminates dictionary attacks, cookie hash attacks and attacks that rely on the Admin user name or User ID. That’s a big group. My version of the tip is to login with the admin user long enough to setup a few users one of which is a user with admin access and then demote Admin/User #1 to a subscriber. All in all this stuff makes your site block some of the more common attacks out there. And again, that’s a good thing. » Posted By Brian Layman On April 12, 2010 @ 11:42 AMComments Posted By Brian Layman
;)
«« Back To Stats Page
#2 I may add to my tool box. I don’t use it now.
#3 eliminates all pre-baked SQL injections. Yeah it’s just obscuring the name of the tables, but you know what, 99.9% of the attacks I’ve seen in the wild would be defeated by this. People copy a link and know just about enough to change the address of the blog inside that link. Beyond that their eyes glaze. So most simple worms that spread by looking for a weak plugin and inject code into wp_options will be blocked by this.
#4 is a must. Without this, if your hash is sniffed off of unsecure wifi or even someone just copying your cookie files, you’re up the creek. #nopaddles
#5 is not practical for many people and beyond what many can do. Personally, I would replace this one with a much more important one: Only use the most popular plugins out there. Most security breaches now come via plugins that open up holes. Mark Jaquith points out the simple fact that: The most popular plugins have had the most eyes looking at the source code. If you stick to the top 1/3 most popular plugins, you will be in pretty good shape. Less popular plugins will have been reviewed less often and are more likely simply be easy ways for people to add data to your database and files to your site.