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