Google Summer of Code Project Ideas 2019

Ideas for GSoC student projects for Plone in 2019.

These are project ideas proposed for Plone's participation in Google Summer of Code 2019. Student interested in working on these are encouraged to apply for the program

Note, most projects do not require the candidate to know Plone already, but we do expect applicants to have started to learn about Plone before applying. Applicants that submit bug fixes, even minor ones to add-on packages, are strongly preferred. The specific technologies required for each project are listed in the details for the idea.

Prospective students should follow our ideas for getting started before writing up their proposal.

Sitewide search & replace

Summary

For larger websites, it can be hard to find, and especially edit, all occurrences of a specific word or term. A tool that can do this site-wide, preferably using regular expressions or at least wildcards, would be extremely useful. This, on the other hand, is also a powerful tool that can be dangerous, so it should probably be restricted to site administrators and be only accessible via the site management screens. One other option would be to build a tool that does this 'outside' of Plone, and uses RestAPI to achieve the same goals.

Implementation

An earlier implementation was created as rt.bulkmodify. The readme still defines what the use cases are. But these days there are better ways of accomplishing these goals, supporting Dexterity content types with plone.api, and having a nicer JavaScript user interface. Maybe using plone.api one could theoretically address both AT and Dexterity content types, but I would start "fresh" and just assume only dexterity types exist. Other options of course could be a solution fully "outside" of Plone: a self-contained app that uses restapi to go through all the content and to the desired search & replace functionality. That could be written in React or Angular and made to integrate with an existing Plone front-end.

Skills

if implemented as Plone add-on: Python, Plone, some JavaScript. If implemented as self-contained tool: React or Angular, rest.api, regular expression handling in JavaScript

Mentors

Paul Roeland

Aims

A releasable product that can be installed on a new (5.2) site, Python 2/3 compatible (if achieved as Plone add-on). A self-contained tool that can do search & replace on an existing Plone site using restapi credentials (if achieved using JavaScript and restapi/graphql)

GatsbyJS Preview for Plone

(join the conversation)

Summary

The project plan is to enhance existing project "gatsby-source-plone" with features that allow "gatsby develop" development server to provide up-to-date instant live previews of pages that contain data from a Plone CMS source. The aim is to enhance "gatsby-source-plone" to provide a GatsbyJS development experience matching the experience provided by "gatsby-source-filesystem" based plugins, which can create, update and delete nodes on from filesystem events.

Implementation

GatsbyJS is a React-based, GraphQL powered static site generator. It creates the fastest web sites possible. It is great. With the gatsby-source-plone plugin, you can build those fast sites from content managed on Plone CMS. That is awesome. Running a GatsbyJS rebuild for a site with thousands of pages can take minutes, if not on hour, after a single change. And only after that long rebuild can the author see if their updates look cool. That's not cool.

The project plan is to enhance the existing project gatsby-source-plone with features that allow the gatsby develop development server to provide up-to-date, instant, live previews of pages with data from a Plone CMS source. This makes it possible to use gatsby develop to provide a preview of the changes and only run the static site rebuild when the author is ready. This would make gatsby-source-plone the best available CMS plugin for GatsbyJS.

GatsbyJS has the required API, but it is not well documented nor seem to be used widely outside gatsby-source-filesystem, which already provides similar development experience with, for example, gatsby-starter-blog. The solution probably includes implementing a small API server inside gatsby-source-plone that receives cache invalidation requests from the source Plone site.

Skills

JavaScript (ES7), ReactJS, GatsbyJS, NodeJS. Learning and understanding gatsby-source-filesystem would be a significant part of this project. 

Mentors

Asko Soukka

Aims

Pull requests to gatsby-source-plone to implement and document the planned feature.

AureliaJS SDK/UI

(join the discussion)

Summary

