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
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.
GatsbyJS Preview for Plone
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.
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.
gatsby-source-filesystem would be a significant part of this project.
Pull requests to gatsby-source-plone to implement and document the planned feature.
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.
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.
Guillotina API Evolution
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.
- 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.
Python - AsyncIO - REST APIs
Nathan Van Gheem
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
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.
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.
Protobuf, Rust, RocksDB, Python3 Asyncio, Tokio, Transaction behavior
Ramon Navarro Bosch
- 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
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.
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.
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.
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
Dylan Jay, Shriyansh Agrawal (GSoC Student, 2017 and 2018)
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
We love your own suggestions! Ask us at community.plone.org and we'll help you polish the idea into something we both love.
Tailor your idea to your own skills
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.
A core contribution or an add-on, most likely.