Ideas for the Google Summer Of Code 2019


(Christian Müller) #1

Ideas for the Google Summer Of Code 2019

This topic is a collection of project ideas for Google Summer Of Code, should we be accepted.

If you have any idea for a smaller/medium feature that would be “nice to have”, feel free to post it here. A reasonable explanation of the feature is minimum required. If you have a detailed plan/idea even better!

Here is a template for you:

Idea title

A summary of the idea here, what, why, benefits, risks, … the more tangible, the better!

  • Expected results: Summary of expected outcome
  • Milestones: A list of intermediate steps to take, if applicable
  • Skill level: …
  • Knowledge required: …

(Christian Müller) #2

Transfer backend modules to react

Our main module (the content editing) provides a great experienced based on react now and offers a good selection of building blocks. It would be nice to rebuild existing backend modules on that so they work with react + (maybe to be build) HTTP APIs.

  • Result would be one (or more) (previously decided upon) backend modules recreated in ReactJS.
  • Milestones along the way could be building the necessary API endpoints and then creating the UI in steps until everything is working, maybe with a second pass to apply extra UX improvements.
  • Skill level: medium, ideally some React experience would be good.
  • JS, ideally React, maybe APIs, some PHP, although help via community/mentor can be given on the API side

(Christian Müller) #3

Better PHPStorm Plugin

(transferred from 2018)

an Intelli-J / PHPStorm plugin for Neos exists but could be improved upon to add QOL features like Better support for Fusion / AXF, refactoring, code usage, …

Milestones could be defined features / additions to the plugin
Skill: JAVA


(Christian Müller) #4

GraphQL for React UI

Our React UI currently uses a mix of different specific APIs, there is a basic implementation of GraphQL for Neos.
The goal of this project would be to extend the implementation on the PHP side and get it working with the backend. Not every single endpoint must be replaced but a solid basis for replacing the old APIs with a common GraphQL API should be created.

Skills: PHP, React, GraphQL, medium/hard


(Christian Müller) #5

REST-ful API

We would like to offer a REST API along the lines of contentful or prismic to access content stored in a Neos ContentRepository.

Skills: PHP, REST, HTTP, medium


(Christian Müller) #6

Welcome package

Flow has a welcome package that should brushed up in terms of style and functionality. It could include a UI based kickstarter for packages and models.

Expected results: Nicer Welcome package with better introduction, first-steps and maybe UI based kickstarter for packages and models.

Milestones: New Design, additional information for Flow newcomers, introduction, kickstart ui
Skils: PHP, HTML, CSS, easy


(Christian Müller) #7

GUI for rights management

But a simple solution for the user rights on pages, contents also backend views/plug-ins would be very necessary.

This could be very broad or narrow and specific to just a defined set of permissions, so the task can be adapted to a student.

Requires PHP knowledge and JS/React.


(Christian Müller) #8

Implement basic structured editing

We have a good idea what we are looking for at this point and there are some rough experiments for these features available as a direction, but actually implementing it in a way it could go into production would be a nice task for a GSoC project.

Probably needs ReactJS experience, at least solid JS experience and some understanding of UX.
This might be a harder task.


(Soren Malling) #9

PSR-15 for Neos Flow

Let’s adopt the new standard fully and introdue PSR-15 and middleware. This will give a huge benefit in getting in to Flow since we streamline with how the PHP world is moving

This is a hard/medium-hard task
There is already a number of PSR-15 implementations in others frameworks that a student will be able to lean upon


(Soren Malling) #10

Remove database dependency in Neos Flow

In a aim to build a more light-weight version with less dependencies, removing the database/orm dependency would be a large and great step.

Feedback from original discussion is gathered here Could we build a version of Flow without doctrine orm / database requirement

Hard task that requires knowledge on the current ORM and database implementation


(Dmitri Pisarev) #11

I’d say it needs more UX/design experience, as the technical implementation is already there and it’s trivial.


(Soren Malling) #12

This will (IMO) also be about removing the http component concept and implement them as PSR 15 middleware. Correct me if wrong :slight_smile:


(Christian Müller) #13

Sadly the Neos Project wasn’t accepted either this year.

I have some ideas but i guess I would need some help next year then. If you are interested to make us a stronger candidate, please hit me up on Slack.