Skip to content

Commit

Permalink
change codebase to directory structure (#1706)
Browse files Browse the repository at this point in the history
  • Loading branch information
Slashek authored May 21, 2024
1 parent 81bf76e commit 51b1d93
Show file tree
Hide file tree
Showing 30 changed files with 387 additions and 381 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ This guide will help you add visuals (images) to your pages using a CSS file, an

To follow the steps in this tutorial, you should be familiar with the required directory structure for your codebase, and understand the concepts of pages, layouts, and assets.

* [Codebase](/developer-guide/platformos-workflow/codebase)
* [Directory Structure](/developer-guide/platformos-workflow/directory-structure)
* [Pages](/developer-guide/pages/pages)
* [Layouts](/developer-guide/pages/layouts)
* [Assets](/developer-guide/assets/assets)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ This guide will help you add visuals (images) to your pages using Javascript.
## Requirements
To follow the steps in this tutorial, you should be familiar with the required directory structure for your codebase, and understand the concepts of pages, layouts, and assets. The example in this tutorial modifies the layout `application.liquid` used in the previous tutorial.

* [Codebase](/developer-guide/platformos-workflow/codebase)
* [Directory Structure](/developer-guide/platformos-workflow/directory-structure)
* [Pages](/developer-guide/pages/pages)
* [Layouts](/developer-guide/pages/layouts)
* [Assets](/developer-guide/assets/assets)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ This guide will help you use static assets (e.g. CSS, Javascript, or HTML files)

To follow the steps in this tutorial, you should be familiar with the required directory structure for your codebase, and understand the concepts of pages, layouts, and assets. You'll extend code samples from the previous tutorials.

* [Codebase](/developer-guide/platformos-workflow/codebase)
* [Directory Structure](/developer-guide/platformos-workflow/directory-structure)
* [Pages](/developer-guide/pages/pages)
* [Layouts](/developer-guide/pages/layouts)
* [Assets](/developer-guide/assets/assets)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ This guide will help you add an Authorization Policy.
## Requirements
So that you can follow the steps in this tutorial, you should be familiar with the required directory structure for your codebase, and understand the concept of Authorization Policy. You will also need the GraphQL query `current_user`, created in a previous tutorial.

* [Codebase](/developer-guide/platformos-workflow/codebase)
* [Directory Structure](/developer-guide/platformos-workflow/directory-structure)
* [Authorization Policy](/developer-guide/authorization-policy/authorization-policy)
* [GraphQL query `current_user`](/developer-guide/users/accessing-authenticated-user-data) (previous tutorial)

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ Mapping is the process of defining how a document, and the fields it contains, a

Each document is a collection of fields, which each have their own data type. When mapping your data, you create a mapping definition, which contains a list of fields that are pertinent to the document. A mapping definition also includes metadata fields, like the _source field, which customize how a document’s associated metadata is handled.

In platformOS, you can define document type via `search_indxes` in [app/config.yml](/developer-guide/platformos-workflow/codebase/config.yml) file. Example mapping definition:
In platformOS, you can define document type via `search_indxes` in [app/config.yml](/developer-guide/platformos-workflow/directory-structure/config.yml) file. Example mapping definition:

```yaml
search_indexes:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ metadata:

## Step 1: Requirements

I want to store my "docs" in platformOS, which is defined by the following mapping. Creating a mapping itself is not required, however it allows you to optimize results of your queries. For the time being, you can define mappings of your documents in [app/config.yml](/developer-guide/platformos-workflow/codebase/config.yml) file:
I want to store my "docs" in platformOS, which is defined by the following mapping. Creating a mapping itself is not required, however it allows you to optimize results of your queries. For the time being, you can define mappings of your documents in [app/config.yml](/developer-guide/platformos-workflow/directory-structure/config.yml) file:

```yaml
search_indexes:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -32,4 +32,4 @@ To use the downloaded folder as your codebase, rename the `marketplace-release`
## Next steps
Congratulations! You have downloaded the codebase of your Instance. To learn more about the directories and files in your platformOS codebase, visit:

* [Codebase](/developer-guide/platformos-workflow/codebase)
* [Directory Structure](/developer-guide/platformos-workflow/directory-structure)
278 changes: 1 addition & 277 deletions app/views/pages/developer-guide/platformos-workflow/codebase.liquid

Large diffs are not rendered by default.

Original file line number Diff line number Diff line change
@@ -1,71 +1,3 @@
---
converter: markdown
metadata:
title: config.yml
description: "**Config** is used to control the behavior of the application developed."
redirect_to: /developer-guide/platformos-workflow/directory-structure/config
---

**Config** is used to control the behavior of the application developed. It is a file located in `app/config.yml`.

| flag | default value | Explanation |
|----------------------------------------------------------------|-----------------|-------------|
|do_not_add_return_to_to_authorization_policies |false|By default, if the authorization policy fails and is set up to redirect, it automatically appends the return_to parameter. By setting the flag to `true`, the return_to parameter will not be appended|
|escape_output_instead_of_sanitize |true|If disabled, any variable will be sanitized before the output and treated as html and corrected, which is unideal as it can change the expected output. By keeping this flag as `true`, the output will be escaped, not sanitized. We highly recommend setting this flag to true. |
|graphql_argument_type_mismatch_mode |error|Defines behavior when the argument type in the GraphQL query is wrong. Possible values:<br/> `warning` - display warning message in log<br/> `error` - raise error, do not allow to deploy query<br/> `ignore` - silently ignore error |
|liquid_check_mode |error|When you deploy/sync liquid files we run static analysis on the files. By keeping this flag as `error` we gonna throw error if file contains unknown filter. <br/>Possible values:<br/> `warning` - display warning message in log<br/> `error` - raise error, do not allow to deploy liquid file|
|liquid_raise_mode |true|If diabled, liquid runtime errors will be displayed inline and the code will continue to execute despite error. By keeping this flag as `true`, whenever there's any Liquid error - like parsing JSON files, providing invalid arguments to GraphQL query, etc., the 500 page will be raised instead and the execution will stop. This is generally the desired and expected behavior and we recommend keeping this flag as `true`.|
|require_table_for_record_delete_mutation |true|The argument `table` for the `record_delete` mutation is optional by default, which can lead to security issues if the type of the record is not explicitly checked before executing the mutation. By setting the flag to true, you effectively make the `table` attribute required to avoid such vulnerability.|
|safe_translate |true|If disabled, the `translate` filter (`t` is an alias for it) will mark the output as html_safe. This can lead to XSS vulnerability, if you provide user input as a variable, as it could contain malicious JavaScript. In such scenario, you should explicitly use another filter, `translate_escape` (or `t_escape`). However, by keeping this flag as `true`, the system will automatically use the equivalent of `t_escape` if you provide any variable to the translation key, making your application safer by default. We highly recommend keeping this flag to `true`.|
|skip_elasticsearch |false|If you do not use the `keyword` argument in `records`/`users` queries or `customizations`/`people` queries, you can increase performance by avoiding indexing data in the ELasticSearch by setting this flag to `true`.|
|slug_exact_match |true|If disabled, a page with slug `abc` will match not only `example.com/abc`, but also URLs like `example.com/abc/1`, `example.com/abc/1/x` and to control this behavior, you would need to set [max_deep_level Page property](/developer-guide/pages/pages#available-properties). By keeping this flag as true, only `example.com/abc` will be matched. Additionally, you will be able to use named parameters in the URLss, like /abc/:id. We highly recommend setting this flag to true.|
|websockets_require_csrf_token |true|If disabled, the websocket connection will not check the CSRF token. By keeping this flag as `true`, connections to websocket will require CSRF token to be included in the parameters, increasing the security of your application.
|liquid_add_old_variables |false|Back at a day there were multiple global objects available, like `page`, `platform_context`, `forms`. We make it easier to use platformOS, we have grouped everything into one [global object context](/developer-guide/variables/context-variable). Setting this flag to `true` will re-enable those deprecated global objects.
|maintenance |{ enabled: false, password_constant: 'MAINTENANCE_PASSWORD', partial: 'maintenance' }|Allows to setup mandatory password protection, useful when the site should be restricted only to users who know the password.
|modules_that_allow_delete_on_deploy |[]|Allows to list module names, for which if a file will be missing on deploy, it will be removed. The default behaviour of module is to not delete any files, because it is possible that developer would know download all of the source code and would like to just deploy an overwrite for a few chosen files. If the module is listed and sync is enabled, then users will be also able to remove the files from the instance by removing them in their filesystem.
|translation_keys_to_ignore |[]|Allows to list translation keys which will not be updated/delete on sync/deploy. It is most useful if you would like to change translations using UI and will not reflect it in your codebase. Translations will still be created if not defined.
|sync_translations |false|If enabled, translations will be synchronized on each sync/deploy similarly to other resources, meaning if you remove a translation form a translation file and sync it, it will disappear from the Instance. It will also remove all translations from the deleted file. The default behaviour (for backwards compatibility) is that translations will not be deleted; in order to delete a translation one needs to explicitly call `admin_translation_unset` GraphQL mutation. This setting is compatible with `modules_that_allow_delete_on_deploy`.


Example `app/config.yml` file with recommended values:

```yml
---
escape_output_instead_of_sanitize: true
graphql_argument_type_mismatch_mode: error
liquid_check_mode: error
liquid_raise_mode: true
require_table_for_record_delete_mutation: true
safe_translate: true
skip_elasticsearch: true
slug_exact_match: true
websockets_require_csrf_token: true
sync_translations: true
liquid_add_old_variables: false
---
```

## Maintenance - setting up password protection

Example `config.yml` for enabling password protection:
```yml
maintenance:
enabled: true
password_constant: 'MAINTENANCE_PASSWORD'
partial: 'maintenance'
```

When a user enters the site, and the `enabled` flag is set to `true`, they are presented with content from the partial defined in the config, in the above example `app/views/partials/maintenance.html.liquid`. Inside this partial you can display any html, and most likely you would like to include a form to allow to provide password:

```liquid
<form action="/_maintenance" accept-charset="UTF-8" method="post">
<input type="hidden" name="authenticity_token" value="{{ context.authenticity_token }}">
<div>
<input type="password" name="password" id="password" value="" class="password" placeholder="Password" />
<input type="submit" name="commit" value="Submit" class="btn btn-blue" />
</div>
</form>
```

The `/_maintenance` endpoint is a built-in platformOS endpoint, which verifies that `context.params.password` is equal to the value of the constant defined in `password_constant`, in this scenario context.constants['MAINTENANCE_PASSWORD']. If there is a match, platformOS stores the information in the `session` and the user will not be prompted again to provide the password.

{% render 'alert/note', content: 'The maintenance page will be displayed only for valid pages and only for GET requests. It means that custom error pages and POST/PATCH/PUT/DELETE will continue to work.' %}
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ What you’ll need:
* [Access to the Partner Portal](/get-started/installation-and-configuration/#sign-up-on-the-partner-portal)

### 2. Create codebase
In order to correctly communicate with the platformOS engine and API, your codebase should be organized into a [specific directory structure](/developer-guide/platformos-workflow/codebase). To create your codebase in a local environment follow the steps in the [Working with the Code and Files](/get-started/working-with-the-code-and-files/) topic.
In order to correctly communicate with the platformOS engine and API, your codebase should be organized into a [specific directory structure](/developer-guide/platformos-workflow/directory-structure). To create your codebase in a local environment follow the steps in the [Working with the Code and Files](/get-started/working-with-the-code-and-files/) topic.

What you’ll need:

Expand Down Expand Up @@ -129,6 +129,6 @@ This is a diagram of our recommended development workflow:
## Related topics

* [pos-cli](/developer-guide/pos-cli/pos-cli)
* [Codebase](/developer-guide/platformos-workflow/codebase)
* [Directory structure](/developer-guide/platformos-workflow/directory-structure)
* [Working with the Code and Files](/get-started/working-with-the-code-and-files/)
* [Working with the Code and Files](/get-started/working-with-the-code-and-files/)
Loading

0 comments on commit 51b1d93

Please sign in to comment.