Render a TypoScript path by URL, especially useful for Ajax dispatching
Home Page: http://insight.helhum.io/post/104880845705/dont-use-eid-ajax-dispatchers-for-your-extbase
License: GNU General Public License v2.0
This extension provides a possibility to render arbitrary TypoScript paths in a given record context.
This is especially useful for rendering a plugin via an AjaxRequest
Just do a composer require helhum/typoscript-rendering to install
the latest version of TypoScript Rendering with composer.
when calling an ajax link created with typoscript_rendering that renders content containing ajax links created with typescript_rendering then the currentContent is a page instead of tt_content.
ex: ajax paging
1/ first load shows page containing a plugin that generates ajax links, ajax links will have a context of tt_content_xxx (the plugin context)
2/ clicking on the ajax links renders new content from this same plugin, output contains new ajax links
3/ these new ajax links are wrong because they have a context of page_xxx instead of tt_content_xxx
Is there a way that a plugin rendering ajax links that will recursively call the same plugin with different parameters keeps the correct context (tt_content) from the initial page call.
When you rewrite your extension parameters with realurl (using your latest realurl fork) - by adding the below example configuration - the AJAX Uris will be invalid (action & controller arguments removed in ajax uri).
The below configuration can be used with your "ajax_example" extension for typoscript_rendering.
You can reproduce this when you click the "AJAX REQUEST WITH TYPOSCRIPT RENDERING (RECOMMENDED)" example.
// Page UID where ajaxexample plugin is added
'467' => [
'ajaxexample' => [
[
'GETvar' => 'tx_ajaxexample_piexample[action]',
'valueMap' => [
// example extension actions
'list' => 'list',
'detail' => 'show',
// etc
],
// If nomatch is bypass, ....[action]=hello is removed. => Ajax Request fails
// If nomatch is removed, ajax url is www.domain.com/page1/hello/?tx_typoscriptrendering... => Ajax Request fails
'noMatch' => 'bypass',
],
[
// If you want to hide controller - But then the Parameter gets removed in the Ajax URI too. Request fails
'GETvar' => 'tx_ajaxexample_piexample[controller]',
'noMatch' => 'bypass',
]
],
],
Hi,
I've got the following warning when calling an action with typoscript_rendering :
PHP Warning: include(typo3conf/ext/typoscript_rendering/Scripts/DummyRendering.php): failed to open stream: No such file or directory in /pathToMySite/vendor/typo3/cms/typo3/sysext/frontend/Classes/Http/RequestHandler.php line 206 (More information)
I think it is due to wrong DummyRendering path on line 46 of FrontendRenderingProvider.php.
I'm using the URI ViewHelper on a (RealURL-build) page http://www.example.com/community/ .
The URI ViewHelper now builds this URL:
community/?tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_5472%22%2C%22path%22%3A%22tt_content.list.20.ppwsicommunity_communitymaincontent%22%7D&tx_ppwsicommunity_communitymaincontent%5Baction%5D=test&tx_ppwsicommunity_communitymaincontent%5Bcontroller%5D=Thread&cHash=45c1010b70afe90005acca584d9dc373
So either the "community/" needs to be removed (so that the path is truely relative), or the path must be absolute ( starting with "/community/...").
Hello,
I'm not sure if this is a typoscript_rendering issue, but i'll explain my problem:
My Extbase controller:
public function initializeUpdateViewsAjaxAction()
{
$this->defaultViewObjectName = JsonView::class;
}
public function updateViewsAjaxAction(Fiche $fiche)
{
........
........
$this->view->setVariablesToRender([
'response',
]);
$this->view->assign('response', ['status' => 'success']);
}
My template:
$.post('<f:uri.action action="updateViewsAjax" arguments="{fiche:fiche}" pageType="99" />')
.done(function(data){console.log(data)});
$.post('<t:uri.action action="updateViewsAjax" pluginName="Videogallery" controller="Fiche" arguments="{fiche:fiche}" />')
.done(function(data){console.log(data)});
Response for typeNum is "real" json : {"status":"success"}
Response for typoscript_rendering is "polluted" with html:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body><p>{"status":"success"}
</p></body></html>
This is on TYPO3 9.5
I tried with your extension ajax_example, on a TYPO3 8.7, and i got the same differences in the responses of Ajax Request with Page Type (not recommended) and Ajax Request with TypoScript Rendering (recommended)
Any idea where this comes from? Did i have some bad config somewhere or do you have the same behaviour?
Thanks!
To reproduce use this setting in TypoScript setup:
config.absRefPrefix = auto
then add an viewhelper to generate an ajax action link into a fluid template:
<tsr:uri.ajaxAction controller="ControllerName" action="actionName" absolute="1" />
Call site using https
The result will be an http-URL and not an https
A possible solution to solve this problem would be to add an additional attribute "absoluteUriScheme" to the ajaxAction viewhelper, and hands over the value (if defined) to the uri builder.
This problem exists under TYPO3 7.6.21, but maybe also under 8.7.x.
If my suggestion is acceptable, I would create a pull request.
Clicking the "Ajax Request with TypoScript Rendering" or "Hello World by TS-Rendering" link from the Ajax example extension creates an error 500 for the Ajax request. The same happens when using the "Greet! (Ajax)" button from the Ajax example.
The respective URLs are:
http://typo362.local/ajax/?tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_241%22%2C%22path%22%3A%22tt_content.list.20.ajaxexample_piexample%22%7D&tx_ajaxexample_piexample%5Baction%5D=hello&tx_ajaxexample_piexample%5Bcontroller%5D=Example&tx_ajaxexample_piexample%5Bformat%5D=json&cHash=7076269f00262e2d35e04e28711f0c1d
http://typo362.local/ajax/?tx_typoscriptrendering%5Bcontext%5D=%7B%22renderer%22%3A%20%22hello%22%7D&cHash=76796c0753ea29fbae9826e23ba46469
/ajax/?tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_241%22%2C%22path%22%3A%22tt_content.list.20.ajaxexample_piexample%22%7D&tx_ajaxexample_piexample%5Baction%5D=greet&tx_ajaxexample_piexample%5Bcontroller%5D=Example&cHash=86e0382e47309e4a68742c2feef0221e
The problem occurs independent of whether the original page is loaded using the RealURL URL or the index.php?id=12341 URL.
This problem has occurred in two independent installations of mine using TYPO3 CMS 6.2 with RealURL 2.0.14 and the ajax_example with the 7.6 compatibility PR.
The problem does not occur under the same conditions on TYPO3 CMS 7.6. It also does not occur on 6.2 when RealURL is not installed. (I haven't tried what happens when RealURL is installed, but not enabled via TypoScript.)
For comparison, these are the URLs from the 7.6 installation:
http://typo376.local/ajax/?tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_14%22%2C%22path%22%3A%22tt_content.list.20.ajaxexample_piexample%22%7D&tx_ajaxexample_piexample%5Baction%5D=hello&tx_ajaxexample_piexample%5Bcontroller%5D=Example&tx_ajaxexample_piexample%5Bformat%5D=json&cHash=40b371ee52d0ce910859b251afb2c1ee
http://typo376.local/ajax/?tx_typoscriptrendering%5Bcontext%5D=%7B%22renderer%22%3A%20%22hello%22%7D&cHash=096c0c1f810360e2b155f104479810e2
/ajax/?tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_14%22%2C%22path%22%3A%22tt_content.list.20.ajaxexample_piexample%22%7D&tx_ajaxexample_piexample%5Baction%5D=greet&tx_ajaxexample_piexample%5Bcontroller%5D=Example&cHash=5238c22d700e828ae0e61cfb2c88f0a7
Is there any way to distinguish an AJAX call to my extbase controller?
What I want to do is change fluid layout or redirect/forward depending on whether my controller was called via AJAX or "normally".
The only way I found is very low-level, looking for a GET variable:
/**
* Checks if it‘s an AJAX call
*/
protected function checkAjax()
{
$typoscriptRendering = GeneralUtility::_GET('tx_typoscriptrendering');
$this->isAjax = isset($typoscriptRendering);
}
Is there another way (e.g. in controller context or TSFE) to achieve this? This would facilitate development of hybrid applications…
From http://insight.helhum.io/post/90365109335/out-of-bound-typoscript-rendering (comments):
Is it also possible to render an action output directly inside a Fluid template with a viewhelper? The problem seems similar to what https://fluidtypo3.org/viewhelpers/vhs/master/Content/RenderViewHelper.html achieves, but v:content.render needs a tt_content-entry to work.
In other words: I mean rendering an action's output inside another action's output in the context of the current page.
this is more for documentation...
How to prevent this line at the end of JSON output? It renders the JSON invalid.
Cached page generated 2020-03-06 09:55. Expires 2020-03-07 09:55
With the test fixtures config.no_cache=1 is set and config.debug=0 is set. But that is not the case for all scenarios. The debug stuff above is appended, if a cache entry is generated and debug is on.
The controller action may be on non-cachable. But it still creates a cache entry anyways. This is probably for the page, on which the ajax request is run.
With TYPO3v9 and v2.1.0 adding
$GLOBALS['TSFE']->config['config']['debug'] = 0;
in the controller action did help. Now with TYPO3v9 and v2.2.2 it doesn't. Possibly by the use of middleware stuff??
So the only help is to create a page with an extension template and config.debug = 0. That page can - or should - be cachable. It is for propper JSON output only. And all uri.action helpers need the pageUid set accordingly.
After upgrading to Typo3 v7.2.0 from 7.0 we realized that the hook
['SC_OPTIONS']['tslib/class.tslib_fe.php']['checkDataSubmission']
might be called too late for typoscript_rendering-URLs. The request gets redirected to the pageNotFound_handling before the hook gets called. On other pages (with correct cHash) it gets called.
Do you have an idea which other hook we could use to intercept the typoscript_rendering-requests?
Hi,
I would be thankful for you to integrate this link into the README in order to make it easier on foolish people like me to install the extension via composer:
https://composer.typo3.org/satis.html#!/typoscript-rendering
If you want me to, I create a pull request, for now I just ask.
Within render() the default contextRecord = 'current' makes it call getContentObject(), which returned NULL. Maybe we messed something up with our TYPO3. We "fixed" it by adding contextRecord: 'currentPage' in the helpers. But there should always be a contentObject, right?
Hi,
I've discovered an issue, related to cached and non-cached plugin actions. If an action is cached and url to such an action is generated via h:uri.ajaxActionall is good, but as son as action get cached, no output is shown anymore - just an empty TYPO3 page with <head> and <body> section (which are not present in non-cached result).
TYPO3 8.7.1
typoscript_rendering 2.0.1
Version 2.1.0 still supports TYPO3 8 and version 2.2.0 supports only version 9. In my opinion this should be a new major release as I can't update the package any more if I'm still using TYPO3 8. I explicitly need to require 2.1.0 instead of ^2.1
In two different plugins I use the t:uri.ajaxAction ViewHelper and it works great in both of them. But as soon as the page is cached, the second usage breaks, because then the viewhelper always returns the result from the first call again. For example:
Uncached page rendering:
<div class="my-first-plugin" data-ajaxurl="?this=is&the=url&for=the&first=plugin"></div>
<!-- ... -->
<div class="my-second-plugin" data-ajaxurl="?this=is&the=url&for=the&second=plugin"></div>
Cached page rendering (notice the identical urls):
<div class="my-first-plugin" data-ajaxurl="?this=is&the=url&for=the&first=plugin"></div>
<!-- ... -->
<div class="my-second-plugin" data-ajaxurl="?this=is&the=url&for=the&first=plugin"></div>
I didn't really manage to track the problem down - I'm not sure wether typoscript_rendering is the problem here. But if you have any ideas, I'd appreciate it very much.
I use your extension for Ajax-based pagination in the ext: news form documentation. Everything works great but I have one but...
After change page in the Ajax-based pagination I need to change URL-address, for example:
typo3.local/list/page/1/
typo3.local/list/page/2/
...
Currently, this does not happen ... I see just typo3.local/list/
How to change the URL without reloading a page via an extension typoscript_rendering?
Please add PHP 7.2 compatibility to the typoscript_rendering extension.
Setup
Using TYPO3 CMS 7LTS (untested in 6.2LTS), I want to use the widget.link and widget.uri ViewHelpers in a widget template to AJAXify the widget.
Expected behaviour
I would expect the generated URL to include the arguments passed to the viewhelper as widget arguments, e.g. &tx_extension_plugin[@widget_0][currentPage]=2.
Observed behaviour
The widget argument prefix &tx_extension_plugin[@widget_0] is not added to the query string. Instead, the resulting query string contains ¤tPage=2, without the prefix.
If I change the lines responsible for fetching the argument prefix to use the getArgumentPrefix() method of the controller context's request object instead of the controller context's uriBuilder, I get the desired result.
If that fix is alright, I could prepare a pull request.
Instead of having a GET argument with a json encoded value, it might be nice to resolve to a controller/action/context with a router (similar to https://github.com/xperseguers/t3ext-routing but resolving typoscript_rendering hook instead)
Would be great to have additional ViewHelpers like
<t:link.ajaxAction action="actionName" /><t:ajaxForm action="actionName" />What do you think?
Hi,
is it possible to add additional query params to ajax action view helper? I have tried something like that:
{tr:uri.ajaxAction(action:'list',format:'html',controller:'Store',pluginName:'P1',additionalParams:'{no_cache:1,type:2}') -> f:format.htmlentities()}
but the resulting URL will always lose this params. Did I miss something here?
It would be good to have a composer.json file
The uri.cObject ViewHelper still extends TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper which has been removed in v10 (Changelog). Thus using the ViewHelper causes an error Class 'TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper' not found. The ViewHelper should extend TYPO3Fluid\Fluid\Core\ViewHelper\AbstractViewHelper instead (as described here).
[WARNING] request="b2b9....." component="TYPO3.CMS.Core.Error.ErrorHandler": Core: Error handler (FE): PHP Warning: Undefined array key 0 in .../vendor/helhum/typoscript-rendering/Classes/Middleware/TypoScriptRenderingMiddleware.php line 76
This is here: https://github.com/helhum/typoscript_rendering/blob/main/Classes/Middleware/TypoScriptRenderingMiddleware.php#L76
I'm not yet sure, how this happens, but maybe a check there would make sense anyways?
(The access log tells me the causing request was done via IPv6, so maybe on our way through our extension this somehow matters.)
In there is a call like:
list($table, $uid) = explode(':', $this->configurationManager->getContentObject()->currentRecord);
But if contentObject isn't set this "fails". Maybe you could add a fallback to pages:uid like:
if (empty($table)) {
$table = 'pages';
$uid = $GLOBALS['TSFE']->id;
}
I run into this problem when adding a custom viewhelper to ext:solr that uses TYPO3\CMS\Fluid\View\StandaloneView to render the results and looks like the "currentRecord" (tt_content element that renders the result) isn't set there.
In TYPO3 9 I get the cached result of typoscript_rendering with content type html, when logged in the content type is json.
Already tried to compensate by using a page type with configured content type with no effect.
Any clue?
Hi Helmut,
we found our requests not working with a plugin configured with flexforms and switchableControllerActions. The error description here https://wiki.typo3.org/Exception/CMS/1313855173 gave a hint on the source of the problem.
Henri
In my current project I have to disabled the pageNotFoundOnCHashError option, but your plugin requires it. I tried to comment it out in the source but realised that it doesn't work without the option. However, is there a way to make it run without the pageNotFoundOnCHashError option enabled?
The yesterday released TYPO3 6.2.27 with the new configuration option
[FE][cHashIncludePageId] = 1
breaks all links generated with this plugin.
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1467983513: ID parameter needs to be passed for the cHash calculation! As a temporary not recommended workaround, you can set $GLOBALS['TYPO3_CONF_VARS']['FE']['cHashIncludePageId'] to false to avoid this error.
When updating TYPO3 to https://get.typo3.org/release-notes/10.4.14 (or newer) this extension doesn't work properly anymore.
In TYPO3 version below 10.4.14 you set up the form according to https://www.comuno.net/blog/detail/formular-mit-typoscript-rendering-per-ajax-verschicken/.
No custom action, everything default. The form you use has a confirmation message and a mail-to-recipient finisher.
You submit the form via AJAX and get the confirmation message back in the form of this response
<div id="Contact-Formular-20">
Thank you for getting into contact! We'll get back to you as soon as possible.
</div>
Everything fine and dandy so far.
You send the form via AJAX, the response is the entire page the form is on.
The mail finisher is executed but the confirmation message finisher is not send back.
This issue can be traced back to the "security" update of TYPO3 where several form related changes were made.
Among them the refactoring of an entire class.
No clue how to mitigate this issue, though.
The extension works fine on PHP 5.6. The dependency should be raised in ext_emconf.php.
Trying to generate a xsd-file from typoscript_rendering with your extension typo3_console
php7.2 typo3cms documentation:generatexsd -t HelhumTyposcriptRenderingViewhelpers.xsd "Helhum\TyposcriptRendering\ViewHelpers"
gives me this:
[ TYPO3\CMS\Core\Error\Exception ] Warning: Declaration of Helhum\TyposcriptRendering\ViewHelpers\Widget\LinkViewHelper::render($pluginName, $extensionName, $action = NULL, array $arguments = Array, $section = '', $format = '', $ajax = true, $contextRecord = 'current ') should be compatible with TYPO3Fluid\Fluid\Core\ViewHelper\AbstractTagBasedViewHelper::render() in /my/path/httpdocs/typo3conf/ext/typoscript_rendering/Classes/ViewHelpers/Widget/LinkViewHel per.php line 171
In TYPO3 7.5 I get a 404 when sending an AJAX Request. The Response is "Reason: Request parameters could not be validated (&cHash empty)". I have read of some possible modifications in UriBuilder.php which will prevent the issue. It works, I have testet it, but I don't want to make changes in the core. Is there another fix for this problem?
Thank you so much.
I am using the AJAX based pagination like documented here:
Everything works fine. But if i have a filtered news list by categorie, the AJAX loader still loads all news.
The href of the next Link is correct:
href="/index.php?id=7&tx_news_pi1%5BoverwriteDemand%5D%5Bcategories%5D=9&tx_news_pi1%5B%40widget_0%5D%5BcurrentPage%5D=2&cHash=fe4d91b4ec30048fa42bdd310cc8675d"
But the data attribute ignores the categories parameter
data-link="/index.php?id=7&tx_news_pi1%5B%40widget_0%5D%5BcurrentPage%5D=2&tx_news_pi1%5Bcontroller%5D=ViewHelpers%5CWidget%5CPaginate&tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_36%22%2C%22path%22%3A%22tt_content.list.20.news_pi1%22%7D&cHash=3eca5db96c37c64eef0348c79f6a70b0"`
I am afraid, the AJAX Link also ignores the option excludeAlreadyDisplayedNews.
Source: #594
System:
TYPO3 9.5.11 (Not composer based)
News 7.3.1
typoscript_rendering: 2.2.2
I'm using this extension together with tx_news. I found out that the widget[@currentPage] is not taken into account when using the pagination. My link looks like this:
<a data-container="45" data-link="/newsroom/aktuelles?tx_news_pi1%5Bcontroller%5D=ViewHelpers%5CWidget%5CPaginate&tx_typoscriptrendering%5Bcontext%5D=%7B%22record%22%3A%22tt_content_45%22%2C%22path%22%3A%22tt_content.list.20.news_pi1%22%7D&cHash=8dab4ebfdf6a3f3322334c6e" href="/newsroom/aktuelles?tx_news_pi1%5B%40widget_0%5D%5BcurrentPage%5D=2&cHash=ed023c1a313f9e3d1d0f6e6e6a68fa44">2</a>
Adding the following line at line 76 in the render() Function of AjaxActionViewHelper.php solves the problem:
$additionalParams = $this->arguments['additionalParams'];
Is it possible to add the rel="nofollow" attribute to the link generated by the viewhelper?
Any plans to go ready for v11? Do you need help?
I found lots of articles that suggest to use your extension for ajax requests.
My actual use case is to mark a news as being read via an ajax call. I'm using the extension mediadreams/md_unreadnews which contains a controller action for that. They have a view helper that calls the controller action which is meant to be included on the news detail page. I need ajax, because I have no detail page. Instead all news are loaded before and an entry is displayed with javascript.
I generated following URLs in my page template:
<script>
[
'<t:uri.ajaxAction pluginName="Unread" controller="Unreadnews" action="removeUnread" />',
'<t:uri.ajaxAction extensionName="MdUnreadnews" pluginName="Unread" controller="Unreadnews" action="removeUnread" />',
'<t:uri.ajaxAction extensionName="Mediadreams.MdUnreadnews" pluginName="Unread" controller="Unreadnews" action="removeUnread" />',
].forEach(url => {
$.post(url).then(resp => console.log(url, resp));
})
</script>
I removed the first one, because it will produce an error:
Argument 1 passed to Helhum\TyposcriptRendering\Uri\TyposcriptRenderingUri::buildTypoScriptRenderingConfiguration() must be of the type string, null given
The required arguments pluginName and controller make sense for me. However it confuses me that most of the resources found on the web don't pass those arguments.
Requests to URLs 2 and 3 respond with a complete page HTML, although I temporarily edited the controller action to throw an error on the first line. I also set a debug breakpoint at the first line and therefore can see that the action is not called.
Next, I registered a plugin and implemented a controller in my own site package extension and tried to call that with ajax. The result is the same.
ext_localconf.php
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
'my_site_package',
'Unread',
[
\MySitePackage\Controller\UnreadnewsController::class => 'removeUnread'
],
// non-cacheable actions
[
\MySitePackage\Controller\UnreadnewsController::class => 'removeUnread'
]
);
.../my_site_package/Resources/Private/Templates/Page/Default.html
<t:uri.ajaxAction extensionName="my_site_package" pluginName="Unread" controller="Unreadnews" action="removeUnread" />
<t:uri.ajaxAction extensionName="MySitePackage" pluginName="Unread" controller="Unreadnews" action="removeUnread" />
Typo3 11.5.9
helhum/typoscript-rendering 2.4
Will be there compatiblity with typo3 9?
Hi,
I am using the t:uri.ajaxAction viewhelper inside a partial of a page template implemented with the extension fluidpages. I am getting the exception "Could not determine rendering location for plugin signature". That is due to the fact that in method resolveRenderingPath, $this->renderingContext->getFrontendController()->tmpl->setup['tt_content.'] return NULL (see: https://github.com/helhum/typoscript_rendering/blob/master/Classes/Configuration/RecordRenderingConfigurationBuilder.php#L111)
I guess, the changes in a7dd7d8 cause that issue.
Of course that commit states that it might be a breaking change but it does not state how to correct this. Or am I missing something out?
For the time beeing I am switching back to Version 1.0.5, where everything works as expected (the controller action get's called correctly). But I would like to update to TYPO3 8.7 in the future, so thank you in advance for your advice!
The additionalParams parameter will be ignored.
t:uri.ajaxAction(additionalParams: '{tagUid:tag.uid}', action: 'filterTags')
I think "$additionalParams = $this->arguments['additionalParams'];" in start of the render-function fix this problem
What is the plan here? Is anyone working on it?
There have been many changes to the TypoScript handling with v12, how will they affect updatability?
hello,
did anybody check the functionality from version 2.1.0 and php 7.3? Is there are issues known?
Thanks for answers.
best regards
-baggyownz
This issue is a spin-off from PR #18.
When registering a plugin using \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin with $pluginType = \TYPO3\CMS\Extbase\Utility\ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT (instead of the default type PLUGIN_TYPE_PLUGIN), the output is completely empty. (The corresponding action also never gets called.)
We most probably will be able to test this using the ajax_example extension (although I haven't checked yet).
From my debugging, I found out that PLUGIN_TYPE_PLUGIN creates a TS setup structure like tt_content.list.20.pluginname = USER while PLUGIN_TYPE_CONTENT_ELEMENT does not create it, but the typoscript_rendering extension relies on this when rendering the content element.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.