Project Ideas

These ideas were proposed for the 2016 Google Summer of Code

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

Note that most of the 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 alongside the title and in the details for the idea.

Better GenericSetup handlers

(Zope, Plone, & Python)

Summary

GenericSetup is used as a generic framework for import/export handlers in CMF and Plone. There are a good number of existing handlers that do useful imports and exports, but they contain various bugs and missing features that need to be addressed. Currently, the missing features are encouraging people to write their own single-use handlers.

Implementation

This will involve replacing handlers in the Plone and CMF core packages, especially CMFCore, with new ones entirely in Plone constructed code. There are about 50 existing handlers spread around the codebase, so the first step is to identify missing features in them by analyzing setuphandlers.py files in other products. For example, the portlet assignments handler only exports portlets on the site root, rather than ones anywhere in the site. This means the round-tripping of portlets has to be done manually, so is done in custom Python in practice.

The existing handlers are also poor at remaining mutually consistent, existing handlers use purge=True attributes, .preserve files, etc as ways of marking configuration that should be excluded. These remove directives are never exported, as it's not possible to export that some configuration has been deleted, but poor design of the output formats makes it hard to make these stanzas manually. The extensive use of non-standard XML documents is a key reason they are unpopular.

Skills

Excellent good knowledge of Python and confidence with Zope features like catalogues and CMF's portal_setup.

Mentors

Matt Wilkes would love to mentor this.

Aims

Pull requests for Plone, potentially as an experimental.setuphandlers package too.

Content import/export

(Plone, Zope, & Python)

Summary

Currently the official way of round-tripping content from Plone to other systems is the GenericSetup content exportimport handler. This handler is based on Zope's WebDAV support and has grown organically over about a decade. It works very poorly indeed and most users avoid it. In recent years it has been improved however it is still not of a fit state for use.

Implementation

The content import/export functionality will be entirely reimplemented with a new implementation. The new export format must be able to export all built-in Plone content types as well as basic custom dexterity content in such a way that it can be reimported to another Plone site and yield identical results. The most challenging part of this is ensuring that all metadata and supplementary field data is retained exactly.

In addition, it is highly desirable that the export format is human-readable and that exported files make sense from a filesystem point of view. This means that if a piece of content contains a PDF file, the PDF file should be accessible if the zip is opened. Doing this in such a way that supports the flexibility of Plone content types would be an exciting challenge for someone that wants to write a significant piece of Python.

Skills

Excellent good knowledge of Python and confidence with Plone features like dexterity.

Mentors

Eric Bréhault would like to mentor this. Other developers with an interest include Matt Wilkes, Sean Upton and Espen Moe-Nilsen.

See also

Aims

A complete and merged PLIP 1386 with full documentation.

plone.app.mosaic improvements

(HTML, JavaScript, & Plone)

Summary

plone.app.mosaic is a new feature in Plone 5 that allows composition of page blocks into layouts, enabling administrators to define set ways pages look and delegating filling the blanks to content authors. The package is being used in production which has led to a number of ideas for improvements.

Implementation

There are currently 24 feature ideas open on the mosaic issue tracker. They cover a range of things, from usability enhancements to performance fixes. Many of these have discussions about how to proceed already, however the successful student would also propose their own improvements.

Skills

The most important skill for this task is a good understanding of user experience design and a methodical manner. Good knowledge of portable HTML and Javascript is essential. The Python and Plone aspects will not be especially onerous but it would not suit someone who isn't keen on learning the various Plone libraries.

Mentors

Asko Soukka would be a great mentor or product owner. Plone generalists that act as mentor will have to have real-world experience with Plone 5 to provide adequate advice.

Aims

A series of accepted pull requests to plone.app.mosaic.

Improving collective.easyform

(Plone)

Summary

