In order to resolve persistent conflicts with date-based permalinks, we should implement support for parts in the $param<regex> format.

This will allow us to replace :year with $year<\d+> in the route definitions sent by the B3 REST API, and prevent the router from mistakenly sending post and page requests to a date archive.

We're following Play! Framework's example, so for more (but not much more): https://www.playframework.com/documentation/2.1.1/ScalaRouting#Dynamic-parts-with-custom-regular-expressions

(Although they serve different purposes, implementing this will make route patterns 100% consistent with the ones used for setting up custom API endpoints in the B3-REST-API project.)

Everyone on the team is using Sass now, and even Bootstrap 4 will have it as their default. (We don't have to wait, there's a Sass-based Bootstrap 3 we can use at twbs/bootstrap-sass).

Since the CSS provided by B3 is minimal, porting the stylesheets to SCSS should be trivial.

Third party plugins will often enqueue scripts on the frontend that interfere with B3's loading process.

These scripts must be saved to a JavaScript array and dequeued with dequeue_script(). On the JavaScript side, the application should require them.

Here's a wild idea: make it possible for each view to configure a transition animation when navigating to another view using the Navigation behavior. A transition function or setting may be passed via the options object/callback to the Behavior.

Consider this a really low priority request, we have bigger fish to fry at the moment.