Building a Aurelia SDK with ready to use components for Plone Rest-API. Including navigation, breadcrumb, toolbar menus and so on. These components should follow the idea of the existing Angular SDK for Plone. The components should make it possible to implement the Pastanaga UI as well as being flexible enough to have other layouts.

Implementation

Aurelia is an easy to learn and use Javascript framework which combines good conventions with standards conformant ES6 or Typescript support. It gives the developer the freedom to choose between ES6 and TypeScript for their applications. With it's great conventions, it removes a lot of the boring configuration boilerplate and extensive imports that other frameworks need. That gives developers peace of min and allows them to focus on the real project. Building apps is fun again. Especially when combined with the Plone Rest-API is a lightweight, well documented and powerful API, which is fun to build apps for.

Aims

A basic Aurelia SDK for Plone Rest-API, with the most important components and services, to have an easy start on building Aurelia based apps with Plone as a backend.

Skills

The student should be familiar with modern Javascript ES6 and/or Typescript. Also with formats like JSON-LD, which is partly used by the Plone Rest-API.

Mentors

Maik Derstappen

Guillotina API Evolution

Summary

Guillotina's API is amazing! This project aims to continue to improve it by providing a more compliant JSON-LD API, support full REST API through a websocket protocol, utilize JSON schema to validate input payloads, provide a mechanism to version our APIs and more completely document our endpoints.

Implementation

  • Create a more compliant JSON-LD API: Guillotina's API is JSON-LD inspired. It should fully adhere to the JSON-LD specification.
  • Websocket API protocol: Fully support all API functionality through the websocket endpoint.
  • JSON schema validation: Right now, Guillotina supports JSON schema for content fields and validation; however, not all JSON bodies have JSON schema compliant validation. We need to validate all JSON payloads against well defined JSON schemas.
  • OpenAPI 3 support: Along with updating JSON schema validation support, we need to update our swagger documentation to work with OpenAPI 3/swagger 3.
  • API versioning: Provide a mechanism to version API endpoints. For example, prefixing all urls with `/v1`, `/v2` etc.
  • plone.restapi compliance: It is also important that we coordinate with the plone.restapi so the APIs are similarly implemented.

Skills

Python - AsyncIO - REST APIs

Mentors

Nathan Van Gheem

Aims

Each of the sections in the project description are separate individual tasks for the project. A desired output for this project would be successfully reviewed and merged pull requests for each of these tasks for Guillotina.

Guillotina Object Server

(join the conversation)

Summary

Guillotina uses a PostgreSQL-compatible database as the source of truth and Elasticsearch indexing of PostgreSQL JSONB. This project involves creating a new component that handles the storage and indexing in a new, distributed piece of software: Guillotina Object Server. The main values of this project are transactional support, distribution of information, and indexing technology using a low-level language: Rust.

Implementation

The aim is to build a small and fast component that handles transactions and keyword/full-text searches from Guillotina. There is already a basic implementation which shows the overall design of the concept with a Protobuffer protocol, Rust bindings to RocksDB and basic integration with Tantivy (full-text indexer). Based on top of Tokio async framework on Rust and Protobuffer protocol this project has four goals:

  • Storing python pickles on a Rocksdb mapping the transaction mechanism from Guillotina. It needs to provide the same API from internal storage Guillotina so each object is stored in a secure hierarchical structure.
  • Storing the indexing information on each transaction on RocksDB and Tantivy to support keyword indexes and full-text index.
  • Providing an interface to search ok keyword indexes and full-text search with the security checks.
  • Providing an interface to load security and pickles using Guillotina internal storage API.

Optionally, providing a Raft protocol to sync multiple instances of the object server and distribute the load would be great.

Skills

Protobuf, Rust, RocksDB, Python3 Asyncio, Tokio, Transaction behavior

Mentors

Ramon Navarro Bosch

Aims

  • A minimum viable binary that receives objects from Guillotina and is able to store and read them on a Rocksdb, handle transactions and index on a keyword index or full-text search.
  • A python package that serializes objects on a transaction to Protobuffer and implements ICatalogUtility so Guillotina can do searches.

