|
A CMS for Elixir/Phoenix that doesn't hijack your development workflow.
Thesis is a lightweight and flexible Elixir/Phoenix CMS for quickly and easily adding content editing to any page on a Phoenix website, as well as creating new dynamically routed pages. It's ideal for either adding limited editing support to existing Phoenix websites or building dynamic websites. Watch Jamon Holmgren give a 5-minute lightning talk about Thesis at ElixirConf 2017: https://www.youtube.com/watch?time_continue=2656&v=YqOwzXNkOyg |
|
You can't have it all. Thesis isn't the same as other -bloated- full-function
content management systems out there. This is a list of what it's not now and
not likely to be in the future.
|
| 0.3.1 |
|
0.3.0 - Removes the LZString compression for backups (page revisions) as per the conversation here. - Adds migration (run `mix thesis.install && mix ecto.migrate`). It is important to do this before 0.4.0 as the LZString dependency will be removed then. - Adds notifications. This allows us to warn users of potential Thesis issues depending on page state, environment, Thesis version, etc. Notifications can also be set in the host app config to include custom logic. - Bug fixes: page revision exception, add new page button hover issue. 0.2.0 - Adds a backup (page revision history) feature. Every time a page is saved, a snapshot of the page and content is captured and can be restored later. - Adds migration (run `mix thesis.install && mix ecto.migrate`). pre 0.2.0 - Core Thesis functionality: content areas, global content areas, file uploads, import/export, dynamic pages, page templates. |
| Thesis is currently considered Beta-quality, but is in production on several websites, including Infinite Red. The API is largely stable and we are committed to providing a clear upgrade path and documentation. |
If you are having problems, view README_INSTALL.md for manual instructions.
def deps do
[{:thesis, "~> 0.3.1"}]
end
def application do
[applications: [:thesis]]
endThis install script will add Thesis to your config/config.exs and lib/yourapp_web.ex, as well
as generate migrations and an authorization module in your lib/thesis_auth.ex.
<body>
<%= thesis_editor(@conn) %>$ mix ecto.migrate
Check out the example app in apps/example to see how Thesis can be implemented.
We'll keep this up to date with examples of the latest features as we develop Thesis.
Use the Thesis.View.content/4 view helper function to make a content area
editable. If you have use Thesis.View in your lib/yourapp_web.ex file, this function
is already available on all of your views.
Thesis will add a wrapper <div> around editable HTML and plain-text content
areas, both in read mode and edit mode, so plan your CSS accordingly.
Simply wrap your HTML in a content function call, specifying html as the content type.
<h1>Title</h1>
<p>
Here's my default description!
</p>becomes...
<%= content(@conn, "Section identifier", :html) do %>
<h1>Title</h1>
<p>
Here's my default description!
</p>
<% end %>Don't like the MediumEditor? Write your own custom editor implementing the common editor interface.
class MyCustomEditor {
constructor(opts) {
this.onChange = opts.onChange;
}
enable() {} // Setup Editor
disable() {} // Teardown Editor
content(editor) {} // Return content
set(name, data) {} // Set content
}For more detail, check out HtmlEditor or this gist implementing a custom editor using Trumbowyg.
To enable, add this in your config/config.exs file:
config :thesis,
html_editor: "MyCustomEditor"For plain-text, provide a do: option for default text.
<h1>My Title</h1>becomes...
<h1><%= content(@conn, "Title identifier", :text, do: "My Title") %></h1>For video embeds, iframes, and any other custom HTML, use the :raw_html content type:
<iframe width="560" height="315" src="https://www.youtube.com/embed/5SVLs_NN_uY" frameborder="0" allowfullscreen></iframe>becomes...
<%= content(@conn, "Section identifier", :raw_html) do %>
<iframe width="560" height="315" src="https://www.youtube.com/embed/5SVLs_NN_uY" frameborder="0" allowfullscreen></iframe>
<% end %>You can have the user specify an image URL and display the image with the image content type.
<img src="http://placekitten.com/200/300">becomes...
<%= content(@conn, "Image identifier", :image, alt: "My alt tag", do: "http://placekitten.com/200/300") %>If you prefer to use a div with a background image, you can use the background_image
content type.
<div style="background-image: url(http://placekitten.com/200/300)"></div>becomes...
<%= content(@conn, "Image identifier", :background_image, do: "http://placekitten.com/200/300") %>Thesis offers support for a few different ways to handle image uploads: store files in the database, point to an uploader/adapter inside your custom app, or use one of the prebuilt adapters (in progress).
For smaller websites and/or website that are hosted on the cloud, thesis offers a no-setup-required image uploader. Files are stored in a separate table and contain all of the needed metadata (name, file type, and blobs themselves). Keep in mind as you upload more and more files, your database will grow quickly. Don't use this for high-traffic, content-heavy web applications. Smaller personal websites are probably fine.
To enable, add this in your config/config.exs file:
config :thesis,
uploader: Thesis.RepoUploaderIf you already set up file uploads in your custom app, point thesis to a module that can handle a %Plug.Upload{}
struct.
config :thesis,
uploader: <MyApp>.<CustomUploaderModule>
The module should have an upload/1 function that accepts a %Plug.Upload{} struct. This function should return either {:ok, "path/to/file.jpg"} tuple with an image url or path, or {:error, _}. You can view
/lib/thesis/uploaders/repo_uploader.ex
for an example.
That's it! Restart your server and image content areas will now contain a
file upload field.
Content areas in Thesis are page-specific. However, if you want an editable
area that can be displayed on multiple pages, use the
Thesis.View.global_content/4 function. Any page using that content area identifier
will display the edited content across the whole website.
<%= global_content(@conn, "Footer Text", :html) do %>
<h4>Contact Info</h4>
<ul>
<li>Call us at (800) 555-1212</li>
<li>Email us at hello@example.com.</li>
</ul>
<% end %>Thesis adds an additional <div> around your editable content areas. We suggest that
you not style these divs heavily, since Thesis uses them as editors and adds its own styles
in edit-mode. However, sometimes, you need to modify that markup slightly for better presentation.
You can provide an ID and additional classes by specifying id and classes, respectively.
<%= content(@conn, "Ident", :html, id: "my-id", classes: "more classes") do %>
<h1>Title</h1>
<% end %>Thesis provides a settings tray to edit each page's title and description. In your layout, you can output the current title and description like so:
<title><%= page_title(@conn, "Default Title") %></title>
<meta name="description" content="<%= page_description(@conn, "Default Description") %>" />Some prefer to set the page title and description as assigns in their controller actions:
def about(conn, params) do
@title = Thesis.View.page_title(conn, "About My Company")
@description = Thesis.View.page_description(conn, "A relevant description here.")
endThesis supports users creating and deleting dynamically routed pages. These differ from static pages in that they are routed by Thesis rather than Phoenix, and live only in your database. They can be rendered with different templates.
To enable dynamic pages, add (or uncomment) this in your config/config.exs file:
config :thesis, :dynamic_pages,
view: <MyApp>.PageView,
templates: ["index.html", "otherview.html"],
not_found_view: <MyApp>.ErrorView,
not_found_template: "404.html"Replace <MyApp> with your app name. Use any view you want, and put any templates
contained in that view that you want to make available in the templates list.
These will be displayed as a drop-down to the user when they are creating the new
dynamic page.
You'll also need to make one change to your router.ex and a controller of your choice.
# web/router.ex
# should be added as the last route
get "/*path", <MyApp>.PageController, :dynamic
# web/controllers/page_controller.ex (or similar)
def dynamic(conn, _params) do
render_dynamic(conn)
endYou can pass in a default template (otherwise, it'll use the first template
option in your config) with render_dynamic(conn, template: "index.html").
You can choose to make only a portion of your website support dynamic pages by routing more specifically. For example, if you want a blog section:
# web/router.ex
get "/blog/*path", <MyApp>.BlogController, :dynamicYou probably don't want your website editable by the world. Thesis doesn't force you to use any particular authorization strategy.
Instead, Thesis will call your auth module's page_is_editable?/1 function
and provide the current conn, which can be used to extract current user
session data as well as the current page, and then you can decide how that
should affect authorization.
Here's an example which we use on our own website, https://infinite.red:
defmodule IrWebsite.ThesisAuth do
@behaviour Thesis.Auth
def page_is_editable?(conn) do
IrWebsite.AuthController.logged_in?(conn)
end
endIn our auth_controller.ex file, the logged_in?/1 function looks something
like this:
def logged_in?(conn) do
!!current_user(conn)
end
def current_user(conn) do
get_session(conn, :current_user)
endSo, in this case, we're simply checking to see if the user has been logged in or not. Since only Infinite Red employees have logins, it's safe for us to assume that if they're logged in, they have permission to edit the page.
If you use Guardian or something similar,
you may need additional manipulations to your conn to properly authenticate the
user. Add those to your auth module like this:
defmodule MyApp.ThesisAuth do
@moduledoc """
Contains functions for handling Thesis authorization.
"""
def page_is_editable?(conn) do
conn
|> Guardian.Plug.VerifySession.call(%{})
|> Guardian.Plug.LoadResource.call(%{})
|> MyApp.SessionController.logged_in_and_admin?
end
endNotifications/alerts allow us to talk with the user about the various aspects of the editing experience. For us, the contributors, this means that we may warn the user or developer of a breaking change that requires migrations (if they were forgotten to be executed). Since this is configurable, the developer may elect to push custom notifications to various parts of the Thesis editor.
Notifications can be configured to be static:
config :thesis, :notifications,
page_settings: ["The changes made here will affect your SEO", "Example notification 2"],
add_page: ["You are about to add a new page to the product site!"],
import_export_restore: ["Example notification 4"]Or, you may elect to add some logic and make them more dynamic:
config :thesis, :notifications,
page_settings: ["Example notification 1", "Example notification 2"],
add_page: &MyApp.CustomModule.generate_notifications/1,
import_export_restore: &MyApp.CustomModule.import_warning/1In either case, there are only 2 things that matter: 1 - you must provide a List of String(s) for each notification type, whether static or the result of a custom function; 2 - if you are using a custom function, it must be able to accept 1 argument: a %Plug.Conn{} struct. You can see an example here.
Note: right now, there are 3 spots to which you can push notifications: the 'Add New Page' tray, 'Page Settings' tray, and 'Import/Export/Restore' tray. As more features are developed, the notifications will be extended to support those features as well.
This is pretty common. While we try to be good citizens by properly namespacing all Thesis elements, we embed Thesis code into your existing web page, and so we're at the mercy of your application's existing CSS.
Inspect the element(s) that are screwed up and see if any of your styles are conflicting. For example, here's a screenshot of an issue:
Note that there is a .tooltip CSS rule originating in a different CSS file
that is affecting our editor.
In future releases, we will namespace all Thesis classes and IDs. But if your
application is overriding whole elements (like div or img), it's up to you
to fix the issue in your own CSS.
We're committed to making Thesis the go-to content editing system for Phoenix websites. Please help us improve!
- Fork it
- Create your feature branch (
git checkout -b my-new-feature) - Commit your changes (
git commit -am 'Add some feature') - Run
npm run webpackduring development - Use the
apps/examplePhoenix app to manually test your feature - Write tests for your new feature
- Run
./bin/ciin the root directory to ensure that Thesis tests pass. - Push to the branch (
git push origin my-new-feature) - Create new Pull Request
Thesis Phoenix, as an open source project, is free to use and always will be. Infinite Red offers premium Thesis Phoenix support and general web app design/development services. Email us at hello@infinite.red to get in touch with us for more details.
| Jamon Holmgren | Yulian Glukhenko | Ken Miller | Daniel Berkompas |
|---|---|---|---|
 |
 |
 |
 |
Also supported by others on the Infinite Red team.
Copyright (c) 2016 Infinite Red, Inc.
Thesis depends on Elixir, which is under the Apache 2 license, and Phoenix, which is MIT.
See LICENSE.md for more information.