Sep 05, 2014
We run our corporate marketing sites on Wordpress. It's not the perfect web content management system for us but, as long as we keep things simple, it does the job reasonably well. When we want to do something that Wordpress doesn't comfortably handle, we tend to use an alternative platform such as Marketo, UnBounce, or develop static web pages.
Wordpress is great, but one thing to consider when using it is that you make yourself a target to all sorts of hacker attacks. When planning server capacity, we need to accept that a lot of our traffic comes from bots trying to hack into WP Admin. There are three things about Wordpress that contribute to this.
-
Wordpress is by far the most commonly used web content management system. According to BuiltWith, 47.90% of CMS powered websites run on WordPress. The second most commonly used CMS is Drupal with 13.10%. Now I know that those statistics are not perfect but it is clear that Wordpress is head and shoulders above the competition when it comes to CMS adoption.
-
Wordpress is incredibly easy to identify. If you look at the source of any Wordpress generated page, Wordpress's signature is impossible to miss. Moreover, Wordpress makes it really hard to hide these tells even if you wanted to.
-
Wordpress is the "go-to" platform for people who know nothing about web development or security. While there are plenty of savvy WordPress developers out there, the majority of WordPress sites were built by people with no clue about security and operated by companies with limited technical know-how. Many of these sites were insecure from day one and only got worse as patching and other maintenance practices were neglected.
Put these three facts together and it is obvious why WordPress is the most attractive platform for hackers and botnets to attack. If you are a malicious hacker and want to get the most out of your efforts, you go after the biggest and most vulnerable target. And in that way, WordPress is a lot like Windows. Windows is everywhere because it is the go-to OS for people who just want a computer at a reasonable price. If you walk into a BestBuy/Staples/Costco to buy a computer, you will walk out with a Windows PC unless you have something else in mind. The majority of these computer shoppers know very little about managing their computers. These users will not keep their software up to date and will accept any dialog. Most of us have spent countless holiday hours removing adware, browser bars, and viruses from these computers.
Just to be clear: Wordpress and Windows are not inherently insecure. With conscientious maintenance, both of these platforms can be as safe to use as the alternatives. It as a sign of success for both Windows and Wordpress that they have earned the distinction of being prime targets for hackers. It is also a great opportunity for external software companies to market services to secure these platforms. The Windows security software market is already large and mature. The number of Wordpress security options is growing fast.
So my advice to everyone is to keep on using Wordpress if it meets your requirements. But accept that your site will be a target for hackers and plan for security. Work with Wordpress specialists (not designers who happen to know a little about Wordpress theming). Follow all the advice in the "Hardening Wordpress" page. Look into 3rd party services that help protect your site. Be safe
May 06, 2013
Anthony Myers (@xanthonysfx) , from CMSWire, recently posted an article listing "Five Alternatives to Wordpress." His list was really interesting. First, he openly left off Drupal, putting Plone there instead. I really like Plone but I would have to say that Drupal is a much closer analog to the core functionality of Wordpress. The projects even have an ongoing rivalry with each other as shown by Dries's April Fools post "The Red Press of Drupal" where he announces that Wordpress is moving onto Drupal.
Second, the author didn't include blogging products like Expression Engine, MovableType (which, I hear, is improving), and SquareSpace. The products that he listed (Adobe Business Catalyst, Plone, Typo (I have a feeling Anthony meant Typo3, not this relatively obscure Rails blogging platform), Umbraco, and eZ Publish) are all traditional, page-oriented (as opposed to post-oriented) platforms. This shows that Wordpress, at least in Anthony's eyes, has grown out of its blogging roots and readers would be considering it for traditional web content management. I would have to agree with Anthony on this.
The third interesting thing about this article is that the various software communities didn't flood it with comments and other reactions. I would at least expect the very large Drupal community to dive in and lobby for their inclusion. Maybe the link-bait title of this post will change that. :)
Mar 14, 2013
When inviting a new user to a Wordpress site, the default behavior is for the system to put that user into a pending state and only activate her when she clicks through on an invitation email. However, if that user never receives the email, you are kind of stuck. You can't activate her because she doesn't show up on the users list. You can't re-create her because she is in that limbo state. I am told that the invitation expires and you can re-invite after that point. But who wants to wait?
The work around that I use is to simply delete the record from the wp_signups table:
delete from wp_signups where user_login = 'username';
Where username is the username you set when you tried to invite the user.
If you don't have direct database access, I would recommend ticking the box that says "Skip Confirmation Email." After that, you can manually set the password and send it through a secure service like Lockify, or you can send instructions to the user to use the password recovery system to set their own password.
Feb 04, 2013
When considering a translation proxy to localize a website, people often ask "if we change the content on the site, what will visitors see while the translators are working on the new translations?" Unless you are using machine translation as a backstop for untranslated content, your source language is going to show through. This is because a translation proxy doesn't cache full pages. Instead, they apply translations one fragment at a time. If it doesn't have a translation for a fragment, the translation proxy will register it as a new string to translate and send the original text through. This is a necessary trade-off to support dynamic websites. You can shorten the period of bleed-through by increasing your translation responsiveness and throughput, but to prevent bleed entirely you need apply one of the following techniques.
These two techniques are really just variations on the same theme of pointing the proxy at two versions of your site: one for content discovery and another one for production.
International Snapshot
The "international snapshot" approach is where you create a non-current snapshot of your production site for international audiences. Depending on your translation velocity, this could be anywhere from a day old to a month old or more. Content discovery and translation is still done on the live site. But when an external visitor browses the site, they are getting a proxy-translated view of the snapshot. There is no bleed-through from the snapshot site because by the time the snapshot is refreshed, all of the translation rules have already been published. Here is a picture
This is what we are doing for the new www.lionbridge.com website. We wrote some scripts to do a full snapshot of the site (code, database, and other files) to another virtual host on the same servers. If you are using a more sophisticated platform than Wordpress, you could probably set up another publishing target and just publish there when you want to update your snapshot.
Translate Staging
The "translate staging" option follows the same pattern as international snapshot. With translate staging, however, you do your content discovery and translation on the staging server (which has content which hasn't been published yet) so your translations are ready before you publish your content. Once your translation queue is down to zero, you can publish your source content to your live site and the translation rules will be waiting to be used.
With "translate staging," you need to make sure:
-
Your staging site is publicly accessible. You will not be able to view the site through the proxy unless it is available on the public internet. For security reasons, you can limit access with a firewall and also add authentication to the staging site.
-
Your staging site only contains translation ready content. If you have are using your staging site for your editorial process, you might wind up discovering draft content that will never be published. Since this is obviously a waste of time and money, it's best to create a staging instance that only has content that is ready for publishing.
Here is a summary of the process
What to choose?
Which approach is right for you depends on your requirements. If, because of regulations or communications policy, you are required to publish new content to all languages simultaneously, you need to go with the translate staging option. If, like it is with us, you can allow your localized sites to lag behind the primary site, the international snapshot option is usually most attractive. And, of course, letting source content leak through may be acceptable if your site is less formal. The most important thing is that you have options.
Jan 11, 2013
As I mentioned in "Marketing I.T. in the Cloud," we maintain a hot-standby infrastructure on another hosting service. We automatically refresh this standby setup at a regular interval so that, if something really bad happened to our primary infrastructure, we could just re-point our domains and relatively recent versions of our sites would be back up.
Because this backup infrastructure is so critical, we monitor it just like our production infrastructure. One thing we have not been able to automate, however, is the check to make sure the front page is loading properly. The problem is that Wordpress forces a redirect to a primary host name. That is, if you try to hit the IP address of the backup server, it will redirect to the primary domain of the site (like http://www.globalmarketingops.com) which is still running on the primary servers. The fact that the redirect even happened told you Apache is running and Wordpress is able to read from the database. But you wouldn't know if the pages were broken. This is a little like driving around with a flat spare tire. You know you have it but you don't know it is useless until you try to use it.
Our work-around has been to manually edit our hosts file (which overrides the DNS) and browse the site on a regular basis. But that is a drag. I couldn't find a ping service that allowed me to override the public DNS with temporary mappings. So I came up with something much simpler.
I edited the /etc/hosts file of the backup server to map the supported domains to itself (localhost). With that setting in place, we can run a script on the backup server that loads the home page of each of the sites and verifies that each homepage contains certain text. The script sends out a pass or fail notification. If the server was too broken to run the script we would not get the pass notifications and other alerts would sound. If we get a fail notification, we know that we need to fix the backup site.
This is a pretty common challenge so I hope others can benefit from this simple solution.
Dec 17, 2012
Warning: geeky coding post
One of my responsibilities at Lionbridge is running infrastructure for our many marketing sites and applications. Like all good technical organizations, our development and deployment processes revolve around a source code management (SCM) system (in our case Git). Because we are running on a CMS (Wordpress - hold the religious war on whether Wordpress is a CMS), our websites are a combination of platform (Wordpress), customization (plugins and themes), configuration, and content. The question is: how much of this do you put into your SCM? Let's start with the obvious. You don't put content in your SCM. With configuration, it depends. Some frameworks allow you to tier your configuration options between global and environment-specific. For example, this is how I handle Django settings. I haven't come up with a clever way to do this in Wordpress so, for now, I am keeping wp-config.php out of the SCM.
As for platform and customizations, my tendency has always been to keep the platform out of the SCM. In this model, your build process is to install the platform than then deploy the themes and plugins from source control. I have done many projects in this way and it worked quite well. But another developer set up our Wordpress infrastructure for these sites and his preference was to put the whole Wordpress install into SCM and do a "git pull" to update the whole site. I also didn't love the idea of using Git to deploy. I like to pull the code to some alternative machine (my workstation or a server), (compile/)package it, and then push it to the web farm. Fabric is an excellent tool for this. You can still use Fabric in this scenario to execute Git commands on the remote servers but it still doesn't feel right to me. I prefer that runtime servers have as little software running on them as possible.
At first I hated this set up. I missed a developer being able to install our themes and plugins into any old Wordpress instance. I had doubts about the complexity of administration settings and the potential of editing source-controlled files trough the web. But I kept an open mind and I have come around. Here are the reasons:
-
The upgrade process is a lot tighter. Now I just upgrade Wordpress on a development instance, test, and then deploy the upgrade through the normal code deployment process. Plugins are handled the same way.
-
Customization compatibility issues just go away. When we have an outside contractor work around the system by working in his/her own Wordpress we run into issues where the new code is incompatible with versions of Wordpress and our installed plugins. This simply doesn't happen when you check out the whole platform.
-
Your SCM provides diff'ing functionality. Suspect that one of your environments does not conform to the rest? Worried that you have been hacked? Simply do a "git status" and see what files are different from the repository.
One thing to keep in mind: in this model you don't do any upgrades or plugin installation through the web. You also need to turn off the ability to edit theme and plugin code through the web. We needed to do this anyway because we have a clustered infrastructure and those changes need to be propagated across every web server in the farm.
It took me a really long time to come around to liking this setup. I think a big part of that is my Java background. Java makes a big deal about packaging and deployment. Pulling directly from Git seems more common in the PHP world, which never had a build process. But now, I am pretty happy with this setup. The best part is ensuring against compatibility issues (#2 on my list above). I still prefer deploying code to servers rather than pulling code from them but my conviction is steadily eroding. It's kind of nice not needing scripts to move around files and avoid overwriting files that are managed independently on each environment.
Just out of curiosity, I would love to know what source code management and deployment processes other PHP developer use. Let me know.
Mar 12, 2009
Lorelle VanFossen posted the first known permanent WordPress tattoo. I guess (tattoo recipient) Ed Morita didn't read my post on CMS exit strategies. As with most CMS implementations, the feedback has been mixed. Comments on Lorelle's blog range from "Woah! I think it’s a good tat! And it is a great location" to "Oh dear I hope that is fake cos that is the lamest tattoo ever!" However, unlike most CMS implementations, which are planned to be in place for less than 5 years, Ed's tattoo should last a lifetime.
Mar 03, 2009
PlayingWithWire has a usability comparison between WordPress and Joomla! that has gotten a lot of attention on Slashdot and the Joomla! forums. The debate as is as you would expect: WordPress is more usable; Joomla! is more powerful. I don't disagree with either position.
I think this highlights the fact that WordPress is at a point in its progression where it can handle many simple web content management use cases but has not yet achieved a level of complexity as to detract from its usability. It has truly become a viable lightweight CMS - not just a blogging tool. This makes WordPress and platforms like it (Movable Type, Expression Engine, etc.) disruptive technologies in the classic Christensen disruption model where a simple technology reaches a point where it can compete against a more complex incumbent that over-delivers in functionality.
The disruption model usually focuses on price; the challenger technology is cheaper than the incumbent. Not that long ago, we were talking about open source as the disruptor (we still are. Just look at all the chatter about the Linux powered Netbooks). In this case, however, both are open source and free. Here, the cost is in the effort it takes to understand and use the technology. Writing good content is hard enough without the barrier of a hard to use web content management system.
There is a clear trend of companies leaning toward simpler technologies that may not meet all of the extended requirements but are very effective in the primary use cases (in this case, publishing pages and articles). There comes a point where a simple tool reaches its limitations but many companies are prepared to make compromises or doubt whether they will ever need the fuller feature set - at least in the near term.
The incumbent CMS products are not taking this lying down. Many of the commercial products on the market offer a simplified, "task-based" user interface for the casual user as an alternative to their traditional "power user" interfaces. But even unused and unseen functionality has a cost in the complexity of implementation and the cost to support. If your website is very simple and you don't have any power users on staff, a simplistic, lightweight CMS (like WordPress) may be sufficient.