[wp-testers] A RE-EXAMINATION OF THEME REQUIREMENTS - AN ESSAY

[Bruce Wampler]

A RE-EXAMINATION OF THEME REQUIREMENTS - AN ESSAY

Some of you may have seen some of my recent comments about some issues 
I'm having getting my theme approved.
I would like to bring up some discussion regarding the process in 
general, and some specifics that apply
to my theme in particular.

I have been writing software for almost 40 years now, a lot of it open 
source. I'm relatively new at
writing themes, with just 4 years of experience with that. But I have 
been a pioneer in this business,
and have written books about Software Engineering and maintaining 
software over long period of time.
I also have extensive experience in designing user interfaces, and 
dealing with the end customer.
And I've taught hundreds of people how to program at the University 
level. Just wanted to be clear
that these aren't the thoughts of some newbie.

1. EVER CHANGING REQUIREMENTS - THERE MUST BE SOME GRANDFATHER PROVISIONS

My theme has been in the repository for over a year now, and during that 
time I have spent countless
hours revising it to meet various new requirements for theme approval. I 
have found the sheer
number of changing requirements excessive, and arbitrary. But perhaps 
the worst part is that
all the requirements are applied to each theme submission - whether the 
theme is new or old.
I have literally spent days bringing my theme into compliance, only to 
have it fail the next time,
a few weeks or months later, because of some new requirement that may or 
may not make the theme better.

I accept that meeting security measures is required - except when it is 
not really clear that those
measures bring about true security. I find some of the measures the 
equivalent of taking my shoes
off for the TSA - no one in the end is any safer, they've just wasted a 
lot of time.

But what is the most difficult is meeting arbitrary requirements that 
are really a matter of style,
or a simple way to make reviewer's lives easier. (And I appreciate the 
difficulty of trying to
improve those standards.)

I'd like to use one example from my own theme to explain the problem. 
Earlier this year, I was
convinced by Chip that I needed to switch to the settings API for my 
options pages. My theme is
somewhat different than most in that it has lots of options - like 
hundreds. (And essentially every
single one of options was added in response to multiple feature requests 
from my user base.)

So I did in fact spend about 100 hours converting to the Settings API. 
(I had been using
forms with nonces before.) But I had a big problem - there was (and may 
still be) a significant
bug in the Settings API. If the same data base item was manipulated with 
two instances of forms
using the Settings API, one case would wipe out the sub-settings 
manipulated by the other instance.
I spent countless hours tracking this down, and in the end, decided it 
was likely a database cache
problem. The result, however, was that I needed to used two database 
entries - one for each of
the different Settings API forms. This also involved substantial 
reorganization of my
internal structure to accommodate the two entries.

At the time I did all this (and I was working with Chip all along to 
make the theme meet
submission specifications as well as using the Settings API), there was 
no requirement to
have only a single settings entry in the database, but that is now a 
requirement.

So what do I do? I spent a long time working with one of the lead 
reviewers to use the Settings
API, which they consider important, and I think are under consideration 
to make required.
Because of limitations of the Settings API, I was forced to use two 
database entries, and
that was OK in March. Now, in June, that no longer is OK.

It seems clear to me that the review process must allow for exceptions, 
especially for
themes that have been previously approved. In this case, allowing more 
than one
database settings entry seems harmless. If the argument is that having 
more than one
entry will break future uninstall plans, I would say than that the 
uninstall plans
should be changed to allow that. I can think of several good reasons to 
use several
database entries for theme settings (certainly not unlimited, but say 
three or four).

This is but one example. I'm sure there are many other requirements that 
might
improve overall theme quality, but that may be very difficult to meet 
for some
existing themes because of internal architecture. (For example, table 
based themes
vs. CSS block based themes - that might reasonably be required for new 
themes,
but it would be unreasonable to block updates to existing themes because 
they
are table based.)

So I would like to propose that existing themes be given some 
grandfather protection
from having to go though major internal restructuring to meet specific 
guidelines. This
may require a special submission process, or an option for the automated 
submission
interface.

To not make an official upgrade/grandfather policy, I believe, will 
ultimately be
harmful to the WordPress community. Personally, I have a long record of 
contributing
open source software. I want to keep my theme alive and up to date on 
WordPress.org.
But I will not re-write the interface again to meet an arbitrary 
requirement for only
one database entry. I will simply withdraw from WordPress.org, and try 
other options.
I would guess that other great theme will also be removed or die of 
neglect because
it is simply too hard for programmers who are giving away their 
programming efforts
to update existing themes to meet new and ever-changing requirements.

2. ATTACK SECURITY CORRECTLY AND COMPREHENSIVELY

