The Proposed WordPress Developer Code Of Honour

Over at WPShout Fred Meyer has published a proposed Code Of Honour for WordPress developers.

The article is address to developers of SME websites and is addressed to both developers and their clients. It addresses problems with SME website projects and puts forth a solution in the form of the code.

It’s a reasonably long read. And if you are either a business owner about to engage in a web project, or if you are web developer who builds out projects single-handedly – then it’s well worth reading.

Immediate Thoughts

After reading the code I had some immediate thoughts: the article and the post itself is timely. In fact, it’s overdue: many good developers have the experience of being pulled into an SME project to discover that the previous developer didn’t know his stuff. Consequently budget gets sucked into cleaning up unholy messes.

Web development professionals aren’t just in it for the money. We want our clients to be happy. We want the projects we work on to succeed. We want to create websites to return an investment. We don’t like seeing clients in pain because the previous team didn’t know what they were doing.

The code requests the developers use professional best practices. Best practices in technically building the project, and in client communication. It requests that developers be accountable to their clients.

The very existence of the code also creates a condition of accountability: accountability to a community that declares itself for the code.

I like this.

Unexpected Controversy

I’ve been in private discussions with people who are in the business of delivering web projects for SME’s. These people are both solo developers and agency owners. These people are good providers and all have records of delivering great projects and making their clients happy.

They largely agree in principle with the code itself. But to my surprise they had two objections to the article itself.

“The problem isn’t the developer. It’s the client”

According to this critique, projects don’t fail because of the developers own weaknesses. They fail because the of faults on the clients end.

There’s some truth to this. Some projects do indeed fail because the client makes unreasonable demands, micromanages the project and doesn’t trust the authority of the agency or the developer. Clients sometimes don’t understand the work that’s involved, and make unreasonable demands. Often clients fail to honour the process by which agencies and developers create good results.

I think that agencies can have good reasons for thinking these things. But I also think that ultimately it’s the responsibility of the agency or the developer to guide the client on these matters. Or to simply turn away clients that won’t work within the process of the agency.

Besides, in all fairness Fred links to content about how to avoid bad clients. And how to be a great client.

“The article is elitist. The author favours programmers over non-programmers”

Now as I mentioned above, the people I heard this critique from have histories of delivering great work. They’ve built many projects that make their clients money. I believe that these people are non-programmers themselves. And they seem to feel that the article shows a kind of hidden contempt for non-programmers the deliver WordPress projects.

But personally I think the critique is baseless.

Someone responsible for delivering an SME WordPress website can deliver without knowing how to program. They can simply hire a programmer.

But the reality is that the better someone knows how to program, and specifically how to program within the WordPress world, then they are in a better position to quickly solve the kind of problems that will come up within the project.

Non-programmers who build websites are spoilt silly by the WordPress world: there are extensions for pretty much everything. From creating real-estate listings, to assessing your content for search engine visibility. There are plugins that promise to make your website faster. Plugins exist for layout out page, for capturing leads, for social media…

There’s a huge amount that you can done without being able to program.

But ultimately if a provider doesn’t understand the underlying technologies then they are disadvantaged.

Understanding the underlying technology brings some significant advantages. Here are just a few.

A programmer can anticipate problems before they happen
A programmer can often solve these problems faster
Cost estimates for projects will be more accurate
When bugs rise from common extensions, programmers can find the cause
… and probably fix them

To clarify: non-programmers can be competent and even excellent at delivering satisfying projects. And sometimes programmers don’t have non-programming skills that great results require.

But personally I think that everyone who is in the business of delivering an SME web project should at least be learning the underlying technologies.

My Endorsement

Personally I endorse Fred’s Code Of Honour 100%. At this point I have zero reservations about it. If the code was “officially released” today in it’s current state then I would commit to it.

The “wild west” period of web contracting is coming to end. Even though cowboy agencies and developers still exist, their opportunities are fading.

Fred’s code is a an idea whose time has not only come: it may be overdue.

In my recent post on OWASP Day 2015 I remarked that WordPress.org itself takes security seriously. I mentioned the recently-released WordPress Security White Paper and pointed to the documents on hardening WordPress.

Of course WordPress.org doesn’t exist in a vacuum and has a tight feedback loop with its wider community. This in itself may be one of the secrets of success both of the CMS itself and the ecosystem.

The Problem

Due to it’s popularity in the shared hosting space self-hosted WordPress is capable of running on old, outdated versions of PHP, including version that haven’t been getting security updates for three years. This has been a result of a design decision by core developers: new installations should not break existing websites. It’s both a feature and a bug.

Of course running on old, unsupported versions of PHP creates security liabilities. A professional developer will, at the very least, raise these issues with site owners where such issues exist. But the reality is that some substandard hosts continue to provision older version of PHP. And many existing sites live on old hosts that haven’t been updated.

An Approach to a Solution

A community project called wpupdatephp exist. It provides a PHP library “… to be bundled with WordPress plugins to enforce users to upgrade to PHP 5.4 or higher hosting.” The project also aims to raise awareness of the risks associated with running insecure versions of php among site owners, and furnishes template email content for owners to include in requests to their hosting company.

The core functionality of the plugin can be seen in the readme viewable on github.

OWASP (The Open Web Application Security Project) is a volunteer-run, non-corporate global organization devoted to making the web a safer place. It provides resources for developers and business to help them secure their assets. It’s many notable projects include the Owasp Top Ten: the canonical list of the top ten most likely types of threat to web applications.

The New Zealand chapter organized another fantastic, amusing and enthralling OWASP Day, and event aimed mostly at Developers. But also of interest to anyone with responsibility for managing (securing) infrastructure.

If that sounds a little dry, you should have seen the metal-as t-shirts worn by the Insomnia crew.

Observations and Thoughts

Pedro Worcel’s presentation ‘CMS Hell’ made an interesting contrast with Nick von Dadelszen’s presentation.

Pedro discussed his own testing of NZ internet for CMS vulnerabilities. Pedro introduced droopscan, a vulnerability scanner for CMS’s. It looks like a really useful tool, and I’ll definitely be experimenting with it.

Nicks talk involved discussion of Section 252 of the Crimes Act, describing penalties for “accessing computer systems without authorisation”. Nicks was focussed on “passive” scanning for vulnerabilities, thus using techniques that can’t be described as possible violations of the Section 252.

One of my takeaways from these two presentations is that a lot of security research that I and others would consider ethically legitimate could be interpreted as violations of the Crimes Act. Even it the resulting research is capable of making the web safer.

The content of Nicks talk can be attained here. (warning: pdf)

Defending WordPress

Adam Bell from Lateral Security presented a case study that provided a cautionary tale about a failure of Defense In Depth. A notorious and very young system cracker had successfully attacked a site managed by the presenter. Adam introduced the log analyser Splunk and described his forensic strategy.

My takeway was that the weakest link will render the entire chain useless. Something anyone in who works around security already knows. But this can be sobering when we consider the possible effect on business. When customers pay for “security”, they tend not to understand that “security” is a thing that can’t be bought. It can be only be defended. But the old maxim holds true: any attacker with sufficient time and skill will always win.

WordPress itself takes security very seriously. WordPress.org has maintained a document for developers and admins on Hardening WordPress for many years. This week they released the WordPress Security White Paper which I read as overview of the security environment of the wordpress world. It applies the OWASP Top Ten to the wordpress world and is required reading for anyone serious about defending wordpress. (Or for that matter, attacking it)

Navigation

Category: tech culture