Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Gsoc2013/Ideas

From TYPO3Wiki
Jump to: navigation, search

About this page

Google has announced the Googles Summer of Code for this year again. GSoC is a program by Google to fund OpenSource projects (like TYPO3) by enabling student developers to contribute to OpenSource projects over a three month period ("flip bits, not burgers").

This page exists to collect and discuss all the ideas from our TYPO3 Community (developers and users) to give the students some inspiration for their project proposals and enable them to get in touch with the possible mentors beforehand.

You will find general informations about TYPO3 in the GSoC 2013 on GSoC2013.


Information for Students

These are ideas collected in our TYPO3 community. If you're an interested student, we highly encourage you to get in touch with the possible mentors for this project and discuss the idea. If you have an own idea, which is not yet in this list yet, do not hesitate to contact us. We will find someone who is in charge for the affected sub-project.

If you have any questions, it's a good idea to contact us, using for example:

Getting in touch with us and discussing the project idea will definitely increase your chance to write a good project proposal and finally to get accepted.

You will find general informations about TYPO3 in the GSoC 2013 on GSoC2013.

If you want to apply for or propose a project, please use our Application Template. The student application period begins at April 22 19:00 UTC.

Adding an idea (template)

If you have an idea for a possible GSoC project, please add it to this wiki page, using the following template. You need a typo3.org-account to edit this page.

It's about projects for all our products: TYPO3 CMS, TYPO3 Flow, TYPO3 Neos, Extbase, Fluid, TYPO3.Surf, <youNameIt>. Feel free to add new ideas to the wiki page, as well as improving the already existing ones. For deeper discussions about an idea I suggest to use the typo3.gsoc maillinglist [3].

GSoC ist the "Summer of Code". So a "documentation task" won't really fit. Remind that possible students might not have any deep knowledge in TYPO3 yet. Also a project should be achievable for one student within the three month coding period. So completely rewriting the TYPO3 backend might not be the best choice for a GSoC project. If your critical business depends on this new feature being available by the end of this summer? Humm.. better do it yourself or pay someone for it. But this idea, you already have in mind for months or years, you can't find time to implement it and you know people will be like "wow, this is cool". Someone really should do it somewhen? Yes, that might be a cool GSoC project! Or this great concept, which came up lately while discussing <something> in the mailinglist/twitter/bugtracker or on the T3Something event. That might be one, too!

Be creative. You might find some inspiration in the issue trackers on forge.typo3.org, in discussions on the mailing lists, on twitter, in offline-discussions, this wishlist and also on last years ideas page Gsoc2013/Ideas/needsCheck.

If you have a good idea for a proposal, but you are not sure if it fits for GSoC, get in contact with the gsoc team in the mailing list http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-gsoc or on IRC irc://irc.freenode.net/#typo3-gsoc.


----
=== <your project idea> ===

'''Suggested by:''' <your name and email address for contact>  --~~~~

'''Brief explanation:''' <give a brief description of the suggested project/idea>

'''Expected results:''' <what should the outcome or goal of this project be?>

'''More informations:''' <links to discussions about this idea, detailed descriptions, bugtracker, an additional wiki page, mockups, whatever helps to get the idea>

'''Skill level:''' <easy, medium, hard>

'''Knowledge prerequisite:''' <any special skills required? (beside of PHP)>

'''Possible mentor(s):''' <name and mail address> (multiple mentors/suggestions possible!)

'''Votes:''' 0 (increase this number by 1 if you like this idea)


TYPO3 CMS projects

TYPO3 is an enterprise-class, Open Source CMS (Content Management System), used internationally to build and manage websites of all types, from small sites for non-profits to multilingual enterprise solutions for large corporations.

http://typo3.org/about/typo3-the-cms/


add your idea here, use the idea/project template provided above


Extend EXT:coreapi

Suggested by: Tobias Liebig <tobias.liebig(at)typo3.org> --Etobi.de (talk) 16:13, 21 February 2013 (CET)

