Chip Bennett

A couple questions:

1. This is the taxonomy-totd_cat.php template file?
2. If so, are your pre_get_posts and posts_found callbacks working? That would be extremely unusual, since by the time the template is loaded, those actions/filters are long-past

Also, there is a lot of code here, most of which is probably not relevant to the question. Can you pare it down to the key sections of code, just for ease of clarity/legibility?

First, thank you for taking the time to comment here. As an admin for the Theme Review Team, I am sensitive to end user needs, and ensuring that Themes hosted in the WordPress Theme Directory serve those needs to the greatest extent possible.

To address some of your issues as they relate specifically to Themes:

1. The Theme Directory listings are at a bit of a disadvantage as compared to the Plugin Directory listings. With the Plugin Directory listings, Plugin developers are required to include a README file that is compliant with a specific markup standard. The Plugin listing then parses that README file, to give the various headings/tabs that you see (FAQ, screenshots, etc.) in each Plugin’s listing. The Theme Directory does not have this same README-parsing functionality, so Theme developers are limited to control over only the Theme description. Fixing this discrepancy is a (very) long-term goal/project of the small (for all practical purposes: one-man) team that maintains the WordPress.org site.

2. The Theme Review Guidelines require Themes to support core implementation of any integrated features/functions in a Theme. So, for example, if a Theme wants to implement a custom header image feature, or a custom background feature, or navigation menus, then the Theme must use the core implementation of those features, rather than create a redundant implementation of those features. So, for all core-implemented features, users should look first to the Codex for documentation of those features.

3. The Theme Review Guidelines do require Theme developers to provide documentation for any non-standard feature/functionality of the Theme. So, for example, if a Theme implements a “featured posts” slider, then the Theme must document how that slider works (e.g. using sticky posts, or using a “featured” category or tag, or a “featured” custom post meta key).

4. But, as mentioned above, there is no user-friendly display of a Theme’s README file. Unfortunately, there’s simply no way to parse/display them in the Theme’s directory listing page.

5. If you find Themes that don’t have non-standard features documented well enough, please post in the Theme’s specific support forum.

6. But always, please keep in mind, the vast majority of people who submit Themes to be included in the Theme directory are submitting free code that they have developed on their own time. Writing user-friendly documentation is a skill; it is hard, and it is time-consuming.

7. While I do intend to push for Themes to have Plugin readme-standard compliant README files, it would be impractical to try to define some standard of inline documentation, and would incur an incredible burden for an already very busy Theme Review Team.

Here’s my own Theme, Oenology. I consider its documentation to be a feature. I can’t tell you how many hours I’ve spent on documentation alone, and it’s still not perfect. I try to provide the same quality of documentation for my Plugins as well – but again, I don’t think it’s practical to try to require all Plugin and Theme developers to meet some level of quality of documentation.

Many Plugin/Theme developers are open to contributions to their code. The best places to start inquiries are the Plugin/Theme’s specific support forum, or, as is often provided now, the developer’s GitHub repository for the Plugin/Theme. Many developers use GitHub as a VCS, and welcome forks/pull requests. I imagine that the vast majority of developers who host their code on GitHub would practically beg for someone to help with their documentation especially.

If you have input or feedback regarding the Theme Review Guidelines, please feel free to contact the Theme Review Team directly. We always welcome any and all input, feedback, and criticism.

@marj

Risky because there is no site backup performed on that installation prior to the upgrade.

While I agree with your underlying premise (core should expose an option to disable all automatic core updates), the above statement is not entirely true. Making a backup is not the only viable means of risk mitigation. In fact, the core update routine does include various failsafe mechanisms, including aborting if certain criteria are not met, and some ability to rollback on failure.

Generally speaking, the failsafes in place are suitable risk mitigation for minor updates, for the vast majority of update attempts (as demonstrated by update statistics). Failures are exceedingly rare. And if a minor-version update results in a Theme/Plugin conflict, in close to 100% of such instances, the Theme/Plugin is at fault.

Automatic core updates for minor versions are very, very safe, and have very, very low risk.

Thanks. Had a good laugh on that one… compatible up to 3.7. Kind of makes my point.

You do know that 3.8 came out like two minutes after 3.7, right?

The Plugin is still compatible with WordPress 3.8. When core updates happen around the holidays, Plguin developers don’t always have the time to push out Plugin header updates. I’ll fix that post-haste.

A few questions for troubleshooting (some may be obvious; please bear with me):

1. WordPress core version before update
2. WordPress core version after update
3. Did you receive email notification that WordPress successfully updated?
4. Currently active Theme
5. Currently active Plugins
6. Did you receive any error messages or indication during the update process?
7. Can you access other areas of your admin?
8. Can you access your site front end?
9. What debugging error messages (e.g. PHP fatal errors) do you receive in the admin or on the front end?

Sounds like you need to use another CMS.

I think that attitude is unnecessarily dismissive. The WordPress decisions not options philosophy, at its extreme ends (i.e. when it overrides user decisions), is antithetical to true free software philosophy, which places the end-users purposes and freedoms above all else.

From a truly free software philosophy perspective, even if the default behavior is to perform updates, the correct implementation would be to expose options for the user to override that core decision.

Google Chrome is the oft-cited example. On a Windows box, Google Chrome updates on its own in the background. Google Chrome in Windows is a nearly, but not fully, open-source/free software package. I’m working in Linux right now. Chromium (the fully open-source/free version of Chrome) does not update without end-user interaction/authorization.

I’m perfectly fine with automatic updates. I encourage them. But the point is: as the end user, I have the right to make that decision. It is a valid criticism that the options are not exposed by default by core, and I don’t think it is helpful to treat such criticism dismissively.

All:

Personally, I agree with you that WordPress should expose options for ALL automatic updates, without needing to use a Plugin to expose those options. But the core dev team disagrees, so you’ll have to expose (or manage) those options yourself, via the filters provided by core.

If you want to go the Plugin route, I maintain the Update Control Plugin first written by George Stephanis.

If you want simple control on your own end, well, you’ll still need to go the Plugin route, but you can use a site-functionality Plugin. I’ve written one here. Just add it to wp-content/plugins (or drop the code in an existing site-functionality Plugin), and enable (uncomment) whichever filters you want to apply. The code is too long to embed in a support forum reply, so I’ve put it in a Gist:
https://gist.github.com/chipbennett/8619087