2016
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:
- 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.
- 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:
- a WSGI server package that would bring FTP capabilities to any WSGI app that handles WebDAV commands.
- 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.