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

[Chip Bennett]

Is there any particular reason that you posted this on the WP-TESTERS email
list - a list that deals with testing new versions of WordPress *core*, and
discussing bug reports?

This type of discussion is *exactly* what the THEME-REVIEWERS mail -list is
intended for. There are a lot of points I would like to discuss (excluding
the file-permission issues, on which I defer to Frumph and Otto), but I
don't believe this list is the appropriate venue.

Chip

On Mon, Jun 27, 2011 at 5:13 PM, Bruce Wampler <brucewampler at gmail.com>wrote:

> 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
> wp-testers at lists.automattic.**com <wp-testers at lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-testers<http://lists.automattic.com/mailman/listinfo/wp-testers>
>