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.
Related
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!
TYPO3 Environment
TYPO3 v9.5.3
EXT:news (7.0.8)
EXT:indexed_search (9.5.3)
Use Composer: No
The Problem
On EXT:indexed_search result listing page, Custom extension record's slug URL are not generating. The slug only contains TYPO3 page URL.
Example; The URL should be http://thedomain.com/news/detail/announce-first-news/, but it currently only generates http://thedomain.com/news/
As per our analysis, it seems TYPO3 v9 site management's slug feature cause issue, and there could be following possible issues.
Issue #1
The major issue is, After enabling site management's slug setup, No more indexing happening for a custom extension.
Issue #2
Indexing result will lose after the page will refresh or move to another page (After clear cache data will show again).
Issue #3
If we create new records for a custom extension, then the created new records will not be indexing.
Issue #4
If anyhow, we have done the indexing and search works well, then at search result listing page, The link redirect to the main action like Listing. Because cHash is missing to each record, That's a bit strange!
Does anyone have any idea/solution? Highly appreciate your any thoughts, Thanks a lot!
Cheers,
Team NITSAN
This has been fixed with release of 9.5.5, released 4.3.2019. Check out the release notes which you can find here: https://get.typo3.org/release-notes/9.5.5
The issue for the bug is https://forge.typo3.org/issues/86994
However there has been also a regression detected which is described at https://forge.typo3.org/issues/87855 but it has already been fixed as well. The bug occurs if MYSQL strict mode is used
I have a problem whose solution is certainly very simple, but it does not come to my mind at the moment :/
I have a multi-domain TYPO3 (6.1) installation and in one of the websites I need to temporarily show only one subpage, and over the rest of the pages I will work/update so I can not delete them. It is important that someone after entering a URL or going to the page from the Google search results has not opened this page, and has been redirected to this temporary.
I've tried the mount points but something does not work ...
Please help.
You can exchange the domain-records.
Make a new page on it's own (independent from the configuration of the domain it should replace). so it is a root-page. give it a domain record and disable the domain record of the pagetree it should replace.
Be aware to change the rootpageid configuration in realurl.
You also may need a special configuration for 404 handling for this domain as the most requests will be a 404 (or better 503).
And hurry up to update your system. TYPO3 6.1 is out of service for a long time.
My Requirement is like Build in a process to lock a component during content development or updation.
For example, Vivek can still publish a page with OLT update while another author is updating another component in the same page. The previous version (that is not being updated) will be published along with vivek’s updates.
Since the User group is large & we have frequent updates we can't go for Pagelevel lock(multiple user will be working on the same Page).is der any Possible way to achieve this?... i hav tried the "FieldEditlockMode" but not works for me,am using AEM 6.1
Thanks
AEM Launches may satisfy your requirements, allowing your authors to edit components for future production releases without affecting an immediate release. Here is the documentation for 6.1:
Launches
Creating Launches
Editing Launches
Promoting Launches
We've been trying to work with Liferay CMS to create Web Content (liferay terminology). The content is versioned in the sense, each time we change the content and publish it, the version increments.
This has an impact on the URL which is publicly exposed, and we're facing the trouble of changing the URL on content change.
Is there a way of getting a published URL that reflects change in content without changing the URL?
You could use friendly urls in this case. Have a look at this post for some more info.
It doesn't appear that you are able to grab the latest journal content with any invokable URL because it requires a version number to be passed along with the request (otherwise it will just grab the first version not the last).
A work around would be to create a hook plugin that modifies the /journal/view_article_content action path with your custom implementation to return the latest article.
See Liferay's Portal Hook Plugins wiki page on how to create a hook.
Then see Mika's blog post on the specifics of overwriting a struts path.
Good Luck!