Category: WordPress

Categories
WordPress

Style Matters

When it comes to writing code, style matters.

Nearly every programming language, framework, and CMS has their own code style standards that they urge you to follow. For example, Symfony and Drupal each have their own code style standards, and similarly WordPress has its own standards. I wouldn’t ask a Drupal engineer to practice WordPress standards on a Drupal project, just as a WordPress engineer shouldn’t be asked to practice Symfony standards on a WordPress project. Generally speaking, follow the standards set forth by the language/framework/CMS that you are working in.

I typically integrate PHP Code Sniffer (PHPCS) with WordPress Coding Standards (WPCS) directly into my IDE (PhpStorm). Partially this helps me avoid mistakes while I write code, and partially it makes life easier for any WordPress developer (including myself) who has to work with code I’ve written in the future. A number of other text editors and IDEs offer similar integrations with PHPCS. WPCS maintains some documentation on their GitHub wiki about using WPCS with other editors.

However, I do not advocate that you should follow all of the rules in all circumstances. I personally do not adhere 100% to WPCS in my projects. There are some sniffs that I exclude because they hinder some aspect of development, or simply don’t make sense for a client project.

Fortunately, if you need to customize or disable one or more sniffs for your own project, you can use a custom PHPCS ruleset do so. The PHPCS Github wiki’s Annotated Ruleset is a great resource for getting started with PHPCS ruleset configuration, and WPCS maintains a page on their GitHub wiki that lists customizable sniff properties. And of course, you can always disable specific sniffs entirely from your ruleset.

As an example, I do not name class files “class-file-name.php” as WPCS would generally require. I write class names and class file names according to PSR-4 standards, because I use Composer for dependency management and autoloading. Disabling that particular “sniff” can be accomplished with a little bit of XML in the PHPCS ruleset.

<rule ref="WordPress.Files.FileName">
  <properties>
    <property name="strict_class_file_names" value="false"/>
  </properties>
  <exclude name="WordPress.Files.FileName.NotHyphenatedLowercase"/>
</rule>

As another example, WordPress typically frowns upon “precision alignment,” but when I’m working with front-end developers, they often like to line up attributes on HTML elements in partials to make the markup easier to read.

If you want to maintain a list of elements which the PrecisionAlignment sniff should ignore, you can do so in your PHPCS ruleset with the ignoreAlignmentTokens property.

<rule ref="WordPress.WhiteSpace.PrecisionAlignment">
  <properties>
    <property name="ignoreAlignmentTokens" type="array">
      <element value="T_COMMENT"/>
      <element value="T_INLINE_HTML"/>
    </property>
  </properties>
</rule>

Or, if you prefer (as I generally do), you can disable the PrecisionAlignment sniff entirely.

<rule ref="WordPress">
  <exclude name="WordPress.WhiteSpace.PrecisionAlignment"/>
</rule>

If you don’t want to start a ruleset from scratch, there’s a phpcs.xml.dist ruleset included in the Underscores starter theme that you can customize for your own theme development, it is also included if you use WP-CLI’s wp scaffold _s command to scaffold your theme. Similarly, WP-CLI can generate a phpcs.xml.dist ruleset for your plugin development using the wp scaffold plugin command.

If you write code for WordPress, and you aren’t using PHPCS and WPCS, I would strongly urge you to begin using these tools. They will improve your code quality, make your code easier to read, and generally make my life easier if I need to work on something you wrote. 😃

Categories
WordPress

Avoid Composer Dependency Hell In WordPress Plugin Development

Some web applications are like gated castles, or walled gardens, where there are limited opportunities for the person running the site day to day to install something without the developer. Generally speaking, this is a good thing.

But WordPress, by empowering its users, is more like a community garden, open to many developers, through the concepts of plugins and themes. You are likely not the only developer whose code is going to run on a given WordPress site. And, you are probably not the only plugin developer using Composer as part of your toolkit.

When developing WordPress plugins, it can be tempting to just install one or more PHP packages with Composer, and continue on your merry way.

If you have complete control of the entire application stack, and you are absolutely positive that your site admin will never install a plugin without your say so, then good on you.

If however, you’re like me, and you want to distribute a plugin to more than one site, and you don’t have complete and total control over all the code on one or more of those sites, you may be setting yourself up for a trip to dependency hell.

