Tag Archives: discussion

Jose Castaneda 5:45 am on February 18, 2014
Tags: , discussion, ,   

Improving our theme previews

As many of you may, or may not, have noticed there are currently over two thousand themes available in the repository. I think that is amazing. Seriously, huge thanks to all those that have contributed not only their time but their efforts as well.

One thing I noticed some time ago was the mentioning of the theme previews. I can’t recall where it was brought up but I do recall it mentioned that it wasn’t the greatest preview of a theme, or themes really. I do hate to admit it but it is fairly true. The current preview is lacking on some things.

One of the things being post formats. Currently the theme preview is just a few posts and a few pages. I think we can do a little better now. I’ve brought up a ticket a few times: #30 in the Meta trac.

Here are some of the things I think we can not only improve upon but can contribute to.

  • Sample data
  • Images
  • Video
  • Audio

Data

Simple and to the point. We need posts and plenty of them. How about quick little tidbits like how to set up a front page, or changing the image headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. Doesn’t have to be huge.

Images

Galleries. Sliders. Single images. We need more boats!! Okay not really but if you have them it would be awesome.

Videos

I think we can find a way to contribute a few videos here and there. I know there are some themes that have video format support and I would love to be able to accent that in some way.

Audio

I’m thinking podcasters and maybe musicians.

So there you have it. Let’s discuss!

#community, #discussion, #discussion-topic, #wporg

Jose Castaneda 10:33 pm on February 11, 2014
Tags: , , discussion   

What is your working environment?

I’ve actually wondered as to what most of us like to use when it comes to reviewing themes and possibly even creating themes.

One thing I would like to see is the use of VVV. I know most of us have never tried it out or even heard of it but I feel we can all benefit from using it. Why? Because as the video states it does make it easier to be on the same page.

I would love to see what you all use for your testing and development of themes. Or even plugins.

#community, #developers, #discussion

Chip Bennett 4:14 pm on November 18, 2013
Tags: discussion,   

Is the Theme Directory “Blog” Focused?

Some recent discussions in the community have indicated that the Theme directory is too “blog” focused, and that the Guidelines actively discourage non-blogging Themes from being submitted.  There are some things that are true, some things that are untrue, and some things that are simply outside of the control of the Theme Review Team, in terms of the Theme directory and “non-blogging” Themes.

One thing that is true is that the current stance of the Theme Review Team is that the “CMS” use case is not significantly compelling for a Theme to omit support for a blog. From a coding perspective, the differences between a post loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. and a static page loop are minimal. From a user perspective, there is no real reason to restrict a “CMS” Theme’s user base only to users who don’t intend to use the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blog functionality.

Another thing that is partially true is that the current Theme Unit Tests appear heavily blog-centric. But that’s mainly because the unit tests are presented as blog posts. Some things – taxonomies, posts navigation, post formats, etc. – only apply to blog posts; but most of the rest of the Theme Unit Tests apply equally regardless of post type. The Theme Unit Tests are designed as test-every-reasonable-use-case data: to push edge cases and boundaries, to ensure that Themes accommodate the widest possible range of use cases and to see how Themes respond to break points. Generally speaking, the entire suite won’t apply to any given Theme (for example, most Themes don’t add support for all post formats; so the unit tests for unsupported post formats wouldn’t apply).

By contrast, one thing that is not true is that there is no recourse for hosting a non-traditional Theme in the Theme directory. Want to submit a Theme intended to be used as a support ticket system, a knowledge base, or a presentation slideshow? Those are all welcome in the Theme directory.  We refer to these Themes as “niche” or “custom use” Themes, and we already have a mechanism in place to “whitelist” those Themes so that they can bypass non-applicable upload script tests. All we ask is that developers email the mail-list and ask for an exemption, along with explaining the justification.

But there are many things that are outside of the control of the Theme Review Team, including anything that deals with the infrastructure of wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//themes itself. We have one Theme directory to work with. We can recommend filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. tags to be added, removed, or modified; but we don’t make the final call on them. We have no control over the each Theme’s page in the directory, the ratings/review system, the algorithms for trending Theme lists, or pretty much anything other than actually marking Themes as “live” in the directory, after completing a review. There are many ways that these things could be improved, but we are dependent on other people who have much higher priorities in the grand scheme of the WordPress project and website.

I would love to have the ability to host Theme frameworks (in the classic, non-marketing sense of the term: a drop-in code library that facilitates Theme development) in the directory, it would greatly simplify review for Themes that use frameworks such as Hybrid Core and the like; but we currently have no infrastructure to do so. I would love to have the Theme’s directory listing page parse the Theme’s readme file the same way that a PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party’s listing page parses its readme; but that’s something else that isn’t possible at the moment.

I would love to explore the idea of having multiple Theme directories, or some sort of “tier” system; but we just don’t have that infrastructure. And that’s one of the primary reasons that we have what appears to be a “one size fits all” approach and mechanism for Theme submission, review, and approval – but that doesn’t mean that we can’t or won’t accept submissions for Themes that don’t fall strictly within the “blogging” genre. If you have an idea or question, mail the Theme Reviewers mail-list and ask. It can’t hurt anything, and you very well may be surprised by the response.

#discussion, #guidelines

Chip Bennett 3:21 pm on December 14, 2012
Tags: discussion,   

query_posts()

While the clock has started ticking on the 3.5 release grace period for Guidelines updates, I would like to discuss formalizing one other _doing_it_wrong() issue that has been implicitly enforced for some time now: use of query_posts().

Would anyone be opposed if we formally added query_posts() to Theme Check as a required stopper?

To understand why query_posts() is always inherently _doing_it_wrong(), see @nacin‘s WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. presentation You Don’t Know Query, and this great WordPress StackExchange answer by @rarst.

In short, if you are creating secondary queries, you should use WP_Query(), and if you’re modifying the main query, you should filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. pre_get_posts.

Thoughts?

#discussion, #guidelines

Chip Bennett 2:48 pm on January 24, 2011
Tags: discussion, , obsolescence   

Follow-Up: Theme Obsolescence Guideline

I haven’t yet seen any discussion of this point in Phil’s post below, so I wanted to highlight it again:

Some of the review team have brought it up that there should be a time limit for non-updated themes, our general consensus is 2 or 3 major revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. of WordPress before suspension for not keeping themes updated. What this means that currently we’re on WordPress 3.0 previous to that was 2.9, 2.8 which is 2, 2.7 being 3 revisions previous, all themes that are prior to 2.7 (or 2.8) should be suspended as being currently obsolete.

To be clear, the Theme Review Team is formally proposing an obsolescence Guideline, that any Theme not updated within 2 (perhaps 3) major releases of WordPress be automatically suspended, until a current version is submitted and approved.

For example, if this guideline were put into place with a timeline of 3 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.8 (i.e. since June 2009) would be blanket-suspended.

Or, if this guideline were put into place with a timeline of 2 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.9 (i.e. since December 2009) would be blanket-suspended.

We very much want input and feedback on this proposal. Would this guideline generally help or hurt – improve or worsen – the Theme Repository? Is the proposed timeline (2 or 3 major WordPress releases, which translates into, generally speaking, 6 or 9 months) reasonable?

#discussion, #guidelines, #obsolescence