Create an IA for devhub

[siobhan]

Currently we're designing in a haphazard way. This is a legacy of the handbooks and the code reference being originally intended to exist in different places. Since they've been merged into one devhub, we haven't yet created an IA that draws them all together.

[siobhan]

Created the following IA:

We'll require the following:

Custom Page Templates

• code reference landing page
• handbook landing page

Custom Post Types

• theme dev handbook
• plugin dev handbook
• functions
• hooks
• classes

[samuelsidler]

Per discussion over the last couple of weeks, we need to add a "Resources" section for things like Dashicons and other resources that will be used by developers.

[Rarst]

To enumerate, not currently reflected:

• resources section
• non-reference search
• break out reference archives as per representations in #173

Also can we please enumerate URL structure for all the things? Sorry, it's just easier for me to grok this from URL resources perspective. :)

[siobhan]

Thus far:

developer.wordpress.org
developer.wordpress.org/reference/
developer.wordpress.org/reference/?s=
developer.wordpress.org/reference/functions/
developer.wordpress.org/reference/functions/some_function
developer.wordpress.org/reference/hooks/
developer.wordpress.org/reference/hook/some_hook
developer.wordpress.org/reference/classes/
developer.wordpress.org/reference/class/some_class
developer.wordpress.org/reference/class/some_class/some_method
developer.wordpress.org/reference/source_files/
developer.wordpress.org/reference/source_files/file-name
developer.wordpress.org/reference/versions/
developer.wordpress.org/reference/versions/version-number
developer.wordpress.org/resources/
developer.wordpress.org/resources/some_resource (e.g. dashicons)
developer.wordpress.org/blog/

Here's where I'm not sure yet what the structure should be. Here are a couple of options:

developer.wordpress.org/themes/
developer.wordpress.org/themes/handbook
developer.wordpress.org/themes/handbook/some_handbook_page
developer.wordpress.org/plugins/
developer.wordpress.org/plugins/handbook
developer.wordpress.org/plugins/handbook/some_handbook_page

Pros: leaves space for the section on themes and plugins to grow beyond the handbooks
Cons: we need to create a separate landing page for themes/plugins. If we don't have any resources beyond the handbooks (and none are planned), the /themes/ and /plugins/ will be redundant

OR

developer.wordpress.org/handbooks/
developer.wordpress.org/handbooks/theme-developer/
developer.wordpress.org/handbooks/plugin-developer/
developer.wordpress.org/handbooks/some-other-handbook/

Pros: keeps the type of documentation together so a person can go and find them in one place
Cons: grouping documentation together by theme and plugin makes it clearer where the developer needs to go

OR

developer.wordpress.org/theme-developer-handbook/
developer.wordpress.org/plugin-developer-handbook/

Pros: simpler structure. We won't need to create additional landing pages
Cons: no scope to grow beyond the handbooks

[siobhan]

Final URL structure:

developer.wordpress.org
developer.wordpress.org/reference/
developer.wordpress.org/reference/?s=
developer.wordpress.org/reference/functions/
developer.wordpress.org/reference/function/some_function
developer.wordpress.org/reference/hooks/
developer.wordpress.org/reference/hook/some_hook
developer.wordpress.org/reference/classes/
developer.wordpress.org/reference/class/some_class
developer.wordpress.org/reference/class/some_class/some_method
developer.wordpress.org/reference/source_files/
developer.wordpress.org/reference/source_files/file-name
developer.wordpress.org/reference/versions/
developer.wordpress.org/reference/version/version-number
developer.wordpress.org/resources/
developer.wordpress.org/resources/some_resource (e.g. dashicons)
developer.wordpress.org/blog/
developer.wordpress.org/themes/ (theme dev handbook landing page)
developer.wordpress.org/themes/some-handbook-page/
developer.wordpress.org/plugins/ (plugin dev handbook landing page)
developer.wordpress.org/plugins/some-handbook-page/

[Rarst]

#179 was marked as a duplicate.

[nacin]

Some /reference/ URLs have changed since then. source_files is now files. version is now since. Additionally, after some discussion in person with siobhan, otto42, and coffee2code, we decided to use functions, classes, and methods always, and not drop to the singular. These URLs should be as hackable as possible and this will help with that. I *do* think we should handle and redirect the singular versions, again so they can be hackable.