Although the chances may seem somewhat slim, it is not outside the realm of possibility, that you and another developer, may install completely incompatible versions of the exact same package.

Which one loads first? What will be the result of the conflict?

Welcome to the ninth level of dependency hell.

Enter Mozart, and the Imposter Plugin.

Mozart, and Imposter Plugin, are two additional tools for your toolkit. They both aim to wrap the namespaces of your package dependencies into your own namespace, thus avoiding a trip to dependency hell.

They both require a little extra configuration in your composer.json, and they can take a little getting used to.

Here’s a somewhat contrived example using Imposter Plugin to wrap the league/container package namespace within my own project’s namespace:

{
  "name": "richaber/project-name",
  "description": "Demo project",
  "authors": [
    {
      "name": "Richard Aber",
      "homepage": "https://richaber.com",
      "role": "Developer"
    }
  ],
  "require": {
    "php": ">=7.1",
    "league/container": "^3.3",
    "psr/container": "^1.0",
    "psr/container-implementation": "^1.0",
    "typisttech/imposter-plugin": "^0.3.1"
  },
  "autoload": {
    "psr-4": {
      "RichAber\\ProjectName\\": "src/"
    }
  },
  "extra": {
    "imposter": {
      "namespace": "RichAber\\ProjectName\\Vendor",
      "excludes": [
        "psr/container-implementation"
      ]
    }
  }
}

After running composer update, I now have access to the league/container thusly:

<?php

namespace RichAber\ProjectName;

use RichAber\ProjectName\Vendor\League\Container\Container as Container;

Now, if another plugin decides to implement the league/container package, my own plugin will ignore the version they’ve included, and run the version that is within my own namespace.

You will note in my example, that I’ve put psr/container-implementation inside of the excludes block. This is because psr/container-implementation is a virtual package, there are no actual files on the filesystem for Imposter Plugin to process there, which can cause an error like File does not exist at path /path/to/project/wp-content/plugins/project-name/vendor/psr/container-implementation/composer.json.

Of course there are some packages these tools simply can’t help you with, extraordinarily complex packages, and packages that do some unusual and/or unexpected things inside of them that the tool authors could not foresee or account for.

But if you are building a plugin, and you don’t have 100% complete control over the entire application stack’s code, these tools are worth knowing about.

Update 07/02/19

Shortly after writing this post I came across another tool which could also be used for this purpose, called PHP-Scoper. Although I have not had a chance to test this PHP-Scoper yet, it looks like another good tool for your toolbox and thought I should mention it here in case one of the other tools doesn’t quite meet your needs. Give this one a look too.

Update 11/09/21

Just throwing another tool in the toolbox, a fork of Mozart, called Strauss… https://github.com/BrianHenryIE/strauss

Categories
WordPress

Using Vagrant for WordPress

In the beginning, we had M/W/X/AMP(/P/S)

One common way to spin up a server for local WordPress development involves using an Acronym Soup server locally, AMPPS, MAMP, Bitnami MAMP Stack, WAMP, XAMPP, or a built-in development server (like the Apache that ships on Mac OS).

The upside to this is that you can quickly spin up a local server and start banging out some code for your project.

The downside to this is that your local development environment may not match your staging and/or production environment(s). You may have to maintain multiple versions of tools locally on your desktop or laptop that are unwieldy or cumbersome from one project to the next. You may need to share a configuration with your team mates that can’t be replicated without giving them a list of tools they need to install and the instructions to do so. You may be using Apache locally, and have Nginx on production. You may be using PHP 5.4 locally, and have PHP 5.3 on production. PHP libraries may be missing from your local dev server, or vice versa. Your installed version control system may have a different binary version locally than it does on production.

Then we had the VM

This is where a virtual machine (VM) can be very useful.

Traditionally, spinning up a VM involved downloading pre-configured boxes for Virtualbox or VMWare that were sort of like the target production environment. They might be overloaded with lots of preconfigured software that may not be necessary, or have a complete GUI attached to them, making the VM large and unwieldy. They might be missing some packages that you need that are specific to your production environment. Depending on how the box was created, you may end up with bloated boxes that are a pain to manage, and sharing the 10 GB VM amongst a team that includes remote workers may be unfeasible. Do you check the VM into version control for the project? How large do you want your version control repository to be on initial checkout for that newb on the project?

