Add a system of page-less nodes

[saltednut]

Since we will soon have relegated blocks to being an admin-only text-only layout element that's saved into config, we are going to need a content-based alternative that is a fieldable entity!

Big picture, what we want are page-less nodes.

We have several examples of entities that come close in Drupal contrib that we can compare/contrast and decide if we want to start from any of them, or would prefer to create our own.

---

Use Cases

1) Fieldable and typable block content: I often need to create a type of content that will only be viewed as a Block. Example: an Ad block that consists of an image field, a link field, an (optional) text field, and can be placed into a layout. Solutions: Bean or entity construction kit

2) Content without a "page" I often need to create a type of content that will only be seen in a view. Example: a "Slider item" that consists of an image field, a text field, an optional description field and an optional link field. Solutions: entity construction kit or Rabbit Hole module

3) Content as part of other content I often need to create a type of content that will only be seen as part of another piece of content. Example: Example: media-rich content. Sometimes content editors want to insert some media items between text paragraphs: sliders, photo galleries, maps, video, etc. Solution: paragraphs or entity construction kit + inline entity form or field collection or multifield

~~4) Grouping fields together (not a great fit for pageless nodes) I often need to group my fields together, so that when I add another "field" I'm actually adding another "Set of X fields". Example: A "contact person" may consist of a name field, email field, and phone field. Solutions: field collection or multifield~~

---

PR by @serundeputy: https://github.com/backdrop/backdrop/pull/2049 New PR, rerolled and tweaked by @herbdool: https://github.com/backdrop/backdrop/pull/2286

[olafgrabienski]

@herbdool Thanks for your feedback, also on the PR page! I'll have a look at it over the weekend.

[MrHaroldA]

I haven't touched Backdrop in quite a while due to a new job, but here's what I tested:

1. Create a 'memow' with path alias 'test'
2. Create a 'page' with path alias 'test'
3. "The alias is already in use."

I'd recon that the pageless 'memow' shouldn't claim a url alias.

[herbdool]

Good point @mrharolda. We may need to disable path aliases and menu links for a content type with this enabled.

[olafgrabienski]

I was curious to test how people were thinking of using it for translated blocks. When I enable a second language and then translate a node and then insert the node into a layout directly, it doesn't show the translated node when switching languages.

Oh my, you're absolutely right! When I insert a node in a layout, I have to pick content of a certain node ID. As a translated node has a different ID than the 'original' one, I have to decide which one to include: the original or the translation.

Thanks a lot for testing this, I should have done it long ago! (In a way it's funny, that we didn't noticed this in the whole discussion about Translating blocks over in the Backdrop4Good issue. (Will report the problem also there.)

At the moment, I'm not sure what to do regarding the not working translation approach. On first sight, it doesn't seem to be crucial for this issue which actually isn't about translation but about pageless nodes. On the other hand it feels strange to introduce the pageless option knowing that one of its main use cases (Fieldable and typable block content) ends up with not translatable content. Opinions?

[herbdool]

@olafgrabienski even though the more direct approach doesn't work, you can still create a views block and put that into the layout. Then assign blocks with a taxonomy term. The view block can filter by the term. Or put a reference field on a content type and show those in the layout as a field. Both aren't as direct but might work for you case

[olafgrabienski]

@MrHaroldA @herbdool The URL alias is an interesting topic. Do we need it on pageless nodes? Not necessarily because main use cases as SEO, or URL readability for visitors, are not so useful here. But URL aliases don't really hurt in my opinion, and they might however help editors or administrators with readability.

What happened to @MrHaroldA could however happen with any other content type, be it with or without pageless setting.

That said, I agree with disabling menu settings / links for pageless content.

[olafgrabienski]

@herbdool Thanks for the views block idea. Do you intend a views block with Filter criteria "Current user's language"? Just an idea: Such a criteria could be a new approach to make node blocks language aware.

The Views Filter criteria "Language" includes:

• Current user's language
• Default site language
• No language
• English
• (other site languages)

In contrast, Block visibility conditions provide only:

• Default site language
• English
• (other site languages)

So, maybe we can add a Block visibility condition "Current user's language" to Backdrop and make sure that an existing content block recognizes the translation nodes. As I said, just a first idea ...

[herbdool]

Yes, you need to use that filter in views.

It's a good idea for layout but it needs to know what to switch it to. It's got to be smarter about using the translation set on a node.

[mazzech]

Thank you @olafgrabienski for reporting... I am not sure if I understood all the points correctly, but IMO a "simple" (from my non-coder perspective;-) additional language parameter for placing blocks in core could do the job, pretty similar to what Views does. This problem will affect any "inserted" content item in i18n projects, they have to be language aware in one or another way (e.g. newsletter signups form).

BTW, I hope to make it to Drupalcamp Ruhr, maybe we can deepen the discussion there:-)

