@kpdesign has been working day and night to…

@kpdesign has been working day and night to get the 4.1 version article filled up leading up to this week’s release. She could really use some help getting it into shape.

In particular, the Under the Hood section could use a bit of work by folks who have more intimate knowledge of core. These would be people like @ipstenu, @sewmyheadon, @dh-shredder, @boonebgorges and others who have helped out in the past.

If you think you know someone from the core team who could lend a hand, please please point them this way.

Some items may also need to simply be reorganized from section to section. Any and all help would be greatly appreciated.

We’re primarily working off of two checklists:

Anything checked off has already been added to the version page in some form, or skipped for brevity.

#codex, #core, #release, #sprint

Agenda for today's Inline Docs chat

It’s been awhile since we’ve had an inline docs chat, and there are several items on the agenda for today’s meeting at 19:00 UTC (3:00 pm EDT) in IRC in #wordpress-sfd:

  • 4.0 Audit – #28885
  • Access tags for all the methods
  • Hook aliases + PHPDoc tags
  • PHPDoc tags for unit tests – #28558

If you’d like to suggest any additional items for the agenda, leave them in the comments below. Thanks!

#core, #inline-docs

Documenting all the dynamic hook aliases

A couple of weeks ago at Open Source Bridge, I started a conversation with @jorbin about an idea to document common aliases of dynamic hooks in core docs. A long-standing pain point in core, and now in the Code Reference, is that dynamic hooks aren’t really searchable.

For example, let’s say I want to search for the ‘publish_post’ hook. If I search the source, I see add_action() calls referencing that hook, but its origin is nowhere to be found. This is because the hook is actually {$new_status}_{$post->post_type}.

The idea would be to make it possible to search the source and the Code Reference for indexed common aliases like ‘publish_post’ and have it return the reference for {$new_status}_{$post->post_type}.

Great, so what’s next?

We’ve already started a spreadsheet at the WordCamp Seattle contributor day to begin identifying common aliases of all of the dynamic hooks in core. Big thanks goes to @trepmal for providing a complete list of all dynamic hooks from her presentation slides.

If you’d like to get in on the ground floor and help out, the spreadsheet can be found here: https://docs.google.com/spreadsheets/d/1QfHEPhI9j_Dts5XAxC_kX-LvdE0fxyHlnRFomOTFzQk/edit#gid=0

Over the next few weeks, I’ll be working with @rarst to devise a solution for parsing hook aliases using WP-Parser. When we have a solution in place, we start planning the effort to begin patching hook docs in core.

We’ll be tracking progress on #557-meta on Meta Trac.

Yay progress!

#core, #inline-docs

Core string feedback

Would anyone care to provide some wordsmithing services over in #28199? It’s just one string change that needs docs feedback

#core, #docs-feedback

Revisions help tab


Yesterday in DevChat, @ocean90 requested we write a help tab for the new revisions screen. I’ve uploaded a first-run patch and am looking for feedback and revisions (ha) on that text.

I’d just like to note that I think we can be succinct about this without leaving out important information.

The ticket and patch are on the #23899 ticket.

The following is the first-run text:

Tab: Overview:

This screen is used for managing your content revisions.

Revisions are saved copies of your post or page, which are periodically created as you update your content. Text highlighted in red shows what content was removed, highlighted in green shows what content was added.

From this screen you can review, compare, and restore revisions:

  • To navigate between revisions, drag the slider arrow left or right or use the Previous or Next buttons.
  • Compare two different revisions by selecting the ‘Compare two revisions’ box to the side.
  • To restore a revision, click the Restore This Revision button.

Tab Sidebar:

For more information:

Revisions Management
Support Forums

Side note: The Revisions Management page is slated for pre-sprint release, in other words, it’ll be done in time for the 3.6 release so forum folks have something to reference.


What it means for a taxonomy to be hierarchical

We\’ve all done it, had to explain the difference between hierarchical and non-hierarchical taxonomies (categories and tags).

In a recent ticket, #23447, it\’s proposed that the description for the parent dropdown on the hierarchical taxonomy form be rewritten to be more generic. In an age of custom taxonomies, I think we can get behind that.

The current patch suggests changing this:

Categories, unlike tags, can have a hierarchy. You might have a Jazz category, and under that have children categories for Bebop and Big Band. Totally optional.

to this:

You might have a Jazz category, and under that have children categories for Bebop and Big Band. Totally optional.

I think we can do better. We\’d need to succinctly explain \”hierarchy\” without button-holing ourselves into just talking about categories.

As @dd32 aptly points out, we need to avoid using taxonomy labels in any future changes because of the difficulty in working with different languages.

So who has a suggestion? 🙂

#core, #taxonomies