Products.PloneFormGen is a very commonly used add-on to Plone that allows people to build form logic into their websites. It is well maintained and well tested, and has had considerable effort expended on the user interface decisions, including past GSoC projects. The backend it uses is the content types framework introduced in Plone 2 which we are moving away from for performance reasons. collective.easyform builds on the work done in PloneFormGen and the changes to Plone Core that introduced dexterity, it is the logical place to continue work on bringing PFG's functionality up-to-date.

The current collective.easyform is at the proof-of-concept stage. It does not have a stable upgrade path or all of the wide functionality of PFG, but much of the heavy-lifting of getting the framework in place is there.

Implementation

Firstly, the existing easyform code will need to be updated to fix problems with Plone5 compatibility. Then the bugs listed in the easyform issue tracker will need to be addressed.

After easyform is at production quality, missing features from PFG can be introduced in an iterative fashion. This will involve researching what features are most useful by talking to users of PloneFormGen.

See Also

Skills

Basic Plone experience, some minor HTML and Javascript.

Mentors

Kim Chee Leong and Michael Graf have been working on improving easyform. Roman Kozlovskyi from QuintaGroup makes sense as a product owner. That said, any Plone generalist would be a good choice.

Aims

New releases of collective.easyform.

Alternative content authoring journey

(Plone)

Summary

The process of adding content to a folder in Plone can be quite counter-intuitive. In older versions of Plone the add content button was available on all pages which caused the button to act unpredictably. If you were viewing the default view of a folder then new content would be added as a child, other pages would add it as a sibling. For this reason, it was restricted to views of folders only.

Unfortunately, this solution is far from perfect and doesn't solve the other issues users have. For example, many sites restrict some content types to particular subfolders (e.g., news items). This has very poor discoverability for new editors, who have to be trained not only on the content management system but their particular implementation.

Implementation

One of the distinguishing features of Plone is the add-in-place functionality, we wouldn't want to lose this. Therefore, this work cannot replace the add content functionality wholesale. Instead, it should supplement it by exposing the same add forms as a global add wizard.

See Also

Skills

Strong Plone experience, minor HTML and Javascript, a good eye for user experience.

Mentors

Dylan Jay

Aims

A new collective package that integrates well with core Plone.

Improve usability of sharing controls

(Plone)

Summary

The Plone security model is very flexible, however sometimes that results in counter-intuitive forms. The sharing UI and permissions isn't as bad as some of the behind-the-scenes forms but it is far from intuitive. This project aims to consolidate some of the terms used and improve the usability of the various forms to improve the experience of set-up for site administrators.

Implementation

The word 'Roles' should be entirely removed from the UI to be Rrplaced it with "permission set" or a similar term. The roles configuration matrix should be removed from the user and groups control panels and instead a link to standard sharing form of the portal root, to make it clearer that there is nothing special about people having access to subsections of the site.

We should also integrate a display of how workflow state affects capabilities on the sharing tab. For example, if submitted state removes edit permission from the Can Edit permissions set that should be noted. This aspect will require especially good UX skills to do cleanly. Combining sharing and state into one form could help show the relationship between what is possible in a certain state and if its possible, who can do it.

See Also

Skills

Strong User Experience design skills, minor HTML and Python.

Mentors

Dylan Jay

Aims

A PLIP and accompanying pull request set for Plone core.

Improved Diff Viewer

(HTML & JavaScript)

Summary

Plone allows users to compare different versions of their content (and revert to previous versions, if required). However, the user interface for this is very technical and of limited use to most end-users. This project is to replace the current way of viewing diffs with one similar to tools users may experience elsewhere.

The biggest improvement that needs to be made is that of diffing HTML text. The current view is very colourful but not very useful. The changes behaviour for Wikipedia would be good to draw influence from, as would Microsoft Word's track changes feature.

In addition, many fields are not "inline-diffable", meaning the user has to switch to code view (which displays a poor side-by-side diff). One possible way of implementing this would be to re-use the UI of the edit form and highlight changes there.

Implementation

