Merge required upstream changes from https://core.trac.wordpress.org/changeset/41294

Best to wait until #134/#135 is merged, or not to avoid conflicts in the .travis.yml file

All archives need some basic tweaking:

• font size is too small
• TOC is cut on right side, probably by some overflow: hidden

Currently both Grunt and Gulp are being used, we should use one or the other.

Gulp is setup for the theme, Grunt for everything else

After a quick impromptu meeting in Salck just now it was decided to use Gulp for all the things

Anyone want to to a shot at this? Happy to help if you do 😄

The current page headers need to be simplified to match new styling.

Current Appearance

Proposed Appearance

Remove centering of text, border, and other misc. meta data. Make sure font size, family, and weight all match new design.

Any search bar that pertains to the immediate section (Docs, or Plugins, or whatever) needs to be displayed in the subnav area.

Current Search field placement (sidebar)

Proposed Search field placement (see Plugins)

We have double #main element on archive, frontpage template and some other places. Initial one opens in header.php to wrap sidebar and main content. The second one, like in archive pages, should be removed from all places.

@justingreerbbi

See http://helphub.wingz-media.com/2016/03/18/htaccess/ as example.

That article definitely looks like it will take longer than 4 mins.

Can we adjust the way read time is calculated?

Semi-related #27 #29

I'm not sure what the plans are currently for localisation.

Eg. The Japanese Codex is quite frankly as I understand a manual effort at checking change logs on pages and them fixing it. It also seems to be hosted out of WordPress.org

I read there are some indications on possibly making one for DevHub or the whole of WordPress.org - see https://wordpress.slack.com/archives/docs/p1454139890000244

Perhaps we might collaborate on this?

