coderedcorp / coderedcms

Wagtail + CodeRed Extensions enabling rapid development of marketing-focused websites.

Wagtail CRX (CodeRed Extensions)

The professional WordPress alternative for building marketing websites with Wagtail and Bootstrap.

Website | Documentation | Blog

Status

Python Package
Build

What is Wagtail CRX?

CRX, formerly known as CodeRed CMS, provides a large set of enhancements and pre-built components for Wagtail which are ready to use out-of-the box! This saves development time and avoids "re-inventing the wheel" by providing features commonly needed by websites:

• Streamfield blocks and page templates for Bootstrap 5: rows, columns, hero units, carousels, buttons, modals, cards, and more!

• Settings for adding logo, navigation, footer, and other common elements.

• Rich set of SEO tagging attributes on each page.

• Configurable Google Analytics and other tracking.

• Robust form builder including the ability for multi-step forms, conditional logic, customized confirmation emails, MailChimp integration, and more.

• Article pages for building blogs, news, etc.

• Calendar and event pages.

• Google Maps blocks, and store locator functionality.

• Dynamic classifier system, for creating filterable categories.

• Website search functionality, filterable by page type.

• Style your site using SASS/SCSS directly from Django, without the need for Node.js

Quick start

1. Run pip install coderedcms

2. Run coderedcms start mysite --sitename "My Company Inc." --domain www.example.com

   Note: --sitename and --domain are optional to pre-populate settings of your website.

3. Enter the project cd mysite/

4. Run python manage.py migrate to create the core models.

5. Run python manage.py createsuperuser to create the initial admin user.

6. Run python manage.py runserver to launch the development server, and go to http://localhost:8000 in your browser, or http://localhost:8000/admin/ to log in with your admin account.

See the documentation for next steps and customizing your new site.

Contributors

In addition to the CodeRed team, many thanks to the Wagtail community and our independent contributors.

If you're interested in building, developing, or contributing to Wagtail CRX, check out the Contributing Guide.

Attribution

Icon files in coderedcms/templates/coderedcms/icons/:

• Were sourced from the Fork Awesome project at https://github.com/ForkAwesome/Fork-Awesome.
• Are licensed under the Creative Commons Attribution 3.0 Unported license, a copy of which is available at https://creativecommons.org/licenses/by/3.0/
• Have been modified from the original sources.

Contact

We would love to hear your questions, comments, and feedback. Open an issue on Github, message us on #coderedcms in the Wagtail slack.

coderedcms's Issues

SEO audit tool

A common task is to crawl a site, analyzing page content, meta tags, etc. It would be a nice time-saving feature to have the CMS perform this analysis and produce an interactive, or downloadable report.

My initial thoughts are that this could be broken into a few categories. Search and Social.

• Search would report on titles, descriptions, word count of page, structured data, redirects pointing to that page, etc.
• Social would check for opengraph and twitter settings, and maybe render a preview of what that would look like

This feature could potentially live in the SEO settings panel. Additionally, we could potentially add some of this of the SEO tab on each page, similar to what Yoast does for WordPress.

Mailchimp integration

We need the ability to integrate form submissions with 3rd party APIs. Specifically for this use case, MailChimp.

Scenario

Admin needs to be able to dynamically map which form fields will feed into MailChimp upon form submission. This does need to be dynamic as it will vary from form to form. Submissions will feed into specific MailChimp lists, groups, segments, or list sources on a per-form basis. Not sure on current set of MailChimp features, but at a minimum a list will be needed.

After the visitor submits the form on the website, the entry will be logged in coderedcms as usual, and the user will now be opted in to a mailchimp list.

Implementation

Ideally some kind of dynamic API integration mechanism would be nice as part of the form page. But this might not be possible or be too difficult to implement. I'm fine with doing a mailchimp-specific feature. This could be an isolated component/package that uses a hook on form submit. Or it could be something baked into the form page. Not sure what is best, although I like the idea of using a hook.

From the technical standpoint, it needs to be fail safe so as not to bomb out or cause data loss if the API call fails. We still need to collect the form submission and notify an admin, rather than bubble this error up to the visitor. Perhaps building in some logging would be good for troubleshooting in different environments which could experience issues caused by IP whitlisting or domain verification.