The functionality for generating diffs has been part of Plone for a long while. The main work here will be in designing a new UI that both accurately shows differences in field values and is easy to understand. This will, by necessity, be primarily a HTML and Javascript project, but some minor knowledge of Python will be needed. That's not to say you'd have a completely free hand in Javascript, though. The use of libraries in making this view would need to be cautious, as this is part of core Plone. Certainly no new JS frameworks could be introduced, but it would be good to explore diffing in javascript.

See Also

Skills

HTML, Javascript. Some minimal Python will be required to ensure the data formats are appropriate.

Aims

A pull request to be included in the next Plone release.

Content Drafts

(Plone, Zope, & Python)

Summary

plone.app.drafts allows content that hasn't been finished yet to be auto-saved to a special location so that if the user has an issue with their browser or connection it's not lost.

Implementation

Integrate and extend plone.app.drafts into Plone with support for Archetypes and Dexterity. The back-end support is pretty much there but it needs a UI and integration with content type frameworks.

See Also

Skills

Plenty of Python and knowledge of Zope. Experience in dexterity would certainly be helpful.

Mentors

Ramon Navarro Bosch or Nathan van Gheem would be great mentors

Aims

Improvements of existing packages and PLIP for Plone 5

New theme pack

(HTML, CSS, & JavaScript)

Summary

Diazo allows us to use HTML, CSS, and Javascript mockups as themes relatively easily. We currently have very few good quality examples. This project would be to create HTML/CSS/JS themes for Plone which can later be converted to Diazo themes.

Implementation

This requires a series of zip files that contain working single-page HTML mockups that demonstrate the core Plone features. They should have support for portlets, a navigation bar, logo, etc.

Preferably these themes would have different colourways available, through compilation of LESS/SASS, as well as different styles for customers in different industries.

See Also

Skills

Javascript and HTML. No Python or Plone knowledge needed.

Mentors

David Bain would like to mentor this project.

Aims

Three or more themes to be packaged with the Unified Installer.

eBook content export

(Plone & Python)

Summary

The idea behind ftw.book is to provide a Plone class "book“ that creates a LaTeX-output for a printable PDF. At the moment, it functions but at the "proof of concept" level. It would be great to extend that and offer – via the plone web interface – some more of the options from the LaTeX universe.

Other members of the community have done extensive work with integration with publishing platforms, both at the small and large scale publisher level. This project would be aimed more at current Plone users that want to generate beautiful printed versions of their content or host dual-format content. Another use-case mooted is that users may like to use this as a hard-copy archive of their content.

Implementation

It's most important to be clear about exactly what functionality is in scope, to avoid building a package that does many things poorly, so the first step will be to work with your mentors to explore exactly what user stories make sense.

We wouldn't expect you to build the tools for generating the book layouts yourself, this is very much a piece of integration work. If there are any generally useful pieces of reusable functionality they should be factored out into their own packages or replaced with existing libraries.

See Also

Skills

Python and Plone knowledge are a must. LaTeX experience would also be very useful.

Mentors

Bernd Kulawik proposed this project and would be the best choice as mentor.

Aims

A new add-on product in the collective namespace.

Improvements to Patterns widgets