Improving the Plone Theme Editor

(join the discussion)

Project Summary

The overall goal is to make it possible for editors of themes to feel comfortable working directly in the theme editor. David Bain and Oshane Bailey suggested an improvement plan for the theme editor in the Products.CMFPlone issue tracker (#2705), which will serve as the base plan. Improving the experience for the theme editor while giving it more superpowers is of great value to Plone developers, designers, and site builders.

Implementation

The following should be made possible:

  • users should be able to clone files from another theme to the current theme, e.g. fragments, rapido apps and images. The mentor for this project implemented this for Rapido apps during GSoC 2017.
  • users should be able to download and install themes from a store TTW from an external site. This would be similar to Wordpress and other major CMS theme/plugin stores.
  • Drag and Drop upload (Almost finished)
  • Implement ACE editor’s autocomplete feature in Plone theme editor for code hinting.
  • help should be displayed in context and not load off-site (it may need to be rewritten to be more Plone specific rather than linking to the diazo.org site)

The following bonus features might also be considered:

Users should be able to change the skin of the theme editor, i.e. change the look of the theme editor. There are cases where individuals may have visual impairment when it comes on to certain colors. By default, ACE Editor allows developers to set the theme to be used when instantiating the editor. With the suggested new theme editor, it will allow users to update the skin from a drop-down menu with all available themes, similar to changing the skin for c9 or sublime text. The selected skin will be stored in localStorage to be activated upon visiting the theme editor.

Users should be able to revert to a previous version of a file from the version history of the file. This should work similar to Google Docs document history mechanism. Old revisions of the file should be loaded from ZODB, but would be a good amount of backend coding. This feature was recommended by Asko Soukka from the plone community.

TTW Git - apart from using git versioning to do the file comparison mentioned above, users should be able to push their theme directly to a git repository from the editor.

Aims

The aim of this project is to build a fully stable user-friendly version of the Theme Editor that supports automated backups, version comparison and integrated service component with git and external services.

  • improve the UX/UI for the theme editor, especially for web accessibility.
  • reduce the worry about overriding themes upon upload even if someone made a change that you don't know about.
  • remove the need to download images, fragments and other files from one theme and upload those files to another theme.
  • instead of cloning the theme and having many versions of it shown in the theme editor, the editor tracks versions of the theme for you and allows you to revert or compare various versions of the theme.

Skills

JavaScript Python JWT Token Version Management and Conflict Management UI / UX

Mentors

Oshane Bailey

Finish plone.importexport

Summary

The ability to import and export content between Plone and other CMS systems was proposed for GSoC 2017. The project was partly completed, but needs to be finished. A proposed UI is in the project issue tracker and includes features like

  • saved profiles
  • users, registry and exporting/importing other settings
  • flexible ways to bulk update or add content
  • handling very large imports using client side restapi calls
  • potential AT support and handling converting to dexterity

Implementation

Complete the work outlined in this issue as well as other issues in the project tracker in GitHub.

Skills

Python. CSV. some JavaScript would also be welcome.

Mentors

Dylan Jay, Shriyansh Agrawal (GSoC Student, 2017 and 2018)

Aims

A fully polished release of plone.importexport available as an installable add-on and possibly accepted into Plone 6 as a core component.

Your Own Idea

Summary

We love your own suggestions! Ask us at community.plone.org and we'll help you polish the idea into something we both love.

Implementation

As long as it benefits the Plone community it can be anything. Most likely the majority will be Python and direct to Plone, but we will also accept Zope, ZODB, WSGI, HTML/CSS, JavaScript, etc.

Skills

Tailor your idea to your own skills

Mentors

Don't worry about this, at Plone we think it's our responsibility to find you the right mentor. We've got a large and supportive community with plenty of mentors waiting to help.

Aims

A core contribution or an add-on, most likely.