WordPress 3.3 Proposed Guidelines Revisions
Please review and discuss. This list will be finalized after release of WordPress 3.3, and will be made effective one month following release.
Note: WordPress 3.3 beta 3 has been released. If you haven’t done so already, now is the time to switch to the beta releases/nightlies for Theme testing.
New WordPress 3.3 Functionality
- Admin Pointers
- Themes MUST NOT use Admin Pointers, which for the time being have been deemed by the core devs as a “core only” feature.
- Code Quality
- Themes MUST NOT generate any
_doing_it_wrong()notices.
- Themes MUST NOT generate any
Revisions to Existing Guidelines (REQUIRED)
- Template Tags
- Themes are REQUIRED to use
get_template_directory()/get_stylesheet_directory()instead ofTEMPLATEPATH/STYLESHEETPATH
- Themes are REQUIRED to use
- Script Enqueueing
- Themes are REQUIRED to use the Theme-specific hook for admin-enqueued scripts/stylesheets, e.g.
admin_enqueue_script-appearance_page_$menu_slug Themes are REQUIRED to enqueue comment-reply script via callback in functions.php, rather than output in document headUpdated:
Themes areREQUIREDRECOMMENDED to enqueue comment-reply script via callback, rather than hard-code the enqueue in the HTML document head
Exxample:
<?php function oenology_enqueue_comment_reply() { if ( is_singular() && comments_open() && get_option( 'thread_comments' ) ) { wp_enqueue_script( 'comment-reply' ); } } add_action( 'wp_enqueue_scripts', 'oenology_enqueue_comment_reply' ); ?>- Themes are REQUIRED to use core-bundled versions of jQuery UI and jQuery UI Plugins
- Themes are REQUIRED to use the Theme-specific hook for admin-enqueued scripts/stylesheets, e.g.
- Document head
tag- Themes are REQUIRED to use
wp_titlefilter to filterwp_title()(RECOMMENDED), or pass argument towp_title()(OPTIONALLY), in order to modify document title content
- Themes are REQUIRED to use
- Backward Compatibility
- Themes MUST NOT use
function_exists()conditional wrappers for functions/functionality introduced more than one (RECOMMENDED) or two (OPTIONALLY) WordPress version prior
- Themes MUST NOT use
- Licensing
- Themes are REQUIRED to declare copyright and license information as specified by the applicable license
- Derivative Themes are REQUIRED to retain/declare the copyright information of the original work (With GPL-applicable examples)
- Footer credit link:
- Themes are REQUIRED to use matching text strings for link anchor text, alt text, and title text
- TimThumb:
- Themes MUST NOT use TimThumb
- Internationalization:
- Themes are REQUIRED to use a string, rather than a variable, constant, or concatenation, as the textdomain in translation functions.
- Trademark
- Themes MUST NOT clone the design of past or present web site. Themes that clone non-website designs will be considered on a case-by-case basis.
Revisions to Existing Guidelines (RECOMMENDED)
- Theme Settings and Data Security
- Themes are RECOMMENDED to use
do_settings_sections()to output settings sections/fields, rather than hard-coding markup
- Themes are RECOMMENDED to use
Guidelines Clarifications
- Credit Links
- Determination of appropriateness of AuthorURI and ThemeURI is at the sole, and final, discretion of the Theme Review Team. For AuthorURI, emphasis is on the personal nature of the site. For ThemeURI, a mere demo site is insufficient; the URI must include content predominately related to the Theme.
Angelo 3:33 pm on November 10, 2011 Permalink |
As for:
“Backward Compatibility
Themes are REQUIRED NOT to use function_exists() conditional
wrappers for functions/functionality introduced more than one
(RECOMMENDED) or two (OPTIONALLY) WordPress version prior
”
Is this to try to prevent theme developers from being backward
compatible with all WP versions? What is the purpose of that?
Chip Bennett 3:37 pm on November 10, 2011 Permalink |
Yes, exactly. Repository-hosted Themes should not facilitate/enable use of outdated versions of WordPress.
This shouldn’t be too much of a burden on developers or users. Note that over 76% of all WordPress installations are 3.0 or newer:
http://wordpress.org/about/stats/
Edward Caissie 4:48 pm on November 10, 2011 Permalink |
What was the reasoning behind this: Themes are REQUIRED to enqueue comment-reply script via callback in functions.php, rather than output in document head.
I don’t recall the discussion, nor am I seeing an obvious reason this morning.
Chip Bennett 5:02 pm on November 10, 2011 Permalink |
Well, *this* is the discussion.
The main reason: it doesn’t belong there. It should be hooked in just like any other functional code.
Would you suggest making this RECOMMENDED instead?
Edward Caissie 5:18 pm on November 10, 2011 Permalink |
I’m seeing the callback function method as more best practice than anything else.
I would rather see it as recommended to use a callback function, at least to start; and then possibly add to the commonly used `header.php` conditional statement specific requirements that need to be met.
For example:
if ( is_singular() ) wp_enqueue_script( 'comment-reply' )… may no longer be acceptable. Even as it works correctly, we could look at requiring additional checks such as
( ! is_admin() )etc. … although as I write this I really am not providing a convincing argument nor do I have one to fall back on except best/better practices.Chip Bennett 5:28 pm on November 10, 2011 Permalink |
My arguments are: 1) best practice, 2) consistency, and 3) Child-Theme/Plugin support.
We generally don’t allow any other
wp_enqueue_script()calls to be placed directly into header.php, so we really shouldn’t be for the comment-reply script, either.Also, there is a non-trivial chance that the comment-reply script might be replaced with a custom script, either in a Child Theme or via Plugin, which makes hooking the enqueue call into an action hook all the more important.
BTW, here is my current, recommended best-practice conditional wrapper for the comment-reply script:
if ( is_singular() && comments_open() && get_option( 'thread_comments' ) )Kenneth Newman 7:21 am on November 12, 2011 Permalink
The proper way for a plugin to do that is to de-register and re-register the script, say on plugins-loaded, isn’t it? Child theme function files run prior to header.php anyway, so the same deregister/reregister method is available to child themes.
It’s hardly necessary, and not at all simpler, for themes to use hooks for this.
I don’t see attaching actions to hooks in a functions file as being particularly better practice then the simplicity and readability of enqueues above the wp_head call. As far as consistency goes, to make it consistent, you merely have to not generally disallow other scripts to be called the same way.
Chip Bennett 3:08 pm on November 12, 2011 Permalink
Ideally script registering/deregistering/enqueueing/dequeueing would take place on the appropriate, script-related hooks, such as wp_enqueue_scripts, etc.
Ken 3:30 pm on November 14, 2011 Permalink
Same point tho, to replace a script as per you non-trivial example, whether the script is hooked from functions.php or enqueue’d from the head directly, is irrelevant.
Chip Bennett 9:47 pm on November 14, 2011 Permalink
So, I could totally go along with making the callback method RECOMMENDED, provided that the direct call to wp_enqueue_script() in header.php doesn’t generate a _doing_it_wrong() error in 3.3. A quick test with TwentyTen, against 3.3-beta3, looks like no such error is generated. So, I’m good with making it RECOMMENDED.
Rob 2:01 am on November 15, 2011 Permalink |
personally this is the right way, in functions.php and not in header.php, besides why go the extra mile for checking for singular posts, etc, this js file is fairly small in size, best keeping it simple and easy i think.
Chris Jean 6:28 pm on November 10, 2011 Permalink |
To me, the wording of the rule is kind of vague:
“Themes are REQUIRED to enqueue comment-reply script via callback in functions.php, rather than output in document head”
I see three problems with the wording. 1) It fails to clarify that “document head” simply means header.php as clearly the output will go in the document head no matter what. 2) By specifically requiring the enqueue to be in functions.php, it may needlessly limit a dev who may have a file structure that breaks some of the steps into different files (such as a functions file that only loads on the front-end and another that only loads on the dashboard). 3) It doesn’t actually address the core issue as you’ve stated, that no scripts should be enqueued or output directly in the header.php file.
I think that changing the rule to explain the why as you just have helps nip this issue while also helping devs avoid other instances of this that aren’t related to comment-reply.
Proposal that may be far too verbose:
“Themes are REQUIRED to use callback functions to enqueue or output scripts and styles. Themes are REQUIRED NOT to include code for these callbacks in the header.php file; rather, the code for the callbacks should be be in the functions.php file (RECOMMENDED) or a file loaded by the functions.php file (OPTIONALLY). In the past, many themes would directly enqueue the comment-reply script in the header.php file, this rule is to remove such practices as callbacks should always be used for such purposes.”
Chip Bennett 6:39 pm on November 10, 2011 Permalink |
On your first point, I think it would suffice to change output in the document head to hard-code the enqueue in the HTML document head.
On your second point, a functions.php sub-file is still part of functions.php. It may even be superfluous to say vial callback in functions.php, rather than merely to say via callback.
On your third point, we do try to avoid verbosity in the Guidelines. (And anyone who knows me, also knows how difficult I find such a task!) If you’ll notice, we don’t go into this level of detail on almost any of the other Guidelines. If we need to make such clarification/explanation, that’s what we have this site for.
So, how about rewording to:
Ultimately, I think this one would generally be covered by our current enforcement of other script enqueues, but this one is so prevalent that I think it merits an explicit mention (at least for the time-being).
Chris Jean 7:43 pm on November 10, 2011 Permalink
It’s better, I still wonder if explicit mention of avoiding header.php is nice to have. I just wonder about theme reviewers that are as pedantic as I am and start strictly enforcing this guideline outside the intended scope.
Chip Bennett 8:04 pm on November 10, 2011 Permalink
I think that’s easily enough avoided/corrected via training.
I’m curious, though: what strict/pedantic enforcement do you see that would be problematic here? i.e. what not-as-intended review comment might you leave, with the requirement as-written currently?
Otto 2:49 pm on November 12, 2011 Permalink |
Can we have an example of the right way to do this included? I had to read it a few times before I understood what it meant, an actual working code example of the right way would be far better.
Chip Bennett 3:04 pm on November 12, 2011 Permalink |
Certainly; I’ll add an example to the post.
kwight 5:49 pm on November 10, 2011 Permalink |
“Themes are REQUIRED to use matching text strings for link anchor text, alt text, and title text”
Why would we require the ALT and TITLE attributes to match? If used to its fullest for accessibility, the ALT attribute should be more descriptive than the TITLE tag. If the purpose is to avoid malicious links, can we just say:
“Themes are REQUIRED to use ALT and TITLE attributes corresponding to footer credit links.”
Chip Bennett 6:08 pm on November 10, 2011 Permalink |
Attempts at malicious code go without saying, and need no specification in the Guidelines. Malicious code would probably result in an on-sight blacklisting of the developer who submitted it.
This is in direct response to incessant attempts to play SEO and other games with these text strings. The problem with your proposed requirement is that it wouldn’t do anything to solve the specific problem. Rather than having the reviewers constantly fight a moving, subjective target, it is better to provide a straightforward, objective requirement.
The credit link is the single most problematic aspect of Theme review. It is a magnet/target for those with ulterior motives, and requires far more oversight and vigilance than it should.
Ian Stewart 10:24 pm on November 10, 2011 Permalink |
I know why we’re doing this but it seems to defeat the purpose of title attributes: “Footer credit link: Themes are REQUIRED to use matching text strings for link anchor text, alt text, and title text.” Can this just be looked at on a case by case basis rather than being made a rule?
Awesome: “Themes are REQUIRED NOT to clone the design of past or present web site. Themes that clone non-website designs will be considered on a case-by-case basis.”
Chip Bennett 11:01 pm on November 10, 2011 Permalink |
Personally, I’d like to see a VERY compelling argument regarding footer link anchor, title, and alt text – compelling enough to outweigh the time spent (or rather, wasted) by reviewers policing footer credit links for SEO crap and other shenanigans.
This issue comes up too frequently, and there are far more important aspects of Themes for the reviewers to be focusing on.
Justin Tadlock 12:33 am on November 11, 2011 Permalink |
I understand the reasoning behind this (avoiding SEO/spam type stuff), but this is a bit too strict. If the title text must match the anchor text, there should be not title attribute in use at all.
An example of the anchor text might be “Twenty Ten”. But, the title text might read “Twenty Ten WordPress Theme”. I don’t see anything wrong with that. Title text is meant to give more information about the link, not say the same thing.
In fact, the Twenty Ten theme actually uses “WordPress” as the link and “Semantic Personal Publishing Platform” as the title text.
I like this so long as we’re not eventually trying to make this a REQUIRED guideline in a future version. There’s still room for customization and innovation in this area.
Chip Bennett 3:05 am on November 11, 2011 Permalink |
The other viable alternative is to prohibit the use of alt and title text. I think the current proposal is probably better, but I could go either way.
As with most things, it isn’t the well-behaved Themes that are the issue, but rather the all-too-frequent Themes attempting to play games with the credit link.
Personally, I’m in favor of moving in that direction – but that will be a discussion that takes place well down the road. (Or sooner, if the core markup changes significantly to move away from table-based output. At such time, I would more strongly advocate making this required.)
For now, though, we just want to recommend the best practice.
Justin Tadlock 3:54 am on November 11, 2011 Permalink |
I’m down with this if well-behaved theme devs are given the option of using title/alt attributes correctly without having to argue their case. We can’t simply make rules that punish everybody for the sake of keeping out the evil-doers.
You know I love standards, but I’d definitely argue against a requirement on something like this. But, we can save that discussion for another day.
***
Basically, I just want to make sure legitimate theme developers are protected from having their theme fail the review process for trivial things or for doing things outside the box.
Chip Bennett 2:24 pm on November 11, 2011 Permalink |
How is this requirement a “punishment”?
I absolutely agree. Bear in mind: exceptions can be made for nearly every requirement, if sufficient justification warrants such exceptions – especially with regard to innovative, outside-the-box implementations.
Justin Tadlock 5:23 pm on November 11, 2011 Permalink
We’d be forcing theme devs to use the alt/title attributes incorrectly.
Chip Bennett 5:39 pm on November 11, 2011 Permalink
I still don’t see how that is a punishment, even if true. Neither attribute is actually even needed for an HTML anchor. The most logical, viable alternative to requiring that identical text strings be used would be to prohibit the use of the ALT and TITLE attributes in the credit link anchor, period.
Chip Bennett 5:45 pm on November 11, 2011 Permalink
If we want to get really technical about it, the ALT attribute doesn’t even belong in an HTML anchor tag. So, I suppose we could just require developers NOT to use the ALT attribute in the credit link?
And for the TITLE attribute: it’s purpose is to “offer[] advisory information about the element for which it is set” – something else that isn’t necessary for a self-explanatory credit link.
Justin Tadlock 6:47 pm on November 11, 2011 Permalink
I wasn’t sure why the alt tag was mentioned at all to be honest. I assumed this was meant for when an image was used for the credit link. So, yes, it could potentially be used.
Don’t single out a word from my comment and focus on it though. Call it “punishment” or whatever. You’re getting away from the point that both I and others have made in the comments.
It’s outright ridiculous to force all theme devs to change their credit link title text to be exactly the same as the anchor text because we get some spam and other evil stuff. This guideline wouldn’t change anything. It’s just another bullet-point for the theme review process. You’ll still get evil-doers trying to add in stuff that shouldn’t be added in.
Chip Bennett 6:55 pm on November 11, 2011 Permalink
Let’s try a different tack: what benefit might Theme developers gain from using the TITLE attribute in the credit link anchor tag? And how much time is reasonable for Theme reviewers to spend on subjective parsing of TITLE text strings for appropriateness?
My answer would probably be that there is no real benefit, and that any such time spent is wasteful.
Justin Tadlock 7:16 pm on November 11, 2011 Permalink
Benefits:
To “offer advisory information about the element for which it is set”.
What other benefits are needed?
As far as time spent goes, it should take all of 2 seconds. Is the text appropriate or not? The reviewer must check the text anyway.
Chip Bennett 7:27 pm on November 11, 2011 Permalink
Again: a footer credit link is self-explanatory. No such “advisory information” is needed. In this context, any such “advisory information” is highly likely to be SEO-seeding.
There is a very strong correlation between use and misuse/abuse of ALT and TITLE attributes in the footer credit links. In other words: if it’s there, there is a high likelihood that it’s an attempted misuse.
Justin Tadlock 7:47 pm on November 11, 2011 Permalink
Maybe all credit links are self-explanatory to you. Yes, some links are. That is not always the case. I’ve already given you the case of the Twenty Ten theme above. Do you require more examples?
Here’s an example credit line: Powered by *Hybrid* and *WordPress*.
What’s “Hybrid”? What’s “WordPress”? That’s where the title attribute comes in. That’s what it’s made for.
And, it’s our job to make sure it’s not abused. It’s not our job to make sweeping generalizations about how HTML is used in themes and to say that no one can do something because some other people are doing it wrong.
Chip Bennett 8:09 pm on November 11, 2011 Permalink
If an arbitrary Theme using anything analogous to the WordPress “Semantic Personal Publishing Platform” TITLE text, it would get dinged for SEO-seeding the link. I don’t think that’s a germane example.
“WordPress” is self-explanatory. “Hybrid” could be “Hybrid Theme” or “Hybrid WordPress Theme”, and would then also be self-explanatory. (Just as examples…)
That’s certainly a fair point.
What if we RECOMMEND not using the TITLE attribute in the footer credit link, but allowed it OPTIONALLY? And then added clarification regarding appropriateness of the TITLE attribute text?
I still think ALT attribute text should not be allowed, as it is not a valid attribute for anchor tags.
Justin Tadlock 8:18 pm on November 11, 2011 Permalink
“WordPress” is only self-explanatory to people who know what WordPress is. Think of the other millions upon millions of people that use the Internet.
Of course, “Hybrid” could be changed. I personally like to keep my links short and simple in this area though.
I think that would be perfectly fine.
I agree.
The only reason I can think of that ALT would be used would be for an image wrapped in a link. I general, I’d recommend a background-image-replacement technique for this though. But, that’s an edge case anyway.
mattr123 2:52 am on November 11, 2011 Permalink |
One of my biggest issues…..
Themes are REQUIRED to use core-bundled versions of jQuery UI and jQuery UI Plugins
If that’s the case why not develop a single function to include all the plugins? Also, the user ( or developer ) may wish to link to the jquery or Google version of the latest updates. Why shouldn’t this be allowed? Especially if they enqueque the scripts?
Also, as far as credit links are concerned, why not just set a standard. Leaving it on a reviewer by reviewer basis just seems inefficient and lazy. There should be clearer guidelines as to what is allowed and what is not.
Chip Bennett 3:01 am on November 11, 2011 Permalink |
Because they might not all be needed.
This requirement isn’t stating that Themes have to use jQuery, jQuery UI, or jQuery UI Plugins; rather, it is stating that if a Theme does use one of these scripts, then it is required to use the core-bundled version of the script, rather than registering one of its own. Only the ones needed by the Theme should be enqueued – but if enqueued, the core-bundled version must be enqueued.
Because the Theme might not – and likely won’t – be the only thing referencing jQuery or other core-bundled scripts. Plugins will rightfully expect the core-bundled version to be registered, and if a Theme deregisters a core-bundled script and registers a different version of that script, that action could cause Plugin breakage. (And if it happens in the back-end, it could cause core breakage.)
mattr123 10:06 pm on November 11, 2011 Permalink |
Because they might not all be needed.
This requirement isn’t stating that Themes have to use jQuery, jQuery UI, or jQuery UI `Plugins; rather, it is stating that if a Theme does use one of these scripts, then it is required to use the core-bundled version of the script, rather than registering one of its own. Only the ones needed by the Theme should be enqueued – but if enqueued, the core-bundled version must be enqueued`
Okay, got it, and I agree.
`Because the Theme might not – and likely won’t – be the only thing referencing jQuery or other core-bundled scripts. Plugins will rightfully expect the core-bundled version to be registered, and if a Theme deregisters a core-bundled script and registers a different version of that script, that action could cause Plugin breakage. (And if it happens in the back-end, it could cause core breakage.)`
I can see your point here, but there is a lot to be gained by linking to say Google’s JQuery. Rather than enforce theme developers to include the core JQuery scripts, I’d say they must link to the latest version of them, and for any custom scripts, they must use JQuery’s no conflict and ensure that their scripts degrade gracefully.
Chip Bennett 10:14 pm on November 11, 2011 Permalink |
Two problems with that: one, jQuery isn’t always forward-compatible, so using a newer version of jQuery (or UI or Plugins, etc.) could still cause breakage for Plugins or core; and two, if the Theme isn’t updated in a timely manner, the Theme-bundled version could end up being older than the core-bundled version. (That became an issue just a couple days ago, when WordPress 3.3-beta3 started bundling jQuery 1.7.)
Otto 2:55 pm on November 12, 2011 Permalink |
mattr123: The choice as to whether or not to use an external library such as Google’s scripts should be one made by the website owner, not one made by the theme developer. If the theme developer is enqueuing scripts properly, then plugins, such as the excellent “Use Google Libraries”, can automagically change those enqueued scripts to point to Google’s versions of the scripts, and so forth.
This has two major advantages:
1. Plugins can do it better. If you simply linked to the google jquery directly, then you’d find that it would break some things because of the noconflict mode difference.
2. Themes will work in settings that don’t have access to Google. Consider WP being used on an intranet site, where not everybody has unrestricted internet access and can’t access Google’s servers directly.
Thus, use the core code. If somebody wants to use other libraries, they still have that option, but that should remain their option, not the theme developers choice.
Chip Bennett 9:23 pm on November 14, 2011 Permalink |
And here’s one more reason that this is better as a rule: no control over the external resources being linked, and absolutely no way to police such sites after approval.
kaiser 3:10 pm on November 11, 2011 Permalink |
Please explain this more in detail. We got the “Text Domain” Plugin/Theme header comment and functions like get_plugin/theme_data( ‘Text Domain’ ) to receive this information/string. Going through plugins/themes and adding/replacing strings is a pain.
Chip Bennett 3:44 pm on November 11, 2011 Permalink |
Here’s the background, from Mark Jaquith.
The issue was discussed heavily on the Theme-Reviewers mail-list (here and here).
Justin Tadlock 6:49 pm on November 11, 2011 Permalink |
It should be a simple text replacement to make this change to your theme, which takes all of a few seconds. Most code editors will let you do this easily. I can show you how to do it in Notepad++ if you need help.
Emil 8:15 pm on November 11, 2011 Permalink |
This looks very good to me. Three questions.
1) This applies to new and live Themes correct?
2) Should we require authors not to alter WordPress Core styles such as wp-login.php, regardless of how they do this. I am strong believer that we should not be doing this.
3) Theme Options to use “Restore to Default” (Reset) button?
“Reset Button” should be able to delete all settings and leave no Theme specific “traces”.
I’ve seen one too many issues with this, starting from my very own release.
Chip Bennett 8:41 pm on November 11, 2011 Permalink |
Only to new Themes. Guidelines revisions only impact Themes submitted after the revisions are made effective.
I think we should definitely enforce this. Does it need to be in the Guidelines, or should it be understood? If it needs to be in the Guidelines, how would you generalize it?
Perhaps making this RECOMMENDED would be a good step. But we would then also need to recommend Otto’s array_merge() method for option defaults. So, we should probably put more time, effort, and thought into how to handle this, before adding anything to the Guidelines – and perhaps write some best-practice tutorials?
Emil 9:03 pm on November 11, 2011 Permalink |
1) Got t.
2) It does not have to be, as long as we agree that this is “must not do”.
3) Best practice tut sounds very good to me.
Kenneth Newman 6:22 am on November 12, 2011 Permalink |
What are the reasons that a theme shouldn’t be allowed to alter the look of the login? It is public front-facing html and css after all…
Emil 5:31 am on November 14, 2011 Permalink |
Simple, it’s not really part of the Theme and author should not dictate the look of WordPress core styles. I personally will not approve any Theme who’s author re-designed the wp-login.php page in any way.
We all got a chance to see WP logo removal and/or replacement, link tempering from the same etc. If user wants to do this on it’s own (i.e. plugin) well that’s up to them, and not us to decide.
That’s why I am in favor of adding few words about this in WP guidelines. Or make a final understood decision that this is a no-go!
Cheers,
Emil
Ken 4:21 pm on November 14, 2011 Permalink |
I’m not particularly *for* changing the logo or style of the login page. I think the WordPress branding adds value; users know WP and like it, but…
The only requirement should be that this kind of functionality be “opt in” by the blog owner (via a theme option page).
Blocking features because they can potentially be abused is a bad habit.
Chip Bennett 9:49 pm on November 14, 2011 Permalink
There is certainly an argument to make that modifying wp-login.php is “Plugin territory”, since wp-login.php really isn’t front end display of content, but rather the front-end/admin gateway, and should probably be considered as admin and not front end. That said: a Theme option, disabled by default, is certainly something that should be considered as a reasonable compromise.
Emil 2:13 am on November 15, 2011 Permalink |
I’ll buy that from both of you guys, sounds reasonable enough.
Emil 6:15 am on November 12, 2011 Permalink |
One more thing, since this comes around often as well. Creative Commons (CC) License is not compatible with GPL in any way, I think that we should make a note of that somewhere in review as well. Many are aware, but it could be good idea to have it in writing too.
MadtownLems 3:14 pm on November 22, 2011 Permalink |
In regards to the timthumb requirement… This makes sense in light of recent issues. Is anyone willing to write a guide to aid theme developers who maintain themes currently using timthumb to make the switch to wordpress’s native resizing?
Sayontan Sinha 5:56 pm on December 8, 2011 Permalink |
Would a replica of the Mac desktop be accepted? I ask because there is one theme that clones the “Aero” look of Vista / Windows 7.
Chip Bennett 6:50 pm on December 8, 2011 Permalink |
Well, a desktop environment is not a website, so it wouldn’t be inherently prohibited, and would be subject to the (quite subjective) case-by-case determination for appropriateness. I seem to remember discussing the “Aero” clone, and the reviewers agreeing that it was acceptable – but I don’t recall the specifics of that discussion off-hand.
To be honest, this isn’t an area that I’d like us to spend a lot of time in nailing down objective guidelines. The website-cloning restriction is being added in order to prevent an obvious, known risk; it really isn’t intended to encourage or explicitly condone non-website clone designs. Bear in mind that we are not lawyers, and are only trying to ensure reasonable diligence in preventing design trademark issues.
mercime 3:12 am on December 23, 2011 Permalink |
Add http://wpdevel.wordpress.com/2011/12/12/use-wp_enqueue_scripts-not-wp_print_styles-to-enqueue-scripts-and-styles-for-the-frontend/