From the admin UX standpoint, I envision this working similar to the CofirmationEmails, which uses the Django templating engine to map form submission fields within a context. That could be useful for rendering a JSON or POST payload to an API endpoint. Similar to ConfirmationEmails, maybe we have an ApiCall streamfield which takes a URL, an http method, and a payload to post (which gets rendered with the context).

Shuttering Peregrine: useful features?

Hey team,

I'm thinking about shuttering Peregrine and putting my efforts here so we're not duplicating a lot of effort, and y'all are farther along than me: https://github.com/flipperpa/peregrine/

There are a few features I think would be worth implementing here that are already completed in Peregrine, and wanted your feedback before I started working:

• embeds with automatic Bootstrap 4 size detection has worked really well in practice: https://github.com/FlipperPA/peregrine/blob/master/peregrine/templates/wagtailembeds/embed_frontend.html
• ability to only keep a certain number of revisions from a setting: https://github.com/FlipperPA/peregrine/blob/master/peregrine/wagtail_hooks.py#L22
• integration with Wagtail Code Block, for consistent syntax highlighted code blocks both in the editor and front end

Do these three sound like PRs that would be worth putting together? Great work, as always!

Make built-in models abstract

If we want to continue using CODERED_FRONTEND_* settings (which I think we do, they will be the foundation of themes), we will have to make everything that uses our streamfield blocks abstract.

The issue is, many coderedcms models use streamfield blocks that pull values from CODERED_FRONTEND_* settings. Which means if you change one of these settings in your project, it triggers a migration in coderedcms. Which is a bad practice and leads to endless migrations.

This fits in with the paradigm we have been following with the page types. Provide beefy abstract models, and provide a very basic concrete model boilerplate in the project template.

One caveat to making the snippets abstract, is that we will no longer be able to provide a snippet chooser, or hard-code templates that pull in navbar/footer snippets. So this will have to be thought through to figure out how to gracefully handle all of this without re-defining everything in the project template (which would be too much boilerplate I think).

Anyhow, this pretty major regarding future stability. Implementing it will inevitably be a breaking change. But there is no other way to have dynamic blocks and themes. So I think it is necessary.

VideoChooserBlock

HeroBlock would really benefit from having the ability to have full width background videos. For this we would need a VideoChooserBlock that mimics the functionality of ImageChooserBlock, but with video. This would probably require the implementation of our own Video model to house/validate/compress the uploaded files.

Database search backend is too bad

Wagtail's build-in database search backend does not provide good search results in coderedcms due to the fact that it can't search multiple fields on multiple different models, it can only search fixed fields on ALL models or multiple fields per-model. We have some workarounds in coderedcms for this (see searching docs), but they are not ideal.

The elasticsearch backend is probably ideal, but adds an extra infrastructure component which is overkill for smaller sites. Similarly, there is a postgres backend but that does not support mysql or sqlite.

I recently discovered https://github.com/wagtail/wagtail-whoosh which would probably solve all of our problem, assuming it is actually portable between all database types. The one trick here is the need to run update_index to relfect changes, but we might be able to run that on a hook when a new page is published or when the cache is cleared. At any rate, if it does have to be run via cron job, I think cron is an "acceptable" piece of infrastructure moreso than requiring a specific database or elasticsearch.

Alternatively, I would love to write a mysql search backend that takes advantage of powerful full text indexing in mysql - but do not have enough knowledge about search backends to accomplish that in a timely manner. Regardless, I think wagtail-whoosh might be preferable to database-dependent backends.

Privacy:password pages are cached

Pages set to "privacy: use a password" are cached by wagtail-cache with the sign in screen. This is caused because the URL does not redirect to a sign in page, but serves different content on same URL depending on whether the password has been entered or not.

I don't imagine this issue effects other sign in types that redirect to the login screen and set an actual user on the request. In this case, there is no user and no redirect URL.

The problem could potentially be fixed in wagtail-cache, or here in coderedcms. But either way it affects the CMS when caching is enabled.

Create login template

When using wagtail's page privacy feature set to a fixed password, the login screen is a very basic unstyled design. We should probably provide a default bootstrap template that uses the site's styles and branding, or possibly extends web_page.html.

To reproduce:

• Create a page in the wagtail admin
• Select "Privacy"
• Set to require a password, and set a password.
• View the page. The default password input template is very plain. It should inherit from pages/web_page_notitle.html or web_page.html and use bootstrap styling for the form.