Then came Vagrant

This is where Vagrant comes in.

From Vagrant’s About page :

Vagrant is a tool for building complete development environments. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases development/production parity, and makes the “works on my machine” excuse a relic of the past.

Using Vagrant, you can define and spin up a headless server environment that can be used for local development. Some cloud providers, such as Amazon Web Service and Rackspace, even support Vagrant boxes as production servers.

You could start with a base box definition that closely resembles your destination production environment by finding one at the Hashicorp Vagrant community box repository, or from the Vagrantbox.es repository.

Technically you could configure a Vagrant box, spin it up, and begin installing all the necessary packages for your server at the command line with apt-get, yum, or whatever package manager the OS of the Vagrant box provides.

Managing installed packages

Fortunately, there are tools to automate and assist with package management as well.

Puppet

Puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. You can use Puppet to manage packages for you.

You can use Puppet to install Apache, or Nginx, MySQL, PHP and other packages that your Vagrant box needs to match production. With Puppet and Vagrant together, you can create virtual machines that reliably match your production environment to a tee.

PuPHPet

PuPHPet is and online “wizard” that allows you to create a Puppet and Vagrant configuration without a deep knowledge of either tool’s specific configuration formats and directives. You could go to the PuPHPet website, spec out the OS, hostname, memory allocation, installed packages, etc., and download a zip archive that contains the configurations. Unzip the archive on your local machine, cd into it, run vagrant up, and your server is ready, without learning all the details of configuring Vagrant or Puppet directly.

Using a tool like PuPHPet, it is a breeze to define the Vagrant box, the OS and installed packages, the whole nine yards, and check the entire configuration into version control. While still being lightweight, your team can check out the configuration, run vagrant up, and start developing in a production environment quickly.

WordPress Vagrants

There are a number of WordPress specific Vagrant Projects that you could use to jumpstart your WordPress development, depending on your needs.

WordPress specific Vagrant boxes aren’t typically aimed at helping you match a specific server environment. They are usually intended to quickly spin up a type of WordPress project setup, i.e. for WP Core contributions, WP Theme Reviews, WP theme development, WP plugin development, or even client site development. They often come pre-loaded and configured with WordPress development tools, and some of them follow best practices for large scale WordPress production environments. They can be quite useful, for example, if you need to share a server configuration amongst a team, or if you need to do WordPress.com VIP development.

VIP Quickstart

VIP Quickstart is a local development environment created by Automattic for WordPress.com VIP developers. The goal is to provide developers with an environment that closely mirrors WordPress.com along with all the tools they recommend developers use.
https://github.com/Automattic/vip-quickstart

Varying Vagrant Vagrants

The “big guy” in WP specific Vagrant boxes, this is the one you will hear of most often when researching Vagrant with WP.
Although it started as a 10up project, it has transitioned to a community project.
https://github.com/Varying-Vagrant-Vagrants/VVV

Chassis

Chassis is a virtual server for your WordPress site, built using Vagrant.
From the project README: You can imagine it as MAMP/WAMP on steroids.
https://github.com/Chassis/Chassis

Primary Vagrant

Developed as a VVV alternative that uses Apache instead of Nginx.
https://github.com/ChrisWiegman/Primary-Vagrant

Useful WordPress Vagrant Tools

VVV Site Wizard

An Alison Barrett project (Nerdery Alum, former Automattician, current 10up).
A Bash script to automate setting up new WordPress sites with Varying Vagrant Vagrants.
https://github.com/aliso/vvv-site-wizard

Variable VVV

A fork of VVV Site Wizard that adds a number of useful features, including deployment options.
Although I have not had a chance to test it, it looks like a very interesting project tool worth exploring.
https://github.com/bradp/vv

WordPress Theme Review VVV

A VVV setup script intended as a WPTRT theme review environment.
https://github.com/aubreypwd/wordpress-themereview-vvv

Vagrant Manager

A handy tool (available for OS X and Windows) to manage your Vagrant boxes right from the desktop.
See which Vagrants are running or halted, and issue commands to them from an easy to use menu.
http://vagrantmanager.com/

Hey, where’s the tutorial, code, or in-depth walk-through?

This post isn’t a tutorial. This post is a brief intro to what Vagrant is, and why you should consider using it for WordPress development.