Requesting a post attachment (for example, http://local.wordpress.dev/2013/03/tiled-gallery/attachment/man-of-steel), causes the application to attempt to GET /posts/b3:slug:man-of-steel instead of (the new) GET /media/b3:slug:man-of-steel.

Navigation behaviors should be combined into a single navigation behavior that looks at the URL and decides the best course of action. I've whittled them down to four (NavigationArchive, NavigationHome, NavigationPost, NavigationURL), but they use different approaches: some take slug and IDs from the anchor element, others parse the URL.

We should either stop relying on ID and slug attributes (href should be enough) or embrace them and create a consistent interface for them.

That way we can fully reuse the Navigation behavior, which should handle linking around the application. For example, rather than handle its own links, the MenuItem behavior should declare support for the Navigation behavior. Post content, widgets and archives should all support the same Navigation behavior as well.

Try it: go to http://<root>/page/3. B3 ignores the request for page 3 and always displays the first page.

Navigating straight to a deep link does not update the menu appearance.

For example, pointing your browser to http://b3.dev/category/images does not highlight the menu items in the Category > Images path.

The onMenuItemUpdate event handler in the new MenuItemActivation behavior should also look at the menu item's object (containing the post or term ID), object_parent and object_type to determine whether the menu should be highlighted when the application loads.

A pre-built Sinon isn't fetched by Bower, we will need to build it ourselves.

In the meantime, do the following as a workaround, starting at the B3 project root:

$ cd bower_components/sinon
$ gem install juicer
$ npm install formatio
$ ./build
$ cd ../..
$ gulp bower

Since B3 requires PHP 5.3 as a minimum, there's no reason not to use namespaces and setting up Composer to autoload theme classes.

When I try to access http://local.wordpress.dev/2014/09/hello-world/ directly, the app attempts to fetch a page resource from the API:

GET http://local.wordpress.dev/wp-json/pages/2014/09/hello-world/ 404 (Not Found) 

I get the same error if I change the permalink's front. So, for http://local.wordpress.dev/my-posts/hello-world/ I get:

GET http://local.wordpress.dev/wp-json/pages/my-posts/hello-world/ 404 (Not Found) 

Comments left by the post author should have the bypostauthor class.

The navigator should prevent event defaults for internal links, and allow external links to lead out of the site.

Stylesheet should use classes, not IDs. Add classes to templates wherever necessary.

Running a search with http://local.wordpress.dev/?s=hello doesn't work (http://local.wordpress.dev/search/hello does, by the way).

WordPress should only generate search links in the appropriate format, we should take inspiration (and code) from Soil:

https://github.com/roots/soil/blob/master/modules/nice-search.php

Use npmjs.org/del instead, see https://github.com/gulpjs/gulp/blob/master/docs/recipes/delete-files-folder.md.

1. Navigate to a list of posts.
2. Using the pager, navigate to a page other than the first.
3. Click to view one of the posts.
4. Go back on the browser.

The URL references the list page you were on (say, http://local.wordpress.dev/page/2), but the list itself shows the first page (the pager goes back to page 1 as well).

JavaScript builds behaving badly.

DisplayTaxonomy duplicates most of the DisplayLink behavior code. I'm keeping it around for now, but I am marking it as a candidate for refactoring.

What happens when Google tries to crawl a site that uses a B3-based theme? What if a user's browser doesn't support JavaScript?

The theme should be able to detect these situations and serve the user/crawler a server-rendered version of the page. This can be done by:

Rendering the B3 application using Phantom.js

• Pro: Visual fidelity.
• Con: Requires Node.js on the server. While it's the best possible solution, this requirement alone makes me not want to go this route, since it severely hampers compatibility, ease of use and, ultimately, adoption.
• Con: Anything not available on page load (as a result of further on-page interaction, timed events, etc.) may not be displayed.

Serving the content using a secondary theme

• Pro: No extra dependencies, WordPress handles theme switching.
• Pro: Fallback is possible using the theme's own PHP resources, it's not necessary to install a second theme for this.
• Con: Unless the secondary theme is custom-built to look the same (read: extra work), the page will not match the B3 application's visual style.

Keeping a single theme, but reusing some components

• Pro: We may be able to reuse WP API models.
• Pro: We may be able to render the same Dust templates on the client and the server.
• Con: Everything in between (views, custom helpers, controllers, etc.) has to be duplicated, in PHP and JavaScript.

How to reproduce (I'm using the wptest.io dataset for this):

1. Search for "super"
2. Results appear
3. Instead of clicking on a result, pick a post category
4. Now go back to the search box and add "califragilisticexpialidocious"

The request is made and the collection is updated, but the view is still showing the previously selected category.

Resetting the search (which triggers a view teardown event) resolves the problem.

So . . . always tear the view down on a search lookup?

Links in the format http://local.wordpress.dev/{post}/#comment-{comment-id} don't work, the fragment is clearly confusing Backbone.

Duplicate #3

When viewing a paged post, all pages start out being displayed.

Setting post permalinks to /%year%/%monthnum%/%day%/%postname%/ results in <host>/%7Byear%7D/%7Bmonthnum%7D/%7Bday%7D/tiled-gallery URLs.

It's not the PaginationView that should have a Pagination behavior.

Rather, it's the ArchiveView and PostView that should mixin that behavior.

Let's have some live updates going!

What's needed:

1. Enqueue the WordPress heartbeat script.
2. Listen to the heartbeat-send and heartbeat-tick events.
3. Profit!

heartbeat-tick

This event is triggered approximately every 15 seconds (the default).

$(document).on( 'heartbeat-tick', function(e, data) {
  // Update your models and collections and views and gewgaws here!
  console.log( data );
});

heartbeat-tick supports "namespaces" as heartbeat-tick.{handle}, which is the recommended approach if we know what we're looking for. There will be a heartbeat-tick.b3 specifically for our stuff.

Taking the heartbeat's pulse will allow us to take action and update content on the fronted whenever changes occur server-side.

Enqueuing data and heartbeat-send

We probably won't need this now that we have a fancy REST API, but the WordPress Heartbeat provides a method to allow us to send data back to the server. (Although I can see this could be useful if we ever need to implement a way to enable/disable certain notifications.)

wp.heartbeat.enqueue(handle, payload, override);

Mind the "enqueue" thing: the payload isn't sent immediately, it's enqueued and sent only on the following tick. You can check if your data was sent using wp.heartbeat.isQueued(handle), which returns the data. If you need to change or replace the payload, you can re-enqueue the object using the same handle and the override flag set to true.

Theres a wp.heartbeat.dequeue(handle) method as well.

When this data is finally sent, a heartbeat-send event is triggered:

$(document).on('heartbeat-send', function(e, data) {
  // If you change data here, it will also be sent back to the server
  console.log( data );
});

The server receives this data via POST and is able to make changes to send back to the browser through the heartbeat_received and heartbeat_nopriv_received filters. (The nopriv option is for guest users.) The browser will then receive all the data on the next heartbeat-tick.

Internal router/href parser doesn't seem to be figuring things out correctly:

• Opening http://<host>/about directly loads the correct page.
• Navigating to the About page via the menu (same URL) loads the yearly archive.

How to reproduce:

1. Go to any post page (e.g. "Hello world!").
2. Start searching.
3. The links in the results list do not work.

However:

1. Go to any archive (main index, category, etc.)
2. Start searching.
3. The links in the results list are working.

Post views don't have the same click events/behaviors as archive views. Aren't search results always put into an archive view?

Create a new LayoutView for the root regions, which should be kept separate from app initialization logic.

By default, links are in the form:

http://local.wordpress.dev/{post}/#comment-{comment-id}

When requesting http://local.wordpress.dev/category/parent-category/child-category-02:

Archive:

(Total: 0)

Note: Even though the total says 0, the list does contain posts.

When requesting http://local.wordpress.dev/category/child-category-02:

Archive: Child Category 02

This is a description for the Child Category 02. (Total: 1)

related: Router should be able to ignore trailing slashes

Links like the following confuse the router:

http://wordpress.local/post/category/parent-category/child-category-03/grandchild-category

I've had mixed results, from fetching just the top-level category to displaying nothing at all. The router regex must be adjusted to look past the slashes (but still stop at /page/:paged).

We should continue to improve the Sass/SCSS codebase to encourage modularization and reuse.

For example, this link:

<a id="1" slug="hello-world" href="http://local.wordpress.dev/hello-world/">Hello world!</a>

Sends the visitor to http://local.wordpress.dev/2014/9/hello-world. While this does not affect the site's operation, the address mismatch could affect SEO.

(The date format in the URL is incorrect, by the way, it should be zero-padded.)

Methinks the view loading class is a prime candidate to be turned into a behavior.

Easy to switch on or off the behavior, configure its options from the view, or even subclass if you need deeper changes.

Since behaviors already listen to the view's events, it should be pretty easy to know when each view is waiting to load, etc.

The recent switch to Sass broke the .screen-reader-text class styles.

So any post that supports replies should declare support for the Reply behavior instead.

Individual comments support the Reply behavior too.

I'm kicking myself that I didn't look at Behaviors sooner!

Requesting a category URL like http://local.wordpress.dev/category/parent-category/child-category-02 causes the application to GET /posts/b3:slug:child-category-02.

This seems to be caused by routes not being given in the correct order.

Links with dates should be zero-padded.

Expected: <root>/2014/01/hello-world/

Actual: <root>/2014/1/hello-world/

• Author header
• Date header
• Header should include data from the taxonomy or author being displayed (title label, description, etc.)

See:

• GET /wp-json/taxonomies/category (name, labels.singular_name)

Helper should take date and, optionally, format and run them through Moment.js.

If format is not given, it should default to the date format settings exposed by WordPress.