Official theme support

We already have the basis of a framework for 3rd party themes. But I think a good step would be actually trying to create an example 3rd party theme, documenting how this is done, and making whatever changes would be necessary in the cms to support this. The first example could be simple, still based on Bootstrap. It is possible to build a theme that swaps out bootstrap for something like foundation, materialize, skeleton, etc., but that is a task for a different day.

Requirements for the theme would be:

• Custom templates that override coderedcms templates
• Custom page and block templates in addition to coderedcms templates, utilizing the Layout or Adv Settings > Template chooser dropdown.
• Custom css and js added to base.html, to show how to properly do that.
• MAYBE some extra blocks or models that are part of the theme, to show how to integrate those into the cms as well.

The theme itself should be a separate pip package. But docs and any enhancements to support theming should be integrated into the CMS.

Theme support is currently possible, but is partially blocked by issues #8 and #56

Internationalization / i18n / translation support

Hello, how i18n is handled in coderedcms?
Is there an easy way to integrate wagtailtrans with coderedcms?
Many thanks.

Unpublished pages show up in navbar

When "show child pages" is selected in a navbar, unpublished pages show up. Ideally unpublished pages should not be returned in the query.

Remove `!important` from CSS in AMP templates

Received error message in Google Search Console for a site with stock codredcms AMP pages: "The text inside tag 'style amp-custom' contains 'CSS !important', which is disallowed." See https://www.ampproject.org/docs/fundamentals/spec#stylesheets.

CSS Issues in Wagtail Admin

The CSS included in for the Wagtail admin creates some weird horizontal spacing when integrated with an existing site. For example, have a look at the horizontal row (including Day of Week):

Without CodeRed (good):

With CodeRed (bad - dropdowns obscured by the bar):

The content_panels declaration is as follows; FieldRowPanel seems problematic with the CSS:

    content_panels = Page.content_panels + [
        FieldPanel("group"),
        FieldRowPanel(
            [
                FieldPanel("day_of_week"),
                FieldPanel("start_time"),
                FieldPanel("end_time"),
            ]
        ),
        FieldPanel("types", widget=CheckboxSelectMultiple),
        FieldPanel("meeting_details"),
    ]

Form field layout enhancement

Currently form fields render individually top to bottom, which works as expected. But there are two additional use-cases that are frequently needed.

1. Ability to add dividers, headings, and text in between form field. In this scenario, form fields would be grouped into some represenation of a fieldset. The fieldset would contain at least a rich text block.

2. A multi-page form wizard. This could be implemented in javascript, but essentially the ability to break a form up into separate views or pages, and then click "back"/"next" to move between the views. The views would not necessarily need to post to the server individually, but at least be presented as separate steps.

Finally, the ability to have form logic, such as IF -> THEN logic on fields:

IF [fieldA] value is X, then show/hide [fieldB]

This probably warrants a separate issue, but if we need to make a breaking refactor of the forms, it would be best to roll this all in together.

Show CodeRed CMS Version

Should probably start maintaining a version in the CMS that is visible on the admin panel and command line. Most python projects appear to do this with a __version__ variable in setup.py

django-el-pagination for pagination

For paginating pages, django-el-pagination might be a good upgrade as it offers two types of pagination style and the app has good documentation.

E-Commerce

Goals

The goal would be to provide a simple e-commerce experience that works out-of-box but can be easily customized by the developer. This feature would primarly be used for smaller clients who need custom business logic that would be difficult to program with online paltforms like Shopify. We seek to have a simple system that would be a suitable (and better) replacement for something like Woocommerce + WordPress.

Target website would be small business e-commerce, or digital goods. Large retailers dealing in high volume would probably defer to a more specialized system.

Basic requirements

• Product management/pages in wagtail admin.
• Product category management/pages in wagtail admin.
• Support subscription products and recurring billing/auto-pay. Either through the payment gateway or something like a simple cron job or management command.
• Cart functionality (can be turned on or off if not needed)
• Payment gateway (I am fine with supporting Stripe exclusively at first).
• Confirmation and payment error email management in wagtail admin.
• Super basic order management - in the form of an order summary email for customers, and order status/notes in wagtail admin. No customer login/dashboard is required at this time, but that would be a need in the future.
• Super basic shipping calculations. We could look to other ecommerce systems for inspiration here.
• Basic tax calculations. Tax laws are complex, so we could support a flat tax-rate out of the box, and provide a hook for doing any more complex calculations. That way developers can easily program this or integrate with a 3rd party tax calculator service based on each individual website's needs.