[olafgrabienski]

@mazzech Thanks for your feedback! I think also that blocks could learn form Views. I'll try to check how Views works exactly in similar situations when I find time.

And yes, hope to see you at DrupalCamp Ruhr!

[olafgrabienski]

you can still create a views block and put that into the layout. Then assign blocks with a taxonomy term. The view block can filter by the term.

@herbdool I'm not sure if I got your views block idea correctly. IIRC, as each block represents a single node, each block would have to use a different term. Do you mean to filter by these terms with a contextual filter? If yes, I could need another hint how to configure it.

(When I assign all blocks with one taxonomy term and filter the view by this single term, all tagged blocks will be displayed in the layout.)

[herbdool]

@olafgrabienski I had to go back and look at how I did it. It was actually a bit rudimentary which was okay for the low complexity of the site. I created a block for each "snippet type" taxonomy term. The term just specified the location, e.g. front page button, blog page, etc. Then each translated node has the same term.

I'm sure there's a more dynamic way to do it with a contextual filter, off the top of my head I'm not sure.

[olafgrabienski]

@herbdool Thanks for your looking up your workaround, indeed reasonable for not too complex sites!

[olafgrabienski]

@ everyone interested in the nodes as blocks translation approach: I've finally filed a request to solve the current issue: Blocks of existing content should follow the translation system

[jenlampton]

No progress on this PR since the 1.9 release, removing milestone.

[alexfinnarn]

Hello all. I am very interested in this issue and would like to test out some of the proposed solutions.

As I'm reading through this issue, it seems like the Rabbit Hole module is a viable option and the first thing to try? Or would you suggest other modules to test?

For my use case, I'm trying to create "node layouts", essentially, that wrap around a node and provide a layout outside of the content section. The Layout admin UI is great, and I'd just like to have a "node/%/layout endpoint to control each node's version.

Anyhwoo...the "pageless nodes" (we use Beans in D7) would be placed in these layouts so it would be nice to edit them from the Layout admin screen like was mentioned before.

I'd be happy to review the latest and greatest ideas in Backdrop core or contrib for implementing this feature.

[jenlampton]

hi @alexfinnarn and thanks for your interest in this topic.

As I'm reading through this issue, it seems like the Rabbit Hole module is a viable option and the first thing to try? Or would you suggest other modules to test?

Rabbit hole will prevent you from visiting the node/% page for any node type that you want to use as a block, in a layout. I'd definitely recommend giving it a try.

For my use case, I'm trying to create "node layouts", essentially, that wrap around a node and provide a layout outside of the content section.

Great, this is what Backdrop core provides when you create a layout at the path node/%. :)

The Layout admin UI is great, and I'd just like to have a "node/%/layout endpoint to control each node's version.

What do you mean by each node's version? Are you looking for a different layout configuration for each node revision?

the "pageless nodes" (we use Beans in D7) would be placed in these layouts so it would be nice to edit them from the Layout admin screen like was mentioned before.

We allow people to edit blocks from the Layout UI, so there's a precedent for allowing people to edit content from there too, but the "Existing content" block doesn't allow it, currently.

Maybe this should become part of Rabbit Hole module, temporarily? We could provide a new block type that works much like "Existing content" (we could call it "New content", or something) and when used, it would allow people to create content of any type, and drop it into a Layout. Once placed, maybe we have an additional drop-button action for "Edit" that would allow editing of the content from the Layout UI, in addition to the "Configure" option.

[alexfinnarn]

The best way for me to explain what I'm trying to accomplish is probably to just show what we have in D7.

Every node has a layout route that users can click on to alter what is in the sidebar, before/after content, and other regions defined in the active theme. The layout is active only for the current node and doesn't need a context like node/%...but maybe creating one layout for nodes would work, if I experimented more.