Based on the wireframes (https://wp-commhub.mybalsamiq.com/projects/helphub/grid), it looks like we need to create a HelpHub specific footer section to implement in addition to the .org footer.

Merge updated logic from https://core.trac.wordpress.org/changeset/41177

The "Leave a Reply" form is in a column right now covering up content and making it difficult to read. It should be removed completely. I don't think we need to allow comments for doc pages.

Current

We have a 'Related Articles' section in the single article wireframe (https://wp-commhub.mybalsamiq.com/projects/helphub/Single%20article) - we need to decide how this will work. Should it be automated based on tags/categories? Should we manually link articles? If it's manual, then do we use an existing plugin or build our own? Need to decide the best way forward.

On one of the home page widgets, Installating WordPress instead of Installing WordPress.

From what I can see this is a widget header, if someone with the right permissions could edit that widget, alternatively if I am allowed access to edit widgets I can do it.

Thanks

So we have a series of articles for WordPress versions, and an 'archive' page for it. See https://codex.wordpress.org/WordPress_Versions

So I paged the core team on this

@Ipstenu: So you're the last one who did multiple changes (anyone else feel free to chip in too). Eventually the leftover non Dev Hub codex pages are gonna be moved into Helphub, there are some pages that don't really fit into the Helphub's general design

E.g. Pages like this https://codex.wordpress.org/WordPress_Versions

So I realised that editing that page and the Changelog page are separate jobs but really it kinda feels like one should able to write the change log and then have the archive generate the links.

So I'm wondering if you guys think it makes sense to create a Custom Post Type maybe called wp_version_article or something, whereby the change log, db numbers, release dates etc all get saved as meta data.

I'm asking this because that Codex article looks like it'll be annoying to manage if you used our Post post type to write it. See https://wp-commhub.mybalsamiq.com/projects/helphub/Single%20article

Should we create a custom post type for WordPress versions? It's a pretty important page.

But I do not know if it belongs to Helphub. But it certainly also doesn't belong to DevHub

We didn't include a search results template in the wireframes, but with the search being such a prominent feature of the home page we need to build that out.

We didn't include a table of contents in the wireframes for the single article view (https://wp-commhub.mybalsamiq.com/projects/helphub/Single%20article), but it would be very useful for longer articles. There are a number of plugins that already do this, but it might be worth building it ourselves so it can be more neatly tailored to our needs.

Overview:
Add ability to reference the correct hook by using a shortcode.

Workflow:

1. User adds [filter name="the_title"] or [action name="do_shortcode"]
2. The system will look for a hook name in the reference database
3. If successful, a link will be created to the reference
4. If not successful, the name of the filter will be displayed with a red underline (marking missing content)

Implementation:
Should be pretty straight forward.

What do you think? Improvements?

The wireframe for the single article view is here: https://wp-commhub.mybalsamiq.com/projects/helphub/Single%20article

We can do this with filler text until we have defined the data structure in #2. Also take note of #6.

We are pulling a lot of styles from .org and should remove all those from Helphub theme.

The sidebar navigation has the correct background color, but the text and structure need to inherit the new styling.

Current Appearance

Proposed Appearance

Solution

• Remove bullets
• Add top and bottom dividers
• Add proper indentations
• Add accordion sections of links
• Add proper arrow icons for visual reference of an accordion
• Main title should just say "CHAPTERS"
• Use correct color blue for links, correct font size and weight

The flow of this is TBD but in the event that there is no search results, we need to guide the user to the forums in some way. Suggesting topics would be ideal but maybe a nice interface guiding the user would be ok as well. This would should feel like HH did not really fail in providing results but rather saying "I don't have what you are looking for, but I know who does!"

This will be one of the gateways from HH to the forums.

The links in the subnav are too difficult to read right now. It looks like they have the new styling, but there's some old styling causing problems.

Current Appearance

Proposed Appearance

Solution
This below style should be overwritten by the new one that pertains directly to the link in .main-navigation

a:visited, #wporg-footer ul li a:visited {
    color: #4ca6cf;
}

This below style can be removed completely.

a:visited {
    color: #800080;
}

HOVER STATE
The styling of the hover states need to be added to the anchor tag to ensure it turns white as well. And add the color to turn white for the li and the a tags.

Current Appearance

Proposed Appearance

Solution
Remove this style altogether.

a:hover {
    color: #d54e21;
}

As tools and workflows are sorted out and improved upon, we need a solid contributor guide.

As such, we should be creating a CONTRIBUTE.md CONTRIBUTING.md as is GitHub standard in such cases.

The content of HelpHub will (most likely) need to be built using custom post types and taxonomies. The other option is that we just use the post post type and it's associated taxonomies. Either way we will need to decide what we're going to do and build the appropriate CPTs, taxonomies, and custom fields.

The Topics box in the page has some of the new styles, but needs a few more things.

Current Appearance

Proposed Appearance

1. Each Topics box should have the header "Topics" with the bottom border.
   SOLUTION: Add the <h2> tag with "TOPICS" as the text. Font weight should be 400 as well.
2. Each Topics box should also be the correct width.
   SOLUTION: Remove max-width: 35% from .table-of-contents selector.
3. Font size needs to be adjusted a bit smaller.

WordPress has a decent built-in search, but it might be a good idea to look into how we can improve that. There are plugins that improve the default WordPress search (the ones that come to mind are SearchWP and Relevanssi), so it might be good to investigate an option like that, or look into building an enhanced search ourselves as the search functionality is very important to achieving HelpHub's goals.

Hola! @Kenshino has created a ZenHub account for the Kenshino organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Multi-Repository burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• Time-saving shortcuts – like a quick repo switcher, a “Move issue” button, and much more.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @Kenshino.

For an easier road moving forward, and since the theme is built on top of _s already, we should use sass for styles.

The benefit to this are modular style rules, making it easier to add/remove styles, and also makes it easier to keep control of the styles that already exist.

It will obviously be a process to set up initially, as development so far was done directly against style.css, but the benefits going forward should make it worthwhile.

@justingreerbbi @Kenshino We'll be needing to finalize the custom functionality of the widget that we will be using in the frontpage as discussed in here: #22

Needs styling and positioning.

But will have to wait for design team to get back on this.

Since it's part of our rules not to merge our own commits and to also get reviews - I'm using the system to enforce that

Moving to Helphub means Codex pages in other languages will lose relevance as the English pages will get redirected.

We'll retain the links to those Codex pages.

#48 aims to fix that

Read Time should check if the post is entirely new or at least if post_content is empty before attempting to run DomDocument() and it's related functions

Now it returns the error message via the Add New Post page

$data->loadHTML(): Empty string supplied as input in /home/hughlash/public_html/wphelphub.com/wp-content/plugins/helphub-read-time/helphub-read-time.php on line 52

Our current theme is mostly not responsive.

Let's make it so

What I expected

• set Recent Posts widgets on Footer1
• set Meta widgets on Footer2
• Footer contents will be like this image

What happened instead

• set Recent Posts widgets on Footer1
• set Meta widgets on Footer2
• Footer contents has two Recent Posts like this image

So, I think it should be 'footer2'.
https://github.com/Kenshino/HelpHub/blob/master/themes/helphub/footer.php#L36

PR at #46

The home page layout is defined in the wireframes: https://wp-commhub.mybalsamiq.com/projects/helphub/Home%20page

We will need to build that out and can use dummy text until we have the data structure in place from #2.

Let's define some core post categories.

Eg. Installing WordPress, Moving WordPress, Using WordPress etc etc

Any thoughts?

Building a plugin that will create post types and custom taxonomies, does the sanitisation, the meta boxes and such

In the single article wireframes (https://wp-commhub.mybalsamiq.com/projects/helphub/Single%20article) we included a thumbs up/down function. We need to spec that out and decide just how it will work before building it.

Good First Bugs

Fix Travis CI error of themes/helphub/header.php

https://travis-ci.org/Kenshino/HelpHub/jobs/254806894

FILE: /home/travis/build/Kenshino/HelpHub/themes/helphub/header.php
----------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
----------------------------------------------------------------------
 40 | ERROR | [x] When an array uses associative keys, each value should
    |       |     start on a new line.
    |       |     (WordPress.Arrays.ArrayDeclarationSpacing.AssociativeKeyFound)
 49 | ERROR | [x] File must end with a newline character
    |       |     (Generic.Files.EndFileNewline.NotFound)
----------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

We need to have the standard header and footer from WordPress.org used here too. The theme directory is a good example of how this is implemented: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-themes

We need a way to

1. Track contributors (both now and in the future) of article content
2. Display the article contributors at the bottom of the article

We already have all the current contributors on the Migration document (and any changes should be in the history) but we might want to find a better way to track this.

We included a 'reading time' feature in the single article wireframes: https://wp-commhub.mybalsamiq.com/projects/helphub/Single%20article - we can look into an existing plugin for that or we can build our own way of calculating the reading time (based on word count presumably).

WordPress.org currently runs PHP 7.0, so there's no need to test PHP 5.6 on Travis CI is there?

Via https://wordpress.slack.com/archives/C02QB8GMM/p1499347132827278

The following files have empty blocks triggering warnings with the latest stylelint release:

• https://github.com/Kenshino/HelpHub/blob/master/themes/helphub/sass/

  • navigation/_menus.scss#L38-L40

  • navigation/_menus.scss#L42-L44

  • navigation/_menus.scss#L57-L59

  • navigation/_menus.scss#L70-L71

• https://github.com/Kenshino/HelpHub/blob/master/themes/helphub/sass/forms/

  • forms/_buttons.scss#L6-L8

  • forms/_buttons.scss#L10-L13

  • forms/_fields.scss#L24-L26

These can all be removed can't they?

Some of our articles require tables.

Jetpack would most certainly be available to HelpHub but Markdown Tables are a pain to use. There is a generator - http://www.tablesgenerator.com/markdown_tables

You could paste tables from MS Word (the code generated actually isn't that bad). It's probably the fastest and most intuitive way owing to the nice table drawing system Word has.

But either of these methods aren't responsive.

A possible method is to have the table allow horizontal scrolling via overflow-x

Any ideas?