Implementation

Most obvious solution would be to integrate something like Longclaw or Oscar. I'm not the biggest fan of Oscar although it is extremely robust. Longclaw looks appealing - perhaps we could join forces with longclaw team and contribute upstream, or fork the project to ensure we can provide professional support and timely code changes as needed. Open to other Django-based solutions as well.

I envision this being either a separate pip package, or an off-by-default feature. If many large dependencies are required, then a separate pip package would probably be more ideal.

Refactor FRONTEND_* settings

Original issue: get_config() should be modified such that it will update FRONTEND_TEMPLATES_PAGES and FRONTEND_TEMPLATES_BLOCKS instead of replacing.

The entire workings of FRONTEND_* settings need to be refactored. Currently, customizing them beyond the defaults triggers a migration back into coderedcms, which ultimately creates migration hell. These settings need to be easily customizable by client projects.

Resolving this is a key blocker for stability, and also theme support.

Reusable Content Snippet

Create a snippet that just holds a generic streamfield. The idea is to have a snippet that contains reusable content that can be used anywhere on the site. We will want to create a SnippetChooserBlock for this snippet so it can be used in other streamfields.

WordPress importer

Yes, the holy grail of wagtail, a complete WordPress importer. Opening this issue here to jot down notes and learnings from various site migrations, so we can figure out what a WordPress importer actually needs to do. For reference, WP=WordPress and CR=CodeRed CMS here.

The WordPress site importer would probably be run first, before populating any content or pages on the site. I would not imagine supporting a use-case where the importer is run after you already have content. It would be much simpler to run it on a clean slate.

To avoid over-engineering, the main goal or minimum viable product would be importing blog posts, as there are usually usually hundreds of them and it is a tedious process to manually replicate.

Base requirements:

• Use the XML format created natively by WP from the "export" functionality. This file should contain all of the information needed.
• WP has two content types: Posts and Pages (which are actually posts). But many plugins create custom post types, so there is no easy way to handle this. So I'm thinking the first step would be to analyze the XML file and determine what types exist. The user would then somehow specify or map which WP post types in correspond to which CR page types or snippets. The importer should probably handle this analysis and provide some sort of template or UI for the user to map the content types. An easy assumption to make would be that all WP pages map to CR WebPage, and all WP posts map to CR ArticlePage.
• The importer would then use the user mapping, to run that against the XML file.
• During import, media would be downloaded from the old site and saved as a wagtail image or document. The reference to that media would also need to be updated within the post content so wagtail knows which image to use.
• During import, the URL of each page would need to be set, and if the old URL is different from the new URL (possibly specified during user mapping?) then a redirect should be created.
• As a baseline, content of WP pages/posts could be saved in a CR rich text field in the body, or even more of a baseline, as an HTML field directly in the body. The HTML field would be the easiest to implement, with the assumption that a content editor would have to go through the pages and manually "massage" the content into a new format. Older blog posts etc could simply keep the content in HTML for posterity.

Possible advanced features:

• Ability to handle shortcodes. Most likely this would work that during XML analysis, a list of shortcodes would be presented. During the user mapping process the user could specify how to handle each short code. I.e. a shortcode could get mapped to a specific block, or could simply be deleted or ignored.
• Special handling of Yoast SEO data, this would get mapped into the appropriate SEO fields in CR.
• Special handling of form plugins. It would be nearly impossible to support them all, but Contact Form 7 is a big one.

Other notes or major concerns: WordPress 5.0 has introduced Gutenberg editor, which I'm quite certain stores the data in a completely different format than the old editor. I'm sure this will need to be accounted for in the importer.

v0.10 release

Ok, time to get this out the door.

Once all of the current issues with milestone 0.10 are merged in we will call it quits and not add any more issues to this release.

For this release in particular, there are a number of migrations and migration issues. So I plan to delete all of the migrations created between 0.9.1 and now, and then re-generate one clean migration with all of the changes. That way existing sites should have a smooth upgrade to 0.10.

Finally, with the new documentation, I also plan to document as much of the new changes as possible after they are merged in, before we cut the release.