(HTML & JavaScript

Summary

Patterns (and plone.app.widgets) is the new widget story for Plone that allows Javascript developers to create new widgets for Plone. There are some specific improvements that need to be made to the widget javascript:

Pick-a-date
Better keyboard-only-navigation of pick-a-date, with support for text-entry of dates and basic normalized, localized date parsing (using a wrapper around moment.js parsing). Recurrence-rule widget pattern, possibly based on work in plone.app.event? Add timezone picker based on select2 pattern as (a) distinct widget; (b) something that can be enabled as part of the date widget.
A "fullcalendar" replacement as a mockup pattern
Possibly based on D3.js and/or Vega; consumes mockup JSON calendar data irrespective of its source. Target deliverable would be pattern that consumes configuration options, JSON/iCalendar/xCal/hCalendar listings of event data and outputs weekly, monthly, or daily calendar (to time-scale) with ability to switch views without page reloads.
A subject/tags picker
Support for tree-like controlled vocabularies and/or ad-hoc keywords, and auto-complete; might re-use parts of related items widget; should support some eventual tool like possible successor ATVocabularyManager. Could use ICD.9, NAICS, IPTC, and other freely available vocabularies as data-sets for development.
Datagridfield
Something like the UI bits of collective.z3cform.datagridfield re-done using more modern code, look/feel, as a pattern.
Basic new widgets
color picker; slider/range input; likert-scale widget; add infinite scroll to Select2 pattern; location picker (search using map that pops up/down in overlay, gets normalized street addresses and/or geocoded latitude/longitude for pin); person-picker based on Select2 supports names/profile pictures; image-thumbnail picker.
Microformat support widgets
For use with TinyMCE 4 when editing rich text. e.g. an hCard entry form, a basic event entry form for (limited) hCalendar, a rel-license generator, location support for h-adr plus h-geo.

Implementation

HTML and Javascript mockups for the new widget designs, added to the mockups repository.

See Also

Skills

Javascript and HTML. No Python or Plone knowledge needed.

Mentors

Sean Upton (former GSoC) has expressed interest, Franco Pellegrini would also be great.

Aims

A contribution to Plone core

Python3.5 support

(Python)

Summary

We would love to get Zope and Plone working on a modern version of Python. We cannot stay on Python2.7 forever, other Python frameworks have already made the switch and we do not want to be left in a wasteland of old, unsupported code.

Zope is harder to port to Python3 than most projects as it has a sandbox that requires updating to work with Python3's new syntaxes. In addition, significant parts of the Zope codebase work on the bytes level, such as databases, web servers and search catalogues.

Implementation

You will want to prioritise packages that are not yet Plone3 compatible and ensure they have a CI environment that includes the latest version of Python 3, then make changes to get all tests passing on Python3. This will be a long process, so a divide-and-conquer approach is the only appropriate way to move forwards. A good place to start is the current master of Zope in GitHub.

It's vital that the Zope codebase continues to run on Python 2.7, at least in the short-term. Once Python3 support is widespread we can consider deprecating Python2 support. We want to do this by writing code in such a way that it runs under both environments, using tools like six. It would be acceptable to use auto-translated wheels using the 2to3 hooks as a way of getting working versions of dependencies so that the harder work can be tackled, however this wouldn't be the way to proceed in general.

Skills

This would suit a student with good Python skills as well as experience with Python 3. A proper understanding of unicode and text encoding would be invaluable. Knowledge of parsers and ASTs would be adventageous.

Mentors

A core developer participating in the Zope4 project, such as Johannes Raggam or Nathan van Gheem.

Aims

Pull requests for Zope.

Make HTTPRequest behave more like its WebOb counterpart

(Zope & Python

Summary

Zope has its own implementation of a HTTP server ('Medusa'), along with request and response objects. They provide a number of pieces of functionality peculiar to Zope, however we would rather not have them in the long term. There are a few ways to handle this, of varying difficulties. The most preferable one would be to completely remove Medusa and replace it with a standard WSGI interface, as well as breaking all dependencies on the Medusa code. This is also the hardest way.

Another option is to modify the existing HTTP objects to implement the same interface as the webob counterparts, allowing users to freely use more modern idioms for interacting with the request layer.

Implementation

The code for this is in ZServer, part of core Zope. The general approach would be to get a Zope core development buildout running and augment its testing to cover the behaviour of WebOb objects, as well as adding the functionality being tested. As this is such a core part of Zope, it's vital that the test coverage is excellent

The next step would be to identify the idioms that are hardest to express clearly with ZServer but are clear in WebOb, and systematically submit pull requests to those projects to take advantage the new code

Skills

To be successful at this project you'll need extensive Python experience and to be comfortable with exploring large code bases. This will involve a lot of core Zope development work.

Mentors

Ramon Navarro Bosch, or other developer familiar with Zope low-level interfaces. Leonardo Rochael Almeida will serve as product owner if this is accepted.

Aims

A branch of Zope that implements the new interface and a PLIP to adopt it in Plone, as well as pull requests for various pieces of Zope and Plone code that can be migrated.

Remove the ZServer dependency

(Zope & Python)

Summary

Zope has its own implementation of a HTTP server ('Medusa'). They provide a number of pieces of functionality peculiar to Zope, such as an FTP server, remote debugger, etc. We would rather not have a hard dependency on them anymore, and we would like the flexibility to use other WSGI servers, such as gunicorn.

Implementation

The successful candidate would take a fine scalpel into the ZServer code base and split it into two parts:

  1. An independent ZServer package that is a WSGI server which is also capable of talking FTP, mapping FTP commands into WebDAV HTTP commands. This code should have no dependency on HTTPRequest/Response or ZPublisher.
  2. Some request marshaling and "module publishing" code that should be folded into ZPublisher, HTTPRequest and/or App.

This same project would turn ZPublisher into an WSGI app that handles the "module publishing" in the old Zope2 fashion.

It should also clear out the cruft from all previous attempts at WSGI from Zope2, which mostly broke the "module publishing" machinery, but only created a barely functional Zope2 WSGI app (broken error handling, among other issues). This is because it attempted to create the WSGI app at the wrong level of the Zope2 code base.

When you look at the ZServer code base in detail, you come out with the impression that the WSGI spec was mostly taken from its implementation, so the project as I described above would have very well defined boundaries and bring about two large benefits:

  1. a WSGI server package that would bring FTP capabilities to any WSGI app that handles WebDAV commands.
  2. Turning Zope (hence Plone) into a true and native WSGI app.

All this with zero impact on code bases outside of the lower levels of the Zope2 codebase.

Skills

To be successful at this project you'll need extensive Python experience and to be comfortable with exploring large code bases. This will involve a lot of core Zope development work.

Mentors

Leonardo Rochael Almeida will serve as product owner if this is accepted. This would involve getting advice from others who have worked on Medusa, such as Nathan van Gheem and David Glick, so the mentor can be anyone with experience working on Zope as the majority of specific advice will be provided by product owners.

Aims

A branch of Zope that implements the new interface and a PLIP to adopt it in Plone, as well as pull requests for various pieces of Zope and Plone code that can be migrated.

Replace DateTime with datetime

(Python)

Summary

Zope, on which Plone is built, predates many parts of the Python standard library. The support for datetimes is in the DateTime module (note the capitalisation). It was written six years before the standard library gained an implementation of datetimes and is not compatible, either in data storage or API. There are methods to convert between the two implementations, preserving information such as timezone.

While this is an okay workaround, this implementation is twenty years old and not used by any other community. We want to move entirely to the standard implementation and stop using DateTime everywhere.

Implementation

All pieces of content within Plone use DateTimes for creation and modification metadata, as well as various other places such as last sign-in times, embargo dates, etc. These are all loaded into the portal catalogue, which allows searching and filtering of content according to these dates. This means that the references to DateTime are scattered throughout the entire codebase and not just in a single module.

As this project involves lots of deep changes in many packages, the successful applicant will have demonstrated the ability to work confidently within a large project, for example by contributing fixes to core Plone as part of the application process.

Skills

To be successful at this project you'll need extensive Python experience and to be comfortable with exploring large code bases.

Mentors

Any Plone core developer will be well suited here, the problem is well defined and doesn't require significant planning. A framework team member, such as Johannes Raggam, would be perfect due to their experience with the PLIP process.

Aims

Multiple pull-requests for Plone and Zope, along with a PLIP to integrate them.