Brief explanation: EXT:coreapi is a TYPO3 extension which provides several helper/services and a CLI Api for some common tasks in TYPO3, like clearing the caches or running the "database compare tool". However it still lacks a lot of additional features. For example:

  • create/manage BE users/admins
  • print the page tree and partial trees (on CLI)
  • list content/records on pages
  • generic create/update/delete records (and not doing the plain SQL, but using the DataHandler (aka tcemain)!)
  • run/check the reports from the reports module
  • list, get and set TYPO3 configurations
  • lock/unlock the TYPO3 backend
  • create a database dump (exclude "temporary" tables like caches, sys_log, ...)
  • update an extension from TER
  • more (maybe check [drush] and [magerun] for appropriate commands)

Expected results: a fully featured EXT:coreapi, which enables a user, to do important tasks from CLI instead of require to them to use the TYPO3 backend.

More informations: https://github.com/etobi/ext-coreapi

Skill level: medium

Knowledge prerequisite: some TYPO3 experience will help

Possible mentor(s): Tobias Liebig <tobias.liebig(at)typo3.org>

Votes: 5 (increase this number by 1 if you like this idea)



TYPO3shell

Suggested by: Tobias Liebig <tobias.liebig(at)typo3.org>

Brief explanation: Replacement for the current "cli_dispatch.php" CLI script. Supporting for example autocompletion, an interactive shell, a "history" and some more, cool features.

Expected results: a "typo3shell"

More informations: Flow shell, MageRun for Magento, Drupal Shell, TYPO3 Console (incubator)

Skill level: easy - medium

Knowledge prerequisite: knowledge of common *nix/CLI tools, drush, magerun, Symfony Console Component will help

Possible mentor(s): Tobias Liebig <tobias.liebig(at)typo3.org>

Votes: 5 (increase this number by 1 if you like this idea)



Database Fixtures

Suggested by: Tobias Liebig <tobias.liebig(at)typo3.org>

Brief explanation: TYPO3 CMS stores some configuration data in the database. This makes it hard to versionize these configurations and deploy it in a multi stage environment. It should be possible to easily write content/rows of certain/configured tables (whole table or just single rows) into a file/multiple files ("fixture file"). This file could then deployed to another installation. Here can be checked if the fixture changed compared to the current database and changes can be applied/imported. (This concept might need to be finished. Get in touch with me!)

Expected results: A backend module and/or CLI interface to check changes in fixture files, import fixtures, write-back database records into a fixture file. Maybe this could also be integrated in the "List" backend module.

More informations: -

Skill level: medium

Knowledge prerequisite: some TYPO3 knowledge could help, but it's not mandatory.

Possible mentor(s): Tobias Liebig <tobias.liebig(at)typo3.org>

Votes: 3 (increase this number by 1 if you like this idea)



Migrations

Suggested by: Tobias Liebig <tobias.liebig(at)typo3.org>

Brief explanation: To deploy on a multi-stage environment (e.g. dev system, integeration/test, live/production) we need to implement migrations.

