bigbluehat / blueink Goto Github PK

Over the Top Content Management System for Apache CouchDB

License: Apache License 2.0

HTML 1.67% CSS 33.19% JavaScript 65.14%

blueink's Introduction

BlueInk™

BlueInk™ began in late 2005 from ideas gathered from previous projects, problems, and paper sketches. Over the years it grew into a unique and powerful CMS.

Using the current commercial Software-as-a-Service BlueInk CMS as the conceptual prototype, BlueInk is being rewritten into an Open Source CMS built on Apache CouchDB and Cloudant mostly as a CouchApp.

Development

It's a bit rough in here still...but improving!

copy config.json.sample to config.json
update it with your settings
copy config_ui.json.sample to config_ui.json
update it with your settings
npm install
npm run prosemirror to build & install ProseMirror
npm run semantic to install Semantic-UI for rework to rework
gulp rework to "namespace" Semantic-UI under .blueink-ui
gulp
visit the URL you stored in config.json sans login info plus /_design/blueink/_rewrite/

That should load the home (see home.json) page.

The site contents (content, templates, schemas, the whole shootin' match) lives in _docs. The BlueInk editing UI and CouchDB views live in _design/blueink.

The default gulp task will run browserify and push the resulting contents of the various Design Docs which make up BlueInk to the database you configured.

If you're working with CSS changes you'll need to re-run gulp rework as it is not (by design) part of the default gulp task. Also npm run semantic can be used in conjunction with a package.json tweak to update the underlying Semantic-UI code. If you've made changes to src/semantic/src/theme.config, you can use npm run styles to rebuild the CSS and then gulp rework.

Note: plans exist in my brain to restructure the top-level gulpfile.js and leverage Semantic's gulp stuff directly. Patches welcome! 😺

Page Demos

License

BlueInk on CouchDB is release under the Apache License 2.0

blueink's People

Contributors

Stargazers

Watchers

Forkers

tmclane tariqhamid themelic

blueink's Issues

Refactor template system

There's a tricky balance between flexibility for designers/developers and consistent feature delivery (RDFa) among BlueInk sites. Try to balance that...simply.

Add Content Item sub-menu

Ran into some trouble with v-repeat over objects passed in with v-with...

Likely, there's a much better way to approach this anyhow as a stack of simpler Vue Models.

Create generic _show function for simple content types

shows/html/map.js contains the most generic content item templating so far. That's likely reusable (with some tweaks) for contact's and possibly many others.

Create _list function for outputing content item lists

Link each item to the _show function URL (or the _rewrite equivalent) for each item.

Create super basic BlueInk bar for accessing new _list/_show and pages tree

Based on the commercial/production BlueInk's UI, but all in HTML5 and CSS3:
http://demo.blueinkcms.com/

Sortable

Use Sortable for new Drag & Drop UI.

Use Rework CSS to prefix Semantic-UI with ui-blueink tag name

Scope this thang!...as much as possible without scoped CSS...anyhow.

The bootstrap example page shows some collision.

create flexible/expandable validate_doc_update for content and page types

Move blog posts into "posts" key and reference from page area

Keeping the full list of blog posts in a page area will mean the entire archive must be moved when a blog is dragged into a different column. It would be much better to only move the reference and store the blog posts in their own key.

add audio content item type

Consider outputting <audio> tags and making ID3 info available (if present in JSON)

Implement Content Item Preview

Third level to the right in the Content Menu. Requires #16 to be done first (obviously).

add Site Info editing form

Add sitemap page ordering

Pages in sitemap _list output are alphabetical. They need to be ad-hoc order-able.

Bosonic

Research using Bosonic for building out the new UI.

Refactor `type~{name}` document structure and finding system

Currently this thing's pretty tangled... 🍝

The doc.name === the type~{name} value. When really, doc.name should be the display name...or at least there should be a "pretty" display name stored somewhere.

Things to fix/refactor:

_view/by_type
_view/type_definitions
_list/types_list (...which is currently busted and unused...)
src/menu-content/*
type loading in main.js (which uses _view/type_definitions to load component.js files.

Somewhat related to #18 as getting this right means meaningful content shared "everywhere." Doing it wrong will be...less good... 😩

Store created/updated data

Options:

use an _update endpoint
set from the UI code
validate_doc_update (with either option)
- prevents replication of non-valid docs...which is probably not what we want...actually

Use npm for `type~{name}` documents

Dug into this a bit last night, but hit issues with doing npm install, etc from gulp.

Ideally, you'd gulp the site project, it would in turn handle building all the type~{name} documents (and/or grabbing them from npm), and push them all to the database along with BlueInk itself (and possibly the BlueInk "core" types--assuming you've not overridden them.

add Page Options form for editing general Page details

create 'sitemap' doc generator MapReduce and _list

This MapReduce and associated _list function should be able to generate the 'sitemap' document. Initially it'll be requested and then stored (replacing the old 'sitemap') via the UI (on page add or URL change), but eventually it would be great to have this use view merging (once that's available).

Draggability

Alternate to #12 ...maybe:
https://github.com/desandro/draggabilly

Cool, regardless.