I hope to inspire WordPress developers who may have “heard” of Vagrant, but aren’t sure how it can be useful for them, or don’t know where to start, to dig in a little deeper. Look into some of the GitHub repos I’ve linked to, and see if one of them might work for your next project. Try using PuPHPet to build your own ideal Vagrant setup for your next WordPress project.

My advice, if you haven’t used Vagrant before, and you just want to get started with using Vagrant, clone Alison Barrett’s VVV Site Wizard and follow the directions. You’ll have a WP specific Vagrant box up and running in no time.

If you want a little more fine grain control over your Vagrant box setup, go to the PuPHPet website and spec out your ideal box. Then the rest… setting up a DB, installing WP, etc., is in your complete control.

Hey, what about Chef / Berkshelf, or Ansible, or SaltStack, or (insert yet another tool name here)?

Yup. Those are other tools that you can use, rather than Puppet. I’ve heard great things about them, however, I have not had the time to dig into all of them myself.

If you have the time to research them, and you find a compelling reason to use one over another, by all means, use it, write about it, then share your discoveries and experiences. The single greatest thing about the WordPress community, I have found through the years, is all the knowledge that the community shares.

Categories
WordPress

24 Hours of Madness (for a good cause) – The 2014 Overnight Website Challenge

Adam Richards and myself pressing all the words.
Adam Richards and myself pressing all the words.

24 hours of no sleep.

Well, it’s actually more like 30 hours or so.

No sleep.
Coding through the night.
In a mad dash to help a non-profit in need.

For the second year in a row, I participated in the Overnight Website Challenge in Minneapolis.

Last year’s Overnight Website Challenge was a disappointment for me. My 2013 team put all of our best effort and our hearts into it, but we ran into insurmountable problems that prevented us from completing the challenge in the 24 hour allotment. The few of us who had a passion to complete the project, did so months later, after a lot of additional work. I told myself “I’m not doing the OWC again,” I didn’t want to feel that disappointment all over again, and lose precious sleep to boot. But, some of my teammates from 2013 wanted to participate again, and I felt the need to support them, and do a good deed for a non-profit.

I had a damn fine team this year. Adam Richards , Brant Day, Bree Compton, Chris Bennett, Corey Stern, Jon Winton, Scott Garrison, Shane Smith, Sherman Bausch, and myself, flying under the banner of Team Raxacoricofallapatorius. We had UX, QA, front end, Javascript, and WordPress back end devs represented on the team. A well rounded, complimentary skill set, and we all worked well together. Tensions and frustration were minimal, technical glitches were few, everyone knew their role and played their part.

We gave our all for 24 hours straight. Coding through the night, until eyes were sore, blurry, bloodshot, filled with tears, with eyelids so heavy it hurt. Committing code up until the last minute, barely able to form complete sentences for git commit messages, but we carried on, doing whatever was needed. We created a fine product for a fine non-profit, and the product was “launchable” at the end of the challenge.

When the challenge was complete, I made the trek home, fell into the most comfy bed I have ever slept in, and slept for 12 hours straight. My family came home. I awoke long enough to hug each of the children, tell my wife I love her, and I fell asleep again, for another 6 hours or so.

Monday was a blur, much like the weekend, and all I could think of is more sleep.

 

And Batman.

 

Categories
WordPress

Listen to this: NerdCast #73 What’s up with WordPress – Inside the Nerdery

Well look at this, or, more appropriately, listen to this. I was included in a Nerdery developer podcast with my friend and co-WordPresser Sherman Bausch on NerdCast #73 What’s up with WordPress – Inside the Nerdery. I’m the shy one, Sherman’s the more outgoing one. It’s weird to hear yourself talk on recorded audio. :-)

Categories
Security WordPress

Why Most Stories About WordPress Security Are Wrong

This article originally appeared on the Nerdery.com blog on September 11, 2013 under the title “Why Most Stories About WordPress Security Are Wrong.”

I have often heard the remark “WordPress is insecure!” My response is “Where did you hear that?” and “When did you hear that?”

WordPress Is the Most Popular Content Management System on the Planet.