Once a user gets to the layout edit screen, they get a jacked up rendition of where the theme regions live and sections that pertain to adding existing or new blocks to the regions. I like the Backdrop forms and modal for editing/adding/rearranging blocks way better than what we have now.

With the current layout system in Backdrop, I think a user would have to create a node, grab the node ID (3 for example), then make a layout with only node/% as the path and node/3 as the visibility condition. I think I also would need to add the existing content around the other blocks in the layout.

We want to avoid all the jumping around and just tell users to click on "Layout", add their blocks, and be done with that individual node. We wanted to have base layouts that users could override, say a layout default for a content type that would be overridden when you saved a layout tied to that node.

Also permissions...we don't want users to be able to edit any layout, but only one that would be cloned to their node as the default. I see there is clone functionality. And multiple Layouts per path as Context allowed. I'm not seeing that so far.

All of this is ramble-y and spans many issues so no need to continue my ramble, but I was trying to make a contrib module I call "Node Layouts" to do what I mentioned above. My description is just an example of a use case for "pageless nodes" or beans/fieldable blocks.

I'll check out Rabbit Hole for your comments in the last paragraph, but we don't want some of the baggage of nodes, like authoring information. Since we know the Bean module, I guess we will be comparing options to that D7 module and how it fits into our current layout workflow.

[klonos]

@alexfinnarn I believe that you are referring to #2894 and/or #1131 and/or #1126. Right?

I think that Rabbit Hole is a good fit for core. I was giving some media-related features in D8 a spin, and I saw that fieldable media assets by default get a /media/MID path (similar to /node/NID). If people want to hide them or even restrict access to them, they have very little options ATM (or they need to custom-code something). With a rabbit-hole-like functionality, this problem could easily be sorted in such cases.

[alexfinnarn]

For #2894, "What you suggest (different layouts per node) would be ideal..." and "Per-node layouts and per-content type layouts would make great contrib modules." Yes to that. The default layout is the content type layout and then when a user goes to "node/%/layout" they see how the blocks are placed in that layout and create a custom layout for that node if they save it with any changes.

For #1131, the user wouldn't be able to pick the layout but go to "node/%/layout" to arrange the blocks on a particular layout. We actually only really have one template so the user isn't choosing between those. It's just that every node can have different blocks in the layout, so I think there would be a layout per. I like the idea of choosing between predefined layouts with predefined blocks places in them, because that would reduce complexity and help with performance, but our users are used to the way it is now, and I don't think we can budge too much on what we setup. They seem to really like the option.

One idea would be to make a layout with the template we like and add a block to each region that dynamically places other content into it based on the current node. That way, out layout form can be saved and tied to a node ID. When the layout is rendered, the content of the block ties the "node/%/layout" values to the regions. I think that might work for our use case and would make it so only one layout would be stored in config rather than mix in content with the layout. I think it would also prevent layouts from pointing to deleted content/blocks...this might be my contrib module stab.

Thanks for pointing me to those issues @klonos! I will follow up in them instead of continuing in this issue since I am straying from the issue's main concerns/topic.

[docwilmot]

Per-node layouts and per-content type layouts would make great contrib modules

I'd actually ported Panel Nodes a long while ago and forgot about it. A few issues to consider in the queue but it works.

[kevincrafts]

The issue I see with Rabbit Hole is that from the administration side, the content seems all the same and on a larger site I think site editors could get confused when they see node/page based content in the same list as node/block based content.

On a site that has 500 nodes and 300 blocks, not having distinct admin areas for them can complicate the work of the current editors and on boarding of new editors.

Keep in mind that @alexfinnarn are coming at this from the perspective that the large majority of our site editors are not web experts - they are doing all the changes on the site themselves, not contracting someone to do it for them.

[jenlampton]

I'd actually ported Panel Nodes a long while ago

This is great! It might also be worth looking at Panelizer. I suppose it depends on what editors were used to before. Because Layouts is a port of Panels, any panels-based module in D7 shouldn't be too hard to get working in Backdrop.

On a site that has 500 nodes and 300 blocks, not having distinct admin areas for them can complicate the work of the current editors and on boarding of new editors.

As long as the "blocks" are nodes (and not blocks) separate admin areas for each will be a sinch using Views (or both Views and Layouts) :)

[herbdool]

This issue seems to cover a lot of different stuff but I think the meat is around a simple Rabbit Hole implementation (e.g. https://github.com/backdrop/backdrop-issues/issues/100#issuecomment-354512657). I've rerolled @serundeputy's PR and tweaked it https://github.com/backdrop/backdrop/pull/2286.

[olafgrabienski]

Thank you, @herbdool! I've tested the new PR on the sandbox site, it looks great!

Quick report:

• created a new content type, in Display settings enabled the setting "Prevent visitors from seeing content on its own page"
• visited such content as Administrator => accessible = ok
• visited it as Anonymous => not found message = ok
• checked the default permissions => ok
• changed the permission for Anonymous => ok (after clear cache "Page and else")
• created a test page and placed a 'pageless' block of existing content => ok
• created a views block of 'pageless' content and placed it on the test page => ok
• created a respective views page => ok
• tested the settings and permissions on an existing content type (Post) => ok

Issues:

Found only one so far: After a "not found" message regarding 'pageless' content, I see also the following warning in the DBlog:

Cannot modify header information - headers already sent by (output started at /home/qa/github/backdrop/backdrop/pr/2286/core/includes/bootstrap.inc:1793) in backdrop_send_headers() (line 1610 of /home/qa/github/backdrop/backdrop/pr/2286/core/includes/bootstrap.inc).

Language related suggestions (not a native English speaker, though):

(a) The term "pageless" is mentioned on the Permissions page but not in the Content type settings, I'd suggest to mention it for reference also in the Content type settings:

Prevent visitors from seeing content on its own page. The Pageless content can still be visible in a view or a block, but will be hidden to those without the proper permissions when accessed as a full page.

(b) On the permissions page the use of the "pageless" term is a bit overwhelming, let's use one less:

Bypass pageless content restriction. View pageless content regardless of pageless setting as a full page.

Summary:

• Looks very good.
• PHP warnings need work.
• Language questions may need feedback of a native speaker.
• We had already made many progress before. With this PR 'pageless' content could become part of 1.11 in my opinion.

Follow-up ideas:

• Disable 'pageless' setting for the Page content type delivered by core?
• Don't display menu settings on pageless content types.

[herbdool]

@olafgrabienski happy to improve the language. It's hard to explain the concept in just a few words so it can be improved.

I'm trying to figure out the conditions for when the error appears. I think it might be an issue of when the page is cached and then this module tries to override by showing a 404 page instead. E.g. error:

Warning: Cannot modify header information - headers already sent by (output started at /home/qa/github/backdrop/backdrop/pr/2286/core/includes/bootstrap.inc:1793) in backdrop_serve_page_from_cache() (line 1766 of /home/qa/github/backdrop/backdrop/pr/2286/core/includes/bootstrap.inc).

[herbdool]

@olafgrabienski I tweaked the code to try get rid of the "headers already sent" error. Can you give it another spin? I couldn't recreate the error consistently so just need to see if we can cause it.

[olafgrabienski]

It's hard to explain the concept in just a few words

Indeed! So let's improve it a bit but not wait for the perfect solution.

I tweaked the code to try get rid of the "headers already sent" error. Can you give it another spin? I couldn't recreate the error consistently so just need to see if we can cause it.

After your code tweak, I couldn't reproduce the error. To test it on the sandbox site, I visited a 'pageless' node as an anonymous visitor without the 'bypass' permission ("not found" as expected, no other error), then enabled the permission for the role so that anonymous visitors could visit the node without restrictions, and disabled the permission again (just "not found" again).

[herbdool]

@olafgrabienski thanks for testing.

I think this still needs some work. There are some situations we need to account for: when someone has permission to edit/create the content but does not have permission to view it on its own page. They would see "page not found" once they saved it. (I saw that Rabbit Hole accounts for this situation by redirecting back to the edit page and core redirects back to the front page if someone doesn't have access to view a node). And we may also need to account for node previews (if/when it is merged) -- should they be able to preview the content but exclude the default/full display mode?

I'm also thinking that this combo of "page not found" and a permission to bypass is just more confusing than a permission to view the full display mode where it could be set up per content type and per role.

[kevincrafts]

I'm confused as to why someone could create/edit but not view. I don't think it should be a requirement that the pageless content be placed somewhere else for it to be viewed.

But if content needs to be placed to be viewed by anonymous users, why does it need a preview? Why not just save, and view, then place?

[olafgrabienski]

when someone has permission to edit/create the content but does not have permission to view it on its own page. They would see "page not found" once they saved it.

Good point! As you say, "core redirects back to the front page". That happens for instance, when an editor has the permission to create or edit content, saves it as draft, and doesn't have the permission to view unpublished content. A comparable situation, in my opinion. Can we do the same redirect to the front page (instead of the "page not found" message) if someone has permission to edit/create content but not to view it on its own page?

Regarding the upcoming node preview, I'd say we shouldn't prevent a preview of the default / full display mode even if the editor doesn't have the pageless bypass permission. The preview is a part of the editing experience, and if an editor doesn't have the respective view permission, I can't imagine it intentional but due to a permission misconfiguration. (Same applies to the upcoming preview feature in case of a missing "view unpublished" permission, in my opinion.)

Re "combo of 'page not found and a permission to bypass" vs. "a permission to view the full display mode per content type", I find the latter more problematic at first sight: Wouldn't it mean, that a site builder had to enable this permission on all existing content types (except the pageless ones) for the anonymous and the authenticated role?

[herbdool]

@kevincrafts that's existing core functionality. As Olaf pointed out someone could have permission to create/edit but not have permission to "view unpublished". So that part isn't going to change. I'm pointing out the same situation applies with this PR (currently). A possible change (though I'm not sold on it yet) is to exempt authors (and anyone who can edit?) from the pageless restriction.

As for the preview, we'll have to see how it work once it's merged. I agree that they should be allowed to see a preview even if they can't view the full page.

At any rate, we're using the Rabbit Hole paradigm for this PR and thus has some oddities when being used with nodes which we built with paths.

[olafgrabienski]

A possible change (though I'm not sold on it yet) is to exempt authors (and anyone who can edit?) from the pageless restriction.

Sounds reasonable!

@herbdool So far the issue has no milestone. Do you think it makes sense to tag it for 1.11, or would that be to hastily?

[quicksketch]

Well, we've got a few days, but the PR is much more limited. I'm down for trying, if we can get an implementation we're satisfied with. Thanks @herbdool for really simplifying this down to the main concept, I think it's a good direction.

[quicksketch]

I posted a code review https://github.com/backdrop/backdrop/pull/2286#pullrequestreview-151150847

I'm also thinking that this combo of "page not found" and a permission to bypass is just more confusing than a permission to view the full display mode where it could be set up per content type and per role.

I agree, a permission to view the full node by type would be easier from an end-user perspective. However, I don't think we should attempt to cover that here. View permissions are not included in core because they can so easily get very complicated and sites have different requirements (hence the plethora of Node Access modules like Permissions by Term, Workbench Access, Domain Access, Organic Groups, etc).

---

For reference, here's the current PRs language on enabling this option:

• Regardless of the description on the checkbox (or radio button), we shouldn't end in a period for consistency.

Here's another stab at language:

• [ ] Hide full page display If enabled, the URL for this content will return a "Page not found", preventing it from being accessed directly. It may still be placed as a block or within a listing. Users who have the "Access page-less content" will still be able to visit the full page URL.

To handle the "author may not be able to view the content" problem, we should modify the submit handler of the node form to redirect to the node/x/edit URL on save.

[herbdool]

Thanks for the code review @quicksketch. I've made some tweaks to the language. I used a slightly different permission: "View page-less content" since users can still edit and view as embedded so "access" didn't seem right.

I added the redirect to the edit page in the submit handler.

I didn't have any luck with using MENU_NOT_FOUND in that context. (See comment on review).

@olafgrabienski perhaps you want to take another look as well.

[olafgrabienski]

Sure, pleased to have another look at the sandbox site! Looks good overall, I also like the new language. I've however found two issues:

(1) The help text at content type setting is missing a word:

Users who have the "View page-less content" will still be able to visit ...

Should be:

Users who have the "View page-less content" permission will still be able to visit ...

(2) The "View page-less content" permission seems to not work anymore: I wasn't able to visit the full page of a "pageless" node as an Editor, got the "not found" error irrespective of the permission. (I had created an account for that role before, you should also be able to test it quickly when you give anonymous the permission temporarily.)

[alexfinnarn]

I made a small comment on the language https://github.com/backdrop/backdrop/pull/2286/files#r214403934. When I read the original first sentence, it made me not want to use the feature or think about how it could be used, because ain't nobody got time for a "Page not found" error. I think stating the purpose of the "pageless node" feature before the caveat makes it sound more powerful and less scary.

[kreynen]

I'm stuck on the terminology too. I mentioned this a few weeks ago when @quicksketch and @jenlampton were on campus and we were reviewing the options Backdrop has for replacing our D7 Bean based layouts, but I really struggle with the "pageless/page-less node". It doesn't seem straightforward enough novice users or technically accurate enough for technical users.

I don't want to derail the progress with bikesheding, but rather than describing these as "pageless/page-less nodes" I'd like to suggest changes to the terminology.

What about "direct path access" (the default) vs. "disabled path access" content types?

The option in the content type could read "Disable path access". Path is a term that is already used when configuring content types so it's a term site builders are already familiar with and more accurately describes what is changing. In most configurations, Page is a content type. So a node type that uses pageless in a way that doesn't refer to the content type will always be confusing.

From a technical perspective, I understand what is happening here and I think this will work for us. Currently we alter Beans -> Blocks for Site Owners replacing the default admin/content/blocks with a view of beans. This creates a lot of confusion every time we work with someone who is more familiar with Drupal than our custom install project. What we would likely do when shifting to Backdrop is avoid trying to repurpose the term block and label the different non-path accessible content types we used to create as beans as "boxes" or "bricks". We'd remove them from the default /admin/content view and add an additional tab for /admin/content/boxes or whatever non-block naming convention we go with to replace beans.

[herbdool]

Thanks @olafgrabienski I fixed the permission error and tweaked the help text (also based on other comments).

@kreynen so far none of the terms hit the spot. "pageless" isn't great either but to me it still seems better than any other suggestions. I think mentioning "path" in the help could improve the conveying the concept, though for a single term I wonder if "pathless content" works better. Though I'm not sure if it conveys as strong a concept as "pageless".

[kreynen]

But the content still has a path? It's not pathless. This just prevents most users from accessing it using the path and would provide a flag for contrib modules like XML Sitemap and Linkit not to include nodes of these types.

I know "beans" isn't a great name or acronym, but it does convey what makes these entities different and how they are designed to be used. I understand the advantage of not introducing another fieldable thing that needs to be maintained into the core code base. Very smart. But if you don't want to give these a name like boxes or bricks, using terminology that accurately describes what is making this content type different from the others makes a lot more sense to me.

For this to work well, it's going to have to be embraced by contrib... that requires explaining it.

[herbdool]

@kreynen yeah it still has a path and a page so I agree the terminology isn't great. How about this for the permission: (I updated the PR with it) "view hidden path content" (or maybe it could be "view hidden path of content" or even "view hidden path display" to match the toggle). That's more accurate. It has a path but we've hidden it by default.

[herbdool]

I tweaked the permission again. Now it's "view hidden path display".

[herbdool]

Note that I'm trying to avoid labelling the content itself and hopefully avoid some bikeshedding. Maybe we can kick that can down the road in future PRs which try to add to the concept.

[herbdool]

Another quick review @olafgrabienski and anyone else?

[kreynen]

Are you going to change the node_type_get_types function in https://github.com/backdrop/backdrop/blob/1.x/core/modules/node/node.module#L380 so that every module won't have to get all the types and filter out the hidden/non-hidden options and add support to Views to be able to select all nodes of any content of either type?

[kreynen]

I'm trying to configure this how we'd actually use it. Not being able to filter views by types is a problem, but simply creating the number of bean types we currently have as pageless node types quickly impacts the usability of the core UI.

Currently node types and bean/block types are separated in UI.

While I understand that having this many content and block types is unlikely to be a usecase 80% of the Backdrop userbase shares, larger organizations are going to need additional functionality in core and views to be able to alter the UI into a usable state.

[herbdool]

There was no discussion about altering node_type_get_types() but perhaps at minimum we can add a views filter to expose the hidden flag. I can't recall where else we've exposed config settings to views but seems like a good idea in this case.

[herbdool]

@kreynen since you expressed interest in the views filter would you be able to produce some sample code for me to add to the PR? I'm not sure if I have time to add it before feature freeze (currently only have small bits of time here and there and not likely to have much time on this Canadian long weekend.

[kreynen]

We have a long weekend in the US too and @kevincrafts (our UI/UX manager) is off next week, but I'll see what we can do.