Any objections or concerns, speak now or forever hold your peace! (until 0.11 at least)

Allow Card Row inside Hero Unit

We currently allow responsive grid row inside hero unit, should also allow card row.

Bug in prod.by

In the snippet

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
'wagtail.contrib.settings.context_processors.settings',
],
'loaders': [
('django.template.loaders.cached.Loader', [
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
]),
],
},
},
]

You can't have both APP_DIRS and loaders set. APP_DIRS should be removed when prod.py is being used.

Remove formatted code block from default streamfield

Topic of debate: the streamfield is extremely heavy when adding nested blocks. I'm thinking we could probably remove the Formatted Code block, since it is actually a bit if a pig due to the language selector dropdown, and is the least likely to be used by 99% of websites.

This would be something we would keep in the cms, just remove it from the default blocks on a web page. So it would give us another opportunity to figure out a clean and easy way for devs to add additional blocks to the streamfield without too much code.

I already have an idea, similar to how we have variables for CONTENT_BLOCKS etc, we could allow the user to override CONTENT_BLOCKS so they can "plug in" their desired blocks, and all the WebPages would automatically pull from the overridden CONTENT_BLOCKS (would still require a migration, but seems relatively painless otherwise). This would function similar to the CODERED_THEME_* settings.

Form help text should be rich

In some cases, it would be beneficial to insert links or minor formatting of the form field help text. This could potentially be a rich text block.

This might introduce concerns such as rendering with django-bootstrap4, or within the form inline panel itself.

Replace EmbedVideoBlock with Wagtail's EmbedBlock

Wagtail's EmbedBlock is much more robust and provides much more embed sources and URL formats than the current EmbedVideoBlock.

Requirements:

• Remove coderedcms.blocks.EmbedVideoBlock (in html_blocks.py)
• Replace embed_video entry in coderedcms.blocks.HTML_STREAMBLOCKS with wagtail's EmbedBlock (or an extended version of it in codredcms/blocks/html_blocks.py if necessary). As long as we keep the dict key named "embed_video" it should remain backwards compatible with existing coderedcms websites.
• Ensure HTML output matches Bootstrap 4 styles and best practices. See https://github.com/FlipperPA/peregrine/blob/master/peregrine/templates/wagtailembeds/embed_frontend.html
• Create a migration for coderedcms and for the project_template website.

See new contributing guide at: https://docs.coderedcorp.com/cms/

Option to clear cache when updating documents/images/snippets

Currently, the cache is always cleared when publishing a page. However the cache must be manually cleared when changing a document, image, or snippet. When changing a document or image, any cached pages that reference that document will continue to serve the old document URL which results in a 404.

I think it would make sense to have options under the General > Performance settings, to automatically clear the cache when updating:

• Pages
• Documents
• Images
• Snippets

by default all would be turned on. For larger sites that want finer grain control over the cache, they could disable these options and clear the cache manually as needed.

Replace Google Analytics with tag manager

Use the new gtag.js instead of analytics.js since Google seems to be deprecating usage of analytics.js

example:

<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-XXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'UA-XXXXXX');
</script>

Upgrade to Wagtail 2.2

Also upgrade any other dependencies if applicable. Regression test wagtail admin and core features.

Add class to the page title in it's html template.

Currently there is no easy way to select a title of a page in the html with css. We should make a change to add a class to the h1 for the titles to make them easily selectable.

Prevent PDF's from being served as a download without specifying it as such.

Currently, if you choose a document with a DocumentChooserBlock and serve the document, you will be forced to download it instead of viewing it in browser. To fix this, you will probably want to use the before_serve_document hook https://docs.wagtail.io/en/v2.2.2/reference/hooks.html#document-serving to use our own response in the case of pdfs. https://stackoverflow.com/questions/47205668/wagtail-document-links-downloading-instead-of-displaying-as-a-page Might provide a good example.

Google tag manager must be in <head>.

According to Google's documentation, but going against their performance guidelines, the gtag.js tag manager code should be in the head of the page. Google site verification fails since the code is not in the head.

Despite the performance hit, I think the tracking script should be moved to the head in base.html template following Google documentation. Documentation is available in google analytics dashboard > admin panel or at https://developers.google.com/analytics/devguides/collection/gtagjs/

LocationPage and LocationIndexPage

