TYPO3    

Improve performance by implementing per-object caching    

TYPO3 caches content on a per page basis. A news-plugin which appears on multiple pages is currently rendered for every site separately.

By implementing a cache for content objects (includes plugins) the performance of a website could be hugely improved.

Further information

Reduce redundant cached content (sharing similar content for different usergroups)    

Conditions: TYPO3 website using several frontend usergroups (e.g. Intranet)

TYPO3 caches content for each frontend usergroup separately. If a frontend user is a member of a group for which the page has not been rendered and cached yet, the whole procedure is currently repeated.
However, since most of the time such content is the same for all groups, it should be reused.

This will result in a) less cache consumption and b) a much faster website.

Further information

OpenID authentification for the backend    

It would be a very nice feature to have and a convenient way to manage the authentication when dealing with many TYPO3 websites.

Extbase - pibase 2.0    

Add a new system extension which acts as a basis for other extensions - including backend modules and frontend plugins. The extension should provide a set of classes to support good OO programming with design patterns like MVC in mind.

Further information

Integrated RSS feed for content elements per page    

Every time when a new content element of a page is created, the RSS feed gets updated with the title and text of the content element.

Add Messaging Queue Support     

Adding a messaging queue would help so that different TYPO3 Installations can talk to each other and therefore create a live and staging setup.

RSA authentication library    

The backend authentication using MD5sums and a challenge value is considered to be highly secure.
However, in combination with SQL injections (e.g. part of a 3rd-party extension) it is possible to get backend access.

Proposed solution: Provide a RSA authentication library for client (JavaScript) and server (PHP).

memcached api    

include a memcached support for core classes.

Further information

localconf.php and SiteName    

Please implement the String regarding the Typo3 sitename
(localconf.php -> $TYPO3_CONF_VARS['SYS']['sitename'])
in the Database and not as a "text Element" in the
localconf.php like cause encoding with german umlauts can be the hell if you use a unicode linux system (that means keyboard,terminal ,file encoding & filesystem are completley based on UTF-8) and the localconf.php has a (for example) latin1 encoding.If you edit the localconf.php and the file encoding is latin1 (even if you set your preferred editor like vi to latin1 encoding) you can't change the "umlaut" (cause the low-level linux kbd driver is set to unicode) without destroying it's representation in the web browser.Then you've a mixed encoding (a-zA-z = latin1,umlaut=utf8) which you can't
convert with recode or iconv or similar tools.
It would be the best (in my opinion) to implement this completely in the database because then you have a real abstraction layer of the encoding (similar to the VFS in the Linux Kernel;)

Zap the Gremlins - 2008 edition    

Zap the Gremlins was a project that was first launched in 2005 and took two weeks. It has the main goal of getting those little bugs fixed (aka "Gremlins") that have been around for ages, but were never solved.

Zap the Gremlins consists of three phases:
1) Request for Gremlins
2) Vote procedure
3) Implementation

While steps 1 and 2 would need to be organised before the event takes place, the last step is the actual coding that would take place at Hackontest.

The project is freely scalable in terms of time and issues, and it would even be possible to have more developers working on the same project who are not participating at Hackontest.

Further information