README

TYPO3 extension gridelements

This TYPO3 extension extends the grid-based concept known from the backend layout of pages to regular content elements - the grid elements.

The grid elements are - just like backend layouts - defined by TypoScript and can thus be easily reused, extended and put under version control. It allows nesting of grids, giving the backend editor a wide range of layout possibilities. Its container nature encourages grouping content elements and assigning them specific frontend renderings, for example to display an accordion, tabs or galleries. Grid elements can be referenced to keep the content structure slim. The focus is always on the usability of the backend editor, which is supported by an advanced drag & drop handling and a granular configuration setting to define rules per grid element.

This approach is an alternative to the TemplaVoilà! template engine, which uses XML in database fields to store relations and provides less convenience across all components.

Inspiring people to share

We strongly believe in the principles of Open-source software, which is why we share this TYPO3 extension with you completely free of charge.

Still even contributors to Open-source projects have to make a living somehow, so even though you are not obliged to do so, you should consider sharing a small part of the money you might be earning with this extension in return. This way we can make sure to still provide the TYPO3 community with better extensions and services in the future.

Thanks in advance for your support.

How to support our efforts?

The Agreement

Excerpt from the coders.care blog post Service Level Agreements for TYPO3 Extensions

Enabling companies, developers and the community to join forces and thrive

There is one particular thing, that should be different to most of the variants of service level agreements provided by other open-source projects though. Having to buy a so called "enterprise" or "professional" edition of the extensions or TYPO3 itself just to become entitled for an SLA is a No-Go, since it will create two classes in the community and contradict the principles of free software implied by the GPL.

The benefit for the people agreeing to a certain service level should be defined by reliability and responsiveness, not by getting access to something, that is unavailable for the rest of the community. So there must be an agreement to still share the improved public extensions with everybody in the community while getting a personal early or immediate access depending on the level and the priority you paid for.

For developers there is the need for another agreement: They have to accept and publish fixes and changes to their extensions up to a certain degree, so the whole pool of developers can take care of the extensions covered by the SLAs. This will avoid forks.

There are several nice side effects of these agreements. For example it would reduce the number of extensions which are maintained by a single person and therefore the risk of loss when using these extensions. Due to the four-eyes principle this would increase the quality of each extension in the approved pool and at the same time reduce the amount of "me too" extensions in the TER.

There would be a powerful team of developers backing the service levels, so it would be easy to keep the approved extensions on a level with upcoming versions of the TYPO3 core. And since this would be done in close collaboration with the TYPO3 core team and the security team, core bugs and security holes affecting extension behaviour could be fixed and published much more easily as well.