Add simple API for creating new content elements
The basic idea is to add some very simple way to create new content elements that can be shared among TYPO3 installations as extensions. The scope is very similar to FCEs with the difference being that they do not require TemplaVoila, are quicker to create (no mapping) and are much more easily shared and updated (extensions instead of T3Ds).
For PHP developers, this offers a more rapid way to add custom contenet when a full extension would be overkill. This also opens up some doors for site builders who are not PHP developers. If they know Typoscript and FlexForm XML, they can add new content elements.
As far as technical details go, this ends up being a pairing of Flexforms for backend data entry and nothing but TypoScript for frontend output.
We've already made an initial attempt at doing this sort of thing in the WEC Content Elements extension  so I'll attempt to describe what we did there. It's nothing earth shattering at all, but the non-developers who have see it really like it.
1. Add a simple PHP API for telling TYPO3 about the new content element (Something like this could easily live in t3lib_extMgm)
tx_weccontentelements_lib::addContentElement($_EXTKEY, 'youtube') adds the necessary entries to the TCA and New Content Element Wizard. Locallang paths, icons, and flexform paths can all be defined but there's a simple convention that should work 95% of the time.
tx_weccontentelements_lib::addTyposcript($_EXTKEY, 'youtube') adds the TypoScript needed for frontend output. This TS is very similar to what the built in content elements use. As a quick example, see  which embeds YouTube on a page.
2. Add ability to read FlexForm data from TypoScript via getData (This could be an enhancement to tslib_cObj)
If we're writing extensions that are simply FlexForm XML and TypoScript, then we need a bridge between the two. Many people have done this before and its really pretty simple with the hooks for getData already. Perhaps its time to bring this into the core.
The syntax for our implementation looks something like this:
t3datastructure : pi_flexform->width
You can see more details at 
3. Add ability to loop over FlexForm sections (This could be an enhancement to tslib_cObj)
Once we can read simple values from FlexForms, the next obvious step is to operate on sections. This is useful for something like a slideshow content element that contains multiple images.
An example of our implementation is in line 139 and following at . We have new FFSECTION cObject that is responsible for iterating over sections and it requires a rootPath to iterate over. Within that, getData is extended with a new flexformSection keyword that reads FlexForm values relative to the root path.
4. Add ability to insert header data from a content element (This could be a pageRenderer enhancement)
In wec_contentelements we've added a HEADERDATA cObject that is an idea Olly had prior to the pageRenderer. A better solution would enhancing the pageRenderer somehow.
(issue imported from #M14015)
#1 Updated by Jeff Segars over 9 years ago
Added patch file for trunk along with a simple demo extension.
Before submitting to the core list, the patch should be split into several parts...
1) Content element helper functions in t3lib_extMgm
2) Flexform-related enhancements to tslib_content
3) Ability to add headerData from within content element (still needs more work, only a primitive solution for now).
#2 Updated by Benni Mack over 9 years ago
The approach sounds right. I'd split up the patch in three RFCs as well.
1) t3lib_extMgm seems to be the right spot, "addContentElement" is not correct for the naming, "addContentType" or "addPlugin"
2) Just make sure that it's possible to fetch from any generic XML field from getData
stdWrap.data = field:pi_flexform:ROOT->sheet1->field_myfield
3) Maybe we should also call this XMLSECTION?
#3 Updated by Jeff Segars over 9 years ago
Thanks for the feedback Benni!
For #1, the goal is to add a standard content element just like text, text w/ image, etc so I think addContentElement fits more closely than anything plugin related.
#2 - Sounds good.
#3 - My only thinking here is that the idea of sections is closely related to t3datastructure and FlexForms so there might be some value in including that in the cObject name.
Since the feature freeze for 4.4 is here and I hate to rush this through and be stuck with some bad decisions later on, I'll hold off until 4.5 and put my efforts today into reviewing other patches. This will still be available as an extension using various hooks in the core and we can revisit again later.