My first question, “WHERE did you hear that?” is a very important question. As of this writing, “WordPress powers roughly 18% of the top 10 million websites on the planet, making it the most widely used CMS in the world. The next largest CMS is Joomla, with 3% of the top 10 million sites, and followed by Drupal at 2%.” [1] [2] [3] That’s a lot of websites running WordPress! This popularity and widespread usage means that WordPress has a much higher profile than other Content Management Systems (CMS). [4] [5]  A larger install base means a larger target for attackers looking for low-hanging fruit. The popularity of WordPress brings with it inaccurate or ill-informed attention from journalists and bloggers. Many of those who report on technology matters are not security experts, and often they lack a thorough understanding of the issue. A reporter saying “(WordPress is) pretty easy to hack” in reference to a scripted brute force attack against weak passwords, does not make it so.   The high profile nature of WordPress solicits the attention of security firms who may have an interest in attracting new customers to a product they offer. By issuing vague security white papers directly to the media, these firms might demonstrate that they are more interested in public relations and “free ink” than actually benefitting the WordPress community.   And just like the “Mac versus PC” debates, and the “Ford versus Chevy” debates, there is often a personal preference involved. A developer may prefer Drupal or SharePoint over WordPress, they may honestly believe that their preferred CMS has a better security model. But without being able to cite specifics, they may rely on the rallying cry “WordPress is insecure!” Just as a Macintosh enthusiast may (incorrectly) say “Windows gets viruses and Macs don’t.”

WordPress Is Secure, You Are Not.

WordPress core is, in fact, very secure, just as secure as any other Content Management System, just as secure as any other software suite or Operating System. Security issues most often arise from administrators and users. In other words, you are the weakest link. A weak password and/or a password used across multiple services, in conjunction with an easily guessable username, is typically the vector of attack against any website. A weak password means a brute force attack script can hammer away on your website until it hits just the right combination to get in, open a back door, add your site to a botnet, lock you out of your site, and potentially infect the computers of your site visitors. This is not a WordPress specific security issue, this is a user issue. If you administer a website, you are an IT professional, own a computer, or have used a computer in the last 20 years, then you should already be aware of the risks of weak passwords. The strategy for preventing exploitation of this attack vector is simple, do not use weak passwords, do not reuse passwords, and do not use easily guessable usernames (like “admin”). The next likely attack vector is an attack at the file system level of a shared web hosting server. A shared host could be running hundreds of websites on one server. An exploit might not come from an attack directly against your website, but your site can be incidentally compromised if an attack was successful against another site on the same server. The simple solution to this is to use a dedicated or virtual server, avoid shared hosting. For script kiddies, crackers, and botnet operators, the ever-growing pool of WordPress installs means that there are more sites to check for “low hanging fruit” vulnerabilities. Old versions of software can be compromised because of known vulnerabilities and exploits. The “bad guys” run automated scripts that check what version of a CMS you have, and if they find a version with a known vulnerability, they deploy an exploit and compromise your site. This is not a WordPress specific security issue, this happens with all major software. The solution is to keep your software and all associated add-ons up to date. With WordPress, all it takes is a simple click to keep your installation upgraded. While it is true that WordPress core is quite stable and secure, security issues can be introduced by third-party software. For instance, a few years ago, there was a widespread attack against websites that implemented the TimThumb image processing script. [6] Though the TimThumb script is not part of WordPress core, some third-party themes and plugins were using it as an image processor. As a result, an incredible number of websites (estimated in the millions) were compromised, which included non-WordPress sites that had TimThumb installed. [7] Again, this is not an issue with WordPress core security. This is an issue with third-party software, plugins and themes. The solution to avoid this attack vector is to use themes and plugins listed on WordPress.org. Do not use themes and plugins from untrusted sources.

Historical Legacy and the Current State of WordPress Core Security.

My next question, “WHEN did you hear that?” is an equally important question in response to worry over . Around 2007–2008, WordPress garnered some unwanted (though admittedly deserved) attention as a number of security issues (in particular SQL injection and code execution vulnerabilities) in WordPress core were exposed. [8] Of course, these security holes were patched by WordPress developers upon discovery. Those vulnerabilities apply to legacy branches of WordPress and are not present in the most recent WordPress release, 3.6. However, the buzz surrounding those vulnerabilities gave some the feeling that WordPress core was, is, and will forever be insecure. That is an inaccurate and invalid assessment when it comes to security. Based on the same criteria, I would argue that your preferred Operating System, software suite, and CMS, was, is, and will forever be insecure. Security breaches and vulnerabilities have been discovered, exploited, and patched in all software. All software is terribly complex, be it an OS, a CMS, or your favorite Word Processor. Due to that complexity, all software suffers from some vulnerabilities (known and unknown) of some kind. All responsible software vendors and developers actively investigate and address vulnerabilities as part of their release cycle. WordPress, Joomla, Drupal, SharePoint, or any other major CMS is no different.