A "migration" can take care of required changes, like add/change configurations (some, which can't be versionized), create/update database records, and so on. Each Migration should provide an "up"/"execute" and a "down"/"rollback" method (to be able to revert a migration). A migration should be able to check if it could be applied (it might depend on another migration, on a certain Core/Extension version or anyfilebase other prerequisite). Extensions can provide multiple migrations. Each TYPO3 instance knows which migrations are already applied for it. A backend module or CLI should list all available migrations, show their status (already and not yet applied) and of course a user (admins only?) should be able to apply and rollback single migrations.

From a IRC chat about ”migrations":

http://guides.rubyonrails.org/migrations.html
http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/reference/migration_classes.html
do you know how database migrations work for e.g. Ruby or Doctrine?
The suggested project is about implementing something similar for the TYPO3 CMS, but not just for database schemas, but for all kind of "changes".
In this case a "migration" would jsut be a a class, whcih provides an up/execute and down/revert method where one can implement something, which he wnats to do/apply in a TYPO3 installation.
So we need smething to create und run these migrations. See which are already applied in a certain installation, ...

Expected results: An implementaion of "migrations", possibly as an extension.

More informations: -

Skill level: medium

Knowledge prerequisite: nothing special, beside good PHP knowledge. Having experience in Extbase or Flow can help.

Possible mentor(s): Tobias Liebig <tobias.liebig(at)typo3.org>

Votes: 5 (increase this number by 1 if you like this idea)



Content REST API

Suggested by: Soren Malling <soren.malling@typo3.org>

Brief explanation: Configurable REST API that makes it possible to submit content to TYPO3. Both tt_content and extension tables should be handled. Response should respect TCA configuration (relations etc), workspace and localization.

Expected results: REST API as a system extension.

More informations: https://wiki.typo3.org/T3A-budget-ideas-2013#Finish_the_REST_API_for_4.x.2F6.x

Skill level: hard

Knowledge prerequisite: REST API knowledge, TYPO3 security

Possible mentor(s): Perhaps some from the original forge project: https://forge.typo3.org/projects/extension-typo3_webservices

Votes: 9 (increase this number by 1 if you like this idea)



TYPO3 / Direct Mail as mail campaign engine

Suggested by: Soren Malling <soren.malling@typo3.org>

Brief explanation: Extend the functionality of direct_mail to work as campaign monitoring. Direct Mail offers a great way of sending simple newsletter with content from your TYPO3 installation, but more professional functionality like monitoring, click observing etc would lift it a lot. With knowledge from mailchimp (www.mailchimp.com) and other campaign motors direct_mail should give a larger statistic of the send email

Expected results: Larger statistic information in the direct_mail module. Click observing statistic, read/unread statitic, unsubscribe statistic

More informations: -

Skill level: medium

Knowledge prerequisite: Knowledge about mail campaigning statistic, direct_mail

Possible mentor(s): -

Votes: 2 (increase this number by 1 if you like this idea)

Remarks: An extension with similar features as requested already exists: https://forge.typo3.org/projects/extension-newsletter



oAuth layer for TYPO3 authentification

Suggested by: Sebastian Michaelsen <sebastian.michaelsen@t3seo.de>

Brief explanation: TYPO3 already ships with a system extension 'openid', that provides OpenID login functionalities for backend and frontend. Since oAuth seems to be the more accepted and wide-spread authentification protocol, TYPO3 could use an oAuth layer too. The layer could be based on or work like Opauth: The layer itself doesn't support any specific oAuth providers, but the support (for Google, Twitter, Facebook etc.) is added by small addons.

Expected results: TYPO3 community extension or system extension that allows oAuth logins for Frontend and Backend. In the long run it could also support OpenID (which Opauth already does) and replace the current system extension 'openid'

More informations: I began a proof-of-concept integration of opauth: https://github.com/smichaelsen/typo3-opauth

Skill level: medium

Knowledge prerequisite: Basic understanding of oAuth and security.

Possible mentor(s): Sebastian Michaelsen <sebastian.michaelsen@t3seo.de>

Votes: 3 (increase this number by 1 if you like this idea)



ExtensionManager: pull (install/update) extensions from Git repositories

Suggested by: Tobias Liebig <tobias.liebig@typo3.org> --Etobi.de (talk) 16:26, 21 February 2013 (CET)

Brief explanation: When installing or updating an extension in the extension manager, usually  the extension manager fetches the extension from the "TYPO3 Extension Repository" (TER) on typo3.org. Sometimes it could be helpful to be able to install an extension not using the official TER, but an own Git repository (maybe the extension is not public). To install an extension from a Git location the user needs to give the repository URL and a extension key. The user should be able to update (git pull) an extension which was installed using Git initially. Maybe, if the repository has "tag"-ed commits, the extension manager should provide to checkout a certain commit/tag.

Maybe it's possible to use "composer" to install or update an extension from a Git repository. Flow/Neos uses composer for its packages, too.

Expected results: Be able to install an extension from a Git repository using the extension manager. Update git installed extension to latest HEAD or to a certain tag.

More informations: -

Skill level: medium

Knowledge prerequisite: Git, composer, basic TYPO3 CMS knowledge and some knowledge how extensions work will help

Possible mentor(s):

Votes: 1 (increase this number by 1 if you like this idea)



Core updater

Suggested by: Tobias Liebig, initially by Xavier Perseguers --Etobi.de (talk) 16:32, 21 February 2013 (CET)

Brief explanation: It should be possible to easily update the TYPO3 CMS core, when a new update is released. There is a json-feed about the latest TYPO3 releases (http://get.typo3.org/json).

Kay Strobach already implemented an extension for backend notifications about new TYPO3 versions. This might need to be finished (currently beta state) and the "updating" part need to be implemented. Beside of a notification in the "toolbar" and additional "report" for the report module would make sense

Before updating the core files, it should be checked if a update is possible at all:

  • is typo3_src writeable?
  • admins only
  • warning if other backend users currently logged in
  • warning if it is an symlink
  • warning if updating from minor to a next minor (might require to run the upgrade wizard)
  • be aware of the system (*nix/windows)

The update process needs some deeper thoughs/concept.

Expected results: An indicator/notice in the backend (Toolbar/Reports) of a TYPO3 installation should show a new TYPO3-Version/Update has been released. Further there should be an update function to update from one patch level version to the next with only some clicks from the backend (like known from e.g. wordpress).

More informations:

Skill level: medium

Knowledge prerequisite: some understanding about how TYPO3 installations work (setup/installation of TYPO3 installations; separation of the typo3_src; common setups of TYPO3 with symlinks; shared TYPO3 cores in several installations)

Possible mentor(s):

Votes: 3 (increase this number by 1 if you like this idea)



Git2TER Service

Suggested by: Tobias Liebig <tobias.liebig@typo3.org> --Etobi.de (talk) 17:04, 21 February 2013 (CET)

Brief explanation: A WebService where you can register an extension key, your TER ("TYPO3 Extension repository") credentials (maybe the TER on typo3.org could extended for authentication by an API-Key (one own key per extension) instead of username and password) and your GIT-Repository-URL. The service will be triggered by a git post-commit-hook or a webhook (if it's a repository on github), whenever a version "tag" (http://semver.org) is created. The service will then pack and upload this extension to the TER. It could create also a changelog from the commit messages and use that as "TER upload comment". might help.

Expected results: Be able to release a new extension version ("upload to the TER") by just tagging it with a version number in the Git repository.

More informations:

Skill level: medium

Knowledge prerequisite: Git, understanding how the TER upload process works

Possible mentor(s):

Votes: 2 (increase this number by 1 if you like this idea)



TYPO3 Extbase projects

Extbase is a backport of some features of FLOW3/Flow to TYPO3 CMS. It's the new way to develop extensions for TYPO3.

https://forge.typo3.org/projects/typo3v4-mvc

add your idea here, use the idea/project template provided above



recursive object validation

Suggested by: Anja Leichsenring anja.leichsenring@typo3.org

Brief explanation: Extbase can validate objects while processing them from one action to the other. This works quite well in the first level. But when it comes to child objects, there is room for improvement.

Expected results: objects with child objects are valuated correctly and proper validation messages are generated.

More informations: There is an extension already able to recursive validate objects. It can be found here: lw_enet_multiple_action_forms

In the framework TYPO3 flow, that is the base of extbase, the objects can be validated recursive. It will be fine if this function can be backported. The lw_enet_multiple_action_forms validate the objects that are in a session. So it is a different solution. The best will be the backport.

Skill level: medium

Knowledge prerequisite: no prerequisite

Possible mentor(s): Markus Günther <markus.guenther@me.com>

Votes: 2 (increase this number by 1 if you like this idea)



TYPO3 Flow projects

Flow is an enterprise application framework written in PHP. It was made to enable developers to create excellent web solutions and bring back the joy of coding.

http://flow.typo3.org/

add your idea here, use the idea/project template provided above



Kickstarter for Flow/Ember.js applications

Suggested by: Manuel Mitasch, manuel@cms.mine.nu

Brief explanation:

  • Kickstart Ember.js model from TYPO3 Flow model semantics.
  • Provide a REST controller that complies to ember's standard REST adapter.
  • Provide a RoutePart for Flow that complies to ember's standard REST adapter routes.
  • Kickstart ember controllers and views for a basic ember-based user interface.

Expected results:

  • Kickstarter: From definition of a TYPO3 Flow model to a fully functional application that uses TYPO3 Flow as the server side framework and Ember.js as the client side framework.
  • The generated project should provide a best practice of how to implement a TYPO3 Flow/Ember.js application.
  • Documentation of how to use it and how generation is done.

More informations:

  • The term kickstart refers to the normal Flow semantic, thus a generation of files initiated from the command line.
  • Rens Admiraal has already done some work into the direction of dynamic model generation from TYPO3 Flow models: https://github.com/radmiraal/Radmiraal.Emberjs. For several reasons, I believe that a generation of a static file base is more reasonable for usual development scenarios opposed to a dynamic generation.

Skill level: medium

Knowledge prerequisite: Flow and Ember.js knowledge

Possible mentor(s): Rens Admiraal, rens.admiraal@typo3.org

Votes: 2 (increase this number by 1 if you like this idea)



TYPO3 Fluid projects

Fluid is a templating engine used in for TYPO3.Flow and TYPO3.Neos. It is also available in TYPO3 CMS since version 4.3.

https://forge.typo3.org/projects/package-typo3-fluid

add your idea here, use the idea/project template provided above



Cut dependencies on Flow

Suggested by: Christian Müller<christian.mueller@typo3.org>

Brief explanation: Fluid (our own template engine for TYPO3 Flow and CMS/extbase) currenctly depends on TYPO3 Flow (respective extbase) as a framework. It would be nice to be able to use Fluid as templating engine in other frameworks.

Expected results: Composer package of Fluid that doesn't have Flow as dependency and can easily be integrated into any PHP project.

More informations: [CD] Already started: https://github.com/FluidTYPO3/fluid (SF2 rendering engine and standalone) but needs a great deal of work to be completed.

Skill level: medium

Knowledge prerequisite: Composer and Flow would be good, but probably not needed.

Possible mentor(s): Christian Müller<christian.mueller@typo3.org>

Votes: 5 (increase this number by 1 if you like this idea)



TYPO3 Neos projects

The next generation content management system from the TYPO3 community is called Neos and is based on Flow. It features extensive frontend editing capabilities based on CreateJS and Aloha editor.

https://www.neos.io/

add your idea here, use the idea/project template provided above



Personalization of content

Suggested by: Mattias Nilsson <tollepjaer@gmail.com>

Brief explanation: Add a possibility to personalize content depending on different criterias. For example I add a piece of content that show a specific product. Now I want this content to only be shown to people logged in and from a specific country. My idea is to create a criteria object which can be created and the applied inside Neos to content. Also adding a backend module to handle all the different criteria types.

Expected results: Add stable foundation inside Neos to be used to personalize content.

More informations:

Skill level: medium

Knowledge prerequisite: TYPO3 Flow, TYPO3 Fluid, TYPO3 Neos

Possible mentor(s): Mattias Nilsson <tollepjaer@gmail.com>, Any Neos core developer

Votes: 2 (increase this number by 1 if you like this idea)



Improve SiteKickstarter to create boilerplate templates for common HTML/CSS frameworks

Suggested by: Christian Müller<christian.mueller@typo3.org>

Brief explanation: Allow the SiteKickstarter to create site packages that include boilerplate code and content element templates to match common HTML/CSS frameworks like Twitter Bootstrap.

Expected results: Be able to create sites with at least Bootstrap and YAML, Zurb Foundation would also be nice.

More informations:

Skill level: entry level / medium

Knowledge prerequisite: (TYPO3 Flow, TYPO3 Fluid, TYPO3 Neos) Can possibly be aquired, frontend frameworks

Possible mentor(s): Christian Müller<christian.mueller@typo3.org>, Any Neos core developer

Votes: 1 (increase this number by 1 if you like this idea)



Replace ExtDirect services with JSON based services to connect to backend

Suggested by: Christian Müller<christian.mueller@typo3.org>

Brief explanation: Currently we connect backend and frontend of Neos via ExtDirect which is a remainder of the old backend interface using ExtJS. This could be dropped and be replaced with a JSON based service on server and client side.

Expected results: Be able to drop the ExtDirect requirement of Neos

More informations:

Skill level: medium

Knowledge prerequisite: TYPO3 Flow, TYPO3 Neos, JavaScript

Possible mentor(s): Christian Müller<christian.mueller@typo3.org>, Any Neos core developer

Votes: 1 (increase this number by 1 if you like this idea)



other projects

This is a place to add e.g. generic/project-crossing ideas or ideas for other projects like TYPO3.Surf, forge.typo3.org, <youNameIt> ...

add your idea here, use the idea/project template provided above



HEAP: ViewHelper/Service Package Compiler (optionally with UX)

Suggested by: Claus Due, claus at wildside dot dk.

Brief explanation: The goal is to have an extension/package (preferably Service-based) which is capable of building new packages/extensions containing a selected list of ViewHelpers and Services as well as their dependencies, compiled into a custom namespace. Such a compiled extension would function as a library-type extension for sites. The benefit would be the smallest possible code footprint and limiting the number of exposed APIs and the lowest possible number of installed extensions.

Expected results: A working Compiler extension/package which can build other extensions based on a manifest file (which can also be built from the extension based on a list of desired included classes). The extension/package would also be able to handle dependencies (which are not part of the core), i.e. if ViewHelper Foo uses an abstract ViewHelper class Bar which is *not* part of Fluid itself, then the abstract ViewHelper class Bar would also be included and the classes which were built as a result, would use the new inheritance information.

More informations: The idea was first described in a chat log (lost), then re-iterated at http://fedext.net/overview/news/ideas-ideas-ideas.html and finally planned in greater detail at https://github.com/NamelessCoder/heap

Skill level: Expert. Involves code generation, class rewriting, namespace handling and dependency tracking.

Knowledge prerequisite: Deep PHP knowledge recommended but the logic itself is OOP and abstracted enough that the specifics are less important - but of course, knowledge always helps. Deep knowledge of Fluid also recommended but also not a hard requirement. Intermediate knowledge of TYPO3 CMS extensions and Flow packages required.

Possible mentor(s):

Votes: 2 (increase this number by 1 if you like this idea)



New user interface for the PHPUnit extension test runner

Suggested by: Oliver Klee typo3-coding at oliverklee dot de

Brief explanation: The PHPUnit TYPO3 extension currently has a back-end module. However, this back-end module currently is not very user-friendly, and the code behind it is not very maintainable. The goal is to improve this.

Expected results: The code for the BE module and the test runner needs to be moved into separate, well-structured classes and be covered with unit tests. We also need new HTML and CSS and maybe some JavaScript magic.

More informations: https://forge.typo3.org/projects/extension-phpunit/issues

Skill level: medium

Knowledge prerequisite: good HTML and CSS, object-oriented PHP, refactoring, some unit testing, design skills

Possible mentor(s): Oliver Klee (multiple mentors/suggestions possible!)

Votes: 3 (increase this number by 1 if you like this idea)