WordPress.org

Make WordPress Themes

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 12:06 am on May 21, 2013 Permalink | Log in to leave a Comment  

    Should Priority #1 Queue be Reserved for Admin Review? 

    I’d like to throw out an idea for discussion/feedback. If we get a consensus, we’ll implement it; otherwise, we’ll maintain our current process.

    Currently, there is a delay between tickets being closed as “Approved”, and Themes being made live in Extend (“Extend” is no more) the Theme directory. This delay exists for two reasons: one, because the synchronization between Theme-Trac and the Theme directory is manual, and two, because Admins do a final audit of “Approved” tickets before making the Themes live. (Because we have so many volunteer reviewers, and don’t have the time or resources to implement any kind of formal training process, we basically give anyone who wants to review Themes, and shows the initiative to get involved, the privileges necessary to assign/resolve/close Theme-Trac tickets. So, the compromise is that, for tickets resolved as “Approved”, the Admins add in an extra, quality-control step before making those Themes live in the Theme directory.)

    Because of that delay, the Admins have asked for up to a week to complete the synchronization to make Themes approved in Theme-Trac live in the Theme directory. While this delay is (unfortunately) not a huge additional amount of time to wait for most Themes in the queue, for currently approved Themes, the delay prevents end users from getting bugfixes or security updates for Themes they currently use.

    Because it is especially important for updates for currently approved (and currently in-use by end users) Themes to be made live in the Theme directory as quickly as possible, I would like to propose a change to the Review process: to reserve the Priority #1 Queue (i.e. currently approved Themes) for review by Admins, who can review, approve, and synchronize those Themes immediately, rather than sorting through the queue of approved Themes waiting to be synchronized.

    I’ve added a poll. Please leave any additional comments or feedback in the post comments.

     

    • Andrew Nacin 12:10 am on May 21, 2013 Permalink | Log in to Reply

      I’m confused by your proposal — the priority #1 queue as it exists now is great. If we implemented this plan as-is, I’d hope that we’d just have priority #2 be the old #1, etc.

      I think we can solve this with better tools. What about this?

      • Create a new status of “Live”
      • Allow theme admins to change a ticket that is closed as “Approved” to “Live”
      • Create a separate report that theme admins can look at for “Approved” tickets that are not “Live”

      I can have this working in a few hours, after dinner.

      • Chip Bennett 12:57 am on May 21, 2013 Permalink | Log in to Reply

        Right now, any reviewer can review any ticket in any queue: basically, take the first Theme in the highest priority. If #1 is empty, check #2, and so on. The only change here would be that only Admins (who can review, approve, and then go immediately to the Theme directory and synchronize as Live) would review Priority #1 queue tickets, and everyone else would start with Priority #2.

        The reasoning is that the vast majority of Priority #1 Queue tickets are resolved as “Approved”, and represent the greatest workload of “Approved” Themes that the Admins then have to audit and synchronize. This proposal would thus short-circuit some of the workflow, and get more “Approved” Themes into the hands of end users sooner.

        We have experimented with the Theme-Trac workflow (previously, via keywords), and we found that it only created more work. The ideal solution would have Admins interacting with Theme-Trac tickets as little as possible during the synchronization. Besides: Otto has already given us ways to filter through the “Approved” Themes waiting to be synchronized (in the Theme directory admin).

        Ultimately, the only thing this proposal changes is that it helps get Priority #1 Queue tickets processed and synchronized faster.

        • Andrew Nacin 3:04 am on May 21, 2013 Permalink | Log in to Reply

          Isn’t Priority #1 for updates to themes that are previously approved, but where the updates still need to be reviewed? If Priority #1 becomes updates that are approved and ready to go live, then surely you need for a second Priority 1A which is the current priority 1?

      • Andrew Nacin 3:10 am on May 21, 2013 Permalink | Log in to Reply

        Here is what we are envisioning:

        • A theme that is approved by a reviewer causes the ticket to be closed.
        • These themes end up in a new report, called something like “Approved themes that must be pushed live by a theme admin”.
        • When the resolution of the ticket is changed to “Live” by an admin, it is automatically approved in the theme directory. There will be no need to go to wordpress.org/themes/admin in this scenario.
        • A theme admin can directly mark a ticket as “Live”, rather than a two-step of marking it as “Approved” and then “Live”.

        Additionally:

        • When a new version is uploaded, with an old version that is still pending review, rather than this being a manual process where reviewers look for new versions, we can automatically (on upload of the new version) update the old version’s existing ticket. This way, things get cross-referenced automatically, and that theme doesn’t lose its place in the queue. We’ll be able to actually adjust the diff link to account for the need to review changes across multiple themes.
        • We’re going to actually *list* other tickets of that theme in the ticket body, rather than linking to this list. It will be a dynamic list that will update on older tickets even as newer tickets are submitted, automatically creating full, easy cross-references.
        • If the theme is an update of a previously approved theme, we may actually be able to show the *entire diff* directly in the ticket. No more needing to open a new window.

        And, some potential presentational changes. Rather than everything being a “theme”, it can be a:

        • previously approved theme
        • new theme
        • new theme (previous versions not approved)

        We already calculate this data in the reports, but this will now be much easier to query and look at. It will also make this reports much faster, because right now they are really slow (and probably are making the server unhappy).

        Tickets will also be able to be “unassigned” (by default), “assigned” (to others, by theme admins only), and “reviewing” (by a reviewer). Regular reviewers will also be unable to “resolve” a theme as approved or otherwise prior to saying they are reviewing it, and they won’t be burdened with additional UI such as the ability to assign to others or resolve a theme, without accepting it. End goal: It will be more streamlined and easier to approved themes.

        This will take up to a few weeks to get to everything, but the first part (the top four bullets) are going to be implemented now.

    • Josh Pollock 12:12 am on May 21, 2013 Permalink | Log in to Reply

      I think that removing the one week window for approval would greatly benefit end users. Concentrating the efforts of non-admin reviewers on new themes will help cut down on that backlog. As someone who just had to wait 6 weeks to get a new theme reviewed that is a very enticing prospect. The only downside I see to this is it could create too much work for the admins.

      As I proposed in the list, I think we should implement this system on a trial basis and if this creates too much work for the admins, thus leading to a backlog of previously approved themes needing reviewed, we can designate 1 or 2 highly experienced reviewers to help out on that queue when needed.

    • Srikanth 12:13 am on May 21, 2013 Permalink | Log in to Reply

      Not all updates to already approved themes are security/bug fixes, mostly they are code cleanup, new feature/skin additions. We are already allowed to request a quick update/review and not wait for 7 days if its security related.
      If admins can dedicate a few minutes every day, then its a good idea. They can also use these few minutes to push the already approved themes live too.

    • Emil Uzelac 12:23 am on May 21, 2013 Permalink | Log in to Reply

      My #1 priorities are pretty much always pushed live after the review and I do agree with you that this should be an admin only.

      Let’s place everything else aside, what happens if there was a “security” fix for any given Theme, newbie won’t know the difference whether or not the fix was done properly.

      • Srikanth 12:33 am on May 21, 2013 Permalink | Log in to Reply

        I don’t assign myself the ticket if i don’t understand whats going on, kind of pre screening, I assume everyone does that?

    • Andrew Nacin 12:29 am on May 21, 2013 Permalink | Log in to Reply

      I am talking with @Otto42, we are going to overhaul how themes.trac is set up tonight. No need for your workflow to be so manual — we can make it better! Stay tuned.

    • Frumph 2:00 am on May 21, 2013 Permalink | Log in to Reply

      Has anyone fathomed any thought to the abundance of regulations and requirements being the reason the queue time is so long? Or is it just the lack of time …. read on twitter that it’s now at 2 months wait time.

      • Chip Bennett 2:17 am on May 21, 2013 Permalink | Log in to Reply

        I honestly don’t think so. Half of the Guidelines are covered by the uploader script and Theme Check. The two biggest issues:

        1) The overall quality of Themes submitted. The quality Themes submitted by developers making a sincere effort to conform to the Guidelines are still overwhelmed by the number of Themes that exhibit little or no effort to conform to the Guidelines.

        2) Participation is wide, but shallow. I just did a very rough estimate. Of over 100 people with reviewer privileges, less than 25 have closed at least 100 tickets (over an almost 3-year period). Now, that number has improved significantly; in fact, it’s doubled in the past six months or so. But, it’s still a classic Pareto: 20% of the reviewers do 80% of the work. In a volunteer activity, that is simply the nature of things. We can’t demand more of anyone’s time; we can only be grateful for the involvement we get.

    • wpweaver 2:33 am on May 21, 2013 Permalink | Log in to Reply

      Sometimes, it would be great to get a priority 1 theme approved and pushed live – especially if there are important bug fixes. But really, sometimes it doesn’t matter. Many themes are well-established, and updates are thus often feature related, not bug related. So it doesn’t matter if it is a week or 10 days.

      But sometimes there are critical bugs, and it would be great to have these turned around asap. So perhaps there could be some way to indicate urgent, bug related updates that affect end users, and those that are not really critical. Maybe even a new 0 level for urgent fixes?

    • Justin Tadlock 2:59 am on May 21, 2013 Permalink | Log in to Reply

      I don’t like this proposal because I don’t think it’s the best solution to the problem and like the current workflow as it is. I definitely don’t want to add another layer of complexity (review these themes but not those).

      I’ve never had much problem with the wait times after approval and don’t see it as an issue (from a theme author’s perspective). However, better tools are always welcome. So, if Nacin and Otto come up with something that would make this less manual for the admins, I’d love to see that put into place.

    • Abhik 10:28 am on May 21, 2013 Permalink | Log in to Reply

      What about giving some additional permissions to veteran reviewers so that they can approve themes and make it live? That’ll off load little pressure from admins.
      But let’s see ehat Andrew and Otto come up with.

    • Edward Caissie 2:46 pm on May 21, 2013 Permalink | Log in to Reply

      I’m all for a better workflow and more streamlined processes. Although some of these “changes” may require a bit of thought in how they are fully implemented I’m all for finding a better way to manage the “bug-fix” and “security issues” scenarios. Otherwise, most of the wait times are within reason for approved themes given the volunteer powered workforce doing all of the heavy lifting.

  • Chip Bennett 11:53 am on April 30, 2013 Permalink | Log in to leave a Comment
    Tags: request queue   

    I just cleared out the ticket request queue. I think I assigned tickets to everyone who requested one, but the moderation queue was a bit inundated with spam, so if I missed anyone, please post your request again. Also: please be sure to include your (case-sensitive) wordpress.org username with your request. Thank you, all, for your contributions!

     

  • Chip Bennett 1:56 pm on March 4, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Follow-Up on End-of-February Review Queue Push 

    Last week, I mentioned that the review queue had reached about 150, and suggested that we get together for an end-of-week/end-of-February push to clear the queue.

    So, how did we do?

    As it currently stands, the review queue is at approximately 50 tickets, with 260 tickets closed in the past 7 days, by 28 reviewers. Special thanks to @gpriday, @nishasingh, and @life.object, who each closed more than 10 tickets each; and @slobodanmanic, @mercime, @labor4it, @jcastaneda, @Frank_Klein, and @Fingli, who each closed at least 5 tickets each.

    (Note: you can now see real-time stats for the past 7 days, here.)

    As it now stands, we have completely cleared the Priority #2 queue, which means that we have no unassigned tickets older than two weeks. Fantastic job on that front as well, since any tickets that wind up in that queue represent developers who have been waiting at least 2 weeks just to get feedback on their Theme. (Ideally, we will never have any tickets fall into the Priority #2 queue.)

    But even better: we now only have 15 unassigned tickets older than one week. While I see the Priority #2 queue as an indication that we’re really not getting the job done, I would love to make it a goal to keep the number of Themes older than one week at zero as well. Getting to the point where the team can turn around all tickets in a week or less, on a regular basis, would be a huge improvement, and would, I hope, keep the developers happy who submit Themes.

    So, let’s see if we can get that queue of 50 Themes knocked out (we last saw review queue “Inbox zero” over a year ago, IIRC), and then see if, from a fresh start, we can keep the number of tickets open longer than a week at zero.

    As always, thanks everyone for your contributions. We know that this is a volunteer activity, and that contributing to the Theme Review Team takes away from valuable time spent elsewhere.

     

  • Chip Bennett 1:07 pm on March 4, 2013 Permalink | Log in to leave a Comment
    Tags: Apache 2.0, GPL, license   

    Licensing Note: Apache and GPL 

    Just a quick note, that came up during last week’s push to tame the review queue: the Apache 2.0 license is GPL-compatible, but only with version 3.0 of the GPL. Works that are either GPLv2.0 or GPLv3.0 are appropriate to be hosted in the Theme directory, so that’s not a problem; however, works that incorporate or bundle Apache 2.0 works must use either unversioned GPL, or GPLv3.0 explicitly.

    The most likely occurrence of this issue is with Themes developed using Twitter Bootstrap. When reviewing such Themes, please be sure to check that, if the Theme is licensed under GPL, that the license specifies either unversioned GPL, or GPLv3.0.

    (And if for any reason this interpretation is incorrect, please discuss in the comments.)

    Edit

    Note, by “unversioned” GPL, I am referring to the current version of the GNU GPL, which can be found at this URL, and which currently is GPLv3.

    What is important is the actual license text associated with the Theme: whether called simply “GPL” or explicitly GPLv3, the license text must be GPLv3. A Theme that claims the license is “GPL”, but that ships with a license.txt that is GPLv2 would not be able to bundle an Apache 2.0-licensed work.

     

  • Emil Uzelac 11:33 am on February 28, 2013 Permalink | Log in to leave a Comment  

    Things you don’t like or would like to improve or change? 

    This is so called anything goes here discussion

    We would like to know: what is it that you as an author don’t like or really want to change around Theme Review and our entire process?

    (no personal agendas please, we do see quite enough of that around here lately)

     

    • unsalkorkmaz 11:48 am on February 28, 2013 Permalink | Log in to Reply

      Waiting.. Waiting is too long. I sent a theme for review and waited 3+ weeks. Theme got denied because of 1-2 little things that can easily fix in 1 hour… Even you fix it, you need to wait another 3+ weeks for second review.
      At least there should be a chance to fix quick like in 12 hours ? I mean give theme author 12-24 hours before decline theme?

      • Chip Bennett 6:34 pm on February 28, 2013 Permalink | Log in to Reply

        Theme got denied because of 1-2 little things that can easily fix in 1 hour…

        But if they were such simple things, why were they not fixed before submission, or during the three-week waiting period?

        One thing that the Admins are adamant about is that Theme Reviewers not be used as “quality control”. The vast majority of the time, simple things that obviously don’t conform to the Guidelines are indicative of a developer not doing due diligence before submission. So, that’s why we no longer require full reviews before closing a ticket.

        Is it possible to overlook things? Sure. But as you’ve seen, the turnaround time for a review is already long enough as it is, and having to weed through the crap submissions just to find the Themes submitted by developers who honestly have made a good-faith effort to conform to the Guidelines is often like trying to find a needle in a haystack.

        At least there should be a chance to fix quick like in 12 hours ? I mean give theme author 12-24 hours before decline theme?

        Allowing a grace period to fix and resubmit is an option entirely at the discretion of the Theme Reviewer. At this point, I don’t think it’s beneficial to *require* Theme Reviewers to provide a grace period, because it would get abused.

        But if you’re able to address issues quickly, and re-submit, it never hurts to comment in the original ticket, indicating that all issues have been addressed, and linking to the new ticket.

        • Paul 7:30 pm on February 28, 2013 Permalink | Log in to Reply

          yes, I did that when I submitted my last theme. There were only a few minor issues that I was able to fix straight away.

    • Paul 12:10 pm on February 28, 2013 Permalink | Log in to Reply

      Well, if anything goes, then I don’t like the email list for communication. I’d prefer forums.
      Another thing: when you submit a theme for review, there’s a period of waiting. If you upload a new version in the meantime, there’s no easy way to manage that.
      An idea: how about a multiple choice quiz about the Theme development guidelines that any person submitting a theme should take. Like a test for being able to upload a theme for the first time.

      • Srikanth 12:24 pm on February 28, 2013 Permalink | Log in to Reply

        I suggested that once, it was shot down :)

      • SriniG 2:12 pm on February 28, 2013 Permalink | Log in to Reply

        Quiz or no quiz, I think there should be more information in the theme upload page than there currently is. Specifically, information that there could be a waiting time, probably a link to the themes trac and that newer versions of the same theme should be uploaded via the extend/themes/upload/ page rather than as attachments to the ticket to the first version, things like that. I see many new submitters getting confused on these points. Just a little information on the process followed can be helpful. Also emphasize the point that themes that don’t meet up with the requirements in the theme review page are subject to disapproval.

        Another thing: when you submit a theme for review, there’s a period of waiting. If you upload a new version in the meantime, there’s no easy way to manage that.

        I don’t think there is any difficulty in managing that. Simply upload a new version and provide a link to the new ticket in the original ticket. But as I said above, it helps let the new submitters know about these processes and methods.

        • Mahesh 5:11 am on April 9, 2013 Permalink | Log in to Reply

          I agree with the “more information in the theme upload page”. As of now there isn’t much transparency for them to make an estimate of how much time it would take for the approval.

      • Chip Bennett 6:10 pm on February 28, 2013 Permalink | Log in to Reply

        Can’t the Trac ticket, with comments, be used for that purpose? Note that any reviewer can comment/provide input/feedback on any ticket.

      • ryanve 6:42 pm on February 28, 2013 Permalink | Log in to Reply

        @Paul Agreed. A forum would be better searchable in Google and more in the vein of opensource. IMO using Github issues would be ideal. I’d love to see WP ditch the trac and use Github (https://github.com/WordPress/WordPress) to greater effect.

        • Chip Bennett 6:57 pm on February 28, 2013 Permalink | Log in to Reply

          A mail-list isn’t ideal for everything, but it is useful for some things. For as much as is feasible, we’re doing our best to move toward most of the communication happening here on the Make/Themes site.

          • toscho 9:32 pm on March 1, 2013 Permalink | Log in to Reply

            The mailing list suffers from full quotes. These create many duplicates and make search unnecessary hard.
            The Make-sites are too restricted. Very few people can open a new thread here.

            Something more community-friendly would be nice.

        • Paul 7:32 pm on February 28, 2013 Permalink | Log in to Reply

          yes, it would be nice to have a pre-screening on Github! I like that idea. then once it’s ready, submit it to trac

    • Greg Priday 12:25 pm on February 28, 2013 Permalink | Log in to Reply

      Some things I’d really like to see:

      == A Vote Based Review System ==

      I’d like to move over to a system where each theme submission becomes a community discussion. This would allow anyone to point out issues, offer help and ultimately vote for or against inclusion in the directory. P2 would be a great platform for this.

      Benefits:

      Allows anyone to start checking new themes without committing to a full review.
      More public theme review process would help educate reviewers and developers.
      Faster feedback for developers. Waiting 1 month for each round of feedback can be frustrating.

      == More Automated Tests ==

      Theme-Check is great, but we could do with a few more automated tests. I’ve extended theme-check to include a whole bunch of extra tests. They aren’t perfect, but they’re a massive help. I used these tests to review ~60 themes on trac last week.

      I think as a community we could automate 90% of the theme review guidelines. We could even include the unit tests with a little help from PhantomJS.

      • Paul 12:48 pm on February 28, 2013 Permalink | Log in to Reply

        maybe you should work together with Mario, he has a theme mentor plugin that adds extra checks

        • Chip Bennett 6:28 pm on February 28, 2013 Permalink | Log in to Reply

          My preference would be for any Theme-Check extension to be pushed back upstream into Theme-Check itself. Theme Mentor is great, but the more we can do with fewer Plugins for Reviewers to install, the better.

          • nofearinc 5:23 pm on March 1, 2013 Permalink | Log in to Reply

            (wrong account switched above by mistake with the reply below)
            Chip, I replied back to your comment in my blog as for the reasons I would keep the Theme Mentor separate. It’s an open discussion, though I still believe these cover two different aspects of the review process.

            • Chip Bennett 7:34 pm on March 1, 2013 Permalink

              No problems there; but anything that is developed using Theme-Check’s designed extensibility would be most logical pushed directly upstream to Theme-Check, rather than being ported to a separate Plugin, IMHO.

      • nofearinc 2:02 pm on February 28, 2013 Permalink | Log in to Reply

        I’m slowly working on the Theme Mentor as Paul mentioned above, it’s purpose is exactly pointing tests based on existing reviews with about 70% success rate (better to have ‘see this’ without guaranty instead of missing details while reviewing code).
        The project is also on GitHub and collaborations are welcome.

      • Chip Bennett 6:25 pm on February 28, 2013 Permalink | Log in to Reply

        Vote-based system:

        Implementing a vote-based system would bring things to a grinding halt.

        Currently, community discussion is entirely possible – right in the Theme-Trac ticket generated for the submitted Theme. That process is entirely public, because anyone can read the tickets, and anyone with a WPORG username can comment on the tickets.

        More people doing piecemeal reviews would introduce further delays, and would result in more issues falling through the cracks, because there’s no guarantee that they were ever checked.

        More automated checks:

        Patches welcome. :)

        If you have extended Theme-Check, please push those improvements back upstream. It was written the way it was specifically with this purpose in mind.

        Ideas for further automating or otherwise facilitating the Review process are always welcome.

        • Greg Priday 8:07 pm on February 28, 2013 Permalink | Log in to Reply

          Yeah, I think I have a fairly idealised view of how voting system would work. Alos, getting it right would also probably take a lot more effort than it’d be worth.

          I’ll put some work into my theme checks and try submit a few patches.

    • konradS 1:38 pm on February 28, 2013 Permalink | Log in to Reply

      It should be possible to have several persons working on themes!

      • christine 5:17 pm on February 28, 2013 Permalink | Log in to Reply

        That might get a bit confusing.

        Instead, I would love to work on abandoned themes. If the dev hasn’t updated the theme in more than 2 years, then I would love the ability to adopt it and resurrect it.

    • Stephen 2:36 pm on February 28, 2013 Permalink | Log in to Reply

      As an theme author, I would like to see same and consistent treatment regarding review guidelines. My theme was asked to remove Author URI as it against the policy – personal site or development site. I removed it in the latest release.
      But this is still bother me as why many themes can have the companies as Author URI. Technically their Author URI is the URI for their Premium or PRO themes, not the URI for Lite theme in repo.
      I am not here to question their business model. The key point is same treatment.

      As a theme reviewer, I would like to see repo promotes Open Source not just GPL. I think the repo is slowly (or has ) become a marketplace.

      • christine 5:16 pm on February 28, 2013 Permalink | Log in to Reply

        I think that Stephen has a point. I’ve been asked to removed things from themes when previous themes were fine. I understand that reviewers are human and make mistake, but perhaps having a thorough list of review items and final score would be a good idea.

        Say, there are 100 things that need checked, when you have your final review, you can see the full list with comments to go along it.

      • Chip Bennett 6:17 pm on February 28, 2013 Permalink | Log in to Reply

        Your point about consistent reviews is certainly valid. That’s why the Guidelines read as rigidly as they do – so that they can be as objective as possible, in the hopes of ensuring the most consistent and least subjective review possible.

        But reviewers are human, and are all volunteers. If you disagree with a review comment, there are recourses (discuss in-ticket, escalate to theme-reviewers mail-list, etc.).

        As for your specific issue: it was discussed in-ticket, and on the mail-list, and the reviewer made the correct decision. Author URI is reserved for the *personal/development* site of an individual developer who submits a Theme, or the Theme shop landing page for a Theme shop that submits a Theme.

        Author URI should not be used for an up-sell page. Nor should the Theme URI be used for an upsell Theme promotion, for that matter.

        Handling of credit URLs is one of the most difficult aspects of Theme review, both because of the inherently subjective nature of the criteria, and because credit links are the single most-likely aspect of a Theme to be intended for abuse.

        • Stephen 8:01 pm on February 28, 2013 Permalink | Log in to Reply

          My case was closed. I believe it is correct according to the guidelines. Can I implement it this way?
          IBM, you are a consulting form, not a theme shop. Therefore, you cannot be the author of GPL-Licensed theme.

    • Satish Gandham 4:14 pm on February 28, 2013 Permalink | Log in to Reply

      Selection of featured themes should be transparent. It should be based on communities choice rather than one single person making the call.

      Featured themes section should be updated regularly and frequently to give a fair chance to all the themes and developers.

      • christine 5:14 pm on February 28, 2013 Permalink | Log in to Reply

        I agree with Satish, the featured themes on wordpress.org is pretty poor. In fact much of the theme section on the wp.org site is poor and there was discussion of this at the community summit. WP.com has a great way to feature it’s theme which is way more visual stunning.

        Having said that, this has nothing to do with theme review, so it’s probably best to continue this discussion at another time.

      • Chip Bennett 6:19 pm on February 28, 2013 Permalink | Log in to Reply

        We’re going to have a discussion on this. It is a lower priority at the moment, but we’ll get to it.

    • ryanve 6:50 pm on February 28, 2013 Permalink | Log in to Reply

      The prescreen is too strict. I think that the only required functions should be the hooks: wp_head() and wp_footer(). There are valid reasons that someone would want to avoid direct use of echoing functions like body_class(). These would be better as warnings rather than fails. Related: http://core.trac.wordpress.org/ticket/23537

      • Chip Bennett 6:55 pm on February 28, 2013 Permalink | Log in to Reply

        What are the “valid reasons” not to require body_class(), post_class(), comment_class() (via comment_form()), etc.?

    • Justin Tadlock 12:16 am on March 1, 2013 Permalink | Log in to Reply

      Frankly, the nit-picking of every little item and spending days arguing over them is tiring. It feels like we spend more time debating inconsequential things than reviewing. It’s a big turn-off from the review team.

      For example, the theme name guideline we just discussed the other day. That should’ve been resolved by just using a little common sense. I see no reason why it warranted a major discussion in the mailing list.

      • Emil Uzelac 12:54 am on March 1, 2013 Permalink | Log in to Reply

        Human nature is to agree and disagree and that’s something we need to live with. Once this discussion is over we will gather your thoughts and act upon them accordingly and hopefully few things will change.

        Discussions are good and never a turn-off :)

        So far this is what we hear:

        Wait Time
        Forum -vs List for Communication – (I am in favor of this and something we talked with all Team Reps last month)
        More Consistent Reviews

        Featured Themes should be on the list, but I do agree with Chip that this is not priority. And just to note that one person does not make this call, it’s between all of us here.

        • Justin Tadlock 2:07 am on March 1, 2013 Permalink | Log in to Reply

          I’ve got nothing against discussions and didn’t claim that they were a turn-off.

          It’s just tiring to see some of the seemingly endless debates about things that are of little consequence when it comes to whether a theme works or does not work.

          Anyway, I’m just answering the question.

      • Daniel 2:47 am on March 1, 2013 Permalink | Log in to Reply

        Another example is branding/demo content, some common sense should have been used there as well.

    • Daniel 2:45 am on March 1, 2013 Permalink | Log in to Reply

      One thing that I would like to see if a checklist of things to check before uploading in a format where we can print then out.

      Maybe it just me but I sometime find it easer to have a checklist on paper than trying to have both theme and checklist up on screen at the same time.

    • Jason Hoffmann 7:13 pm on March 1, 2013 Permalink | Log in to Reply

      I’d just like to echo what christine said. If a theme hasn’t been updated in over 2 years, it would be great if there was a way to update or adopt it. Since it’s all GPL, as long as attribution remains with the new author and the old author that should be something that’s possible right?

      Other then that, improving findability should perhaps be a bigger priority, as well as getting rid of very old themes.

  • Chip Bennett 9:31 pm on February 26, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Who’s up for a push to clear out the queue?

    We’ll call it the “end of February” push, but we can use the weekend, too.

    There are almost 150 tickets awaiting review.

    We have about 90 people with close-ticket privileges.

    That’s less than one and a half tickets per reviewer, by the end of the weekend.

    Who will commit to reviewing 1-2 tickets between now and Sunday?

     

  • Chip Bennett 2:48 pm on February 26, 2013 Permalink | Log in to leave a Comment
    Tags: , Theme Name   

    Clarifying Guidelines for Theme Name 

    The current guidelines for Theme Name are as follows:

    • Themes are not to use WordPress in their name. For example My WordPress Theme, WordPress AwesomeSauce, andAwesomeSauce for WordPress would not be accepted. After all, this is the WordPress Theme repository.
      • Themes are not to use the term Theme in their name, such as: AwesomeSauce Theme. Same reason as above … it’s a Themerepository.
      • Themes may use the WP acronym in the Theme name, such as WP AwesomeSauce.
    • Themes are not to use version-specific, markup-related terms (e.g. HTML5, CSS3, etc.) in their name.
    • Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, etc.) in their name.
    • Themes are not to use Theme author/developer credit text in their name. For example AwesomeSauce by John Q. Developer(makes for a much better credit link); or, SEO/SPAM-seeded text, such as: AwesomeSauce by Awesome Free WP Themes (this is just not going to pass).
    • Themes are not to use related Theme names (e.g. WP Twenty Eleven, Twenty Eleven WP, The Twenty Eleven, etc.) in their name.

    In light of recent discussions, I think this would be a good time to clarify these guidelines. Please discuss below if you have any comments, questions, or feedback related to the Theme Name guidelines.

    WordPress

    The requirement not to use the term WordPress in a Theme Name should be obvious; all Themes hosted in the directory are WordPress Themes.

    Generic Terms

    The following Guidelines relate to the use of generic terms:

    • Themes are not to use version-specific, markup-related terms (e.g. HTML5, CSS3, etc.) in their name.
    • Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, etc.) in their name.

    These are the guidelines that I think are the least articulate, and need clarification.

    The intent is to avoid generic terms related to design elements, features/functionality, or intended use of the Theme. Whether that’s markup (HTML5, CSS3), design (responsiveness), features/functionality (photo galleries, jQuery masonry), or intended use (“Tumblogging”, real estate, business), terms related to these aspects are better left to the Theme description and, where applicable, filter tag keywords.

    The purpose of a Theme name is to ascribe an identity to the Theme through the uniqueness of that name.  It is perfectly fine to invoke design elements or intended use of the Theme through the Theme Name, but it should be done using a creative/unique term, rather than a generic term. The intent of the related Guidelines here is to emphasize this point, and to help avoid naming conflicts and disagreements that arise from the use of generic terms.

    Developer name

    As with the WordPress term, I think this one is self-explanatory.

    Reserved Core Theme Names

    The WordPress Core team has chosen a naming convention to use for the annually updated Theme distributed with core. Thus, it makes sense to ensure that this naming convention is reserved for core.

     

    • Rob van Linda 2:58 pm on February 26, 2013 Permalink | Log in to Reply

      Hello there,

      I normally work with Joomla but started to play with WordPress about a week ago (http://robvanlinda.de and http://wp.webdesign-labor.de) and I don’t understand why I shouldn’t put my name or terms like “responsive” in my theme name?

      Isn’t it entirely up to me to choose the name? It is my creation and I do what I want with it, right? As long as I don’t do something illegal I will do exactly what I want to do and even will mention WordPress in the description.

      Best regards,

      Rob

      • Chip Bennett 3:06 pm on February 26, 2013 Permalink | Log in to Reply

        Isn’t it entirely up to me to choose the name? It is my creation and I do what I want with it, right? As long as I don’t do something illegal I will do exactly what I want to do…

        Of course it is, and of course you may.

        But that doesn’t mean that said Theme will be approved to be hosted in the official WordPress Theme directory. Regardless of what you do with your own creation via your own distribution medium, for the official Theme directory, we need to, can, will, and do define and enforce guidelines regarding those Themes. Among those guidelines are the ones being discussed here: Theme Name. We don’t want the official Theme directory to be a magnet for marketing efforts, and we want to avoid conflicts/clashes over terms used in Theme names. So, we do need to have reasonable guidelines in place along those lines.

        • Srikanth 3:19 pm on February 26, 2013 Permalink | Log in to Reply

          I recently submitted a theme called “xyzthemeshop_business” somehow missing this no developer name rule. credit text is xyzthemeshop.com
          So will it be allowed?

          • Chip Bennett 4:56 pm on February 26, 2013 Permalink | Log in to Reply

            “xyzthemeshop_business”? No, I wouldn’t think so.

            A more acceptable construct might be “XYZ Business.” (But does that really sound like a great way to identify your Theme uniquely?)

            • Srikanth 5:14 pm on February 26, 2013 Permalink

              I was thinking XYZ_Business will be unique name since no one will get to use the XYZ. Something along the lines of Domino’s Pizza, CiCi’s Pizza etc.

    • Paul 3:01 pm on February 26, 2013 Permalink | Log in to Reply

      I think the last paragraph is pretty clear. The theme name should not be like a search engine keyword phrase that would make sense. Like “WPAjaxTheme”. But rather “Ajaxio” or something like that.
      “QueryPosts” would be rejected but not “QyPosts”. Be creative.

    • stuartwider 10:39 am on March 1, 2013 Permalink | Log in to Reply

      Hi Chip,

      Just for clarification for myself (and possibly others who are reading this) could you tell me which of the following names would pass or fail if they came to you in a theme review?

      Here’s the scenario…

      Imaginary theme shop ‘JollyMax Themes’ submits a ‘responsive’ theme to the directory and comes up with the following possible two word names…

      Jolly Responsive
      Jolly Respond
      Jolly Response
      Jolly Responsivo

      and single term names…

      Respond
      Response
      Responsivo

      Note I do not intend using any of these names at any time – these are just examples for clarification of the gray areas.

      • Chip Bennett 2:42 pm on March 1, 2013 Permalink | Log in to Reply

        I would say that, based on the clarified intent of the Guidelines, that none of them would be acceptable. However, since we already allowed a Theme named “Responsive”, then fairness would dictate that the term “responsive” is now fair-game for other Theme names.

        So, replace “responsive” with any other term that falls under “design elements, features/functionality, or intended use” and I would say none would be approved. But because we’ve set a precedent with the term “responsive” itself, we must be fair to all developers, and allow that term’s use in Theme names.

        • stuartwider 7:36 pm on March 1, 2013 Permalink | Log in to Reply

          I haven’t really been watching the development of theme guidelines up until recently but it seems to me that the clarification above of “Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, etc.) in their name” is actually stepping beyond its original intent, which I would guess was originally just there to prevent themes from stating the obvious in a name.

          I’m not sure the original guideline intent would have been to prevent theme authors from indicating design or features using generic terms such as responsive either. (The actual term ‘Generic terms’ is not mentioned anywhere in the existing guidelines as far as I can see).

          It appears to me that the clarification might be actually be a reinterpretation or retrofitting based on current discussions on the theme reviewers list, but not the intent of the guideline when it was originally created.

          If there is a consensus in the theme review community now to only allow original and creative names that do not use common words, generic terms or terms related to design or use, then the guidelines needs to be changed.

          I’m not convinced yet though from watching the theme reviewers list that there is the consensus on this issue, or that the existing guidelines need to be changed. I just think that the original intent of the guidelines need honored.

          My own view is that terms that indicate intended use and design are useful for theme users and should be fine in names, and that to prevent their use would be restrictive.

          I would say that as long as the intended use and design terms don’t cause confusion with a theme that is already in the repository, and dont hog an entire generic namespace then they should be allowed to be used.

          • stuartwider 8:10 pm on March 1, 2013 Permalink | Log in to Reply

            Further thoughts…

            Rather than reinterpreting the guidelines to be more restrictive with words (which will end up being a very long ever expanding and subjective list, and a stick for everyone to hit themselves and others with), maybe, think in terms of useful guidelines for namespacing and how names can be constructed as to be unique within the repository.

            I’d say its more desirable to encourage useful unique names for themes, rather than worrying about which specific generic or common usage words might be used in them.

            • Chip Bennett 9:14 pm on March 1, 2013 Permalink

              I would be fine with simply saying, “First come, first served” on all names/namespaces, and if someone chooses a “generic” term, we won’t field objections to other Themes that use that same term, as long as the overall Theme name is different. (With some common sense, of course: “Foobar” and “WP Foobar” are, for all intents and purposes, the same name.)

    • stuartwider 9:36 pm on March 1, 2013 Permalink | Log in to Reply

      Chip,
      First come first served sounds reasonable,
      as does no objection to themes using the same generic terms as long as its different overall.

      If a ‘first come first served on generic terms / different name overall’ guideline were put in place then everyone would know before right from the outset that if they use a generic term for their name then others may use that term also in their names. It makes it a level playing field, and everyone knows from the outset so theres nothing for anyone to get upset about in the future. It also resolves the ‘Responsive’ name question neatly.

  • Chip Bennett 3:08 pm on February 24, 2013 Permalink | Log in to leave a Comment
    Tags: coming-soon   

    Coming-Soon Themes 

    Another topic for discussion: Coming Soon Themes.

    Should the Theme Directory host “Coming Soon” Themes? If so, how should we handle them? By design, Coming Soon Themes would omit some functionality (e.g. comments) that would get flagged/blocked by the uploader script, and by design such Themes would obviously not pass the Theme Unit Tests. And what would be the requirements for such a Theme?

    One suggestion for handling uploads/reviews: rather than having to whitelist Coming Soon Themes in the uploader, perhaps we could add a new tag, e.g. “coming-soon” (or whatever), that the uploader script could check for, and that the Theme Reviewer would note during the review.

    What are your thoughts?

     

    • Srikanth 3:14 pm on February 24, 2013 Permalink | Log in to Reply

      I think a little variety would be nice. Those themes can have the usual blogness and add this as a layout option. Standard layout, Coming soon layout etc.

      • Chip Bennett 3:18 pm on February 24, 2013 Permalink | Log in to Reply

        Sure, any Theme can add a “Coming Soon” or “Landing” custom page template. This question is more specifically: whether the Directory should host Themes that are *only* a “Coming Soon” or “Landing” page.

        • Srikanth 3:37 pm on February 24, 2013 Permalink | Log in to Reply

          In my opinion directory should host all types of themes, as Abhik said WordPress is not confined to just blogging.

          New tag idea should work, uploader script can perform checks required for that tag and skip the other checks.

    • Dane Morgan 3:39 pm on February 24, 2013 Permalink | Log in to Reply

      I would tend to say no. That is more appropriately a plugin function. No matter what purpose you are using WordPress for, setting a coming soon, maintenance mode or what have you as a theme rather than a function blurs the line and confuses the issue.

    • Greg Priday 3:50 pm on February 24, 2013 Permalink | Log in to Reply

      It would be nice if themes had a way of saying they don’t support posts and/or comments. This would open the directory up to all kinds of speciality themes without us needing to specially consider each case.

      I’m still building blog functionality into my business themes even though the majority of my business theme users aren’t using the blog functionality.

      • Justin Tadlock 5:14 pm on February 24, 2013 Permalink | Log in to Reply

        That’s something that should really be addressed in core first. We’re talking about completely disabling expected, default functionality. With the way it’s currently coded in core, this is plugin territory.

        Now, if WP core comes along and adds the ability for themes to support/not support posts/pages, it’s definitely something we should consider. I could see that happening. Comments are a different thing because they’re based on the specific post type, so I don’t ever see a theme being allowed to not support comments.

        • Greg Priday 6:38 pm on February 24, 2013 Permalink | Log in to Reply

          I just mean using a tag in the stylesheet that informs users, theme reviewers and the theme-check plugin that posts and comments aren’t supported. Coming Soon themes, for example, essentially ignore requests to single posts URIs and render the home page. So they’d get the no-posts-support tag.

          Using these, rather than a coming-soon tag, would allow other speciality themes to easily make their way into the directory. Think about.me style themes, social feed themes, etc. Why limit speciality themes to the ones we can think of?

          The other option is to put the onus on the theme developer to interpret posts and handle them accordingly. Coming soon themes might interpret posts as status updates and have a very simple single post view.

          +1 for speciality themes in the directory

          • Justin Tadlock 9:26 pm on February 24, 2013 Permalink | Log in to Reply

            A coming soon theme technically does support posts. It’s merely a way to hide the display of them from visitors until the site launches. Anyone using a coming soon theme better be able to actually preview their posts. Otherwise, I’d argue the theme is doing it wrong. I’d wager that most people who want to use a coming soon theme are actually building a site that’s coming soon. If they can’t write posts and preview them, then I’d say that’s a major problem.

            ^ That’s probably a good argument for coming soon themes to actually be plugins.

            We’re also not limiting specialty themes. We’ve always said that we’d take specialty themes on a case-by-case basis. If a new scenario arises, we’ll address that scenario when it comes.

            A “no-posts-support” tag is not something we should be dealing with right now. WP core doesn’t support this theme feature, so the theme review team shouldn’t do it either. If/when core allows this, we’ll cross that bridge then.

            • Greg Priday 10:29 pm on February 24, 2013 Permalink

              If a coming soon theme displayed posts and comments, then it wouldn’t need special treatment in a theme review. We could approve it. The problem is that most coming soon templates don’t support these. LaunchPad for example had a fairly static index.php without a single reference to the_post(), so previewing posts won’t work. The same was true for a couple coming soon themes I reviewed this weekend.

              I guess this topic really boils down to “should WP.org list themes that don’t display posts and comments.”

            • Justin Tadlock 11:06 pm on February 24, 2013 Permalink

              If a coming soon theme displayed posts and comments, then it wouldn’t need special treatment in a theme review.

              Yes, it still would. There are numerous other requirements that a coming soon theme wouldn’t need to do that a normal theme would.

              I guess this topic really boils down to “should WP.org list themes that don’t display posts and comments.”

              As I mentioned before, posts and comments are two different beasts. Nevertheless, that’s not what this discussion boils down to. We’re specifically talking about coming soon themes. If you have any specific, special use cases, you should bring them up with the rest of the theme review team. We can decide on those on a case-by-case basis.

    • Justin Tadlock 5:05 pm on February 24, 2013 Permalink | Log in to Reply

      The repository currently has one coming soon theme that I know of: http://wordpress.org/extend/themes/launchpad I’m just throwing that info out there.

      To answer the question, yes, Coming Soon themes should be allowed. And, +1 on adding a tag specifically for this use case so that we don’t have to whitelist individual themes.

    • @mercime 5:28 pm on February 24, 2013 Permalink | Log in to Reply

      +1 Allow specialty themes in the WP Theme Repo.
      +1 tag them

      In addition to tags, so as not to confuse the users who search for themes via wp-admin and presented with results, I suggest adding short phrases at the beginning of the specialty theme’s description. For example:

      -> Coming soon themes:
      Coming soon theme. And then the rest of the description

      -> One page themes:
      One page theme. And then the rest of the description

      -> Child themes:
      Child theme of Twenty Twelve. And then the rest of the description

      etc.

    • Edward Caissie 5:51 pm on February 24, 2013 Permalink | Log in to Reply

      “Coming Soon” themes are very niche in their application … there are several plugins that can manage this just as easily with the exception they generally do not provide the decorative features a theme would offer.

      I am not against having “Coming Soon” themes in the repository but even if they have zero use for a particular functionality it is still quite easy to implement the absolute minimum functionality all the same. For the most part, making exceptions (to the nth degree) for theme functionality being included in “Coming Soon” themes essentially would allow a simple HTML only page to be considered. We are already trying to avoid too many slippery slopes.

      If we were seeing a plethora of “Coming Soon” themes being submitted to the repository then perhaps a new tag would be warranted but as I see things, it would be more useful for a theme to support a “Coming Soon” template page which would ultimately provide the same look and feel of the finished product … and that may warrant a new “feature” tag which I would support.

    • John Turner 7:59 pm on February 24, 2013 Permalink | Log in to Reply

      As the author of one of the more popular coming soon plugin in the repo, Ultimate Coming Soon Page http://wordpress.org/extend/plugins/ultimate-coming-soon-page/

      The main use case or purpose of having a coming soon page is so you can work on your main site while you display a coming soon page to non logged in visitors. As a plugin this is possible. Once you launch it as a theme then you lose the ability to work on your main site.

      So implementing it as a theme does not make sense to me, but if they are ultimately allowed then I think you have to start allowing all niche themes.

    • Paul Appleyard 5:49 am on February 25, 2013 Permalink | Log in to Reply

      I say: No.
      This kind of functionality really needs to be implemented either as a plugin, or even as a static front page implementing other plugin functionality.

    • Devin Price 5:50 am on February 25, 2013 Permalink | Log in to Reply

      I think this particular feature is handled much better via a plugin than a theme. There’s several that have well designed “Coming Soon” pages, like: http://wordpress.org/extend/plugins/wp-maintenance-mode

      • Paul 11:30 am on February 25, 2013 Permalink | Log in to Reply

        I agree completely.

        • Frank Klein 4:20 pm on February 25, 2013 Permalink | Log in to Reply

          I agree with the points above.

          So if the only thing that the theme does is display the coming soon page, then it should be a plugin.

          If a theme contains a special template for the coming soon page bundled with a complete theme (on which the admin can work), then it should be allowed.

    • Jose Castaneda 4:28 pm on February 25, 2013 Permalink | Log in to Reply

      +1 for coming-soon tag. We have front-page,so why not coming-soon? The theme would of course still have to pass the tests since it is a theme otherwise it would have to fall under the category of plugin.

    • Justin Tadlock 4:43 am on February 26, 2013 Permalink | Log in to Reply

      After giving this a few more days thought, I’m not entirely sure coming-soon themes should really be themes. The purpose of this type of theme would be to serve as a placeholder while you get your content ready for launch. However, it seems that many of the themes I see like this provide no way for allowing the user to view their content privately. Moreover, if a theme actually did allow the viewing of this content, it’d need to style that content. So, the point of a coming soon themes starts to become pretty useless.

      Now, a coming soon template or option makes a lot of sense. It allows the user to see their site in action but shows the coming soon page to visitors.

      So, I’m thinking a coming soon theme would be better as a plugin. Also, a plugin that would integrate with a special theme template would be straight up awesome.

  • Chip Bennett 12:51 pm on February 19, 2013 Permalink | Log in to leave a Comment
    Tags: , Theme Branding   

    Theme Branding/White-Labeling Guidelines 

    Recently some questions have come up on the mail-list that I think warrant extended discussion here. Those questions essentially revolve around Theme branding vs. “white labeling”: should footer credit links be required to be user-configurable (i.e. disabled) via Theme option? Should Themes include “branded” default logos or demonstration content, such as slider content, Twitter feeds, etc.?

    Rather than making decisions (or creating new Guidelines) on the fly, let’s discuss those questions, and the issue of branding vs. “white labeling” as a whole, here. What I would envision coming out of this discussion would be a clarification of the Guidelines, to indicate more clearly what we’re currently requiring/enforcing, under a “Theme Branding” heading (or similar) that would envelop the existing “Credit Links” requirements.

    For example: logos. Some Themes add a “logo” Theme option, but set the default as a text-as-image Theme Name “logo”. This is obvious branding, and obviously an instance where the user would rather have the Theme default to displaying the user’s configured Site Title, rather than a Theme-branded text-as-image “logo”. But a different developer may want to display a generic/arbitrary logo by default, to demonstrate the Theme’s custom logo feature. So: we should discuss where/how we want to draw the line of appropriateness.

    In a discussion such as this one, my default position is: with all else equal, which decision is in the best interest of the end user? But it is equally important to consider the needs and interests of developers, as well. Guidelines should not be onerous or unreasonable for developers. I would contend that, when initially activating a Theme – whether on a new site or a site with established content – an end user will not want then to have to go through the Theme to “disable” the demo/branding content. So, I think it is reasonable to require that all default/demo imagery be generic/non-branded/”white-labeled”.

    To take a counter example: footer credit links. Should developers be required to make footer credit links user-configurable (i.e. able to be disabled) via Theme option? I don’t think so. We put enough requirements around the form/display of footer credit links to ensure that they are appropriate, that I think requiring them to be user-configurable via Theme option crosses the line into being too onerous. (Consider all the Themes that have no Theme options; should we force developers of those Themes to incorporate all the overhead of Theme options, just for footer credit links?) What might be more reasonable, however, would to to recommend that footer credit links be user-configurable, via Theme option, custom filter, template-part file, etc.

    Feel free to discuss from both high and low levels: from principle to guideline. But, please try to avoid the, “but Theme X does this” type of arguments. That we are discussing the need to clarify the Guidelines implies that existing Guidelines have been interpreted differently, resulting in different review comments for different Themes. Our aim here is to find consensus regarding the correct approach to handling these issues, regardless of how these issues have been handled consistently or inconsistently in the past.

     

    • Srikanth 1:01 pm on February 19, 2013 Permalink | Log in to Reply

      My opinion is that theme user should not have to go and disable even the generic logo, Themes should display site name as default.

      • Chip Bennett 1:06 pm on February 19, 2013 Permalink | Log in to Reply

        Keep in mind that we try to give as much deference as feasible to the developer’s Theme design aesthetic. That “generic logo” could reasonably be a part of that design aesthetic. I could see it being reasonable at least to recommend that Themes display Site Title by default, rather than a generic default logo.

        • John Saddington 2:10 pm on February 19, 2013 Permalink | Log in to Reply

          i love that you’re considering how much the “generic” may play a part of the overall design layer – that’s really thinking critically and openly about the variety of use-cases. I like this.

          But this “humble submission” and deference gives a lot of flexibility which is going to be hard to use for any development of a concise and explicit guideline and/or policy. Just top-of-the-head thoughts here.

          • Chip Bennett 2:24 pm on February 19, 2013 Permalink | Log in to Reply

            If anyone bangs the explicit, objective requirements drum, it’s me. :) But those who say that we cannot make the guidelines so rigid that Themes become cookie-cutter have a valid point. A Theme could be designed to incorporate both a logo and Site Title simultaneously, or a Theme could be designed to incorporate both, but not simultaneously, or a theme could be designed to incorporate only a logo, or a Theme could be designed to incorporate only a Site Title.

            I’m not convinced that we should require developers to use any one of those alternatives, to the exclusion of any of the others.

    • Srikanth 1:24 pm on February 19, 2013 Permalink | Log in to Reply

      Okay, site title as recommended and generic logo if they must have a default logo.

      Theme authors can take the user upon activating the theme to a welcome tab of theme options page where they can tell what all awesome features the theme has and explain that they can upload a logo, set a fav icon etc

      • Srikanth 1:37 pm on February 19, 2013 Permalink | Log in to Reply

        Also if a generic logo is set by default, there should be an option to show site title instead of any logo. Not all of them will have a logo :)

        • Chip Bennett 1:41 pm on February 19, 2013 Permalink | Log in to Reply

          I still think that is a bridge too far. We already require that Site Title be incorporated in some manner, and I think it would unnecessarily restrict design aesthetic to require that any custom logo also be able to incorporate Site Title.

          • Srikanth 1:44 pm on February 19, 2013 Permalink | Log in to Reply

            I mean there should be an option to disable logo entirely and choose to have site title

            • Chip Bennett 2:04 pm on February 19, 2013 Permalink

              I know what you mean, but I think that such a requirement would be going too far.

          • Srikanth 2:29 pm on February 19, 2013 Permalink | Log in to Reply

            Okay, lets consider this scenario :

            User installs a theme.
            Theme displays default logo (either generic or brand name).
            User can upload his/her logo and it will replace default logo.

            But if user doesn’t have a logo, what then? will he be forced to use the theme with default logo? forced to change the theme?

            Even if site title is somewhere else on the site, he/she will still be forced to live with default logo?

    • Stephen 2:27 pm on February 19, 2013 Permalink | Log in to Reply

      I am new to this community. Here is my 2 cents.
      1. Logo (generic or not) should be allowed as long as it can easily be removed to replaced (i.e. upload).
      2. Credit link is the credit for theme author. We should not require theme option to remove it. However I believe it should be in template file (i.e. footer.php) not through hooks, functions.
      I am more concerned about repo has become marketing site flooded with lite versions.

    • Zach Russell 2:58 pm on February 19, 2013 Permalink | Log in to Reply

      Chip,
      I completely agree with you the first topic. It really doesn’t make sense to put your own logos/images in with the default theme because 99% of the time, it will be replaced with the site’s logo or text anyway. I think it is kind of a waste of time to put effort into something that will be changed almost immediately.

      From the footer link’s perspective, I am torn. As a developer, I want to have my name on everything I do, and footer links make sense for that. Giving an easy way to filter out credits is also the most user-friendly way to do this, especially through a theme options page. I am also an SEO, and from that perspective, I am kind of torn. By putting links that would be more or less universal across all sites can pose some issues from a “keyword spamming” stance. We all remember when EDUBLOGS got blacklisted by Google for a similar reason, even if they weren’t intentionally spamming. Just some food for thought.

    • Frank Klein 3:28 pm on February 19, 2013 Permalink | Log in to Reply

      Concerning the Credit link, I don’t recommend requiring this to be disabled as an option. If someone doesn’t want the link to display, there are easy ways to remove it (for example some custom CSS via Jetpack).

      Concerning the logo discussion, I think that we should not restrict developers, however when using a custom logo, there should be an option to simply not display a logo at all. This would avoid developers having to change their Themes to work with a title, and it would allow users to get rid of the default logo quickly if they don’t have a custom one available.

      Concerning the other “branded” elements, I’m strongly against any demonstration content that comes bundled with the Theme code. However I recognize that such content is useful to show all the Theme’s features and help users figuring out how the Themes works.

      One possibility might be to point users to XML files with demo content (available for download on the Theme URI website for example). This would allow the users starting a site from scratch to easily import content, while taking into account those users who already have existing content.

    • Bryan Hadaway 3:52 pm on February 19, 2013 Permalink | Log in to Reply

      1. Configurable Footer Credit

      Since most themes do not have theme options to begin with (as I first pointed out in the mailing list) nor should they ever be required to, I think this point is moot.

      The hard-coded theme author credit is a respected staple of free WP themes and users have always been free to remove them as they please under the GPL.

      While, I’m sure we can all agree that we should never obscure or obfuscate the credit link to make it purposefully difficult to remove nor should we hide its removal behind a paywall misleading the user to believe the only way to remove is to upgrade, it is also not our (as theme authors) responsibility nor obligation to educate or provide convenience to users in removing our credits. This crosses the line of what should reasonably be expected from a free theme.

      This is no different than educating them on how to change fonts, colors and other styles, which no free theme author is required to cover such support. Since we’re allowed to hard-code our cred links, themes do not have to have theme options (in fact WP wants us to move away from this anyways) and we’re under no obligation to teach our users how to hack the themes and it would be ridiculous for any of this to ever change, we simply cannot allow this to happen.

      2. Demo Content

      This seems like an easy one. NO HARD-CODED DEMO/PLACEHOLDER CONTENT ALLOWED. NO SPAMMY DEMO/PLACEHOLDER CONTENT ALLOWED.

      However, if it’s merely demonstrating configurable options and does not contain promotional language, URLs etc then it’s fine. Why should it not be branded if relevant to the theme? A theme name in and of itself IS branding.

      I’ve seen the arguments both ways from users, pretty much 50/50:

      1. “How do I get my site to look like the demo?”

      2. “How do I remove the demo content?”

      This is definitely dangerous territory because theme features and methodologies vary drastically here in 2013 between one another.

      So you’re very right in your concern that what’s a good guideline for one theme that would benefit its users might be bad for another theme and its users.

      That’s why I don’t think the discussion should be about whether demo content is allowed or not, or even whether it should be enabled/disabled by default, because this will all vary between themes.

      As long as demo content is not hard-coded, the only additional guideline should be what can the demo content contain.

      Thanks, Bryan

    • Justin Tadlock 5:00 pm on February 19, 2013 Permalink | Log in to Reply

      Configurable footer credit links

      No, to this. We’ll be requiring that themes add theme options, something I’d like to see a lot less of. How footer credit links are done is something that’s been established over many years as a WordPress theme standard. There’s no point in trying to change that.

      Also, if the theme is internationalized, there’s already the gettext hook that allows this to be filtered.

      Default logos, Twitter feeds, etc. (not related to content)

      For header logos, Twitter widget feeds, and things of that nature, I don’t see an issue with branded items. These are user-configurable items that are going to be changed. They just have to be configurable via the admin.

      Branded content-related items

      For things relating to the content such as a slider image or thumbnail, branding shouldn’t be allowed unless it’s configurable via a theme option. A generic image is okay.

      Let’s look at thumbnails as an example. Suppose I added a “Theme Hybrid” branded default thumbnail to display on archive-type pages when a user didn’t set a thumbnail. I’d be potentially advertising my site on 100s or 1,000s of pages on that user’s site. That’s just a bit too far and shouldn’t be allowed. As a theme author, I’d be forcing my users to create specific content, and that’s outside the scope of what a theme should be allowed to do.

    • mercime 7:06 pm on February 19, 2013 Permalink | Log in to Reply

      For reference, this conversation arose from theme author’s post at http://lists.wordpress.org/pipermail/theme-reviewers/2013-February/011836.html

      One of the issues mentioned and in contention is that not of a tasteful text credit link back to the author’s site but that of the theme author’s LOGO at the footer of the theme. Which is why I posted => “User should be able to replace/remove Cyberchimps logo located in the footer. ” at http://themes.trac.wordpress.org/ticket/11163#comment:2

      If the theme author is going to add his/her company logo at the footer of the theme, the user should be able to remove it without going through the ringer.

      Good points made above – User advocacy
      Srikanth – http://make.wordpress.org/themes/2013/02/19/theme-brandingwhite-labeling-guidelines/#comment-29351
      Stephen- http://make.wordpress.org/themes/2013/02/19/theme-brandingwhite-labeling-guidelines/#comment-29350

      • Chip Bennett 7:12 pm on February 19, 2013 Permalink | Log in to Reply

        But the appropriateness or tastefulness of a text link vs a logo link is entirely subjective. Who is to say that a logo isn’t more tasteful/less obtrusive than a text link?

        And why should removing a logo footer credit link be treated any differently from removing a text footer credit link?

        • Bryan Hadaway 10:07 pm on February 19, 2013 Permalink | Log in to Reply

          Exactly, doesn’t make any different how a credit link is implemented as long as it’s not breaking any guidelines or intruding on the theme, making it not function correctly etc.

          In the specific example of CyberChimps, what’s the difference between text that says CyberChimps or a graphic that says CyberChimps? Indeed, purely subjective as to preference. Either way, they’d both need to be removed the same way as with any other theme since the beginning WP themes, manually.

      • mercime 2:14 am on February 20, 2013 Permalink | Log in to Reply

        Theme author’s logo/image is obtrusive i.e., intruding, compared to text credit link in the footer. The issue is not a credit link but using an image as a credit link. There’s a big difference. It’s as simple as that.

        Do you really believe a user wants the image of a monkey or anyone else’s logo in the footer throughout his/her site? No way.

        Another good point by Srikanth below – http://make.wordpress.org/themes/2013/02/19/theme-brandingwhite-labeling-guidelines/#comment-29383

        • Srikanth 3:00 am on February 20, 2013 Permalink | Log in to Reply

          Credit links should be pretty straight forward : “Designed by xyz.com” or “Powered by WordPress & xyz theme”

          WordPress traffic is quite expensive, try buying all the traffic you are getting for free here and it will cost you a lot.

          No need to get greedy and plaster the user’s site with brand logo’s, pretty soon WordPress foundation will come along and say no more up-sell’s. They already have a theme team and they are submitting quite a few themes themselves.

          Lets not give them an opportunity to get rid of us, something is better than nothing :)

          • mercime 3:44 am on February 20, 2013 Permalink | Log in to Reply

            >> pretty soon WordPress foundation will come along and say no more up-sell’s.

            That’s not likely to happen because of logo in footer :-) Careful, someone might take you seriously and lambast you with something or the other, lol.

            I say protect the users from monkeys, leaves, jungles or whatever logo/image-credit-links in the footer.

        • Justin Tadlock 7:24 pm on February 20, 2013 Permalink | Log in to Reply

          I actually think the logo (in this particular instance) looks more professional than a basic text link.

        • Bryan Hadaway 1:32 am on February 21, 2013 Permalink | Log in to Reply

          You’re still only demonstrating subjective points.

          The funny thing is most of the users love that little monkey, I get more requests for “How can I add my CyberChimps affiliate link to the footer logo?” then how they can remove it.

          But, that’s just to rebuttal your subjective point which is irrelevant and so is my response to it.

          You can say that you think an image credit link is uglier than a text credit link, that’s your OPINION. You can’t decide that everyone agrees with that and imply it as factual or objective.

          You’ve already been disproved:

          http://make.wordpress.org/themes/2013/02/19/theme-brandingwhite-labeling-guidelines/#comment-29413

          Perhaps some people like image based credits and hate text based ones? I don’t know, there hasn’t exactly been a study on this, I only know how I feel and you only know how you feel and handful of others here (which we come no where near representing the common WP user mind you).

          In any case, this is really ALL irrelevant.

          This discussion isn’t about image credits, it’s about two separate subjects:

          1. Should users be able to remove credits (regardless of the style of credit) without hacking the theme.

          Which can only mean that authors would now have to build this into themes or WordPress would have to build something into itself and credits would then have to use a WP function.

          All crazy, never going to change.

          2. Should branding be allowed in themes (regardless of where).

          I think the answer to that will remain yes, but the guidelines will be more specific on what are considered appropriate branding images.

    • CyberChimps 9:53 pm on February 19, 2013 Permalink | Log in to Reply

      The two main issues at hand here are:

      Issue 1: Branding demo content, and the ability to put a theme shop / theme name / or logo on default images.

      Many themes including CyberChimps offer feature sliders, portfolios, Twitter feeds, etc. To show these features off on the Preview section on wordpress.org we have to load defaults.

      Example of a default slider image: http://wp-themes.com/wp-content/themes/ifeature/images/branding/slide1.jpg

      The core issue here really is are we allowed to put our brand on default images?

      From a user standpoint branding helps them identify themes by authors or theme shops they trust, it also shows them the potential functionality of theme, and it also indicates to them that they need to replace this content when they use the theme.

      The con is if a user doesn’t change the default images then they will carry over the branding of the default images.

      Personally I believe we should be able to brand our themes as long as it doesn’t contain a link, violate the credit rules or limit the functionality of the theme or mislead users. We should be supporting theme shops and theme authors so they continue to contribute. If we ban branding from .org then we are literally forcing attribution to a single footer link. I’m not sure I see why that’s necessary.

      I believe we should all be able to market and brand our themes as being made by us, and released under the GPL for the greater good. Taking the ability to brand our themes away is a slippery slope that may discourage theme shops from releasing more themes on .org.

      Issue 2: Footer credit links.

      Again I believe we should be able to use logos instead of text, and I do not believe there is any valid or logical purpose for theme authors to provide a theme option to easily disable the credit link.

      Themes are released on .org under the GPL for the greater good, anyone can edit them however they want, including removing the credit link. Are we really going to punish theme authors for using frameworks, hook systems, functions, or other logical programming techniques because you have to edit the core file or hook? These methods don’t exist to be deceptive, they exist because they allow us to organize our code more efficiently. A user can easily remove the hook, or edit the core file if they want to. There is nothing stopping them, so why should we be forced to provide a theme option to do this for them?

      Furthermore, if we do ban branding on .org, and implement this credit removal theme option then we’re really telling theme authors they get no credit for their themes if you release them on .org.

      Given all the issues facing the WordPress community and ThemeForrest right now, we should be opening standards to get more people contributing themes under the GPL and via WordPress.org, not making rules to phase out attribution, and credit.

      • Justin Tadlock 3:14 am on February 20, 2013 Permalink | Log in to Reply

        Any branding within the *content* should be strictly forbidden for the reasons I stated earlier. I’d argue that a post-thumbnail/slider-image is a part of the user’s content and should contain no marketing/branding/advertising material at all (with the exception of a theme option to configure these things).

        I have no issues with branding elsewhere, to a degree anyway. I’m even fine with a tasteful image (subjective, I know) instead of a text link in the footer.

        For your particular theme, Eclipse, this all seems fine to me. The branded images are configurable via theme options, so it’s not something the user is stuck with without having to change their content.

        • memuller 11:14 pm on February 23, 2013 Permalink | Log in to Reply

          In short:
          Keep branding the theme with footer, text-based credits, and allow developers to brand anything else as they see fit and include demo content (branded or not), as long as it’s the user choice to allow this, and this choice can be easily reverted (and remade).

          In both cases, the developer community will survive and deal with this, since for us, it’s a simple rational choice – we either do these thing if they’re worth the trouble, or we won’t. For the user, however, it’s not that easy – an undesired logo or a bad experience with demo content can be harmful regardless of any other factors.

          …now, for some boring stuff:

          About the use of logos and branded content as credits:
          @frank, @justin: mostly agreed.
          @cyberchimps: I think the issue here is that, even if some uses of logo/images as footer credits can be tasteful and valuable, the act, by nature, is obtrusive, since images *are* obtrusive.
          What if the theme offers different colors – will the logo change to match then? What about layout responsiveness? If the user tries to remove the image via CSS, won’t it be easier for him to break the layout?
          To avoid inflating the guidelines and theme review processes with worries about issues like these, I think images as credits on the footer should not be allowed, unless it is presented as an option to the user, and that option is disabled by default. That is, the user can *chose* to user your logo/whatever as a form to give credit.
          That empowers the user, and is a good heuristic for theme developers – if you think adding this theme option is not worth the hassle, then it indeed isn’t.

          About branded and demo content:
          @cais: mostly agreed.
          @brian: agreed, but I would still add that enabling such content should be a user choice. That’s easy to do in a nice way – when first enabling the theme, it can prompt for this choice; there can be a theme option for this, or a dashboard widget for loading specific content parts (eg. loading only the default taxonomies, or a specifit content type). Again, I think its a good heuristic for developers – if your theme is complex enough to use demo content in a useful way, you likely won’t mind the trouble.

      • Frank Klein 6:58 am on February 20, 2013 Permalink | Log in to Reply

        In order for a user to recognize an author or Theme shop by only looking at a logo, you’d have to build up some serious brand recognition first, which you do by branding your themes. So it’s a chicken-and-egg problem.

        I don’t agree with your argument on trust either, the whole point of the Theme review is to ensure that all Themes available on .org are trustful, regardless of the author.

        I’m squarely against the any branded content that comes with the theme. I don’t think that banning branding from .org will discourage Theme shops from releasing Themes on .org, because .org provides them with access to a huge audience to which they can distribute light versions of their themes. If shops release on .org it’s because it makes business sense, not for the greater good.

        As far as the credit logo is concerned, I think that tasteful is difficult to define. But I think starting with a maximum size of this logo is a good starting point.

        • Justin Tadlock 7:18 pm on February 20, 2013 Permalink | Log in to Reply

          A maximum size would be hard to define for a credit logo too. This is something that should fit in with the design of the theme, not some review team’s “standard” logo size.

          A little bit of common sense sometimes goes a long way. Of course, you wouldn’t put a 500px-high logo within a footer with 16px text.

    • stuartwider 10:00 pm on February 19, 2013 Permalink | Log in to Reply

      Footer links:
      I’d say l agree with Justin. As long as its not intentionally obfuscated and hard to remove I don’t think that there needs to be an option specifically to remove it. I dont think it matters either if its a text link or a image link.

      Users themselves have the choice whether they want to use a theme, and if they see a text link or image link at the bottom that they dont like then they have the choice not to use the theme. They have ultimate subjective say over the aesthetics of the theme by voting with their feet… (or download clicks in this case).

      Default Logos, demo content etc
      Sometimes these things are very necessary in order to demonstrate the features of the theme in the theme preview and how the theme works. As long as they easily configurable in the admin and not overtly promotional in nature I see no reason why demo content should not be branded elements. The user will remove them anyway in the theme options (no difference whether the elements are generic or branded) and in doing so learn how the theme works. Using generic elements vs branded elements makes no difference.

      What classifies as generic content vs what is branded content is also subjective anyway, so why add another decision making headache?

      There are already themes on the repo which are good examples of how to do this tastefully, so lets not throw the baby out with the bath water and allow the developers a little credit.

      Theme users are quite robust creatures and will not be harmed in any way if they just happen to see a cyberchimp, internet-dolphin or web-ferret tastefully displayed on the demo content of their newly downloaded theme. They will just go Appearance > Header and upload their own e-Platypus.

    • Srikanth 11:13 pm on February 19, 2013 Permalink | Log in to Reply

      Large percentage of users don’t even know how to set a featured image, forget about replacing a hook.
      No need to provide a theme option, but link should be plain html.

      Thats why i think, all this should be opt in, you can take the users to welcome tab upon theme activation and explain to them about the features like logo upload and what not. Experienced users will take full advantage and ordinary Joe will not walk around with huge billboard advertising your company for free.

      When i activated a theme for review recently, that’s what i saw : a giant billboard advertising the company with no user content at all, that too when i was testing it with theme unit data.

      This whole review team idea was created to protect users.

    • Paul 11:33 pm on February 19, 2013 Permalink | Log in to Reply

      how about the screenshot image, can that be branded, as in have a watermark logo or similar. or even the URL of the theme author on it?

      • Daniel 11:37 pm on February 19, 2013 Permalink | Log in to Reply

        Well it already in guidelines:

        “screenshot.png

        Recommended 4:3 W:H ratio, size 600x450px (2x the previous 300x225px, to account for Retina displays).
        Maximum size: 600x450px
        Should be a “reasonable facsimile” of the Theme after it is initially activated with default options”

        • Paul 11:42 pm on February 19, 2013 Permalink | Log in to Reply

          that doesn’t mention anything about branding

          • Daniel 11:45 pm on February 19, 2013 Permalink | Log in to Reply

            Are you talking about putting a watermark over the image (Like how Istock put their photos up)?

    • d5creation 4:50 am on February 20, 2013 Permalink | Log in to Reply

      I don’t see an issue with branded items (Such as Theme Logo, Slide Images) if these are user-configurable items via the WP-Admin easily. But these should not be linked.

    • Edward Caissie 4:08 pm on February 20, 2013 Permalink | Log in to Reply

      Although I have no real issues with user configurable “branded” demonstration content (read: header logos, slider images, etc.) … or whatever you want to call it. I do see it as something that should be addressed, at a minimum, in the theme’s ‘readme.txt’ file and how it can be “easily” disabled and/or removed.

      Simply put, just because it is configurable does not mean it is easy to configure. If “branded” content is used it must be easy for the end-user (think: one-click / push-button simple) to not use this “branded” demonstration content.

      Similarly, I see the footer credit in a text link as more or less a non-issue; but, if it’s “shiny” (like a logo) then once again I would strongly recommend instructions to easily hide / remove / replace with a text link be included, again at a minimum, in the theme’s ‘readme.txt’ file.

      As a caveat to this idea on the footer credit as logo, if the theme already implements theme options then an option to change the “logo” credit link to a text link would be acceptable rather than explaining how to remove it.

      • Bryan Hadaway 1:38 am on February 21, 2013 Permalink | Log in to Reply

        Regarding branded content:

        Maybe it’s as simple as a few extra guidelines:

        “If your theme utilizes demo content to demonstrate key features, it must provide ample documentation for users on how to either remove or replace demo content with their own.”

        “Demo content may match the overall look and feel of the theme, basic branding and colors, but may not contain promotional language or URLs.”

        Cased closed?

        • Srikanth 2:24 am on February 21, 2013 Permalink | Log in to Reply

          Opinions are still split, dunno how it is resolved in such cases…

      • @mercime 11:28 am on February 21, 2013 Permalink | Log in to Reply

        @cais Thank you for articulating those points so very well. Just outstanding.

    • Thomas 11:13 am on February 21, 2013 Permalink | Log in to Reply

      What about a guideline which requires own demo images to provide short information how to remove or replace it directly in the image?

      Since I got a lot of questions from users how to change the personal picture in my business card theme, I simply added a short line to my default image: http://wp-themes.com/wp-content/themes/zeebizzcard/images/default_header.jpg

      For example demo slider images should include a line “Learn more how to configure the slideshow and place your own images here at readme.txt” or something similar. The user sees immediately he is looking at demo content and get more information how to replace or remove it.

      In my opinion most users never ever look in the readme.txt by themselves, so any information putted there never gets read ;)

    • Chip Bennett 3:14 pm on February 23, 2013 Permalink | Log in to Reply

      All: let’s please keep the scope of the discussion on the Guidelines.

  • Lance Willett 11:48 pm on February 18, 2013 Permalink | Log in to leave a Comment
    Tags: , , twentythirteen   

    Twenty Thirteen Draft Now in Core 

    Hi theme reviewers,

    Twenty Thirteen is ready for feedback and testing in core: http://make.wordpress.org/core/2013/02/18/introducing-twenty-thirteen/

    Our goal is to have it ready along with the rest of 3.6 for an April launch. Would love your eyes on it for testing, performance, tying in with core features, all that good stuff.

    Also noting several theme-related core tickets, if anyone wants to jump in with comments, patches, and testing:

    We’ll have open office hours Tue/Thu throughout the cycle (see http://make.wordpress.org/core/ sidebar for times), so hope to talk with you soon.

     

    • Emil Uzelac 11:50 pm on February 18, 2013 Permalink | Log in to Reply

      Will do for sure and Twenty Thirteen looks mighty fine :)

      Emil

    • @mercime 1:06 am on February 19, 2013 Permalink | Log in to Reply

      Congratulations @matt @lancewillett @obenland @joen and team.

    • Daniel 6:53 am on February 19, 2013 Permalink | Log in to Reply

      Can we please add the ticket about styling the post comment button?

    • Sallie Goetsch 11:55 pm on February 19, 2013 Permalink | Log in to Reply

      I like the typography (except the menu font, which is microscopic–PLEASE bear in mind that not everyone using WP is under 25) and the color. It’s pretty and fun. Can’t imagine using the theme in a million years, though, because the sites I build aren’t blogs and do need to be customized to the user. Where does the theme customizer fit in with something that has such distinctive colors?

      I’m also wondering how to fit Twenty Thirteen into my intro WordPress class for May, because I’m not at all sure it will suit my students half as well as either Twenty Eleven or Twenty Twelve.

    • Nathan Reynolds 6:11 am on February 20, 2013 Permalink | Log in to Reply

      I am wondering if there is a reason that when I post under the link or quote format the .entry-content is empty so it’s just showing the post-meta.

      I am using the built in boxes for URL in link, and quote/source in quote. I just test to see if the post body will show up and it does, just none of the other boxes I filled out.

      • Lance Willett 4:07 pm on February 20, 2013 Permalink | Log in to Reply

        Hi Nathan, are you using trunk 3.6 bleeding edge? That code is brand new, and doesn’t work with Twenty Thirteen yet.

    • bjornsennbrink 7:40 am on February 25, 2013 Permalink | Log in to Reply

      Remove hyphens from body.

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel