Even though we've only had about a week between v1.3 and v1.4, this new version comes about 40 quick commits later, but offers several new features. Let's look at the big ones.
Custom Menu Builder
We hadn't given much attention to menus in the past. But I was beginning to see some issues with hard-coding menus, and getting requests for different behavior on menus.
Therefore, although simple at first, we now have a custom menu builder.
To stay consistent, simple, and predictable, the menu builder works just like pages. Menu items are nestable, and you drill down by clicking through to children, and following breadcrumbs in the title.
And I also added a quick snapshot of the entire menu. Although there is no editing capabilities from this screen, it does offer an ability to see the nested lists in one shot.
Menus are nice and easy to render. The menu itself has a
slug, which is used when you call
<%= viewer_menu(slug) %>.
See the doc page for more information.
Custom Error Pages
I'd been putting it off, but I finally added in custom error pages. No longer do we default to the standard Rails error pages.
Sapwood itself comes with two sets of
500 error pages.
Builder errors in development will still lead you to the interactive errors page so you can see what's going on. In production, we land on static error pages, but still get the error notification.
The viewer is only trapping two errors at the moment (see below for more information). Trapped errors will render a more dynamic error page. The default
404 page will render a list of search results, while the
500 page has a simple message.
Custom Error Pages
Overriding error pages in your individual site's is simple. Just add a
404.html.erb and/or a
500.html.erb template in your
Note: These error pages will only be rendered for the errors being trapped (see below).
Also note: You still have access to your assets, since we're rendering an
erbtemplate, but you may not have access to the
current_pageobject, depending on the error.
On the viewer (in your public sites), we are trapping two errors:
This is just to start simply and see how it works.
When an error occurs, it is saved in the database. You can access these errors through your builder application.
The trapped errors also act as a checklist in a way, as you can close errors when you have resolved them. This is the first step in making this process much more dynamic.
All Markdown, All the Time
While Sapwood aims to be flexible, I was being a little too flexible when it came to editing text. There are three important changes to note.
First, we're now only using markdown. Markdown is easy to learn and this way we can be much more flexible with how we handle editing.
Second, because of the first point, I also added the ability for any field to be a markdown field, which will automatically load a markdown editor and parse it on save.
And last, I stopped using my self-built markdown editor. Instead I found this awesome editor and began using it. I plan to work on this project a bit and enhance how it works with Sapwood over time, but for now this is still a significant improvement over my self-built editor.
The last major update is about bringing settings into the database. As you probably know, there are two types of settings in Sapwood:
- Sapwood (app) Settings
- Site Settings
Sapwood settings are those that affect the entire application. Because some low-level tasks rely on these settings, we aren't using the settings in the database just yet, but we are using v1.4 to bring those settings into the database. They will be used in the future.
Meanwhile, site settings have previously been included in a
utilities/config.yml file in each site's repo. No longer does this need to be the case. Now those settings will be kept within the database, and they are editable in the builder (under Settings).
You can still access site settings the same way. See the doc page for more information.