I find the approach to security used by the WordPress theme review 
process less than
optimal. The philosophy seems to be a that it all must be done in the 
theme, even to
the extent that themes can't use tools available to core WordPress. At
the same time, there are no controls whatsoever for plugins. I guess one 
could
argue that everyone needs a theme, and plugins are options. But that 
doesn't take
into account reality. It would be a real challenge to find a WP site 
without a
plugin.

For my example, I'd like to discuss the ban on fopen. I've read the 
reasons and arguments
for the ban, but I remain unconvinced of the necessity. To summarize, 
the argument
is that on shared hosts, using fopen to create a file will result in a file
ownership of Apache or nobody, which could then be exploited by other 
accounts on
the same shared server.

The problem is - just how many commercial shared servers exist that 
actually work
that way? Seriously. I only have access to two shared servers, but they both
always set all ownership to the account holder automatically. It is 
impossible
to create a file using fopen that doesn't belong to the account owner.

The arguments about ownership don't apply to standalone servers such as VPS
or others.

So there probably are some shared sites that don't work that way, and create
accounts with apache/nobody as owners. From my perspective, forcing themes
to use the unfriendly WPFilesystem instead of fopen is the wrong solution
for several reasons.

1. It is unfriendly. Some users will be forced to enter their FTP 
credentials
over and over, or modify the wp_config.php file to include the FTP info. Or
keep the info in the database - oh wait: only one database entry is allowed.

2. It totally ignores the possibility of the unrestricted plugins that can
use fopen as freely as they like.

3. The current implementation of the WordPress media library does not ensure
that media files are owned by the site owner - they are created and owned
by apache or nobody on sites configured that way.

An how, in any way, shape, or form, does a ban of fopen to read files have
anything to do with security at all? The only thing I can think of is that
Theme Check is too lazy to distinguish the difference.

And I think this is the wrong approach. It is way too micro-managed. A 
much better
approach would be to make the solution a bit more global - one that would
help protect sites that use plugins as well as themes. One that would 
educate
the end users, and help web security as a whole.

How to raise the level higher? Put some checking functionality into 
WordPress.
Have WordPress run a basic security check.

Take fopen - from my small sample, I would conclude that an increasing 
number
of shared hosts don't have a file ownership problem that could be exploited
by other accounts on the same server. The goal should be to make that number
zero. You don't accomplish this by micro steps way down in themes. You do
it by providing feedback to the end user:

WARNING! WordPress has detected a potential exploit path on your site's 
host or
server. If you are using a shared hosting company, you should consider
changing hosts to a different company. If you are not running on a
shared host, you can ignore this message.

Provide appropriate wording - links to explanations, etc. But the goal is
to shutdown badly configured shared servers, or encourage them to configure
their sites to make all file ownership go to the owner and not the server.

Now we have a solution that helps everyone. Plugins that use fopen are now
safer. Theme writers can use methods that lead to an optimal user 
experience.
And we don't waste anybody's time on servers that aren't affected by a
problem that should handled at that level anyway.

(On the other hand, I believe that themes should flash big warning messages
to people still using IE6, and even IE7, for that matter. We'd more likely
prevent far more evil things that way than banning fopen from themes.)

IN SUMMARY

1. Grandfather previously accepted themes
     It is not fair to force authors of previously accepted themes to go
     through major re-writes whenever they submit a new version of their 
theme,
     or a bug fix.

2. Get real with the security
     Security is important. Placing all the burden on theme writers for 
issues
     that can and should be addressed at other levels is also unfair.

Thanks for listening. I really want the WordPress community to have 
access to
the best themes possible, but I believe some of the theme requirements have
gotten out of hand over the past year, and lend nothing to the functionality
and security of sites. There seems little appreciation for the efforts made
by theme writers, or any mechanism for handling special cases.

I really want to keep my theme on WordPress.org, but I'm really not sure 
I want
to waste more and more hours meeting ever changing, and arguably overly 
restrictive
and irrelevant theme requirements. It is good to have standards, but as 
someone
who has been writing themes for 4 years, I find the constant moving target
pretty difficult to tolerate, especially when the changing requirements will
force fundamental redesign of a theme which was initially designed to
meet the requirements at the time the theme was created.

If WordPress.org want to continue to attract top notch free themes, I think
something has to change. I haven't decided yet, but I'm really close to
abandoning the free theme world, and going down the premium path. It would
be a shame.

Bruce Wampler

-- 
-----------
Bruce Wampler, Ph.D.

Software developer
Creator of first spelling checker for a PC
Creator of Grammatik(tm), first true grammar checker
e-mail: bw at brucewampler.com
blog: brucewampler.wordpress.com