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
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
