substance / journal-old Goto Github PK

View Code? Open in Web Editor NEW

7.0 6.0 1.0 743 KB

Run a journal based on Substance (WIP)

JavaScript 90.45% CSS 9.55%

journal-old's Introduction

Substance Journal

Run simple journals based on Substance. This is a work in progress.

Install

Clone the repository.

$ git clone https://github.com/substance/journal.git

Navigate to the source directory.

$ cd journal

Install via npm

$ npm install

Seed the SQLite database.

$ npm run seed

Start your journal.

$ npm run start

Open http://localhost:5000 in your browser to see the journa's front end.

In order to edit and create articles navigate to http://localhost:5000/substance.

Features

Write and publish articles on an integrated web-platform using Subtance editing technology
Collaboration (write together, esp. review stuff)
very easy to deploy (runs on every linux system)
no dependencies on external services (no facebook, twitter integration, yes you heard right)

A blog engine?

No. Substance Journal is intended to create professional web-first publication rather than smaller timely pieces (blog). Here are some differences.

Table of contents during editing and for your readers
Collaborate during editing and make notes to point out problems and make suggestions
Reader comments

Future Challenges

How can we combine individually owned instances but still can announce some articles to be globally available.
Decentralized search index / routing?

For example: there are 20 different substance journals hosted by different people, they also run different versions. can there be a public index about

Roadmap

This roadmap is not final, and may change.

0.1.0

Basic editing (text, headings)
Comments (for editors and readers)
- Readers authenticate via Twitter
User management
- no public signup
- new users are created from the control panel
- everybody is an admin
SQLite only (using Knex.js query builder, so we can switch to other SQL databases)
Simple Reader view (non-interactive -> mobile friendly)
Server-side rendering so google can easily index the page

0.2.0

