Theme Checker Plugin issues….

How are these wrong tags?

First – bear in mind that the Theme Checker plugin is geared towards developers who wish to submit a theme to the WPORG Theme Repository. So there is a strict list of allowed tags. You cannot just throw in a few of your own.

fwrite was found in the file

That’s totally banned in the Theme Repo. Why do you need to write to a file anyway?

Dreamweaver project file

You can only include theme specific files.

One thing that really baffels me is

All required under the Theme Review Guidelines. You did read that page., didn’t you?

So I assume I will be punted to the curve

It’s safe to say that your theme will be instantly rejected if you try to submit it. If you do want to submit it, you need to do some homework on what is, and isn’t allowed, first.

That’s retarded.

Um… that’s perhaps a little harsh. The original scripts were built to assist with auto-checking of themes submitted to the Repository prior to the manual review. These were then bundled into a plugin as a service to theme developers. Personally I find the plugin extremely helpful and I use it on bespoke themes for clients to check that I haven’t missed anything. Coding all of your themes to WPORG standards has to be a Good Thing(tm), in my opinion but I can appreciate that theme frameworks may a little different. That said, Suffusion – which is also a framework – has passed all of the checks multiple times.

Because you have a custom css, php and js editor built into the themes options page

So why not store these in the db and generate them on the fly?

So I assume I have to strip this functionality out if I want the theme to be used in the wordpress theme repo?

You’d need to discuss that with the Theme Review Team. They have a dedicated site at http://make.ww.wp.xz.cn/themes/ and a mailing list at http://lists.ww.wp.xz.cn/mailman/listinfo/theme-reviewers I’m sure they’ll happily deal with any queries that you may have and are open to the possibility of “special case submissions”, You have to keep in mind that the plugin is just dumb (but useful) software. 🙂

How is that a theme specific file?

Um… that’s the point. A Dreamweaver project file isn’t theme-specific (ie not needed to actually use the theme). That’s what the plugin is trying to tell you so that you remember to remove it before zipping the theme up and submitting it. FWIW, I tend to keep all of these files in a theme sub-folder called something like “source-files”. I then routinely remove this sub-folder from any archive that is to be submitted or downloaded.

But i find it ridiculous that they are REQUIRED css classes.

Sorry but at the end of the day – them’s the rules. There is logic at work here. The main aim (as I understand it) to to try and provide a consistent, high-quality, user experience from theme to theme. In order to do this, themes have to have taken specific, core-generated, classes into account. Doesn’t mean that you have to do anything funky with them. Just ensure that they are part of the theme’s stylesheet and are dealt with appropriately on the site’s front end. The Theme Unit Test data can be very helpful in this respect.

Any thoughts, suggestions, flaming remarks?

No flames. And I do understand your frustration. When the theme review system was first revealed about 2 years ago, I think it would be fair to say that I didn’t exactly like it either. I was seriously concerned that it would constrain designs and designers. But, over time, I’ve come to see that it has had a very definite positive effect on the overall standard of themes in the Theme Repo. If you get a theme accepted, you really have achieved a high level of theme design. So, all in all, I’m now very pro the review system – even if it does sometimes mean that one of my theme updates gets rejected because I forgot something. That’s my fault – not theirs.

I also hang out on the theme review mailing list and it really is a good place to learn new techniques and keep up-to-date. The team are extremely hard-working but open to ideas and ways to improve the system.

I know this is a really bitter pill to swallow when you have put so much time & effort into your theme (BTDT) but please do not give up now. Read the Guidelines. Use the Unit Test data. Talk to the team. We’d all like to see your theme in the Repo.

First – bear in mind that the Theme Checker plugin is geared towards developers who wish to submit a theme to the WPORG Theme Repository. So there is a strict list of allowed tags. You cannot just throw in a few of your own.

That’s retarded. But I guess, I understand. Where are these “tags” I can use?

At first glance, one may think so. However, consider things from the end-user’s perspective. Unless we maintain a whitelist of tags, then tags quickly become utterly useless. (For cross reference: try doing a tag search here in the forum.) The list of valid tags may be found here.

That’s totally banned in the Theme Repo. Why do you need to write to a file anyway?

I already explained that – Because you have a custom css, php and js editor built into the themes options page in which you can edit the custom css, php and js file right from inside the theme, this requires opening, writing to, (possibly) creating said files which are: custom-css.css, custom-functions.php and custom-js.js

I do not want the user using the functions.php file because of how the theme framework works. Most theme frameworks come with a custom-functions.php for the user to use instead.

There is absolutely no need to write/read files for this functionality. Store the user-generated data, properly sanitized, in your options array, and print them out, properly escaped, via callback, hooked into an appropriate action hook.

If you have any questions regarding how to implement, just ask on the theme-reviewers mail-list.

So I assume I have to strip this functionality out if I want the theme to be used in the wordpress theme repo?

Certainly not. It just has to be implemented properly.

Dreamweaver project file

You can only include theme specific files.

Im sorry what? How is that a theme specific file?

It’s not. And that’s the point. You need to remove development files from the Theme package before you upload it to the repository.

All required under the Theme Review Guidelines. You did read that page., didn’t you?

I skimmed it. I wont lie there. I will check out that page, But i find it ridiculous that they are REQUIRED css classes.

WordPress generates those classes. We must ensure that the Theme developer, at a minimum, considered and accounted for the use cases in which the classes are generated. Your Theme will be used to display image galleries, and pictures with captions. So yes: you need to have considered how those elements will be presented (styled) by your Theme.

My “rage” comes from the fact that I am building a theme framework similar to others such as thesis, woo themes and what not, with the difference of being in the WordPress repo because I am no where as famous as these people.

I promise you that we show no favoritism. If any of those Themes were to be submitted to the repository, they would undergo exactly the same scrutiny.

Any thoughts, suggestions, flaming remarks? There are some things I wont budge on, which are used in a lot of popular themes and that’s the whole writing to files when using the php, css or js editor.

You’re welcome not to budge on some things. However, anything that is listed as required in the Theme Review guidelines are things that the Theme Review Team also will not budge on, without extraordinarily compelling justification.