The Real Indication of How Secure a CMS Is, Is Determined by the Vendor’s and Developers’ Response to Security Issues.

For WordPress, the response was to implement an easy “click to update” functionality in WordPress’s Admin Dashboard, a regular release cycle to continually patch and improve core, and a full-time security team to continuously address security issues. Upgrading WordPress core is easy, it is so “WordPress.” When an administrator with proper privileges accesses the WordPress Dashboard, and an update to WordPress core is available, a simple “WordPress x.x is available! Please update now.” banner displays at the top of the screen. “Update now” is a link to initiate the upgrade process. Additionally, an “Update to x.x” button displays in the “Right Now” metabox. Clicking the “Update” button also initiates the upgrade process. The upgrade process itself consists of clicking a button, waiting a couple of minutes, and you’re done. This makes it easy for a site administrator to keep their installation patched for the latest security fixes. This simplicity is akin to the simplified update systems that the major OS vendors have implemented. Making updates simple means that users are more likely to keep their software patched. And of course keeping software secure means continuously applying security patches. A regular, ongoing release cycle addresses WordPress core security issues as they are discovered or reported. The release cycle consists of major version upgrades to add features to WordPress, and minor release versions as needed to address security vulnerabilities and critical bugs. [9] If a critical security vulnerability is identified in core, a security release that addresses the vulnerability is released as quickly as possible (usually within days, sometimes even faster). The number of critical or severe vulnerabilities discovered in WordPress core has decreased significantly since the 2007–2008 years, in part due to the regular release cycle, the simplicity of upgrading, and of course, the security team. WordPress has a dedicated security team that actively investigates and patches core to address security concerns. This team keeps abreast of all security issues, and enforces security procedures within core. The WordPress security team has a standardized process to address security reports: [10]

  1. Receive and acknowledge security report
  2. Work to confirm the report and its severity
  3. Plan and develop initial patch to address the security report
  4. All of this typically happens within 48–72 hours of receiving a security report.

“The WordPress security team is made up of 25 experts including lead developers and security researchers — about half are employees of Automattic, and a number work in the web security field. We consult with well-known and trusted security researchers and hosting companies.” — Andrew Nacin, WordPress Lead Developer, in a presentation “WordPress.org & Optimizing Security for your WordPress sites,” June 2013. [11]

In conclusion, the vast majority of fear surrounding “WordPress insecurity” is unfounded, and most often is completely unrelated to WordPress core itself. WordPress is secure. What you do with it, how you deploy it, how you administer it, that’s where the real security concerns lay. Here are some helpful guidelines to keeping your WordPress website safe (for more in-depth security hardening guidelines, visit the Hardening WordPress page in the Codex)

  • Use a dedicated or virtual server, avoid shared hosting
  • Back up your site (files and database) regularly (consider a service such as VaultPress)
  • Keep your WordPress core installation up to date
  • Keep your WordPress plugins up to date
  • Keep your WordPress themes up to date
  • Uninstall (not just disable) any unused plugins or themes
  • Avoid plugins and themes from untrusted sources
  • Do not use admin (or other easily guessable usernames)
  • Use a strong password!
  • Ensure your own PC is malware free (to keep keyloggers and malware from stealing your credentials)
  • Monitor your server and user stats
  • Restrict WP-Admin to your VPN or proxy
  • Restrict WP-Admin using HTTP Basic Auth
  • Restrict WP-Admin to your IP address
  • Deny access to wp-content directories
  • Remove WordPress version from meta
  • Protect WP-Admin with authentication
  • Force SSL
  • Get a security audit
  • Report potential core vulnerabilities
  • Report potential plugin vulnerabilities

If you’re interested in notable WordPress users, there is an ever growing list of government entities, educational institutions, major brands, celebrities, and musicians that rely on WordPress as a secure Content Management System to power their websites and blogs. Visit the WordPress Showcase to see some of the big names that trust WordPress security.