Support for Images
Control about publishing changes (See Issue #2)
Invite collaborators via email
More fine grained permisison system

0.3.0

Full Text Search on text fragment level using Elastic Search
Integration of Lens Browser interface

0.4.0

Subject tagging based on selections in the doc
Expose subjects in the browser interface

journal-old's People

Contributors

Stargazers

Watchers

Forkers

data4society

journal-old's Issues

Implement table of contents for Writer

Trigger seeding from the app start workflow

We could avoid the explicit step of npm run seed, and do seeding implicitly on very first start of the system.

Twitter auth integration for reader comments

@Integral Can you work on a sample implementation, and choose the strategy that you think work best.

Take your time for it. In the meanwhile I will only allow fully authenticated users to comment in the reader.

Add warning when user navigates to a different page and there are unsaved changes

Provide RSS feed along with the front page

(requested by Manuel Berger)

Reader should use React only

That way we can use React.render on the server (React.renderToString). We need to find out if it's a problem that we use our own view implementation for rendering annotations. I guess when we just do that and use dangerouslySetInnerHTML we should be fine.

Fix broken create document link

Introduce abstract editor

Also show that abstract on the landing page.

Add deleteDocument button in dashboard

Make server not crash when there's a syntax error in server.js

See tahi-journal.

Seems this is not enough error handling:

    browserify({ debug: true, cache: false })
      .add(path.join(__dirname, "client", "app.js"))
      .bundle()
      .pipe(res)
      .on('error', function(req, res, next) {
        res.status(500).send("Internal error.");
      });

I tried adding a try-catch but still i get:

http://127.0.0.1:5000/

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Parsing file /Users/michael/projects/plos/tahi-journal/client/writer/components/content_toolbar.js: Unexpected token (86:4)
    at Deps.parseDeps (/Users/michael/projects/plos/tahi-journal/node_modules/browserify/node_modu

Introduce tool groups

We should be able to group our tools, so we have better control about how they are displayed (order etc.)

Implement headings

This requires us to introduce a TextTool, for switching between different text modes.

Are our tokens secure?

Just wondering, that we can look inside our tokens, which i thought is just some sort of session id.

speaking of:

atob(data.token.split('.')[1]);

that produces:

{"email":"[email protected]","created_at":1432401077298,"updated_at":1432401077298,"data":"{}","iat":1432458804,"exp":1432545204,"iss":"[email protected]"}

so if somebody grabbed a token, they would know the email address associated.. well but maybe that's anyway a problem, if you have the session hijacked, then getting to the email and userdata is easy anyway.

just loud thinking.. ;)

Implement basic info/metadata panel

Features needed for 0.1.0

Edit author bio (will be stored in user table in the backend)
- problem: it would be nice to allow substance annotations here, but when we store it in the user table this could be problematic. so i guess for now we only allow plain text
Ability to modify the publish date
Adjust url-slug (by default generated from current document title, once published this can not be edited anymore)

Future ideas:

Simple categorization mechanism (create some bins where posts can be stored in)

Implement user admin

So we can create new authors and admin author bio etc. For now password is set in the backend by the admin. So we don't integrate email invitation processes. it's too early for that.

Ability to switch between draft and published

we'll just put a switcher into the content tools bar

Implement pre and blockquote node types

These are simple text-ish nodes and can be implemented easily. So we include them in 0.1.0.

Delete user edge cases

User should not be able to delete it's own user

No checkToken for GET /documents/:doc

In the front end (Reader) I need to be able to access the GET /documents/:doc service without authentication. However we need some proper permission logic here.. other than just checking if the user is logged in.

Send result when:

document has published_on property set (not null)
user is logged in (every user is an admin)
(in future: only document owner or collaborator have access)

For now i just disabled checkToken, but we must fix this.

Initial setup UI

See Wordpress/Ghost et. al:

Publications vs. Documents

We need a workflow to handle editing vs. publishing a document.

Use case:

write a doc
publish a doc
make fixes (which should not be visible in the published version)
republish (aka publish changes: creates a new publication which will be shown to the user)

We also may want to store each published version, so the reader can access previous versions.

From a db perspective we can have a table publications that has snapshots of each published revision of a document. Metadata such as the published-date of that version will live in this table.

I've put this on target for 0.2.0.

Create generic DocumentController to deal with code duplication writer_controller vs reader_controller

Serve everything through HTTPS

But first let's put all functionality place for 0.1.0.

Use only single db connection

@Integral You require db/index.js multiple times. That could lead to problems, if we have multiple connections to the db. So that's why i was using app.set('db', db) and use only that single db instance. Can we switch back to that approach?

Do automatic logout when invalid token is provided

Currently we stay logged in but receive errors from the api. Maybe we should poll every few seconds if the login token is still valid.

Automatically reset session info if autenthicate request is not successful

Work on deployment

We need to provide a simple deployment way. Ideally people who want to try the journal should be able to make a DigitalOcean deployment in a few minutes.

Daniel yesterday suggested using dokku, which is like a mini-heroku implementation.. that gives you all freedom.

Let's investigate what we need and if dokku can help us.

http://progrium.viewdocs.io/dokku/index

Add username, which will be the new primary key

We will allow logins by username or email. There will be a default user "admin" with password 1234, when you start the system the first time.

Keyboard shortcuts for annotations

@oliver---- let's develop some concept to introduce commands to the editor. currently toggling untoggling strong/emphasis etc. is trapped in the tools.

Use knex migrations for seeding

We are reinventing the wheel here. See Oliver's implementation for a better approach.

https://github.com/substance/tahi-editor-standalone/tree/master/backend

We use knex-cli for that so we can:

$ knex migrate:latest && knex seed:run

Document API permissions

We should think who can get/put document(s).

TOC does not get updated when new heading is inserted

Get inspired by ghost for the admin panel

we'll give people the opportunity to give the journal a custom name, and description. also we can use the user admin panel to specify short bio of the authors etc.

also nice feature: protect journal with a password to share journal entries in a private way.

Provide a url /editordev that brings up a demo editor instance with a test article

We need this because once we connect to the server API we need to click around to actually get to the editor. This will be annoying during editor dev so we provide a shortcut that also doesn't care about authentication etc. (this url is only available in dev mode).

Implement Image support

@Integral we need file upload api for this. Let's think about it but not include this for 0.1.0 release.

Check username/email availability

We should check whether or not username/email available.
Btw, if you trying to insert account with already used email - knex.js just didn't to do it and nor return any errors. :/

After login, always reload dashbord

Reader UI Ideas

To make it more reader-like, remove top bars and move context toggles to the very right.

Good:

more minimal than editor
we have space for many panels in the reader

Bad:

no labels for context toggles
would look weird if we used rich scrollbar for resource panel too

@Integral what do you think in the context of the archivist app?

Substance Reader requirements

Extension mechanism for content_panel (e.g. methods like markActiveTOCEntry) should be installed by extensions, reader listens for clicks on references while writer handles selection changes.
Maximum code share between Writer (disable editing but not loose ability to track selection changes)
Introduce generalized application api (2-panel) that reader and writer can use (same extension API)

Approach:

Bootstrap reader with Writer codebase but do refactorings to support the above usecases
Have in mind the writer case so we can later make the writer also conform to that new API

Implement links

We could do it like we did it in the native composer, or alternatively just make a classic link with url input.

Links as citations of web resources:

Pro: same thing can be referenced multiple times (we can store things like web description etc.)
Con: makes user interaction more complex (user has to decide between

Regular link:

Pro: easier, people are completely used to it (also easier to implement)
Con: redundancy (if you want to link the same thing each time you have to provide the url)
Con: We can no generate a references section

Idea: we go for regular links in the default version and offer a citations extension in a later version. maybe we could even monetise that feature as a commercial module for the pro users.

Signing in

If you already decide to use some email server for invitations, then we could use this thing: https://passwordless.net