We need to develop a concept of a LocationPage and a LocationIndexPage. The idea here would allow certain websites (ie, restaurants, retailers, etc) to show a list of their locations that are searchable. This would be done with the LocationPage. The LocationPages would live under a LocationIndexPage. The LocationIndexPage would show a google map with the locations of all the LocationPages. It would then be able to be searched upon.

Provide apple-touch-icon

From looking at web server logs, I can tell that we are remiss in omitting favicon.ico and apple-touch-icons.

We already store the favicon in a setting and generate it in the pages/base.html template. Ideally we should implement all possible favicon standards.

See Apple docs: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html

Apple icon size reference: https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/app-icon/

Store Finder enhancments

A few enhancements for the store finder functionality. Will continue updating this issue as early adopter feedback is gathered.

• Make search bar wider/longer, ideally percentage based to fill most of the width of the map on any device size. With current size, autocomplete suggestions are not clearly visible.
• "Near me" button should have some kind of feedback while polling location, perhaps a spinner, as sometimes it can take several seconds to poll location. And ideally, it would populate the search box with the found location for further user confirmation.
• Zoom bounds. When searching for a specific address or zip code, the map is zoomed in very far which can be deceiving if there are no results. Perhaps when querying a location, a max zoom should be implemented to prevent the map from zooming in too far after finding a location.
• Change default search box text to "search by city, address, or zip code"

Documentation

Add documentation. Critical pieces that are required for 1.0 milestone:

• Quickstart
  • Install
  • Deploying
• Basic Tutorial
  • Setup, branding, getting started
  • Adding home page content
  • Adding a blog
  • Categorize the blog
  • Adding a basic contact form
  • Customizing navbar and footer
  • Coding: add a custom field to WebPage model and template
• Features
  • Page types
  • Block types
  • Snippets
  • Settings (wagtail)
• Customizing
  • Custom CSS/JS
  • Overriding templates
• How-To
  • SEO
  • Using a different frontend CSS framework
  • AMP Pages
  • Making custom page types
  • Making custom blocks
• Settings (django)
• Contributing guide
• Roadmap

no such table: main.wagtailimages_image__old

I have installed the https://www.coderedcorp.com/cms/
When opening in http://127.0.0.1:8000

I get this error

Request Method:	GET
http://127.0.0.1:8000/
2.1.4
OperationalError
no such table: main.wagtailimages_image__old
/Users/timvogt/.virtualenvs/coderedcms-5CS8FIAC/lib/python3.7/site-packages/django/db/backends/sqlite3/base.py in execute, line 296
/Users/timvogt/.virtualenvs/coderedcms-5CS8FIAC/bin/python3
3.7.1
['/Users/timvogt/Software_projects/Github:Gitlab ' 'Downloads/coderedcms/myproject', '/Users/timvogt/.virtualenvs/coderedcms-5CS8FIAC/lib/python37.zip', '/Users/timvogt/.virtualenvs/coderedcms-5CS8FIAC/lib/python3.7', '/Users/timvogt/.virtualenvs/coderedcms-5CS8FIAC/lib/python3.7/lib-dynload', '/usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7/lib/python3.7', '/Users/timvogt/.virtualenvs/coderedcms-5CS8FIAC/lib/python3.7/site-packages']
Thu, 27 Dec 2018 09:53:54 -0500

ADA Compliance

The CMS should be ADA compliant out of the box.

Features should be implemented that cover as many of the points on this page as possible. as applicable. https://www.ada.gov/pcatoolkit/chap5chklist.htm

Look into integrating this package for testing and giving the end user the ability to check their own pages for accessibility. https://github.com/takeflight/wagtail-accessibility

Allow uploading text version of Documents along with original doc. Also include setting to generate text versions of Documents (PDF and Word) if an alternate text version is not provided. https://automatetheboringstuff.com/chapter13/

Things to discuss: - Should all accessibility features be able to be flipped on/off with a settings toggle? - Should we allow users to deviate from accessibility if they desire to?

Unit Tests

Base level unit tests, ideally for:

