This concerns the typo3 v9 main page tree in the backend view.
I have a very large page tree with about 20.000 page entities. The query takes a long time...
In my Typo3 v9.5.5 environment, the data is retrieved in a single slow query.
How can Typo3 build the page tree in several fast queries level by level?
In the older Typo3 version (8.7.24) this also works with the method getNextTreeLevel() I think.
The core team is working on it.
There are 2 patches pending:
https://review.typo3.org/c/Packages/TYPO3.CMS/+/62329 - this patch makes page tree less bandwidth
https://review.typo3.org/c/Packages/TYPO3.CMS/+/62086 - this adds asynchronous tree rendering (it's a work in progress, as needs some tuning regarding workspaces support)
The new behaviour is like this by design in TYPO3 9.
There is a slack-channel discussing that issue: https://typo3.slack.com/messages/CK20S7EKS
And a bug-ticket on forge: https://forge.typo3.org/issues/88474
Out of that there will come a patch for the core.
The only help for now is the extensions: https://github.com/bueroparallel/bp_pagetree (discussed and reviewed in the slack channel). This speed up the tree load but just loads up to a defined nesting level what results in not all pages are automatic included in the filter results. But for now (and hopefully just for a small time period) the best solution!
Related
How can i set up multisite in typo 3 version 11.5.8?
The extensions available on the internet are for versions upto 10.
I get the error shown in the diagram below, when I try to install multisite extension from typo3 GUI
Sure, you need this extension?
TYPO3 is out-of-the-box a multisite-system:
https://typo3.org/cms/features/massively-multisite-multilingual
EXT:multisite
That extension may solve special requirements for huge multisites. What a "huge multisite" looks like in numbers is written in its doc:
We have a multisite installation with
600 website (root pages)
3.500 frontend users 400 frontend user groups
60.000 pages
250.000 content elements
3.000 categories
100.000 news
5.000 news categories
So, for this (or a similar) use-case, the backend can get slower. EXT:multisite changes some behaviors of the backend to speed up operations.
For a "normal" TYPO3 instance with a couple of sites/rootpages and fewer pages/records, the basics of TYPO3-Core will met all requirements for a multisite.
For the construction of an extensive list of links, since the source page is a thematic portal, I am looking for a suitable EXT., Which also runs under TYPO3 7.6 LTS.
it if the list of links to a permits the use of categories and multiple categorization of links is possible would be nice. should Weiterrhin the links are described not only the destination address and an alias but here should still an outline of the target page (possibly with photo) be possible.
Additional functions such as proposing links by users, reporting broken links or even a User Voting would nice additional features.
There were times the Modern Linklist, but they were no longer being developed for TYPO3 <6.x.
Is there perhaps somewhere an alternative or as one might like to vorhnandenen solutions might realize? It would be nice of course, without any programming knowledge, since I'm not a programmer.
P.S .: It is not about building a spam list but high quality links with topics relating to the original page.
As this seems to be a straight forward usage you could try to build that extension by yourself with the ExtensionBuilder.
just build up the records neccessary for your data. and let the EB generate all usefull actions: list & show, even create, edit, delete in FE would be possible.
Afterwards you just need to edit the generated fluid templates.
these links may help:
Overview
EB manual
small remark: if you want the newest code state, use the EB from git instead of TER
I`m not aware of an existing extension for it but it could be a good project to learn extbase / fluid.
You should also take a look at
typo3/sysext/fluid_styled_content/Resources/Private/Partials/Menu
and
typo3/sysext/fluid_styled_content/Classes/ViewHelpers/Menu
Fluid Content contains everything you need to create a list like that, you "just" have to combine the necessary bits and pieces.
You can do a lot with TYPO3 core functionality: there is a page type "external URL", pages can have categories by default, there are plenty of menu options (TypoScript HMENU, menu content elements, Fluid menu Viewhelpers). The Linkvalidator can periodically check all links and report broken links.
For suggestions you could add a form. Powermail for example can also store submitted info in database records, so your visitors could prepare page records (they are hidden until you make them visible).
I am facing a TYPO3 performance problem.
When I clear the cache of my website, the website waits for a user to visit pages again to cache the website. This seems to be a time consuming task and obviously this affects the performance.
So I would like to create a new extension or scheduler task which will check on a regular interval for pages which are not cached, and I want to force the pages to get cached.
So my question is: how is this possible?
There is an EXT:crawler, which allow you to index your website, including custom URLs with extnesion's parameters.
Current TER version is not compatible with TYPO3 6.2 yet, but latest git version is, so you can take it.
I am searching for a good source for understanding the userFunc = tx_extbase_core_bootstrap->run magic incantation.
The seemingly autoritative documentation on forge (http://forge.typo3.org/projects/typo3v4-mvc/wiki/Documentation) starts off with non-functional links ("400 - Invalid action parameter" from git.typo3.org) and seems dated, pointing to articles with the newest date in late 2011.
The API doc at http://typo3.org/api/typo3cms/class_t_y_p_o3_1_1_c_m_s_1_1_extbase_1_1_core_1_1_bootstrap.html#a890c7dde66b4a9462983759de4d9576a is rather sparse as to what the "TS configuration array" might contain. It also seems a little odd to list two sets of arguments and two different return informations, it is almost as if two methods were concatenated in one entry. Trying to follow the source code leads to initilializeConfiguration where it seems to hand over control to some general routine.
There is a revision e6c08008 committed "over a year ago" which claims to have updated the docs to the current URL, which is supposed to be http://api.typo3.org/extbase/current/ - but this only leads to a page with lots of classes and blank frames with no content. This is the URL that is offered in my copy downloaded a few months ago as well.
So: Where might it be that I can learn how to utilize this extbase bootstrap run method? Source code is fine, but I am not able to determine where the config is actually digested.
The Extbase bootstrap can be used to use an Extbase plugin via TypoScript. Which configuration is needed to achieve that (using TYPO3 6.x) can be seen here:
Assign plugin in typoscript
This may also be a source - the Fluid and Extbase book, unfortunately not all chapters are translated to english yet (and it is based on TYPO3 4.x):
http://docs.typo3.org/typo3cms/ExtbaseGuide/singlehtml/#bootstrap
This is covering the SwitchableControllerActions:
http://forge.typo3.org/projects/typo3v4-mvc/wiki/Dispatcher_rework
Use Extbase Plugin in TypoScript
What is to be understood by "Fluid powered TYPO3" (as stated by http://fedext.net/) and what are its benefits for the integration?
Are there other modern templating approaches for TYPO3 6.x that would be best practice to switch to now?
I don't understand the different systems that are around at the moment and I need some clarification.
The background of the question, what I am looking for:
Don't use Templavoila
Keep it simple, little coding overhead
That's why I still use markers!
Enable Custom content items in the backend like FCEs in TV
Foment "structured content" approach in TYPO3: predefined inputs and detailed rendering vs. "Anything goes" like in css_styled_content
And what about https://github.com/Ecodev/bootstrap_package ? Is it recommendable?
Although this question is fairly old by now (I didn't see it until now) and you probably already found out more about what Fluid Powered TYPO3 offers:
The features you ask for (TV-style FCEs, low coding overhead and especially the last one which is more regarding the process than the tool) are exactly what Fluid Powered TYPO3 is all about:
We provide simple ways to get page and content templates recognised by TYPO3 and made available to use by the site's content editors.
We use a common API approach (which is built on top of TYPO3's TCA/TCEforms) which you can use in both page and content templates to add custom fields (as an example: create a field to set the color of the site's header or configure a content element to have a blue background, and so on).
We use Fluid which is (as Michael already stated) a superb rendering engine.
But this is just a small part of the possibilities you have with the extensions (currently there are 20 - no, really, 20) which all provide different feature sets: there's the ViewHelper library VHS which you can use with any type of Fluid template, there's fluidpages, fluidcontent and fluidbackend which lets you place template files in a recognised path and made available to use without further hassle, there's view which lets you use overlay paths for plugin templateRootPaths (example: override only one template file from EXT:news without having to copy all template files from EXT:news). There's builder which can generate extensions, ViewHelper unit test classes, test your Fluid templates and more. There's tool which contains a range of Extbase Service-type classes that you can use in your own Extbase plugins. There's fluidwidget which is a great base for complex Fluid Widgets. You've got side utilities like *extbase_realurl* which can generate automatic realurl rules for any Extbase plugin. And there's schemaker which can let you create your own XSD schemas for your own ViewHelpers (or any version of for example fluid itself, or VHS, or flux etc.).
And there is more than this. Simply put, we offer you every tool you need to create every type of site, template or plugin. Our tools have one primary focus: efficiency.
It sounds like a huge mouthful but it isn't as complicated as it seems. Usually you will start off by using three or four of the extensions and their purpose is quite clear: Flux allows you to add the form fields which content editors use to configure content, pages and plugin instances; VHS provides a large number of multipurpose VieWHelpers to use whenever you need more than just those included with Fluid. And then one or both of fluidcontent and fluidpages which are -very- simple in that all they do is allow you to use template files as content elements or page templates.
There is quite a bit to get used to - this is true of any framework - but we spent a lot of effort on making the API the same across the line, which means anything you learn in one context (for example page templates) you can use in others (like content templates and backend modules).
If you want to save time and be consistent when creating content, pages and plugins, Fluid Powered TYPO3 (which is the umbrella name for all those twenty-something extensions) will do exactly that for you.
I can recommend taking a few minutes to read the new tour I published on fedext.net - the URL is http://fedext.net/tour/form-api.html - it primarily speaks to developers who've touched on Extbase and Fluid earlier, but even if you're used to "just" working with TYPO3 the main points should make sense.
And if you need more details than this you are welcome to find us on Github or on IRC (#typo3 on Freenet). We're always happy to help new users.
Cheers,
Claus aka. NamelessCoder
Fluid offers a much cleaner approach of dividing template logic from display logic and controller logic. Your result will be structured much better when using the possibilities fluid and the mentioned extensions like vhs provide (like layouts and partials).
The usage is actually very simple but can still be combined with the oldschool marker approach (you can do things like <f:cObject typoscriptObjectPath="lib.marks.MAIN-MENU"/>). If you need more flexibility in the backend like in TV, you (of course) have to code some things yourself.
The easiest way is to use an extension which is created by modelling it in the backend to fit your custom needs, but you can also adjust the rendering of pages and/or default content elements by using typoscript and the fields given (like pages.layout, header_layout, section_frame and so on).
So you always have the choice between detailed inputs (extbase extension objects) and using the TYPO3 default things like page properties and RTE config in combination with some typoscript magic (css_styled_content).
So as a conclusion I strongly recommend using fluid templates and additional extensions like vhs as they provide a lot of (additional) power and reusable templates while still let you use markers if you want to. Personally, I also prefer to enhance or limit the RTE in the backend in favor of writing too much special code for an FCE-like result.
BTW: There are very good autocomplete features by using the DTDs/XSDs from fedext.net in your IDE which made my template programming much faster (like 25%).