Posts

Grav 1.6 Released

Grav is an open source flat-file CMS that we use for client documentation and server healthchecks. Since it requires no calls to a database and has baked in caching, page load speed is very fast and offers a simple search that will quickly search your content for matching strings. We chose Grav as we thought it would be an ideal solution for simple, static, searchable pages such as those used for flow documentation and healthchecks.

Recently, Grav 1.6 was released on 4/11/2019. It is being touted as their “biggest release since Grav 1.0” and there are many new features to potentially take advantage of. This latest update to Grav 1.6 requires upgrading PHP to 7.1.3+ (7.3+ is preferred for optimal performance) and also updates Admin Panel to v1.9 and Form/Login/Email plugins to v3.0.

Full article: (https://getgrav.org/blog/grav-1.6-released)

INSTALLATION

Grav comes with a built-in command-line interface (CLI) which can be found at bin/grav

The simplest way to upgrade would be through CLI as upgrading through the admin panel could result in some error messages.

To upgrade to Grav 1.6 and update all plugins, open a terminal and once in the root directory of the Grav site use:

php bin/gpm self-upgrade (Windows) OR bin/gpm self-upgrade (Mac)

followed by

php bin/gpm update (Windows) OR bin/gpm update (Mac)



NEW FEATURES 

BACKUPS

There is a new backups tab in the Tools section. This can integrate with the new scheduler to create scheduled backups. We now have the ability to create multiple backup profiles each with their own set of files. In our case, this will be useful for creating and keeping track of backups when updating documentation and healthchecks.

 

SCHEDULER

A new scheduler tab is in Tools section of the Admin panel. It allows for scheduling tasks such as cache clear, backups, synchronization, search indexing, etc.

LOGS

This is a new CLI command that can be used to display Grav log entries. In addition, the logs are accessible from the new Logs tab in the Tools section of the Admin panel. This new tool should help us in the future with troubleshooting.

REPORTS

The Reports feature is accessible from a tab in the Tools section of the Admin panel. This section provides information to the site administrator on things such as configuration, server issues, and content issues and can help with troubleshooting.

ASSET MANAGER

One of the most important changes in Grav 1.6 was implemented on the asset manager. Previously, there was an issue with plugins that had their own CSS and JS assets in which the content was rendered in the order encountered and once rendered, could not be modified. The asset manager was rewritten as part of this update and basically solves this issue with custom plugin CSS and JS.

For complete details, please visit the Asset Manager documentation:
(https://learn.getgrav.org/16/themes/asset-manager)

Overview of Flow Documentation Sections

Grav is an open source flat-file CMS that we use for client documentation.

Requirements:

  1. Web Server (Apache, Nginx, LiteSpeed, Lightly, IIS, etc.)
  2. PHP 5.5.9 or higher

Advantages of using a Grav CMS for documentation:

  1. SEARCH bar: Can search entire collection of documentations for a search term instead of going through each doc file individually
  2. Not reliant on database: Flat-file content management system means that the data is stored in folders rather than a database = fast loading
  3. Easy to maintain since all data in local folders
  4. Simple HTML format written with Markdown syntax (http://nogalis.com/docr/how-to-use-docr to learn more about Markdown)
  5. Many useful plugins freely available (http://www.nogalis.com/2018/07/27/grav-a-modern-flat-file-cms for more information on plugins)
  6. User authentication and custom user privileges

Documentation Sections


  1. Introduction – Screenshot of the IPA flow and a short description about what it does
  2. General Data Flow – Box diagram showing step-by-step what is happening in the flow. Also accompanied by a paragraph explanation
  3. Components Table – A table that lists all input/output files, databases, scripts, triggers, jobs, and configuration variables
  4. Dependencies – The files, triggers, jobs, or SQL/server connections required for the flow to function
  5. Scheduling and Triggers – How/when the flow gets triggered
  6. Recovery – This section provides instructions on how to manually execute the steps of the flow if it fails. Each step here represents a box in the General Data Flow box diagram.
  7. Archiving – Table showing archived files and their archived locations
  8. Notifications – Details of the notifications sent by the flow
  9. Troubleshooting – General tips for troubleshooting
  10. Maintenance – Maintenance needed by the flow (usually involves cleanup of archived/done files)
  11. Security – Overview of user permissions and connection credentials needed for the flow
  12. Key Contacts – The person to contact for questions about the flow/documentation
  13. Related Files – File uploads related to the flow (these are able to be viewed/downloaded from the page)

For full examples, please visit http://nogalis.com/docr/demo_documentation

Monthly Server Healthcheck Section Overview

Nogalis offers monthly server healthchecks that informs clients of any current or potential problems in Lawson for both PROD and TEST servers. The healthcheck covers error logs, smoke tests, patches, LID functionality, portal check, database integrity, and many other sections (26 total) which will be briefly outlined here.

You can visit http://nogalis.com/docr/demo_hc to view a demo healthcheck for yourself.

  1. Summary

    This is arguably the most important section of the monthly healthcheck. If there is one section to read, it should probably be this one as it brings to attention the most pressing needs of all the other sections. There is also a handy letter grade assigned each month so you can quickly keep track of the overall health of your server!
  2. Recommendations

    This section has all the combined recommendations from the other sections of the healthcheck. It is divided into three levels of urgency so the client can decide what to focus in on.

  3. System Layout

    System hardware and OS information.

  4. Component Versions

    Lawson components version information. If server versions start to fall significantly behind latest versions, recommendations are made.

  5. Application Versions

    Lawson application version information

  6. Programs with Errors

    Any .err files found in the Lawson directory are pointed out in this section. As with any section, further investigation into any issue can be requested by sending an email to the Key Contact.

  7. Custom Programs

    List of custom Z/Y/X programs

  8. CPU Performance

    Tested while idle and under duress. Just a very rough idea of the CPU performance.

  9. Disks Report

    Report on the free space available of the different drives on the server. We make sure to point out in the Summary and Recommendations sections when a drive is getting dangerously low on free space.

  10. Purge Recommendations

    The disks report is followed by purge recommendations where we point out certain things that could be deleted to free up some space.

  11. Java

    Java settings information/recommendations and a screenshot of the jconsole.

  12. licsta

    Summary table of current licenses (viewable in LID)

  13. Error Logs

    Every month we grab these 6 important logs to analyze them for current errors. These errors are pointed out in this section so that the client can determine if they are worth investigating or not.

  14. Smoke Tests and Component Testing

    Various smoke tests with LID, Lawson portal, and various URL tests

  15. Recurring Job Listing

    Simple table listing of recurring jobs. One of the sneaky benefits of having all this information in one healthcheck page is that it allows for a quick search for any terms using the DOCR search bar on the left panel.

  16. Waiting Jobs

    List of waiting jobs

  17. Database/Table Review and Sizing

    This section displays the 10 tables with the largest number of rows for each of PROD/LOGAN/GEN. A quick overview of this section might lead to decisions to purge certain tables for example.

  18. Database Integrity Check

    Summary of database integrity check performed through LID. Any errors here are pointed out in Summary/Recommendations.

  19. Printers

    List of printers and their commands

  20. Work Directory Review

    Overview of Lawson work folder

  21. Print Directory Review

    The Lawson print directory list by user. This information could possibly be used to purge old users/records.

  22. Security Analysis

    Security analysis performed using LSFIQ
    (1-click Lawson security audit and reporting tool: see http://www.nogalis.com/nogalis-products/lawson-security-with-lsfiq/ for more info.)

  23. Patches Installed Report

    List of latest patches installed on this server.

  24. Source Versions Report

    The source versions report is in a zipped file available to download in the Related Files section.

  25. Related Files

    Any related files related to the healthcheck are in this section where they are available to view or download.

  26. Key Contacts

    If you have any questions about the healthchecks or would like to request an investigation into some error discovered by the healthcheck, please contact anyone in the Key Contacts section with your questions.

Creating an Email Contact Form in Grav/Docr

Here is a step-by-step guide for creating an email contact form in Grav/Docr

 

  1. Install “Email” Plugin if not already installed. The simplest way to do this is through the admin panel:

  1. Rename the Markdown file to form.md (instead of chapter.md for example) and include this code snippet (or similar) in the YAML portion at the top of the page below “title”:

Snippet:

form:

name: contact

fields:

–   name: name

label: Name

placeholder: Enter your name

autocomplete: on

type: text

validate:

required: true

 

–   name: email

label: Email

placeholder: Enter your email address

type: email

validate:

rule: email

required: true

 

–   name: message

label: Message

size: long

placeholder: Enter your message

type: textarea

validate:

required: true

 

buttons:

–   type: submit

value: Submit

–   type: reset

value: Reset

 

process:

–   email:

from: “{{ form.value.email }}”

to: “{{ config.plugins.email.to }}”

subject: “[Healthcheck Contact Form] {{ form.value.name|e }}”

body: “{% include ‘forms/data.html.twig’ %}”

–   save:

fileprefix: contact-

dateformat: Ymd-His-u

extension: txt

body: “{% include ‘forms/data.txt.twig’ %}”

–   message: Thank you for getting in touch regarding your healthcheck report!

–   display: thankyou

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Full example of form.md YAML:

We can place any page content below this YAML portion. Our contact form will show up on the bottom of the page after all page content.

  1. Inside the page folder (in which the form.md is placed), create a subfolder named “thankyou” with a file named “formdata.md” with this snippet:

title: Email sent

cache_enable: false

process:

twig: true

 

## Email sent successfully!

This will result in a “Email sent” success screen when the user clicks submit on the contact form:

  1. Final Step – Configuring Email Plugin settings. Full email configuration documentation can be found here (https://github.com/getgrav/grav-plugin-email/blob/develop/README.md)

 

Set-up for Google SMTP (Gmail)

  1. Enable IMAP in your Gmail by going to Settings -> Forwarding and POP/IMAP -> IMAP Access

  1. Enable “Less secure apps” in your user account settings (https://myaccount.google.com/lesssecureapps)

  1. From Admin dashboard, go to Plugin -> Email to configure settings:

Fill out configuration: