GitBook: [master] 34 pages and one asset modified

Author: toastercup

Diff for: .gitbook/assets/cortex-example-screenshot.png

@@ -1,11 +1,12 @@
-# [![](/assets/branding/cortex-logo--reverse--small.png)](https://github.com/cbdr/cortex)
+# Introduction
 
-Cortex [CMS](/glossary.md#cms) is a [multitenant](https://en.wikipedia.org/wiki/Multitenancy) identity, [custom content](/glossary.md#custom-content-cms) distribution/management and reporting platform built by the [Content Enablement](https://github.com/cb-talent-development) team at [CareerBuilder](https://github.com/careerbuilder). Its purpose is to provide central infrastructure for next-generation applications; exposing a single point of management while enabling quicker build-out of new software.
+Cortex [CMS](glossary.md#cms) is a [multitenant](https://en.wikipedia.org/wiki/Multitenancy) identity, [custom content](glossary.md#custom-content-cms) distribution/management and reporting platform built by the [Content Enablement](https://github.com/cb-talent-development) team at [CareerBuilder](https://github.com/careerbuilder). Its purpose is to provide central infrastructure for next-generation applications; exposing a single point of management while enabling quicker build-out of new software.
 
 Cortex adheres to a headless, API-only architecture - it avoids a monolithic, all-in-one architecture associated with CMSs like WordPress or Drupal.
 
-[![Build Status](https://semaphoreci.com/api/v1/projects/ec90715a-da8f-4960-bb64-f371850f9c98/813409/shields_badge.svg)](https://semaphoreci.com/content-enablement/cortex) [![Code Climate](https://codeclimate.com/repos/53f62c2869568018180036c9/badges/78e3c3c865b118bbd72b/gpa.svg)](https://codeclimate.com/repos/53f62c2869568018180036c9/feed) [![Test Coverage](https://codeclimate.com/repos/53f62c2869568018180036c9/badges/78e3c3c865b118bbd72b/coverage.svg)](https://codeclimate.com/repos/53f62c2869568018180036c9/coverage) [![Documentation Status](https://www.gitbook.com/button/status/book/cortex-cms/cortex-cms)](https://docs.cortexcms.org/)
+![Build Status](https://semaphoreci.com/api/v1/projects/ec90715a-da8f-4960-bb64-f371850f9c98/813409/shields_badge.svg) ![Code Climate](https://codeclimate.com/repos/53f62c2869568018180036c9/badges/78e3c3c865b118bbd72b/gpa.svg) ![Test Coverage](https://codeclimate.com/repos/53f62c2869568018180036c9/badges/78e3c3c865b118bbd72b/coverage.svg) 
 
-![](/assets/branding/cortex-example-screenshot.png)
+![](.gitbook/assets/cortex-example-screenshot.png)
 
 Copyright \(c\) 2018 CareerBuilder, LLC.
+

Diff for: README.md

@@ -1,18 +1,18 @@
-# Summary
+# Table of contents
 
 * [Introduction](README.md)
-  * [Motivation](introduction/motivation.md)
-  * [Core Concepts](introduction/core-concepts.md)
-  * [Prior Art](introduction/prior-art.md)
-  * [Examples](introduction/examples.md)
+* [Motivation](motivation.md)
+* [Core Concepts](core-concepts.md)
+* [Prior Art](prior-art.md)
+* [Examples](examples.md)
 * [Basics](basics/README.md)
   * [Setup](basics/setup/README.md)
     * [Manual](basics/setup/manual.md)
     * [Docker Compose](basics/setup/docker-compose.md)
   * [Deployment](basics/deployment.md)
   * [Tenancy & User Management](basics/tenancy-and-user-management.md)
   * [Building Content Types](basics/building-content-types.md)
-  * [Data Validation](basics/setup/data-validation.md)
+  * [Data Validation](basics/data-validation.md)
   * [Designing Indexes](basics/designing-indexes.md)
   * [Designing Wizards](basics/designing-wizards.md)
   * [Consuming Content](basics/consuming-content.md)
@@ -29,3 +29,4 @@
 * [Troubleshooting](troubleshooting.md)
 * [Roadmap](roadmap.md)
 * [Glossary](glossary.md)
+

Diff for: SUMMARY.md

@@ -1,15 +1,13 @@
 # Advanced
 
-This guide typically goes beyond the role of a [superadministrator](/glossary.md#superadministrator) and is more engineering-focused. Whether you want to author plugins, extend search functionality, build reports, or contribute to the project, these guides will step you through the process.
-
-* [Developing Plugins](/advanced/developing-plugins.md)
-  * [Basic Architecture](/advanced/developing-plugins/basic-architecture.md)
-  * [Service Layer](/advanced/developing-plugins/service-layer.md)
-  * [Examples](/advanced/developing-plugins/examples.md)
-  * [Extending Search](/advanced/developing-plugins/extending-search.md)
-  * [WYSIWYG Widgets](/advanced/developing-plugins/wysiwyg-widgets.md)
-* [Contributing](/advanced/contributing.md)
-* [Testing](/advanced/testing.md)
-
-
+This guide typically goes beyond the role of a [superadministrator](../glossary.md#superadministrator) and is more engineering-focused. Whether you want to author plugins, extend search functionality, build reports, or contribute to the project, these guides will step you through the process.
+
+* [Developing Plugins](https://github.com/cortex-cms/cortex-cms/tree/ec0acc5e822e7cd071403cac968f82e8f6df4a96/advanced/developing-plugins.md)
+  * [Basic Architecture](developing-plugins/basic-architecture.md)
+  * [Service Layer](developing-plugins/service-layer.md)
+  * [Examples](developing-plugins/examples.md)
+  * [Extending Search](developing-plugins/extending-search.md)
+  * [WYSIWYG Widgets](developing-plugins/wysiwyg-widgets.md)
+* [Contributing](contributing.md)
+* [Testing](testing.md)
 

Diff for: advanced/README.md

@@ -2,26 +2,18 @@
 
 Anyone and everyone is encouraged to fork Cortex and submit pull requests, propose new features and create issues.
 
-* Ideally, we'd first like to hear your concerns or suggestions in the form of an [issue][issue]. We can all avoid
-unnecessary re-work if a problem and its potential solution are first discussed before code is written.
-
+* Ideally, we'd first like to hear your concerns or suggestions in the form of an [issue](https://github.com/cbdr/cortex/issues). We can all avoid unnecessary re-work if a problem and its potential solution are first discussed before code is written.
 * Fork on Github, then clone your repo:
 
-```sh
+```bash
 git clone [email protected]:your-username/cortex.git
 ```
 
-* Follow the [setup instructions][setup]
-
-* Follow the [test suite instructions][test-suite], and ensure all tests pass
-
-* Make your changes. Make frequent commits, but keep commits and commit messages focused on individual, atomic
-feature changes or fixes. If you end up making many small commits during debug or development that belong to the same
-chunk of functionality, squash those commits before creating a pull request.
-
+* Follow the [setup instructions](../basics/setup/)
+* Follow the [test suite instructions](testing.md), and ensure all tests pass
+* Make your changes. Make frequent commits, but keep commits and commit messages focused on individual, atomic feature changes or fixes. If you end up making many small commits during debug or development that belong to the same chunk of functionality, squash those commits before creating a pull request.
 * Add tests for your change. Once again, ensure all tests pass.
-
-* Push to a branch on your fork and [submit a pull request][pr]. Your PR must adhere to the following conventions:
+* Push to a branch on your fork and [submit a pull request](https://github.com/cbdr/cortex/compare). Your PR must adhere to the following conventions:
   * For CareerBuilder team members, if the PR relates to a JIRA card, use the following naming convention:
     * `JIRA card #`: `PR Title`
     * Example: `COR-365: Unhandled Error on Media Upload`
@@ -30,35 +22,36 @@ chunk of functionality, squash those commits before creating a pull request.
     * Example: `Unhandled Error on Media Upload`
   * Names should use titleized capitalization. i.e.: `Login Form Redesign and Refactor`
   * Names should be dense, yet informative. For example, `Testing` is not an appropriate PR name, nor is
-  `For update_url task, must use the body method to actually retrieve the stream from the S3 GetObjectOutput`.
-  PR names are more high-level than commit messages.
-  * PRs should be tagged appropriately (i.e. `enhancement`, `bug`, etc). Tags should be preferred over including things
-  like 'bug' in the PR name.
+
+    `For update_url task, must use the body method to actually retrieve the stream from the S3 GetObjectOutput`.
+
+    PR names are more high-level than commit messages.
+
+  * PRs should be tagged appropriately \(i.e. `enhancement`, `bug`, etc\). Tags should be preferred over including things
+
+    like 'bug' in the PR name.
+
   * PR Descriptions should be a clearly-separated, bulleted list summarizing what's contained in the commits, as well as
-   any relevant notes or considerations for developers or ops. It should also detail any potential follow-up issues.
+
+    any relevant notes or considerations for developers or ops. It should also detail any potential follow-up issues.
+
   * If working with a versioned library, open source users should not include version bumps or changelog updates in
-  their PRs.
 
-From here, it's up to the Cortex maintenance team (<[email protected]>) to review your pull request.
-We operate in 2-week sprint lifecycles, but we'll try to get to your request or contribution sooner. We may suggest
-further improvements or alternatives, or the community at large may have input.
+    their PRs.
+
+From here, it's up to the Cortex maintenance team \([[email protected]](mailto:[email protected])\) to review your pull request. We operate in 2-week sprint lifecycles, but we'll try to get to your request or contribution sooner. We may suggest further improvements or alternatives, or the community at large may have input.
 
 Some things that will increase the chances that your pull request will be accepted:
 
-* Write [good tests][tests]
-* Write [good][good commits], [atomic][atomic commits] & [semantic][semantic commits] commit messages. All commits should follow this general structure:
-  > type(Affected Subject): present-tense summary
+* Write [good tests](http://betterspecs.org)
+* Write [good](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), [atomic](https://www.freshconsulting.com/atomic-commits/) & [semantic](https://seesparkbox.com/foundry/semantic_commit_messages) commit messages. All commits should follow this general structure:
+
+  > type\(Affected Subject\): present-tense summary
 
   For example:
-  > fix(Contact Us): remove 'Send Us a Note' form
+
+  > fix\(Contact Us\): remove 'Send Us a Note' form
+
 * Be consistent
 * If applicable, suggest additional options or alternatives, follow-up issues or potential future improvements
 
-[issue]: https://github.com/cbdr/cortex/issues
-[tests]: http://betterspecs.org
-[atomic commits]: https://www.freshconsulting.com/atomic-commits/
-[good commits]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
-[semantic commits]: https://seesparkbox.com/foundry/semantic_commit_messages
-[setup]: /basics/setup/README.md
-[pr]: https://github.com/cbdr/cortex/compare
-[test-suite]: /advanced/testing.md

Diff for: advanced/contributing.md

@@ -2,8 +2,9 @@
 
 This guide lays out how to build new plugins for Cortex CMS, which will allow you to extend the system with more `FieldTypes`, queries, WYSIWYG widgets, jobs, etc.
 
-* [Basic Architecture](/advanced/developing-plugins/basic-architecture.md)
-* [Service Layer](/advanced/developing-plugins/service-layer.md)
-* [Extending Search](/advanced/developing-plugins/extending-search.md)
-* [WYSIWYG Widgets](/advanced/developing-plugins/wysiwyg-widgets.md)
-* [Examples](/advanced/developing-plugins/examples.md)
+* [Basic Architecture](basic-architecture.md)
+* [Service Layer](service-layer.md)
+* [Extending Search](extending-search.md)
+* [WYSIWYG Widgets](wysiwyg-widgets.md)
+* [Examples](examples.md)
+

Diff for: advanced/developing-plugins/README.md

@@ -1 +1,4 @@
 # Basic Architecture
+
+
+

Diff for: advanced/developing-plugins/basic-architecture.md

@@ -4,5 +4,3 @@ Currently, there is only one reference Plugin implementation.
 
 * [cortex-plugins-core](https://github.com/cortex-cms/cortex-plugins-core) - This provides the basic `FieldTypes` we'd expect most applications to need, such as `TextFieldType`, `BooleanFieldType`, `UserFieldType`, etc.
 
-
-

Diff for: advanced/developing-plugins/examples.md

@@ -1 +1,4 @@
 # Extending Search
+
+
+

Diff for: advanced/developing-plugins/extending-search.md

@@ -1 +1,4 @@
 # Service Layer
+
+
+

Diff for: advanced/developing-plugins/service-layer.md

@@ -4,14 +4,15 @@
 
 Initialize the test database:
 
-```sh
+```bash
 $ RAILS_ENV=test bundle exec rake db:schema:load db:seed cortex:core:db:reseed
 $ RAILS_ENV=test bundle exec rake cortex:rebuild_indexes
 ```
 
 To run Ruby and JS specs, utilize:
 
-```sh
+```bash
 $ RAILS_ENV=test bundle exec rake spec
 $ RAILS_ENV=test bundle exec rake spec:javascript
 ```
+

Diff for: advanced/testing.md

@@ -1,19 +1,17 @@
 # Basics
 
-Working with Cortex CMS as a [superadministrator](/glossary.md#superadministrator) may seem daunting at first blush, but we're here to walk you through every step and demonstrate the simplicity & power of the platform.
-
-* [Setup](setup.md)
-  * [Manual](/basics/setup/manual.md)
-  * [Docker Compose](/basics/setup/docker-compose.md) _\(not yet supported\)_
-* [Deployment](/basics/deployment.md)
-* [Tenancy & User Management](/basics/tenancy-and-user-management.md)
-* [Building Content Types](/basics/building-content-types.md)
-* [Data Validation](/basics/setup/data-validation.md)
-* [Designing Indexes](/basics/designing-indexes.md)
-* [Designing Wizards](/basics/designing-wizards.md)
-* [Consuming Content](/basics/consuming-content.md)
-* [Scheduling Content](/basics/scheduling-content.md)
-* [Search](/basics/search.md)
-
+Working with Cortex CMS as a [superadministrator](../glossary.md#superadministrator) may seem daunting at first blush, but we're here to walk you through every step and demonstrate the simplicity & power of the platform.
 
+* [Setup](https://github.com/cortex-cms/cortex-cms/tree/ec0acc5e822e7cd071403cac968f82e8f6df4a96/basics/setup.md)
+  * [Manual](setup/manual.md)
+  * [Docker Compose](setup/docker-compose.md) _\(not yet supported\)_
+* [Deployment](deployment.md)
+* [Tenancy & User Management](tenancy-and-user-management.md)
+* [Building Content Types](building-content-types.md)
+* [Data Validation](data-validation.md)
+* [Designing Indexes](designing-indexes.md)
+* [Designing Wizards](designing-wizards.md)
+* [Consuming Content](consuming-content.md)
+* [Scheduling Content](scheduling-content.md)
+* [Search](https://github.com/cortex-cms/cortex-cms/tree/ec0acc5e822e7cd071403cac968f82e8f6df4a96/basics/search.md)
 

Diff for: basics/README.md

@@ -8,7 +8,7 @@ Each FieldType has a number of validations that can potentially be run. You choo
 
 So, in AwesomeBlogPost you would specify that the Field named "Title" is a TextFieldType which comes first, its presence is required, and it should be a maximum of 50 characters; the Field named "Body" is a TextFieldType which comes second and should have a maximum of 1000 characters; the Field named "Video" is a YoutubeFieldType which comes third; and the Field named "Image" is an ImageFileFieldType which comes last and must be a jpg under 1MB.
 
-```
+```text
 ct = ContentType.new(name: "AwesomeBlogPost", description: "The kind of blog post that goes on my Awesome Site", creator_id: 1)
 
 ct.fields.new(name: "Title", field_type: "text_field_type", validations: { presence: true, length: { maximum: 50 } }, metadata: { placeholder: "This is the title" })
@@ -19,5 +19,3 @@ ct.fields.new(name: "Image", field_type: "image_file_field_type", validations: c
 ct.save
 ```
 
-
-

Diff for: basics/building-content-types.md

@@ -1,8 +1,8 @@
+# Consuming Content
+
 > TBD - a rudimentary RESTful API and RSS feed system already exist, but these will be replaced \(or augmented\) with a GraphQL API in 3-6 months.
 
-### API Client Libraries
+## API Client Libraries
 
 * [cortex-client-ruby](https://github.com/cortex-cms/cortex-client-ruby)
 
-
-

Diff for: basics/consuming-content.md

@@ -4,7 +4,7 @@
 
 Each FieldType defines the validations that can be run on a FieldItem's data. It should have a hash where the keys are the different types of validations that can be run, and the values are method names that will be called to determine if the requested Field validation is legitimate:
 
-```
+```text
 VALIDATION_TYPES = {
   length: :valid_length_validation?,
   presence: :valid_presence_validation?
@@ -15,7 +15,7 @@ In order to define the validations that can be run, we use the [validators defin
 
 The Field validations themselves are run when creating a ContentItem and its associated FieldItems. A ContentItem is only considered valid if all of its FieldItems are valid. To determine validity, the FieldItem instantiates the FieldType, passes in its data, and tells the FieldType to run the validations hash specified by the Field.
 
-```
+```text
 class TextFieldType
   def text_length
     validator = LengthValidator.new(validations[:length].merge(attributes: [:text]))
@@ -24,5 +24,3 @@ class TextFieldType
 end
 ```
 
-
-

Diff for: basics/setup/data-validation.md renamed to basics/data-validation.md

@@ -2,21 +2,21 @@
 
 > Note: Docker Compose instructions coming soon
 
-If you want to self-host Cortex CMS, this guide is for you. Currently, only [Manual Setup](/basics/setup/manual.md) is officially supported.
+If you want to self-host Cortex CMS, this guide is for you. Currently, only [Manual Setup](setup/manual.md) is officially supported.
 
-### Configuration
+## Configuration
 
 To use an automated tool to deploy the server, set this environmental variable:
 
-```shell
+```text
 CI=true
 ```
 
 This will suppress Bower's interactive request to enable insights/metrics reporting, which normally prevents the CI process from continuing.
 
 Additionally, deploying the `development` environment as a non-local server will require an additional environmental variable be set:
 
-```shell
+```text
 DEPLOYED=true
 ```
 

Diff for: basics/deployment.md

@@ -2,5 +2,3 @@
 
 > TBD - this system is currently in flux as we switch from server-side Cells to React
 
-
-

Diff for: basics/designing-indexes.md

@@ -2,5 +2,3 @@
 
 > TBD - this system is currently in flux as we switch from server-side Cells to React
 
-
-

Diff for: basics/designing-wizards.md

@@ -2,5 +2,3 @@
 
 > TBD - this system is built but is being refactored for greater reliability before we harden its interface
 
-
-

Diff for: basics/scheduling-content.md

@@ -2,10 +2,8 @@
 
 > Note: Docker Compose instructions coming soon
 
-If you're interested in local development with Cortex \(relevant to [integration engineers](/glossary.md#integration-engineer), or those who wish to contribute to the project\), these guides will walk you through the process across any POSIX OS.
-
-* [Manual](/basics/setup/manual.md)
-* [Docker Compose](/basics/setup/docker-compose.md) _\(not yet supported\)_
-
+If you're interested in local development with Cortex \(relevant to [integration engineers](../../glossary.md#integration-engineer), or those who wish to contribute to the project\), these guides will walk you through the process across any POSIX OS.
 
+* [Manual](manual.md)
+* [Docker Compose](docker-compose.md) _\(not yet supported\)_
 

Diff for: basics/setup/README.md

@@ -1,3 +1,4 @@
-# Docker Compose Setup
+# Docker Compose
 
 > Note: Docker Compose instructions coming soon
+