• Default project_template(make sure it works so we aren't generating a broken project)
• Each block
• Each page type (including forms)

More advanced things to test (for consideration): file blacklist/whitelist email functionality (not sure how to test this, but make sure any default emails get rendered without issue) custom admin functionality e.g. snippets, settings. HTML validity checker of generated pages * Accessibility tool checker of generated pages.

Default template changes

After having worked with a few different sites now, I think that our default article_page.html template is a bit too styled. It should probably be more plain and include less custom css in the way of the cover image, article body etc.

Since all pages have a cover_image attribute, the best thing to do would probably be to put that in web_page.html, web_page_notitle.html, or possibly base.html (although maybe not in base, as base is kind of ideal as a bare-bones template for doing whatever you want).

That would make the article page template a little less unique, and make all page templates a bit more common, which seems to be favorable when doing custom designs.

Requirement: All templates provided by coderedcms should have each individual element inside a {% block %} for easy overriding in client projects (or future themes).

Confirmation email format

The body of confirmation emails is always HTML currently. It would be ideal to have a toggle to select text or HTML, as HTML is not necessarily needed in all cases.

At a minimum, it should at least be documented that the body is HTML in both the help text and the docs. Since this is HTML, newlines have no effect and <br> tags must be used. This is a point of confusion among users.

Special home page template

Right now the homepage defaults to web_page_notitle.html template - however it would probably be nice to make a special home page template as a convenience for the developer to do any special designs or layouts on the home page as needed without affecting other page layouts.

I would just envision this being a template called home_page.html that simply extends web_page_notitle.html. It would essentially serve as a stub for designers to use as needed.

Javascript templating library

There are a few instances where we end up running js files through the Django templating engine to "generate" dynamic JavaScript, or have to make ajax calls that render HTML using the Django templating engine. To me, this feels a bit hacky and like a bad practice. In my view, JavaScript should be completely decoupled from back-end code as much as possible, and not rely on the Django templating engine.

For our use-case, I really think something small like vue.js would do wonders here to simplify the code. Of course there are hundreds of other options - open to hearing ideas as long as they are lightweight and do not require some kind of webpack or build system.

First two problem areas that come to mind are the store locator (front-end), and the new MailChimp API integration (wagtail admin).

File Field Specific Whitelist

Add the ability to restrict a specific file field to a certain file type(s). This would be in addition to the global whitelist/blacklist.

Content Wall

The content wall would add the ability to implement a pay wall, age gate, terms-of-use acceptance, etc. before being able to access a page.

The content wall would be a somewhat generic functionality, probably either in the settings or at the page level. Contents of the wall could be customized with full LAYOUT_STREAMBLOCKS or CONTENT_STREAMBLOCKS. We might want to also add the ability to have a light weight form (newsletter sign up, yes/no buttons, checkbox, etc.). Or alternatively we could let the user implement that themselves in HTML.

Questions:

• Should this be at the page instance level? With option to apply to all sub-pages or just this page?
• Should it be a snippet in similar vein to the navbar, and have the option within the snippet to specify which pages this applies to? (This would enable the user to create multiple walls for different content)
• Or a setting? We would probably still need some kind of clusterable sub-model to enable multiple walls.

Default built-in template could be a modal, with option to make the modal dismissible or non-dismissible.

Enhance GA tracking

We can up our game at "not being evil" (which in Google speak means more tracking). When the Settings > Tracking > Track all button clicks setting is turned on, it does track all button clicks, but should be extended to track all link clicks, not just buttons. This includes links in the RichText Editor, navbar, etc.

For a cleaner implementation, the tracking script currently in button_block.html could be reafctored into a global jquery event that fires on all $('a').click() events, and the tracking parameters could be provided in as data-attributes. Links without the advanced settings to specify tracking details should use reasonable defaults.

Search page empty query

On an empty query, the default behavior is not super user-friendly. If you go to the search page without specifying a query, or try to search with an empty query somehow, it currently shows a search term of "None" or a search term of "" (empty string) and no results found. Ideally with None or empty search query:

• Title would just say "Search"
• "No results found" message would probably be omitted.

These changes should be possible in the search html template.

Calendar and Events

• Visual calendar layout
• Upcoming events / agenda view (list)
• Categorize events (Use tags)
• Downloadable iCal for each event
• Downloadable iCal for entire calendar

Form Captcha

Ability to enable a caption on forms.

This could potentially be implemented as either a form field, or at the page level. Potentially useful library https://github.com/praekelt/django-recaptcha

Remove pygments CSS

One last relic of the code block remains... the pygment highlight styles in codered-front.css. These should be removed as they are no longer needed.